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.
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.
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.
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.
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
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
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.
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 (
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.