4.3 Batching and Separating Entities

Of the flow chart modules on the Basic Process panel, there are two remaining modules to discuss: BATCH and SEPARATE. The BATCH module allows entities to be grouped together into a temporary or permanent representative entity. A representative entity is an entity that consists of a group of entities that can travel together and be processed as if there was only one entity. A temporary representative entity can be split apart, by a SEPARATE module, so that the individual entities can again be processed. For a permanent representative entity, the batched individual entities cannot be separated. You can use a permanent entity when you no longer need the information associated with the individual entities within the group. You can think of a temporary entity as having an open bag that holds the batched members in the group, and a permanent entity as having a closed bag. Temporary entities are useful for modeling a manufacturing system when items are assembled and disassembled during processing. A permanent entity is useful in modeling a situation where the assembly is complete.

The batching of entities can be performed based on a number of criteria. For example, the batch might form when at least 10 entities are available. Thus, an important consideration in batching is how to determine the size of the batch. In addition, batches might be formed based on entities that have similar attributes. For example, suppose red and blue paper folders are being manufactured in batches of 5 of a specific color for sale by color. The batching of entities is also useful in synchronizing the movement of entities. As indicated above, when potential members of a batch enter the BATCH module, they wait until the batching conditions have occurred before they continue their movement with the representative entity in the model. Because of this, the BATCH module has a queue that holds the entities that are waiting to be batched. In the case of a temporary representative entity, the SEPARATE module provides the functionality to split apart the representative entity into the individual entities. The SEPARATE module also can duplicate or clone the incoming entity. This provides an additional mechanism to introduce new entities into the model, i.e. another way of creating entities. In the following examples, the BATCH and SEPARATE modules will be examined to investigate some of the rules involved in the use of these modules.

Example 4.1 Suppose production orders for tie-dye T-shirts arrive to a production facility according to a Poisson process with a mean rate of 1 per hour. There are two basic psychedelic designs involving either red or blue dye. For some reason the blue shirts are a little more popular than the red shirts so that when an order arrives about 70% of the time it is for the blue dye designs. In addition, there are two different package sizes for the shirts, 3 and 5 units. There is a 25% chance that the order will be for a package size of 5 and a 75% chance that the order will be for a package size of 3. Each of the shirts must be individually hand made to the customer’s order design specifications. The time to produce a shirt (of either color) is uniformly distributed within the range of 15 to 25 minutes. There are currently two workers who are setup to make either shirt. When an order arrives to the facility, its type (red or blue) is determined and the pack size is determined. Then, the appropriate number of white (un-dyed) shirts are sent to the shirt makers with a note pinned to the shirt indicating the customer order, its basic design, and the pack size for the order. Meanwhile, the paperwork for the order is processed and a customized packaging letter and box is prepared to hold the order. It takes another worker between 8 to 10 minutes to make the box and print a custom thank you note. After the packaging is made it waits prior to final inspection for the shirts associated with the order. After the shirts are combined with the packaging, they are inspected by the packaging worker which is distributed according to a triangular distribution with a minimum of 5 minutes, a most likely value of 10 minutes, and a maximum value of 15 minutes. Finally, the boxed customer order is sent to shipping.

4.3.1 Conceptualizing the Model

Before proceeding you might want to jot down your answers to the modeling recipe questions and then you can compare how you are doing with respect to what is presented in this section. The modeling recipe questions are:

  • What is the system? What information is known by the system?

  • What are the required performance measures?

  • What are the entities? What information must be recorded or remembered for each entity? How are entities introduced into the system?

  • What are the resources that are used by the entities? Which entities use which resources and how?

  • What are the process flows? Sketch the process or make an activity flow diagram

  • Develop pseudo-code for the situation

  • Implement the model

The entities can be conceptualized as the arriving orders. Since the shirts are processed individually, they should also be considered entities. In addition, the type of order (red or blue) and the size of the order (3 or 5) must be tracked. Since the type of the order and the size of the order are properties of the order, attributes can be used to model this information. The resources are the two shirt makers and the packager. The flow is described in the scenario statement: orders arrive, shirts made, meanwhile packaging is made. Then, orders are assembled, inspected, and finally shipped. It should be clear that a CREATE module, setup to generate Poisson arrivals can create the orders, but if shirts are entities, how should they be created? To do this, a SEPARATE module can be used to make the number of shirts required based on the size of the order. After this, there will be two types of entities in the model, the orders and the shirts. The shirts can be made and meanwhile the order can be processed. When the shirts for an order are made, they need to be combined together and then matched for the order. This implies that a method is required to uniquely identify the order. This is another piece of information that both the order and the shirt require. Thus, an attribute will be used to note the order number.

The activity diagram for this situation is given in Figure 4.44. After the order is created, the process separates into the order making process and the shirt making process. Notice that the orders and shirts must be synchronized together after each of these processes. In addition, the order making process and the final packaging process share the packager as a resource.

Activity diagram for Tie Dye T-Shirts example

Figure 4.44: Activity diagram for Tie Dye T-Shirts example

To prepare to represent this situation in pseudo-code, let’s define the structural elements of the model.

Pseudo-Code Definition
ATTRIBUTES:
  myOrderNumber // assigned to provide a unique number to each order
  myOrderType // assigned based on the type of order
  myOrderSize // represents the order size (number of shirts in the order)
  
VARIABLES:
  vOrderNumber // to count the orders and assign a unique number to each order
  
RESOURCES:
  Packager (1)
  ShirtMakers (2)

The following pseudo-code represents the activity diagram. In the pseudo-code, a variable is incremented each time an order is created and then the value of the variable is assigned to the attribute representing the order. In addition, the order type and the order size are both assigned based on the probability distribution information that was given in the problem. The parallel processing is represented by the two pseudo-code segments labeled A and B.

CREATE orders every hour exponentially
BEGIN ASSIGN
   vOrderNumber = vOrderNumber + 1
     myOrderNumber = vOrderNumber
     myOrderType = DISC(0.7, 1, 1.0, 2)
     myOrderSize = DISC(0.75, 3,1.0, 5)
END ASSIGN
SEPARATE into order and shirts based on myOrderSize
    Original: Shirts GOTO Label A order making
  Duplicates: Order GOTO Label B shirt making
END SEPARATE       
    
Label A: Order Making
SEIZE packager
DELAY UNIF(8,10) minutes 
RELEASE packager
GOTO Label C, Final Packaging

Label B: Shirt Making
SEIZE shirt maker
DELAY UNIF(15,20) minutes 
RELEASE shirt maker
BATCH myOrderSize shirts based on myOrderNumber, together
GOTO Label C, Final packaging

Label C: Final Packaging
BATCH order and shirts together, based on myOrderNumber
SEIZE packager
DELAY TRIA(5,10,15) minutes
RELEASE packager
DISPOSE: Ship order out of the system

4.3.2 Building the Model

The completed model is given in Figure 4.45 and can be found in the files associated with this chapter as TieDyeShirts.doe. Notice how there is a parallel structure in the middle of the model. This is where the orders are processed separately from the shirts. Parallel processing is quite a common pattern in simulation modeling.

Overall Tie Dye T-Shirt model

Figure 4.45: Overall Tie Dye T-Shirt model

Take the time now to drag and drop the necessary modules to your model area. Each of the modules will be discussed in what follows.The CREATE module is essentially the same as you have already seen. Open up your CREATE module and fill it out as shown in Figure 4.46.

CREATE module for Tie Dye T-Shirt model

Figure 4.46: CREATE module for Tie Dye T-Shirt model

In the ASSIGN module of Figure 4.47, a variable is used to count each order as it arrives. This unique number is then assigned to the myOrderNumber attribute. This attribute will be used to uniquely identify the order within the model. Then, the DISC() random distribution function is used to assign the type of order (Blue = 1, Red = 2) according the given probabilities. Notice the concept of blue and red are mapped to the numbers 1 and 2, respectively. This is often the case within , since attributes and variables can only be real numbers. The DISC() distribution is used to randomly assign the size of the order. This will be remembered by the entity within the myOrderSize attribute.

Assigning the order number, type, and size

Figure 4.47: Assigning the order number, type, and size

After you have filled in the dialog boxes as shown, you can proceed to the SEPARATE module. The SEPARATE module has two options Split Existing Batch and Duplicate Original. The Duplicate Original option is used here. The entity that enters the SEPARATE module is an order; however, after proceeding through the module both orders and shirts will depart from the module. Open up the SEPARATE module and notice the text box labeled # of Duplicates as shown in Figure 4.48. This field indicates how many entities will be created by the SEPARATE module. It can be any valid expression. The size of the order should be used to indicate how many entities to create. For example, if the myOrderSize attribute was set to 3, then three additional entities will be cloned or duplicated from the original entering entity. For modeling purposes, these entities will be conceptualized as the shirts. Don’t worry about the text field in the dialog box relating to cost attributes at this time.

SEPARATE module for creating shirts from orders

Figure 4.48: SEPARATE module for creating shirts from orders

When an entity enters the SEPARATE module, the original will exit along the original exit point, and the duplicate (or split off) entities will exit along the duplicate exit point. Since the created entities are duplicates, they will have the same values for all attributes as the original. Thus, each shirt will know its order type (myOrderType) and its order size (myOrderSize). In addition, each shirt will also know which order it belongs to through the (myOrderNumber) attribute. These shirt attributes will be used when combining the orders with their shirts after all the processing is complete.

Next, you should define and use the resources in the model. First you should add the resources to the model using the resource data sheet view as shown in Figure 4.49. Notice here that there are two units of capacity for the shirt maker resource to represent the two workers involved in this process.

Defining the resources for Tie Dye T-Shirts example

Figure 4.49: Defining the resources for Tie Dye T-Shirts example

The packager is used to process the orders along the original entity path. Figure 4.50 shows the dialog box for using the packager. This is similar to how the pharmacist was implemented in the drive through pharmacy model. Fill out both PROCESS modules as shown in Figure 4.50 and Figure 4.51.

Seizing, delaying, and releasing the packager

Figure 4.50: Seizing, delaying, and releasing the packager

Seizing,delaying, and releasing the shirt makers

Figure 4.51: Seizing,delaying, and releasing the shirt makers

After the order’s packaging is complete, it must wait until the shirts associated with the order are made. As seen in Figure 4.45, the orders go to a BATCH module, where they will be batched by the attribute myOrderNumber with the associated batch of shirts that exit the BATCH module named Batch Shirts. Open up the BATCH module that you previously placed and fill it out as shown in Figure 4.52. This BATCH module creates a permanent entity because the shirts do not need to be process individually after being combined into the size of the order. The entities that enter this module are shirts. They can be red or blue. The shirts enter the module and wait until there are myOrderSize other entities also in the batch queue that have the same indicated attribute. Then these entities are combined together and leave as a permanent entity.

Batching the shirts in an order together

Figure 4.52: Batching the shirts in an order together

The attributes of the representative entity are determined by the selection indicated in the Save Criterion text box field. All the user-defined attributes of the representative entity are assigned based on the Save Criterion.

First or Last

assigns the user-defined attributes based on the first/last entity forming the batch.

Product

multiplies the value of each user-defined attribute among all entities in the batch and assigns the product to the corresponding attribute of the representative entity.

Sum

performs the same action, adding instead of multiplying.

For a detailed discussion of how Arena handles the assigning of its special purpose attributes, you should refer to the help files on the BATCH module. In fact, reading the help files for this important module is extremely useful. In this example First or Last can be used. When an entity leaves the BATCH module, it will be a group of myOrderSize shirts for specified order number. The group of shirts will exit the BATCH and then enter the second BATCH module (Figure 4.53) where they will be combined with their associated order. Since the order number is unique and the batch size is 2, the result of this BATCH module will be to combine the group of shirts and the order/packaging together into a permanent entity. After the order is completed, it is sent to a PROCESS module (Figure 4.54) where it is inspected and then sent to a DISPOSE module, which represents shipping.

Batching the shirts and the order together

Figure 4.53: Batching the shirts and the order together

Using the packager to do inspection and packaging

Figure 4.54: Using the packager to do inspection and packaging

The only items that have not been discussed are the two ASSIGN modules labeled Assign 2 and Assign 3. In these modules, the animation picture of the entities is changed so that the operation of the SEPARATE and BATCH modules will be more visible in the animation. To do this, a SET is used to hold the pictures for each type of entity.

The SET module is found on the Basic Process panel as a data module. A set is a group of related (similar) objects that are held in a list within . In this instance, a set is defined to hold a list of animation pictures. Click on the SET module and use the edit via dialog option to add the picture of the blue ball and the red ball to a set with its type set to Entity Picture as shown in Figure 4.55. The order of the entries in the set matters. The first location in the set is associated with the blue ball and the second location in the set is associated with the red ball. This is done because the numbers 1 and 2 have been mapped to the type of order, Blue = 1 and Red = 2. The order type attribute can be used to index into the set to assign the appropriate picture to the entity.

Defining a picture set

Figure 4.55: Defining a picture set

In Figure 4.57, an assignment of type “Other” has been made to the Entity.Picture special purpose attribute. The expression builder was used to build the appropriate expression for indexing into the set as shown in Figure 4.56. The resulting ASSIGN module is shown in Figure 4.57. Figure 4.58 indicates the ASSIGN module for directly assigning a picture to an entity. In this case, since the shirts and packaging have been combined, the combined entity is shown as a box.

Using the expression builder to index into a set

Figure 4.56: Using the expression builder to index into a set

Assigning an animation picture based on a set index

Figure 4.57: Assigning an animation picture based on a set index

Directly assigning an animation picture

Figure 4.58: Directly assigning an animation picture

You should run the model for 8 hours and set the base time unit to minutes. When you run the model use the animation slider bar to slow down the speed of the animation. You will see in the animation how the SEPARATE, MATCH, and BATCH modules operate. For this short period of time, it took about 75 minutes on average to produce an order. You are asked to further explore the operation of this system in the exercises.

In this example, you learned that parallel processing can be easily accomplished within by using a SEPARATE module. This facilitates the creation of other entity (types) with the model and allows them to proceed in parallel. The BATCH module shows how you can combine (and synchronize) the movement of a group of entities. Finally, you saw that that also has another data structure for holding information (besides variables and attributes) called a set. A set acts as a list of similar items and can be indexed to return the items in the set. The use of the set allowed an index to be used in an animation picture set to assign different pictures to the entities as they move through the model. This is especially useful in debugging and interpreting the actions of modules within Arena.

What is the difference between a DECIDE module and a SEPARATE module? It seems like DECIDE and SEPARATE control the flow of the entities. There are two ouput ports on each of the modules. However, these modules function quite differently. The DECIDE module allows for decision-making processes in the model. One entity enters and the same entity exits on one of the output ports. For the SEPARATE module, one entity enters and potentially multiple entities exit. The original entity exits the port labeled “original” and duplicates exit the port labeled “duplicates.” A SEPARATE module can also be used to split an entity that has been batched together. The CLONE module also has similar functionality.

In the next section, we will review some statistical concepts related to comparing two random samples. Then, we will examine another modeling situation that uses the SEPARATE module and then use that model to compare two design configurations.