Intro to Arena. A Third Simulation. Model 3. We add more features to Model 2, also from Ch. 5 of Simulation with Arena.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
A Third Simulation
We add more features to Model 2, also from Ch. 5 of Simulation with Arena.
The justification for adding features is quite simple: the first model was a “first prototype”, and we have just gone through the first verification/validation cycle. At the end, we concluded that the system actually operates on two shifts a day, and that the second shifts has two operators assigned to the Rework operation, thus easing the bottleneck problem we encountered.
Another problem we have to resolve is the fact that the Sealer breaks down, rarely enough, and for short enough times that our first approximation could ignore it, be we now must incorporate it in the model. From extensive records, we could determine that the mean uptime between failures was 120 minutes, exponentially distributed, and that the repair time had a mean of 4 minutes, also exponentially distributed.
How do we add all this to the model?
Our run length of 2000 minutes is equivalent to a little more than 4 shifts (60*8 = 480 minutes/shift). We now need to model the shifts explicitly, since the number of operators changes from one shift to the next. This will be done by adding a “Resource Schedule” to the Rework resource.
The sealer failures are shift independent and will be modeled using a Resource Failure or Downtime.
Let’s start with the “Inspector” for Rework - double-click to open the dialog. Notice that “Capacity” has the value 1: this means that there is only ONE copy of the resource available, so that only one part can be worked at one time. Since we will have two operators during the second shift, we must change that.
When you choose “Schedule” from the Capacity Type list, you have two new fields appearing. The second provides you with the scheduling options: Ignore, Preempt and Wait. If a capacity decrease is scheduled and the resource is idle, all three options cause the resource to
become inactive immediately. If the resource is in use, the response differs. If “Ignore” is chosen, the resource capacity is decreased immediately. When the resource is released by the
entity to which it is allocated, it is placed in an inactive state. It COULD happen that a request to increase capacity arrives before the resource is released - in this case the increase occurs immediately. The effect is that the capacity change may never be “seen” in its effects.
The “Wait” option will wait until the entity releases the resource before starting the capacity decrease.
The “Preempt” option preempts the resource by taking it away from the entity controlling it, starting the capacity reduction, and holding the entity in an internal (to Arena) storage area until the resource becomes available. At that point the entity will be reallocated the resource and will continue processing.
When do we use each option? There are no absolute rules but a suggestion would have us use the “Ignore” option if the duration of the scheduled capacity decrease is long when compared to the processing time. We would use the “Wait” option if the time between capacity decreases is large compared to the duration of
the decrease. The use of the “Preempt” option should be clear.
In the Server Data area, in the Schedule window type:
Now click on the “Schedule” button at the bottom of the area. A new “Schedule” dialog will appear, with <End of list> on it.
Click on Add, to come up with a further dialog.
Make sure you have: Capacity 1, Duration 480
After clicking on Add, repeat the Add, but make sure you now have Capacity 2, Duration 480. You should have the configuration in the next slide:
Make sure that “Duration” has a value. If you leave the field empty, the system will interpret the value as infinity and it will never change after being set.
As long as you have positive entries, the simulation will repeat through
the values you have chosen.
We now turn to modeling the Sealer failures. Click on the Sealer, click on the “Resource” button to get the dialog at the right. In the “Failures” area click on Add. Fill in as indicated on the slide. The Uptime and
Downtime follow the distributions we claim to have gleaned from historical data. Note we chose Time-based rather than Count-based failure. Count-based would depend on the number serviced… Notice that we choose “Wait”: consistent with the schedule choice.
The next thing we will do is save more statistical data - the defaults are useful, but not all that we may need.
The Common panel has a Statistics module, which allows us to define additional
statistics to be collected. Notice the five areas, denoting five types of statistics. Let’s assume we are interested in number of parts in various queues (Prep B, Sealer, Rework areas), and cycle times.
Let’s begin by setting up collection of Time-Persistent (or Discrete-Change) statistics. Click on the Time-Persistent Add button.
Check the Queue button in the Data Object area. The dialog will change to the one on the right. Fill in:
Queue Name Part B Prep_R_Q
Save Observations to File
OS File Name in Double Quotes (appears after check is done)
Add two more queue statistics:
Queue Name Sealer_R_Q
Save Observations to File Check
OS File Name in Double Quotes “Sealer_Q.DAT”
Queue Name Rework_R_Q
Save Observations to File Check
OS File Name in Double Quotes “Rework_Q.DAT”
Add a Tally
Save Observations to a File
OS File in Double Quotes
And you end up with a dialog that looks like the one on the right.
1) Go to the help files and learn how to use the Output Analyzer.
2) Go to the help files and learn how to use the Input Analyzer.
What can you say about the “fit” of the file partbprp.dst to the Normal Distribution? What is the mean-square error?
3) Modify Exercise 1 of Model 2 by adding agent breaks. The 16 hours are divided into 8-hour shifts. Agent breaks are staggered, starting at 90 minutes into each shift. Agent lunch breaks (30 minutes) are also staggered, starting 3 1/2 hours into each shift. Compare the results of this model to the result withotu agent breaks.
4) Using the model from Exercise 2 of Model 2, set the inter-arrival-time distribution to exponential and the process-time distribution for each Process to Normal, with a mean of 9 minutes. Setting the standard deviation of the normal distribution to values of 1, 2 and 3, make three different runs of 10,000 minutes each and compare the results.