2.5 Elements of Process-Oriented Simulation
Chapter 1 described a system as a set of inter-related components that work together to achieve common objectives. In this chapter, a method for modeling the operation of a system by describing its processes is presented. In the simplest sense, a process can be thought of as a sequence of activities, where an activity is an element of the system that takes an interval of time to complete. In the bank teller example, the service of the customer by the teller was an activity. The representation of the dynamic behavior of the system by describing the process flows of the entities moving through the system is called process-oriented modeling. When developing a simulation model using the process-view, there are a number of terms and concepts that are often used. Before learning some of these concepts in more detail, it is important that you begin with an understanding of some of the vocabulary used within simulation. The following terms will be used throughout the text:
- System
A set of inter-related components that act together over time to achieve common objectives.
- Parameters
Quantities that are properties of the system that do not change. These are typically quantities (variables) that are part of the environment that the modeler feels cannot be controlled or changed. Parameters are typically model inputs in the form of variables.
- Variables
Quantities that are properties of the system (as a whole) that change or are determined by the relationships between the components of the system as it evolves through time.
- System State
A "snap shot" of the system at a particular point in time characterized by the values of the variables that are necessary for determining the future evolution of the system from the present time. The minimum set of variables that are necessary to describe the future evolution of the system is called the system’s state variables.
- Entity Type
A class of things (objects) that interact with the system elements. Entity types describe entity instances.
- Entity or Entity Instance
An object of interest in the system whose movement or operation within the system may cause the occurrence of events. Entities are instances of an Entity Type.
- Attribute
A named property or variable that is associated with an entity type. The value of the attribute is associated with the entity instance described by the entity type.
- Event
An instantaneous occurrence or action that changes the state of the system at a particular point in time.
- Activity
An interval of time bounded by two events (start event and end event).
- Resource
A limited quantity of items that are used (e.g. seized and released) by entities as they proceed through the system. A resource has a capacity that governs the total quantity of items that may be available. All the items in the resource are homogeneous, meaning that they are indistinguishable. If an entity attempts to seize a resource that does not have any units available it must wait in a queue.
- Queue
A location that holds entities when their movement is constrained within the system.
- Future Event List
A list that contains the time ordered sequence of events for the simulation.
When developing models, it will be useful to identify the elements of the system that fit some of these definitions. An excellent place to develop your understanding of these concepts is with entities because process-oriented modeling is predicated on describing the life of an entity as it moves through the system.
2.5.1 Entities, Attributes, and Variables
When modeling a system, there are often many entity types. For example, consider a retail store. Besides customers, the products might also be considered as entity types. The products (instances of the entity type) are received by the store and wait on the shelves until customers select them for purchase. Entities (entity instances) may come in groups and then are processed individually or they might start out as individual units that are formed into groups. For example, a truck arriving to the store may be an entity that consists of many pallets that contain products. The customers select the products from the shelves and during the check out process the products are placed in bags. The customers then carry their bags to their cars. Entities are uniquely identifiable within the system. If there are two customers in the store, they can be distinguished by the values of their attributes. For example, considering a product as an entity type, it may have attributes serial number, weight, category, and price. The set of attributes for a type of entity is called its attribute set. While all products might have these attributes, they do not necessarily have the same values for each attribute. For example, consider the following two products:
(serial number = 12345, weight = 8 ounces, category = green beans, price = $0.87)
(serial number = 98765, weight = 8 ounces, category = corn, price = $1.12)
The products carry or retain these attributes and their values as they move through the system. In other words, attributes are attached to or associated with entity types. The values of the attributes for particular entity instances might change during the operation of the system. For example, a mark down on the price of green beans might occur after some period of time. Attributes can be thought of as variables that are attached to entity types.
Not all information in a system is local to the entity types. For example, the number of customers in the store, the number of carts, and the number of check out lanes are all characteristics of the system. These types of data are called system attributes. In simulation models, this information can be modeled with global variables or other data modules (e.g. resources) to which all entity instances can have access. By making these quantities visible at the system level, the information can be shared between the entity instances within the model and between the components of the system.
Figure 2.18 illustrates the difference between global (system) variables and entities with their attributes in the context of a warehouse. In the figure, the trucks are entities with attributes: arrival time, type of product, amount of product, and load tracking number. Notice that both of the trucks have these attributes, but each truck has different values for their attributes. The figure also illustrates examples of global variables, such as, number of trucks loading, number of trucks unloading, number of busy forklifts, etc. This type of information belongs to the whole system.
Figure 2.18: Global variables and attributes within a system
Once a basic understanding of the system is accomplished through understanding system variables, the entities, and their attributes, you must start to understand the processes within the system. Developing the process description for the various types of entities within a system and connecting the flow of entities to the changes in state variables of the system is the essence of process-oriented modeling. In order for entities to flow through the model and experience processes, you must be able to create (and dispose of) the entities. The following section describes how allows the modeler to create and dispose of entities.
2.5.2 Creating and Disposing of Entities
The basic mechanism by which entity instances are introduced into a model is the CREATE module. An entity (entity instance) is an object that flows within the model. As an entity flows through the model it causes the execution of each module through which it flows. Because of this, nothing will happen in a model unless entities are created. Entities can be used to represent instances of actual physical objects that move through the system. For example, in a model of a manufacturing system, entities that represent the parts that are produced by the system will need to be created. Sometimes entities do not have a physical representation in the system and are simply used to represent some sort of logical use. For example, an entity, whose sole purpose is to generate random numbers or to read data from an input file, may be created within a model. You will learn various ways to model with entities as you proceed through the text.
Figure 2.19 illustrates the CREATE module dialog box that opens when double-clicking on the flow chart symbol within the model window. Understanding what the dialog box entries mean is essential to writing models. Each dialog box has a Help button associated with it. Clicking on this button will reveal help files that explain the basic functionality of the module. In addition, the text field prompts are explained within the help system.
Figure 2.19: CREATE module dialog box
According to the help files, the basic dialog entries are as follows:
- Type
Type of arrival stream to be generated. Types include: Random (uses an Exponential distribution, user specifies the mean of the distribution), Schedule (specifies a non-homogeneous Poisson process with rates determined from the specified Schedule module), Constant (user specifies a constant value, e.g., 100), or Expression (pull down list of various distributions or general expressions written by the user).
- Value
Determines the mean of the exponential distribution (if Random is used) or the constant value (if Constant is used) for the time between arrivals. Applies only when Type is Random or Constant. Can be a general expression when the type is specified as Expression.
- Entities per Arrival
Number of entities that will enter the system at a given time with each arrival. This allows for the modeling of batch arrivals.
- Max Arrivals
Maximum number of entities that the module will generate. When this value is reached, the creation of new entities by the module ceases.
- First Creation
Starting time for the first entity to arrive into the system. Does not apply when Type is Schedule.
The CREATE module defines a repeating pattern for an arrival process. The time between arrivals is governed by the specification of the type of arrival stream. The time between arrivals specifies an ordered sequence of events in time at which entities are created and introduced to the model. At each event, a number of entities can be created. The number of entities created is governed by the “Entities per Arrival” field, which may be stochastic. The first arrival is governed by the specification of the “First Creation” time, which also may be stochastic. The maximum number of arrival events is governed by the “Max Arrivals” entry. Figure 2.20 illustrates an arrival process where the time of the first arrival is given by T1, the time of the second arrival is given by T1 + T2, and the time of the third arrival is given by T1 + T2 + T3. In the figure, the number of arriving entities at each arriving event is given by N1, N2, and N3 respectively.
Figure 2.20: Example arrival process
A CREATE module works by scheduling a future event to occur according to the specified pattern. At each occurrence of the event, a new instance of the entity type is created. The instance is called an entity. The entity instance then executes additional modules until the entity instance hits a module that blocks its progress. More details of how this process works is provided in Section 2.10. The CREATE module continues scheduling the next creation event until the maximum number of creation events is reached or the simulation ends. A common creation process is the Poisson arrival process.
To specify a Poisson arrival process with mean rate \(\lambda\), a CREATE module as shown in Figure 2.21 can be used. Why does this specify a Poisson arrival process? Because the time between arrivals for a Poisson process with rate \(\lambda\) is exponentially distributed with the mean of the exponential distribution being \(1/\lambda\).
Figure 2.21: CREATE module for Poisson process
To specify a compound arrival process, use the “Entities per Arrival” field. For example, suppose you have a compound Poisson process where the distribution for the number created at each arrival is governed by a discrete distribution. See (Ross 1997) for more information on the theory of compound Poisson processes.
\[P(X = x) = \left\{ \begin{array}{ll} 0.2 & \quad \text{x = 1}\\ 0.3 & \quad \text{x = 2}\\ 0.5 & \quad \text{x = 3} \end{array} \right.\]
Figure 2.22 shows the CREATE module for this compound Poisson process with the entities per arrival field using the DISC(0.2, 1, 0.5, 2, 1.0, 3) discrete empirical distribution function.
When developing models, it is often useful to create one entity and use that entity to trigger other actions in the model. For example, to read in information from a file, a logical entity can be created at time zero and used to execute a READ module. To create one and only one entity at time zero, specify the Max Arrivals field as one, the First Creation field as 0.0, the Entities per Arrival as one, and the type field as Constant. The value specified for the constant will be immaterial since only one entity will be created.
Figure 2.22: CREATE module for compound Poisson process
Each entity that is created allocates memory for the entity. Once the entity has traveled through its process within the model, the entity should be disposed. The DISPOSE module acts as a “sink” to dispose of entities when they are no longer needed within the model.
Figure 2.23: DISPOSE module dialog box
Figure 2.23 illustrates the dialog box for the DISPOSE module. The DISPOSE module indicates the number of entities that are disposed by the module within the animation. In addition, the default action is to record the entity statistics prior to disposing the entity. If the Entities Statistics Collection field is checked within the Project Parameters tab of the Run/Setup dialog, the entity statistics will include VA Time (value added time), NVA Time (non-value added time), Wait Time, Transfer Time, Other Time and entity Total Time. If the Costing Statistics Collection field is also checked within the Project Parameters tab of the Run/Setup dialog, additional entity statistics include VA Cost (value added cost), NVA Cost (non-value added cost), Wait Cost, Transfer Cost, Other Cost, and Total Cost. Additionally, the number of entities leaving the system (for a given entity type) and currently in the system (WIP, work in process) will be tabulated. These cost allocations assume an activity based costing model which is beyond the scope of this chapter.
You now know how to introduce entities into a model and how to dispose of entities after you are done with them. To make use of the entities within the model, you must first understand how to define and use variables and entity attributes within a model.
2.5.3 Defining Variables and Attributes
In a programming language like C, variables must first be defined before using them in a program. For example, in C, a variable named x can be defined as type float and then used in assignment statements such as: float x; x = x + 2;
Variables in standard programming languages have a specific scope associated with their execution. For example, variables defined within a function are limited to use within that function. Global variables that can be used throughout the entire program may also be defined.
In , all variables are global. You can think of variables as belonging to the system being modeled. Everything in the system can have access to the variables of the system. Variables provide a named location in computer memory that persists until changed during execution. The naming conventions for declaring variables in are quite liberal. This can be both a curse and a blessing. Because of this, you should adopt a standard naming convention when defining variables. The models in this text try to start the name of all variables with the letter “v.” For example, in the previously discussed CREATE module examples, the variable vLambda was used to represent the arrival rate of the Poisson process. This makes it easy to distinguish variables from other constructs when reviewing, debugging, and documenting the model.
In addition, the naming rules allow the use of spaces within a variable name, e.g. This is a legal name is a legally named variable. Suppose you needed to count the number of parts and decided to name your variable Part Count. The use of spaces in this manner should be discouraged because woe unto you if you have this problem: Part Count and Part Count. Can you see the problem? The second variable Part Count has extra spaces between Part and Count. Try searching through every dialog box to find that in a model!
According to the naming convention recommended here, you would name this variable vPartCount, concatenating and capitalizing the individual components of the name. Of course you are free to name your variables whatever you desire as long as the names do not conflict with already existing variables or keywords within Arena. To learn more about the specialized variables available within Arena, you should refer to the portable document file (PDF) document Variables Guide, which comes with the installation. Reading this document should give you a better feeling for the functional capabilities of Arena.
To declare variables, you use the VARIABLE module found in the Basic Process template. The VARIABLE module is a data module and is accessed either through the spreadsheet view (Figure 2.24) or through a dialog box (Figure 2.25).
Figure 2.24: Data sheet view of VARIABLE data module
Figure 2.25: Dialog box for defining variables
Variables can be scalars or can be defined as arrays. The arrays can be either 1-dimensional or 2-dimensional. For 1-dimensional arrays, you specify either the number of rows or the number of columns. There is no difference between an array specified with, say 3 rows, or an array specified with 3 columns. The net effect is that there will be three variables defined which can be indexed by the numbers 1, 2, and 3. When defining a 2-dimensional array of variables (see Figure 2.26), you specify the number of rows and columns. Array indexes start at 1 and run through the size of the specified dimension. A runtime error will occur if the index used to access an array is not within the bounds of the array’s dimensions.
Figure 2.26: Data sheet view for 2-D variable array
When defining a variable or an array of variables, you may specify the initial value(s). The default initial value for all variables is zero. By using the spreadsheet view within the Data window, see Figure 2.24, you can easily enter the initial values for variables and arrays. All variables are treated as real numbers. If you need to represent an integer, e.g. vPartCount, you simply represent it as a variable. There is no specific integer data type.
It is important to remember that all variables or arrays are global within Arena. Variables are used to share information across all modules within the model. You should think of variables as characteristics or properties of the model as a whole. Variables belong to the entire system being modeled.
Arena has another data type that is capable of holding values called an attribute. An attribute is a named property or characteristic of an entity. For example, suppose the time to produce a part depends on the dimensions or area associated with the part. A CREATE module can be used to create entities that represent the parts. After the parts are created, the area associated with each part needs to be set. Each part created could have different values for its area attribute.
Part 1: area = 5 square inches
Part 2: area = 10 square inches
Part 1 and part 2 have the same named attribute, area, but the value for this attribute is different for each part.
For those readers familiar with object-oriented programming, attributes in are similar in concept to attributes associated with objects in languages such as VB.Net, Java, and C++. If you understand the use of attributes in those languages, then you have a basis for how attributes can be used within . When an instance of an entity is created within , it is like creating an object in an object-oriented language. The object instance has attributes associated with it. You can think of an entity as a record or a row of data that is associated with that particular object instance. Each row represents a different entity.
| IDENT | Entity.SerialNumber | Size | Weight | ProcessingTime |
|---|---|---|---|---|
| 1 | 1001 | 2 | 33 | 20 |
| 2 | 1002 | 3 | 22 | 55 |
| 3 | 1003 | 1 | 11 | 44 |
| 4 | 1001 | 2 | 33 | 20 |
| 5 | 1004 | 5 | 10 | 14 |
| 6 | 1005 | 4 | 14 | 10 |
Table 2.14 presents six entities conceptualized as records in a table. You can think of the creation and disposing of entities as adding and deleting records within the model’s “entity table.” The column IDENT represents the IDENT attribute, which uniquely identifies each entity (instance). IDENT is a special pre-defined attribute that is used to uniquely track entities currently in the model. The IDENT attribute is assigned when the entity is created. When an entity is created, memory is allocated for the entity and all of its attributes. A different value for IDENT is assigned to each entity that currently exists within the model. When an entity is disposed, the memory associated with that entity is released and the values for IDENT will be reused for newly created entities. Thus, the IDENT attribute uniquely identifies entities currently in the model. No two entities currently in the model have the same value for the IDENT attribute. Think of IDENT as the primary key into the entity record table.
Every entity in the model has a unique row in the table to store its attribute values. Entity.SerialNumber is just one of those attributes. The Entity.SerialNumber attribute is also a number assigned to an entity instance when it is created; however, if the entity is ever duplicated (cloned) in the model, the clones will have the same value for the Entity.SerialNumber attribute. When an entity is cloned (duplicated) all attributes except IDENT are duplicated. Entity.SerialNumber will not be unique when entities are cloned. IDENT can be used to uniquely identify an entity. Entity.SerialNumber can be used to identity entities that have the same serial number. In other words, all duplicates of an entity instance. In the table, there are two entities (1 and 4) that are duplicates of each other. The duplication of entities will be discussed later in this chapter. The size, weight, and processing time attributes are three user defined attributes associated with each of the entities. To find a description of the full list of pre-defined entity attributes, do a search on "Attributes and Entity-Related Variables" in the Help system.
When you define a user-defined attribute, you are adding another “column” to the “entity table.” The implication of this statement is very important. The defining of a user-defined attribute associates that attribute with every entity type. This is quite different than what you see in object-oriented languages where you can associate specific attributes with specific classes (types) of objects. Within Arena, an entity type is an entity type. You can specify attributes that can allow you to conceptualize them as being different. This is conceptually defining the attribute set for the entity type that was previously mentioned. For example, you might create entities and think of them as parts flowing in a manufacturing system. Within a manufacturing system, there might also be entities that represent pallets that assist in material handling within the system. A part may have a processing time attribute and a pallet may have a move time attribute.
| IDENT | Type | Size | Weight | MoveTime | ProcessingTime |
|---|---|---|---|---|---|
| 1 | 1 | 2 | 33 | ——- | 20 |
| 2 | 1 | 3 | 22 | ——- | 55 |
| 3 | 2 | 1 | 11 | 23 | ——- |
In Table 2.15, the type attribute indicates the type of entity (part = 1, pallet = 2). Notice that all entities have the move time and processing time attributes defined. These attributes can be used regardless of the actual type of entity. In using attributes within Arena, it is up to the modeler to provide the appropriate context (understanding of the attribute set) for an entity instance and then to use the attributes and their values appropriately within that context.
There are two ways to distinguish between different types of entities. Each entity has a pre-defined attribute, called Entity.Type, which can be used to set the type of the entity. In addition, you can specify a user defined attribute to indicate the type of the entity. Arena’s on-line help has this to say about the Entity.Type attribute:
Entity.Type This attribute refers to one of the types (or names) of entities defined in the Entities element. Entity type is used to set initial values for the entity picture and the cost attributes. It is also used for grouping entity statistics (e.g. each entity’s statistics will be reported as part of all statistics for entities of the same type).
The Entity module in the Basic process panel allows you to define entity types. The dialog box shown in Figure 2.27 shows the basic text fields for defining an entity type. The most important field is the "Entity Type" field, which gives the name of the entity type. The Initial Picture field allows a picture to be assigned to the Entity.Picture attribute when entities of this type are created. The other fields refer to how costs are tabulated for the entity when applying activity based costing (ABC) functionality. This functionality is discussed in Section D.4.
Figure 2.27: Entity module dialog box
The advantage of using the Entity.Type attribute is that some automated
functions become easier, such as collecting statistics by entity type
(via the DISPOSE module), activity based costing, and displaying the
entity picture. Using the Entity.Type attribute makes it a little more
difficult to randomly assign an entity type to an entity, although this
can still be done using the set concept, which will be discussed in a later chapter.
By using a user defined attribute, you can change and interpret the
attribute very easily by mapping a number to the type as was done in
Table 2.15.
Now that a basic understanding of the concept of an entity attribute has been developed, you still need to know how to declare and use the attributes. The declaration and use of attributes in is similar to how variables can be declared and used in Visual Basic. Unless you have the Option Explicit keyword specified for Visual Basic, any variables can be declared upon their first use. For attributes in this also occurs. For example, to make an attribute called myArea available simply use it in a module, such as an ASSIGN module. This does cause difficulties in debugging. It is also recommended that you adopt a naming convention for your attributes. This text uses the convention of placing “my” in front of the name of the attribute, as in myArea. This little mnemonic indicates that the attribute belongs to the entity. In addition, spaces within the name are not used, and the convention of the concatenation and the capitalization of the words within the name is used. Of course, you are free to label your attributes whatever you desire as long as the names do not conflict with already existing attributes or keywords within Arena. Attributes can also be formally declared using the ATTRIBUTES module. This also allows the user to define attributes that are arrays. Using the ATTRIBUTEs module is the preferred method for defining attributes because comments can be provided for the attribute and pre-defining attributes facilitates their selection within drop down text fields or when using the expression builder. This approach tends to avoid annoying syntax errors.