First Model: Description
First Model: Description
Description
In this model we will look at the process of manufacturing three types of products in a factory. In our
simulation model, we will associate an itemtype value with each of the three product types. These three
types all arrive intermittently from another part of the factory. There are also three machines in our model.
Each machine can process a specific product type. Once products are finished at their respective
machines, all three types of products must be tested at a single shared testing station for correctness. If
they have been manufactured correctly, they are sent on to another part of the facility, leaving our
simulation model. If they were manufactured incorrectly, they must return to the start of the simulation
model to be re-processed by their respective machines. The goal of the simulation is to find where the
bottleneck is. Is the testing machine causing the three other machines to back up, or is it being starved
because the three machines can't keep up with it? Is the amount of buffer space before the tester
important?
Steps
Step 1: Start FlexSim
Step 2: Select Units
Step 3: Create the Objects
Step 4: Connect the Objects
Step 5: Define the Inter-Arrival Time
Step 6: Assign an Itemtype and a Color
Step 7: Define the Queue's Maximum Content
25
Step 8: Define Queue1's Routing
Step 9: Define Process Times
Step 10: Define Queue2's Maximum Content
Step 11: Define Tester's Process Time
Step 12: Define Tester's Routing
Step 13: Reset and Run the Model
Creating a Dashboard
Randomness
Results
26
Step 3: Create the Objects
Create a Source, two Queues, four Processors, and a Sink in the model. Name and place them as
shown below (note that one of the Processor objects will be the "Tester").
To review the process for creating objects in FlexSim, refer to the Creating An Object section of the
Interacting with FlexSim page. To review how to rename an object, refer to the Naming An Object
section.
27
Step 4: Connect the Objects
To review how to connect objects, refer to the Connecting Objects section of the Interacting with FlexSim
page.
Notice the Tester object has an output connection to Queue1. This will allow rejected items to be sent back
to the start of the process.
28
The next step is to change the properties of the different objects so they will behave as specified in the
model description. We will start with the source and work our way to the sink.
Each object has its own properties window through which data and logic are added to the model. Double-
clicking on an object accesses the object's properties window.
For this model, we want three different product types to enter the system. To do this, each flowitem's
itemtype will be assigned an integer value between one and three using a uniform distribution (see FlexSim
Concepts for more information about itemtypes). This will be accomplished using the source's exit trigger.
1) Click on the Source to bring up its properties in the Quick Properties window.
29
2) Double-click on the Source to bring up its Properties window.
30
o Set Stream to 0.
If you edited the Inter-Arrival time through the Quick Properties window, you'll need to open the
Source's Properties window in order to perform Step 6. This can be done by clicking the More
Properties button under the General Properties section of the Quick Properties.
Click the Triggers tab. Add a function (press the button) to the OnCreation trigger. Select Set Item
Type and Color from the list. A popup will appear.
31
The duniform distribution is similar to a uniform distribution except that instead of returning a real number it
will only return whole numbers. Click OK to apply the changes and close the window.
32
Step 8: Define Queue1's Routing
Click the Flow tab.
Under Output, select By Expression from the Send To Port drop-down list.
A popup with suggested expressions will appear. The default expression for By Expression is
getitemtype(item) . This will send type 1 to port 1, type 2 to port 2, and so on. Click anywhere outside
popup to close it, and then click OK to apply the changes and close the window.
33
Step 9: Define Process Times
The next step is to set the processing times for the three processors.
As described for Step 7, the Process Time can be set through the Quick Properties window by clicking on
the object once in the 3D view.
34
Step 10: Define Queue2's Maximum Content
Follow Step 7 to change Queue2's Maximum Content to 10000.
Click the Flow tab. Select By Percentage from the Send To Port list.
35
Use the to add another field.
Fill the fields to match the picture below.
This means that 80 percent of the products (the correctly manufactured products) will be sent through
output port 1 to the Sink, and 20 percent (the incorrectly manufactured products) will be sent through
output port 2 back to the first queue.
One more thing we might want to do is visually distinguish items that have already been through the testing
station and have been sent back to the first queue.
Click the Triggers tab. Add a function (click the button) to the OnExit trigger and select the Set
Color option. Select colorblack(item) from the list.
36
Press OK to close the Properties window.
Click on the button, located at the upper left-hand corner. Resetting the model sets all system
variables to their starting values and clears any flowitems present in the model. Resetting is also
necessary any time new connections are made between objects.
Click the button, located right next to the reset button.
The model should now start to run. Flowitems should move from the first queue, into one of the three
processors, then to the second queue, into the testing station, and from there to the sink, with some being
re-routed back to the first queue. Re-routed items will be colored black.
37
To stop the model, press the button at any time. Later you will learn how to run a model for a
specified time, and for a specified number of iterations. Running a model more than once is important
when statistical distributions have been used in the model definition.
To speed the model up or slow it down, move the Simulation time slide bar at the top of the window to the
right or left. Alternatively, you can press the Ctrl + Down Arrow and the Ctrl + Up Arrow to increase or
decrease the run speed.
Moving the slide bar changes how fast the simulation time proceeds relative to real time. It has no effect on
model results.
We have now completed building the model. Let's look at some of the statistics the model generates.
Creating a Dashboard
Finding the Bottleneck
In the model description, we said that we wanted to know where the bottleneck was in the system. There
are several ways to determine this. First, you can simply examine the visual size of each queue. If one
queue in the model consistently has many products backed up in it, then that is a good indication that the
processing station(s) that it feeds are causing a bottleneck in the system. In running this model, you'll
notice that the second queue very often has a lot of products waiting to be processed, whereas the first
queue's content is usually 20 or less, as shown below.
Another way of finding the location of a bottleneck is by examining the state statistics of each of the
processors. If the three upstream processors are always busy, while the testing station is often idle, then
the bottleneck is likely to be at the three upstream processors. On the other hand, if the testing station is
always busy, while the upstream processors are often idle, then the bottleneck is probably at the testing
station.
Evaluating the New Configuration
38
Run the model for at least 50,000 seconds. Notice first that Queue2 is now almost always empty, whereas
the Queue for the 3 processors backs up quite often. Let's use the dashboard to compare the two testers
side by side.
From the Statistics menu at the top, select Dashboards > Add. The Dashboard window will appear.
Drag the icon into the Dashboard window. This should bring up an object selection window.
39
Click the Select button on the popup to finalize your selection. Then click OK. A blank chart should
appear in the dashboard.
Reset and run the model again. The graph in the Dashboard will dynamically update.
The reason that these two are different is because the tester queue sends to the first available tester.
Whenever both testers are available, a product will always go to the original tester, since it is the first
available. Products only go to the second tester if the original tester is already busy. Thus the original
tester gets higher utilization than the second tester.
Now add the other three processors to the State Bar graph.
Double-click on the graph in the dashboard and the same object selection dialog opens.
Select Processor1, Processor2, and Processor3 from the selection list. Whatever you select is added to
the previous contents of the graph.
Reset and run the model again. Now all five processors can be compared side by side.
40
We have effectively moved the system bottleneck from the tester to the three upstream processors. Also,
by increasing throughput by 15% and consequently adding another tester, we have significantly decreased
the utilization of each tester. Whether this is a good decision depends much on the cost it would take to
add a second tester. Since the bottleneck is in the 3 processors, in order to further increase throughput,
and thus increase the utilization of each tester, we would need to add more processors. Again, there is a
cost/benefit analysis to this decision.
Try changing any parameter (like a processor's process time) and watch its effect on the model. Even
small changes can dramatically change the overall model.
Randomness
Let's do some more testing before we actually decide to add another tester. Since on average one product
arrives from the source every 5 seconds, and on average one product goes to the sink every 5 seconds,
why should the queue accumulate at all? Products are leaving just as fast as they arrive, so there shouldn't
be any accumulation in the system.
The reason the queue accumulates is because of randomness in the system. Yes, on average a product
arrives every 5 seconds, but this arrival rate is according to an exponential distribution. For an exponential
distribution with a mean of 5, most of the time products will actually arrive at a faster rate than every 5
seconds. But every once in a while there will be a long drought where no products arrive at all. In the end it
evens out to an average of 5 seconds, but usually products arrive faster, and thus will accumulate in the
tester's queue, since the tester is the bottleneck.
What if, in our facility, products actually arrive at a more predictable rate, instead of by the somewhat
unpredictable exponential distribution? Will the queue size generally stay at a lower level? Let's test it.
41
Once set, Reset and Run the model again.
If you do not still have Queue2's properties window available, open it again by double-clicking on Queue2.
Continue to run the model. You will notice here that the queue's maximum content doesn't go up as high.
Usually they won't go much higher than 50 or 60 now, whereas before they would sometimes get up to 150
or 200. This is a significant difference caused by simply changing the type of randomness in the model.
Higher Throughput
Now suppose that the facility does indeed need to increase the throughput rate of this system by 15%. This
equates to a change of the mean inter-arrival time of the source from 5 seconds to 4.25 seconds. Since the
tester was already at 100% utilization, we will obviously need to add a second tester to the system. Let's
make this change.
Change Tester2's Sent To Port to By Percentage Enter the same parameters as you did for Tester1.
Add an OnExit trigger to change the color to black, just like the other Tester.
Now that you have finished making the changes, Reset and Run the model again.
42
Results
By creating a model that simulates our system, we have clearly determined what effect certain decisions
will have on the system. We can now use the information we have gathered from the simulation to make
better informed decisions for the future of the facility.
With this simple model, many of the same conclusions could have been made through mathematical
models and formulas. However, real systems are often much more complex than the model we have just
built, and are outside the scope of mathematical modelling. By using FlexSim simulation, we can model
these real-life complexities, and examine the results just as we have done in this model.
FlexSim also gives your simulations much more visual appeal. It is much easier to convince a management
team of the wisdom in a decision if the management team can see the effects of that decision in a virtual
3D world. This world is created automatically as you build your FlexSim models.
What Next?
Now that you have become familiar with FlexSim and the use of simulation, we suggest that you go
through the other tutorials included in FlexSim Help.
43