364
line (truck capacity) across the entire shift. The Flow Planner has largely neglected Truck
Type B (which has a smaller tray size). As can be seen in Figure 1(a), the excavator is down
from 06:45 to 07:30, and thus the flow rate is zero during this time interval. This excavator
digs block B4 from 06:00 until 11:45—apart from the down-time—before starting on B3.
Block B5 is the last block due to its lower priority.
Figure 1(c) shows the material flow rate into process plant ‘A’. Between 7:45 and 8:00, the
excavator digging block B1 is down, and since this is the only block going to process plant ‘A’,
the total incoming rate to this process plant is zero.
4.2 Re-planning (feedback control)
The Flow Planner also enables feedback control on material quantity targets. To demonstrate
this, suppose that process plant ‘A’ unexpectedly breaks down at 13:00. Since unexpected, the
generated allocation plan has not taken this downtime into account, and continuing with this
plan for the remaining part of the shift may no longer be optimal. In such situations, Flow
Planner takes into account the amount already excavated since the beginning of the shift till
now, and is re-run to generate a new plan for the rest of the shift. Figure 2 shows the new plan
from 13:00 to the end of the shift. The maximum dump rate in Figure 2(a) is zero between
13:00 and 15:00, implying that the process plant is offline. No flows go to process plant ‘A’ in
the new plan, as Flow Planner digs block B2—rather than B1— at 13:00, and the excavator
cannot finish B2 by the end of the shift (the projected value for this block is 18 KT, meaning that 18 KT of the block can be extracted by the end of the shift). In the same figure, the
excavated value of block B1 is 24.30 KT, meaning that 24.30 KT have already been extracted
before 13:00 within the plan in Figure 1, and the remaining 5.70 is never extracted since the
excavator only works on B2 after 13:00.
4.3 Comparison
We now examine the improvements that Flow Planner brings to truck dispatching systems
by comparing it to the LP developed by White and Olson (1986). Due to the nature of the
contributions in Flow Planner, making a fair, meaningful comparison with existing algorithms
is difficult; this is mainly because the advantage of Flow Planner over existing methods is
generating an optimal allocation plan for the entire shift and incorporating the disruption
events, such as maintenance and breaks, and scheduled changes in equipment availabilities
throughout the shift. In exiting commercial packages, however, these are handled by a human
operator. Nevertheless, we try to mimic the human based process to run the LP of White and
Olson (1986) for the entire shift and compare the output with that of Flow Planner. We consider five case studies similar to the one described earlier in this section. All these examples
include excavator downtimes and changes in truck availabilities across a 12-hour shift, and the
targets are given for the entire shift. The mentioned LP is able to take the targets for the entire
shift, but is unable to see the excavator downtimes and truck availability changes as well as the
given extraction order of blocks. Therefore, to be able to obtain a plan for the entire shift from
the LP, we run it every time one of the following occurs: 1) a block is completed—this is to
cope with the fact that the LP does not consider the extraction order, and in practise, a human
operator would run the system again to make new decisions for the next block; 2) the truck
capacity changes; 3) an excavator goes offline; and 4) an excavator returns online. In every run,
the state of the mine (i.e. input data) must be updated manually, e.g., subtracting the amount
of material that has already been moved from the total target, and updating equipment availability. The blending of the process plant feed in the LP is controlled through a constraint that
ensures the blend of material fed into a process plant is within acceptable bounds (for brevity,
we refer the reader to White and Olson (1986) for details on this constraint). To have a fair
comparison, we added this constraint to Flow Planner. Since the parameters of this constraint
did not exist in our case study data, we generated them randomly.
Table 1 records the outputs of both Flow Planner and the LP on the five case studies. The
second column indicates the number of runs needed to obtain a full plan for the entire shift
line (truck capacity) across the entire shift. The Flow Planner has largely neglected Truck
Type B (which has a smaller tray size). As can be seen in Figure 1(a), the excavator is down
from 06:45 to 07:30, and thus the flow rate is zero during this time interval. This excavator
digs block B4 from 06:00 until 11:45—apart from the down-time—before starting on B3.
Block B5 is the last block due to its lower priority.
Figure 1(c) shows the material flow rate into process plant ‘A’. Between 7:45 and 8:00, the
excavator digging block B1 is down, and since this is the only block going to process plant ‘A’,
the total incoming rate to this process plant is zero.
4.2 Re-planning (feedback control)
The Flow Planner also enables feedback control on material quantity targets. To demonstrate
this, suppose that process plant ‘A’ unexpectedly breaks down at 13:00. Since unexpected, the
generated allocation plan has not taken this downtime into account, and continuing with this
plan for the remaining part of the shift may no longer be optimal. In such situations, Flow
Planner takes into account the amount already excavated since the beginning of the shift till
now, and is re-run to generate a new plan for the rest of the shift. Figure 2 shows the new plan
from 13:00 to the end of the shift. The maximum dump rate in Figure 2(a) is zero between
13:00 and 15:00, implying that the process plant is offline. No flows go to process plant ‘A’ in
the new plan, as Flow Planner digs block B2—rather than B1— at 13:00, and the excavator
cannot finish B2 by the end of the shift (the projected value for this block is 18 KT, meaning that 18 KT of the block can be extracted by the end of the shift). In the same figure, the
excavated value of block B1 is 24.30 KT, meaning that 24.30 KT have already been extracted
before 13:00 within the plan in Figure 1, and the remaining 5.70 is never extracted since the
excavator only works on B2 after 13:00.
4.3 Comparison
We now examine the improvements that Flow Planner brings to truck dispatching systems
by comparing it to the LP developed by White and Olson (1986). Due to the nature of the
contributions in Flow Planner, making a fair, meaningful comparison with existing algorithms
is difficult; this is mainly because the advantage of Flow Planner over existing methods is
generating an optimal allocation plan for the entire shift and incorporating the disruption
events, such as maintenance and breaks, and scheduled changes in equipment availabilities
throughout the shift. In exiting commercial packages, however, these are handled by a human
operator. Nevertheless, we try to mimic the human based process to run the LP of White and
Olson (1986) for the entire shift and compare the output with that of Flow Planner. We consider five case studies similar to the one described earlier in this section. All these examples
include excavator downtimes and changes in truck availabilities across a 12-hour shift, and the
targets are given for the entire shift. The mentioned LP is able to take the targets for the entire
shift, but is unable to see the excavator downtimes and truck availability changes as well as the
given extraction order of blocks. Therefore, to be able to obtain a plan for the entire shift from
the LP, we run it every time one of the following occurs: 1) a block is completed—this is to
cope with the fact that the LP does not consider the extraction order, and in practise, a human
operator would run the system again to make new decisions for the next block; 2) the truck
capacity changes; 3) an excavator goes offline; and 4) an excavator returns online. In every run,
the state of the mine (i.e. input data) must be updated manually, e.g., subtracting the amount
of material that has already been moved from the total target, and updating equipment availability. The blending of the process plant feed in the LP is controlled through a constraint that
ensures the blend of material fed into a process plant is within acceptable bounds (for brevity,
we refer the reader to White and Olson (1986) for details on this constraint). To have a fair
comparison, we added this constraint to Flow Planner. Since the parameters of this constraint
did not exist in our case study data, we generated them randomly.
Table 1 records the outputs of both Flow Planner and the LP on the five case studies. The
second column indicates the number of runs needed to obtain a full plan for the entire shift