APS APS Haulage Calculations

“Instantaneous Trucks” vs “TUM Trucks”

Firstly, it’s important to understand the difference between an “instantaneous truck” and a “TUM truck”. An “instantaneous truck” is one which is operating and productive at an instant in time. A “TUM truck” is the number of truck hours in a period divided by the number of hours per truck in the period, based on the TUM.

In reality, trucks do not respect the TUM in an instant in time - in any one instant, the truck is either available or unavailable, not a mixture of the two. There’s a probability of whether a truck will be operating at an instant in time in the future (the TUM is the average over an extended period of time). This is the most correct way to think about trucks on an instantaneous basis, and for very short term scheduling. The TUM accounts for, but does not explicitly contain, the frequency and duration of downtime events (a cyclone vs a broken bucket tooth). However, the industry standard is to use the TUM methodology regardless of the timeframe, and it’s difficult to tie a probability into a deterministic two-week plan without running a large number of scenarios which simulate downtime events. For this reason, APS, like ATS, consumes truck hours and uses TUM trucks.

Truck Hours Calculation

Truck hours are based on the cycle time of the truck (when being loaded by the specific digger), the truck’s payload, the quantity and type of material moved, and the time usage model (TUM) which applies to the truck.

Cycle Time

Haul Infinity, integrated into APS, determines the cycle time. Therefore, in order for useful cycle times to come through, the haul network must be updated and accurately reflect the roads being used.

The truck’s cycle time consists of:

Spot Time at Loader
Loading Time
Loaded Travel Time
Spot at Dump
Dumping Time
Unloaded Travel Time
TKPH Delay (if TKPH constrains the truck cycle time)
Queue Time

The cycle time of a truck calculated by Haul Infinity depends on the truck, loader, source, destination, and operating condition. The payload of the truck is entered into Haul Infinity but can be overridden by the operating condition.

The operating condition used in APS is not one of the ones specified in Haul Infinity. Instead, the operating condition is either a default which does not alter any haulage parameters, or it’s specified by a script based on your site-specific requirements. A few examples of what is possible with the operating condition are:

Change the dig rates by location, blast type, etc.
Alter the truck payload based on time or pit.
Factor the truck travel time based on a variety of factors.
Specify the temperature for TKPH calculations.
And many more.

Material Type and Truck Payload

The material type is specified in Haul Infinity and is used to determine the swell factor from BCM into the tray and the dry tonnes from the wet tonnes based on the moisture. How the material types in Haul Infinity are mapped to into APS is specified in the Final Configuration item “Haulage Materials”. The truck’s payload/capacity is specified in Haul Infinity in terms of wet tonnes (not dry tonnes) or volume.

Based on the material type, and payload/capacity, Haul Infinity knows what the maximum dig rate in BCM/h, Dry Tonnes/h, and Wet Tonnes/h, as well as the truck’s limiting payload in wet tonnes (which could be less than it’s stated payload if the truck’s capacity is limited by volume).

Quantity Moved

The quantity moved is automatically calculated by the scheduling engine - the user has no control over this, other than through Rapid Reserver, the preschedule, and the database corruptor.

Time Usage Model (TUM)

The TUM applies to both diggers and trucks. An explanation of the loader TUM can be found on the following page: APS APS Agent TUM Calculations. The Trucks' TUM operates in the same way as the diggers, except that an additional default availability type “Planned Availability (PA)” is provided, which is unique to Trucks as it is not possible to specify planned maintenance windows for individual trucks.

The TUM affects diggers by establishing a difference between the Nominal Rate, and the Productive Rate (factored by the TUM). For haulage calculations, the Nominal rate is used. The effect the dig rate has is limited to how Haul Infinity chooses a number of “instantaneous trucks” to match onto a Haul, which affects queue time if the truck matching method (specified in Haul Infinity) is set to OverTruck or Round.

The user in the calendar specifies the TUM for the trucks, and for each truck, there is a calculated "Hours / Unit" field.

Calculation of Truck Hours and Number of Trucks

Now that the scheduling engine knows the:

Truck
Loader
Source (Dig Block or Stockpile)
Destination (Stockpile, Crusher, Dump Block, or Point Dump)
Operation Condition (Site-specific - specified by script)
Quantity Moved
Material Type / Limiting Payload
Hours per Truck per Period

It can calculate the number of truck hours, and the number of trucks required:

//Pseudocode:

var loader = Agent.Name;
var truck = Haulage.Truck;
var source = Source.FullName;
var destination = Destination.FullName;
var parcel = Source.Parcel;
var qty = Mining.WetTonnes;

var hoursInPeriod = GetFromCalendar();
var overrideLoaderRate = GetFromCalendarOrScript(loader);

var material = Haulage Result.Material 
             = GetFromHaulInfinity(parcel);
             
var payload = Haulage Result.Truck Payload 
            = GetFromHaulInfinity(truck);

var cycleTime = Haulage Result.Times.Total 
              = SpotAtLoader + TruckLoadTime + LoadedTravelTime + SpotAtDump + DumpTime + UnloadedTravelTime + TKPHDelay + Queue
              = GetCycleTimeFromHaulInfinity(loader, truck, material, payload, source, destination, overrideLoaderRate, ... other factors by script)

var numTrips = Haulage Result.Number of Trips 
             = qty / payload;
             
var truckHours = Haulage.Truck Productive Hours 
               = numTrips * cycleTime (in minutes) / 60;

var engineFactor = GetAvailabilitiesFromCalendarWhereEngineIsOn(truck)
var calendarFactor = GetAvailabilitiesFromCalendar(truck);

var truckEngineHours = Haulage.Truck Engine Hours = truckHours / engineFactor;
var truckCalendarHours = Haulage.Truck Calendar Hours = truckHours / calendarFactor;

var numberOfTrucks = truckCalendarHours / hoursInPeriod;

The number of trucks is based on the productive hours of the truck and the Time Usage Model (TUM). This is how APS uses TUM Trucks.

Note that there are many equivalent methods to calculate the number of trucks. For example, dividing the number of productive truck hours by the number of available hours per period for each truck will yield the same result.

Truck Assignments

In APS, each time a digger has a valid source and destination combination, it determines which trucks to use (if any) in the transaction. If the digger requires trucks, and if no trucks are available at that point because they are not assigned or because they’ve run out of truck hours, it will go into idle. How the loader chooses their trucks is specified in the “Truck Assignments” step in the main setup.

In this step, the user creates rules which consist of several filters and the trucks which apply to the rule. Details of the filters are shown below.

Enabled - Whether the rule will be considered at all.
Calendar Switch - If the calendar switch is set a certain way, the rule will apply.
Loaders - The loaders which can use the rule.
Sources - If the source is one of these, the rule will apply.
Parcels - The rule only applies to these parcels.
Destinations - If the material is sent to one of these destinations, the rule can apply.

For a rule to apply, ALL of the filters must pass.

Note that you can copy rules by holding Ctrl, and dragging the icon for the rule.

Each time an Agent has chosen a block and a valid destination, it will go through the table from the top down (ignoring the tree structure) and find all the rules that apply for that movement and put them in a priority list. Each rule can have either <LoadHaulDump> or one or more trucks in it.

LoadHaulDump

<LoadHaulDump> is a specific setting which enables the loader to send material to the destination itself (by tramming). If <LoadHaulDump> is used, typically a script is utilized to provide the rate at which the loader can send material for a specific source-destination combination (as the tramming time depends on the route).

Trucks

If a rule doesn’t use <LoadHaulDump>, it will have one or more trucks associated with it. What this means to the loader is it can use these trucks, and ideally it will use those trucks as equally as possible.

If none of the trucks in the rule can be used anymore (because they have no more truck hours left), the loader will then choose the next rule that applies out of its priority list and use the trucks in that one. In this manner, it’s possible to specify that a loader should prefer to use one type of truck, but once that’s out of hours, start using a lower priority truck.

Assigning Truck Numbers

After all of these rules are specified, new calendar rows are created automatically which give control over truck limits in three ways:

Truck Numbers by Truck Type
Truck Numbers by Truck Assignment Rule
Truck Numbers by Loader by Truck Assignment Rule

The user can type in a number of trucks in any of these areas (which, behind the scenes, is providing a maximum number of hours), and the maximum number of hours associated with the number of trucks will not be exceeded. Once the loader runs out of trucks with remaining hours, it will go idle.

Scheduling with Trucks

APS accounts for trucks in terms of their hours over the course of a period. Practically this means that once the truck hours are exhausted, the loader will go idle toward the end of the period, as shown below.

Whether this is an issue or not is a very personal decision, and it is ultimately up to the engineer to decide if it’s an issue by themselves or in consultation with their team.

Alastri’s position is:

For two-week planning and less (where maintenance events are scheduled, instead of modelled as availabilities), this is an issue that should be resolved.
For 3-month and longer-term schedules (which are using availabilities instead of scheduled maintenance events), this is not a concern.

If the loaders idling at the end of each period needs to be resolved, there are two ways to resolve it:

Run the schedule and evaluate one period at a time. When you see the loaders shutting down, derate the lower priority diggers by lowering their dig rates or shutting them down until the truck numbers come down.
Uncap the number of trucks initially, and run the entire schedule without considering truck numbers. Then, start derating diggers over the whole schedule until the correct number of truck hours is reached.
- This method is riskier as it’s possible that by derating a low priority digger, access to ore at the end of the schedule is blocked. However, in short term plans, the risk of this is low.

Where are the Haulage Fields in Reports?

Within the Steady States tab, trucking requirements at any instant in time can be viewed. Additionally, a Mining Movements report provides access to the fields mentioned above in the Pseudocode. This can be exported to CSV for detailed analysis if desired.

How do I report Trucks in a Chrono Report?

Report the availabilities out of the calendar and the period duration. Multiply them together to get the number of hours available per truck per period. Divide “Haulage. Truck Productive Hours” by this number to get the number of trucks.

Why can’t I report the number of trucks in a Pivot / Step / Table report?

You might think that you could divide the truck hours in each movement by the number of truck hours per unit in the schedule and sum that up in a pivot table. And you’d be right - but only if the sums are broken down into the scheduling periods as specified in the calendar - if not, it doesn’t work.

Why do my truck numbers look so high/low? What can I do about it?

Examine the animation, which displays the routes taken to ensure the correct paths are being used. If not, use Haul Infinity to ensure the correct routes are used. Take the time to ensure your haulage model is correct before starting to schedule.
Use a pivot report to ensure that the right destinations are used for each material type. If not, alter the destination rules.
If the numbers are too high, look to mine some material with shorter hauls.
If the numbers are too low, there’s an opportunity to mine some material with longer hauls.
Your last option, if you’ve tried the above, is to derate or shut down diggers. Often this cannot be avoided to meet short term ore requirements.