The text below contains an example how to model the mine example. Please note that multiple answers are possible, and this is just one possibility.
1. Start by thinking about the "form" of the model
As there are clearly multiple locations where
activities take place, with transportation in-between, the most logical form of
the model is using stations between which transportation can take place. There
are at least four stations: the ElevatorTop, ElevatorBottom, ShaftEnd,
and Plant. Transportation between ElevatorTop and ElevatorBottom
is done by elevator, between ElevatorBottom and ShaftEnd by truck,
and between ElevatorTop and Plant by conveyor belt. It is clear
that we have to create entities called miners who go down the elevator,
take a truck, do the mining activities, and go back after their shift is over
with the truck and elevator. Determining when their shift is over is a
challenge; we will come back to that later. The ore is difficult: is it created
separately with a CREATE module, and then put into the truck by the miners? It
will be hard to determine when to create ore and how much. Probably it is best
to create the ore with a DUPLICATE from the miners; this will also ensure that
ore is only produced when the miners are present at the end of the shaft. Please
note that other solutions are possible as well. This leads to the following
picture:
2. Determine the major resources, transporters,
entities, attributes, and conveyors
In this case, we will probably have two entities: miners and ore.
For the miners we might need their state later: are they coming into the mine,
or leaving the mine.
The elevator could be modeled in different ways, but a transporter is best. When
we model it as a resource, it will be hard to determine the time it takes to
reach us: is it down or up when we need it, and what speed can it travel?
Therefore, a resource is less ideal, but it could serve as an approximation.
Routes or delays are certainly wrong: these constructs would lead to multiple
entities traveling at the same time, where only one entity (a group of miners or
a load of ore) could use the elevator at the same time. So it is at least a
resource, but a transporter looks better because it travels up and down and has
to be called when it is at the other location.
The trucks are certainly transporters: two instances are available, and they
travel with loads between two locations. It is almost impossible to successfully
model the trucks as resources, and certainly impossible to model them as routes.
3. Determine the Run Setup
The Run Setup can clearly influence the way we are going to run our model.
When we would e.g. use 7-day weeks, we would have to stop the generation of
entities for 2 days every week. A good reduction here is to model the mine for
5-day weeks, 24 hours a day. That makes it possible to work without
interruptions in the model and without schedules for resources etc. Enter this
information early, so you cannot forget it (it usually brings you a few points
in the exam as well). In this case we want 3 replications of 5 days of 24 hours
each. We want the default reporting unit to be in minutes (but hours would be
okay as well), because we expect waiting times of miners and transport time of
ore to be in minutes, and we want to avoid reporting e.g. "0.012 hours", which
is hard to interpret. Therefore, the Run Setup looks as follows:
4. Model the major
creation process where new entities arrive
New shifts arrive every 8 hours, so the only right way to model this is as
follows:
Remarks: Do not forget to name your module
-- this is your documentation. Include the Entity Type; no-one
understands what "Entity 1" is. The inter-arrival time is constant in
this case, Random (exponential) is wrong, because shifts arrive every 8 hours
exactly. Schedule is also wrong, because a schedule creates a random arrival
as well. Always check the Unit: hours in this case. It is not
important to know which shift this is. It is also not necessary to set any
variables or to use multiple CREATE modules. One will be sufficient to create
the shifts at the exact times. Make sure that Max Arrivals is Infinite;
you do not want to stop the model after e.g. 3 shifts. Do not create multiple
miners per arrival; you do not know how many there are, and they will probably
take the elevator and the truck one-by-one, unless you batch them. When batching
them in the rest of the model, why create them separately to begin with?
Make sure that the entity is at or goes to the station ElevatorTop in
zero time; this can be done by putting the STATION module right after the CREATE
module, or by a ROUTE to ElevatorTop in zero time.
5. Set-up the basic shape of the model with proper
documentation
Create the four stations, and some blocks to indicate the four locations of
the model. For each station block, fill in both the Name and the
Station Name. Usually, it is most clear to use the same name for both.
After that, we have a first lay-out of the model, see mine1.doe for the Arena example.
6. Make the elevator, so we can transport the miners
down
We already decided to model the elevator as a transporter. When we look at
the definition of a Transporter in the Advanced Process template (one of the
spreadsheets), we see that we have to fill in a speed, and later a distance in
the distance table. But no distance and speed have been given, only times.
Therefore, we have to assume a convenient distance, e.g. 100 meters, and a speed
to bring the miners down of 20 meters per minute, do it takes them 5 minutes to
reach the bottom. See below how we fill in the Transporter spreadsheet:
and the distance table:
Now we can Request the elevator, and transport the miners down. This is done by REQUESTing the elevator to come up (and if it is already up, the request is granted immediately). When the request has been granted, the miners can ask to be transported down with the elevator. Both the REQUEST and the TRANSPORT can use the default speed, leading to a 5 minute ride. Please note that we do not have to BATCH miners and the elevator; they ride on the transporter, and batching is only for two or more entities that have to be aggregated. Now we have the model mine2.doe. Do not forget to FREE the elevator at the bottom of the elevator. The FREE module can be put right after the ElevatorBottom station.
7. Make the trucks, so we can transport the miners to
the end of the tunnel
We follow the same process, and create 2 trucks with a default velocity of
10 km/h. The units to express the distance and the speed have to be the
same. Broken numbers are not possible, so we cannot enter the length as 0.4 km.
Therefore, we indicate distance in meters, and speed in meters per hour. The
Number of Units is two:
Transporting the miners to the end of the tunnel is analogous to taking the elevator down: REQUESTing one of the two trucks, and TRANSPORTing the miners to the end of the tunnel. There is one small trick: the truck drives 10 km/h when empty, and 5 km/h when full. Therefore, our REQUEST has to indicate a speed of 10 km/h, and our TRANSPORT a speed of 5 km/h. This can be entered in the TRANSPORT and the REQUEST block:
Do not forget to FREE the truck when arriving; this is usually good practice, even though the miners need a truck to fill with ore. By the way, a version of the model where the truck is not freed here because the miners want to load it with ore is also possible. When you see the full model, you can probably figure out how to change it to a version where the truck is not freed here.
Now we have the model mine3.doe.
8. Drilling process
Now it gets difficult: how do we ensure that we can create the ore? The
easiest and most used way is "duplicating" the ore from the miners and changing
the entity type for the duplicate. The process is shown below in the picture:
first request a truck to be loaded, then work for TRIA(15,20,30) minutes, after
which the truck is filled. DUPLICATE the miners entity into ore, change
the Entity Type with an ASSIGN, and send off the ore with a TRANSPORT to the
ElevatorBottom station:
9. End of shift or continue drilling?
The miners have to continue drilling for 8 hours. Therefore, they have to
"go back" to requesting a truck to load the ore in the above picture, unless
their shift is over. Determining this can be done in different ways: setting a
variable by a separate process to indicate shift over, or letting the miners
decide themselves if they want to continue working. A SIGNAL will not work,
because the miners will not "see" the signal when they are loading ore into the
truck. Therefore, we choose to have the miners look on their watch every time
when they finished loading a truck, and decide whether to go for a next load or
not. What we want to know is if 8 hours have passed since starting the shift,
i.e. since being created. The expression to do so in the expression builder is:
TNOW - Entity.CreateTime > 8*60. Why the 8*60? Well, we chose our Base
Time Unit in the Run Setup to be in minutes. That means that TNOW will be
in minutes, as well as the Entity.CreationTime. Therefore, we have to
compare the difference between TNOW and Entity.CreationTime also
with a time in minutes, hence 8*60. (This also means that when we would have the
Base Time Unit in hours, the equation would read: TNOW - Entity.CreateTime >
8). When the time is below 8*60, we can send the miners back to the "Request
truck" module in the picture above to get a truck for loading ore,
otherwise, they have to request a truck for themselves and transport themselves
to the ElevatorBottom station:
Now we have the model mine4.doe.
10. Conflict: more entities with different directions
arrive at stations
Now we have a problem: at the ElevatorBottom station, multiple
entities arrive: miners that came down, miners that want to go up, and ore that
has to be transported up. How are we going to solve this? There are two good
solutions to this problem.
The first solution is to create separate stations for each flow, see the figure below, and to expand the distance table to include all potential distances, where the distance between two stations at the same place is zero.
The second solution is to keep one station, and include a DECIDE at ElevatorTop and ElevatorBottom to see whether we have arriving miners, departing miners, or ore. We can indicate that with an Entity Type and/or attributes. (No variables, as these are individual properties for each entity). We already have Entity Types "miners" and "ore". Suppose we would add an attribute "arrive" that could be "0" or "1". The DECIDE at the bottom of the elevator could then look as follows:
Now we have the model mine5.doe.
11. Complete the transportation
We can now transport the ore up with the right speed of the elevator,
transport the miners up with the right speed with the elevator, and include a
similar DECIDE at the top of the elevator. Unloading the truck with ore at the
bottom of the elevator takes between 5 and 10 minutes, which has to be spent
before FREEing the truck. At the top of the elevator, 2-4 minutes are spent. We
assume that this is also keeping the elevator busy -- we therefore insert it
between the DECIDE and the FREE of the elevator for the ore. We also read in the
case that miners take priority over ore when requesting a truck. Therefore, you
will see in the model that we have Medium(2) priority for the ore when
requesting a truck or elevator, and High(1) priority when miners request a truck
or elevator. Finally, we have to send back the ore truck to the end of the
tunnel as soon as we are finished. The MOVE module can do exactly that. Moving a
truck before you FREE it means that you send it to a destination, without
waiting for the move to be completed. After the MOVE, you can fee it, so another
entity can claim it after it has arrived. Please note that the elevator speeds
can be entered as 100/5 per minute The process at the bottom of the elevator now
looks as follows:
And the process at the top of the elevator looks as follows. A number of temporary DISPOSE modules have been added to be able to run and test the model.
The model indeed runs, but it has a problem: no miners ever leave the mine; they continue running in circles at the mine bottom, also after 480 minutes. This is because we DUPLICATEd the miners entity, and sent the original as ore to the elevator. When DUPLICATing an entity, it gets a new Entity.CreationTime, which we used to decide if the shift is over. As it gets a new CreationTime in every loop, the shift is never over... Therefore, we introduce a new attribute for the true creation time, which we allocate right after the CREATE of the shift, and we call it arrivalTime. Attributes will be copied nicely when duplicating an entity. In the DECIDE whether the shift is over, the formula now becomes: TNOW - arrivalTime > 8*60. After this, we have a running model where we have to finalize a few things, as shown in mine6.doe.
12. Add the conveyor belt
The conveyor belt can be added by defining it and creating the segment using
the spreadsheets for Conveyor and Segment in the Advanced Process template. Do
not forget that a segment has a Beginning station (ElevatorTop) and one
or more Next Stations that have to be added in a table; in this case there is
one, and it is called Plant:
To convey the ore to the plant, we have to ACCESS the conveyor, and CONVEY it. At the Plant station, we EXIT the conveyor, and the ore has arrived:
The full model of the assignment is now ready. Only the animation is missing. The model can be retrieved as mine7.doe.
13. Animation
To add the animation, start with placing the four stations (see below in the
Animate Transfer toolbar where to find stations). Make sure that you have
Distances (D-D) between ElevatorTop and ElevatorBottom, A Distance
(D-D) between ElevatorBottom and ShaftEnd, and a Segment (S-S)
between ElevatorTop and Plant. The symbols to use from the Animate
Transfer toolbar are shown below.
Make the stations also "parkings" for the trucks and the elevator (which we will create in a minute). The two distances for the elevator and the trucks are added as follows:
And the segment for the conveyor belt is added as follows:
Now, we have to create the right symbols for the elevator and the truck. Furthermore, we have to assign pictures for the miners, and for the ore. This can be done as the default picture in the Entity spreadsheet in the Basic Process template, but the picture will not change after duplicating the entity. Therefore, we have to ASSIGN the picture to the ore, in the same ASSIGN module where we indicate that the Entity Type is ore. In this case, we make the ore a Picture.RedBall, and the miners a Picture.Man.
Now, we have to make an elevator and a truck. These are Transporters, which we can add with the Transporter in the Animate Transfer toolbar:
We make two transporters, a square for the elevator, and we take a dumptruck from "vehicles.plb" library for the truck.
Make sure to include a "ride point" where the entities "ride" on the transporter for the animation:
After this, two transporters have been created:
and the animation will start:
We can clearly see the elevator move up and down, and the ore being transported as well as the shifts (right-hand picture). The final model that we have created is mine8.doe.
When you want to run the model with a nice animation, turn off the connector animation. In order to do so, make sure that the toolbar for Run Interaction is open, and turn off the "Animate Connectors" feature. Then slow down the model until there is an acceptable speed with the "<" key on the keyboard (press repeatedly). After that, the animation will run more smoothly.
14. Notes
Note 1. Calling the elevator before the truck leaves the end of the mine shaft. This has not been included in the model example, but can be easily done by inserting a MOVE of the elevator down with a speed leading to it arriving at the down position in 3 minutes just before the truck leaves. This would look as follows:
But just adding the MOVE module would lead to an error message. In order to MOVE a transporter, you have to "own" it. A REQUEST would not work to do so, because a REQUEST brings the transporter to the current location! The elevator cannot go to the end of the mine shaft (although we could add it to the distance table with a distance of 0, which would work, but which would not be so elegant). Therefore, we use DUPLICATE entity and an ALLOCATE module to gain control of the elevator. ALLOCATE works like REQUEST, but just gives you control of the elevator without moving it to your location. After that you can move it to any location without actually riding the transporter.
We need a duplicate entity, because we want the truck to leave while "another" entity takes care of bringing the elevator down for us. Halting the truck till this has been completed is a waste of time. This leads to the following changes in the model:
which have been reflected in mine9.doe.
Note 2. Another possibility for determining the difficult "end of shift" decision is to create a duplicate "watchdog" entity for the miners that they consult for each decision. Consultation can be e.g. based on the entity sitting in a BATCH or MATCH. This would mean that you DUPLICATE the miners when they arrive at the digging location, DELAY them for 8 hours, and enter a MATCH or BATCH module to wait for the miners to join their watchdog:
This is more complicated than the original solution, but it does work.
15. Interpreting model outcomes
The following performance indicator were requested, with their average and
maximum value from 3 replications of 5 working days:
Please note that to get utilization and other performance indicators of transporters and conveyors, you have to indicate that you want to gather these. You do that in Run - Setup... - Project Parameters. There are two tick-boxes, one for transporters and one for conveyors. Only if you ticked these boxes, statistical data will be gathered on the transporters and conveyors.
In order to gather statistics fast, run with fast Forward:
After the three replications, the data has been collected:
The names can be easily found, because names are very clear. The mapping is as follows:
This leads to the following answers for the performance indicators (for the maximum, the absolute maximum in a replication has been chosen, not the maximum of the averages of the three replications; as this was not clearly specified in the assignment, both are okay):
| Performance Indicator | Average | Maximum |
| waiting time of miners for a truck | 0.9 minutes | 4.9 minutes |
| time miners actually present at the end of the shaft | 478 minutes | 516 minutes |
| number of truckloads of ore produced per week | 324 | 325 |
| time miners have to wait for the elevator before going up | 3.7 minutes | 10.3 minutes |
| utilization of the two trucks | 0.8 | 1.0 |
Alexander Verbraeck
21 April 2007