Lesson 5: Attributes, Variables and Action Logic
Attributes are placeholders associated with an individual entity. Its value cannot be seen or changed by any other entity. An attribute describes an entity such as name, size, color, type, condition, etc. They can be either numeric values or character descriptors (single word descriptions). Attributes follow an entity as it moves through a model and can’t be changed globally by events that occur elsewhere in the model. All entities have 5 system defined attributes including Name, Cost, ID, VATime, and CycleStart. You may also create user-defined attributes. Attributes are often used to control action logic or to make routing decisions in the model. User-defined attributes are not displayed in the output reports. It is recommended that you begin all attribute names with “a_”. For example, a_Type, a_Color, a_Weight. That way they are easily recognized when reading your action logic.
Variables are placeholders for either numeric values or character descriptors (single word descriptions). They may be used to describe or track activities and states in the system such as the number of entities that have completed a particular activity, day of the week, hour of the day, etc. Variables are global in nature. That means any entity can view them or assigned a value in the Action tab of the properties dialog at any location. Variables are shown in the output reports and may be used to export modeling results to Excel. It is recommended that you begin all user-defined variable names with “v_”. For example, v_Count, v_Completed, v_BatchSize. That way they are easily recognized when reading your action logic.
ProcessModel allows you to design custom behavior in your model by writing simple but powerful logic statements. Action logic allows you to go beyond the normal property fields to determine how an entity is processed. Examples would include assigning values to attributes or variables, or performing a test using an If…Then statement.
Creating Attributes and Variables
You create an attribute by clicking the Insert menu and selecting Attributes & Variables. Then click New and enter the attribute name.
To create a variable click the Insert menu and selecting Attributes & Variables. Click the Global Variables tab, click New and enter the variable name.
Customizing with Action Logic
Let’s begin customizing our model behavior by adding a variable which will track the number of entities in our model at any given time.
Open the Lesson 1 – Call Center model. Create a variable by clicking the Insert menu and select Attributes & Variables. Click the Global Variables tab. Click New and enter the name v_Count in the Name field.
Next we need to write some action logic to use the v_Count variable.
Double click the arrival route (between the Call entity and the Take Call activity). Click the Action tab. In the window on the left, type Inc. That is a system statement which mean increment. Then click the Filter drop down list on the right and select the Variable option. This will display the name of all variables you have created using the Insert / Attributes & Variables option. With v_Count highlighted, click the Paste button.
Even though you can just type v_Count rather than selecting it from the filter list, selecting from the list eliminates typing errors, and can save time when you have defined many variables and attributes but have trouble remembering exactly how you spelled each one.
Inc v_Count is equivalent to writing v_Count = v_Count + 1, just shorter.
Now that we are increasing v_Count each time an entity enters the model, we need to decrease or decrement v_Count when each entity leaves.
Double click the 75% route leaving Take Call, then click the Action tab. Repeat the steps to create the action logic on the arrival route, except use Dec (for decrement) instead of Inc.
Since entities also leave the model after the Return Call activity is complete, we need to add an exit route and add the needed action logic.
To save a little typing time, click and drag your mouse over the Dec v_Count action logic. Then hold down the Ctrl key on your keyboard and press C to copy the text. Now add an exit route to the Return Call activity by hovering your mouse over the Return Call activity. Then drag your mouse to the right. Click the Action tab. Click your mouse in the Action window. Hold down the Ctrl key on your keyboard and press V to paste the action logic from the Windows clipboard.
To get a longer look at the process lets increase the simulation run length to 100 hours.
Click the Simulation menu and select Options. Change the Run Length to 100 hours.
Click Close. Now save your model as Lesson 5 – In-Process Count. Simulate the model and view the results. In order to create a Time Series plot of the counter variable, press the icon (Generate a time series plot) in the report toolbar.
In the Value window, double click the v_Count Value History item to add it to the Selected Values window on the right. Then click OK.
We created a variable to track the number of entities in the system at any given time. We then added action logic to increment that variable each time an entity entered the model, and used similar action logic to decrement the variable at each location where entities left the model. By using the Time Series Plot option in the output report, we now can see the trend of in-process entities. The increasing slope of the plot shows us that more entities are arriving in the system than it is able to process.
To learn about all the functions and statements allowed in ProcessModel, see Section 3.11 of the ProcessModel User’s Guide.
Let’s try adding a second Level 2 resource to see what happens to the plot.
Double click the Level 2 resource. In the Quantity field, enter 2. Save the model as Lesson 5 – In-Process Count 2. Then simulate the model and generate the time series plot as you did before.
Output Summary Report
A business decision is seldom made on a single factor such as in-process inventory. Consider some of the other things you need to evaluate before making a decision about the success of your change. Let’s look at another output report, the Output Summary.
Return to the modeling window by closing the Output Detail report. Then click in the ProcessModel toolbar, or click the View menu and select Output Summary. Click the Total Cost option on the left. Review each of the reports to see how the summary of
The Output Detail report (standard report shown following a simulation) uses an ABC costing method which only shows direct value added costs. To see the total cost of the simulation you must view the Output Summary report which includes all overhead costs such as unused resource costs. That total cost is then distributed across all entities leaving the process. Therefore, the average entity cost shown in the Output Detail report may be different than the cost shown in the Output Summary report.
1. Is it better from an in-process inventory perspective to have a 2 nd Level 2 resource?
2. What are the factors involved in deciding if it was cost effective to add a 2 nd resource?
3. Do you feel it is cost effective to add a 2 nd resource?
4. Are there better alternatives?
There are many functions and statements that can be used in ProcessModel to achieve a high degree of customization. Let’s just look at a couple of other examples.
Install the model package Lesson 5 – Route Distribution.
The Process2 activity utilizes 2 entity attributes in action logic to distinguish between the two entity types and route them accordingly. NAME is a system defined attribute given to all entities. In this model, a_Route is a user-defined attribute used on conjunction with the Conditional routes exiting Process2. All Item2 entities are to be routed to Process3 and are assigned an a_Route value of 1. The condition of the route leading to Process3 requires that a_Route must equal 1, therefore all Item2 entities will select that route. If the entity name is not Item2, a user-defined distribution is used to assign the a_Route value. 40% of all Item2’s are to be routed to Process4, and 60% to Process5.
Remember that a Percentage route must use a numeric constant in the Percent field. Distributions, attributes, and variables may not be used. However, if your routes are selected based on a percentage which may vary, Conditional routes can be used instead. The model above is only one example of using randomness in a percentage route selection.
Rework is a common part of just about every industry. This next example demonstrates the concept that each time an entity goes through rework, the odds of it needing additional rework diminishes.
Install the model package Lesson 5 – Rework Loop.
When a Card arrives, the a_LoopCount attribute is initialized to a value of 0. At Inspect, that attribute is incremented in order to track how many times the entity has been inspected. The 1 st time, there is a 50% chance it will require rework and the a_OK attribute will be set to 0. If the Card is ready to ship, a_OK is set to 1. The 2 nd time through the loop, 80% of the time it is ready for shipping. The 3 rd time, 90% of the time it is ok. Cards are always ok the 4 th time through.
If you need to execute multiple lines of action logic based on the result of an IF…THEN statement, you must enclose those statements within a BEGIN…END block. For example
If a_PatientType = Critical Then
Get Nurse And Doctor
5. In the Route Distribution model, if you changed the condition on the route leading to Process3 to “Name = Item2”, how would you change the action logic in Process2 to make the model give the same results as it does now?
6. Since user-defined attributes are not shown in the output report, how can you report on the number of times cards were reworked?
Continue to Lesson 6: Shifts