Mine Haul Fleet Dispatch Software: Why Trucks Still Queue While the Crusher Starves

Why a shift loses tonnes without anyone noticing until morning

Night shift, 14 haul trucks, two shovels and a primary crusher. At 02:10 the shovel in the north pit is waiting because four trucks are stacked at the crusher tip. The dispatcher hears none of this, because dispatching is happening on channel 2 and the operators are managing it between themselves the way they always have. At 06:00 the shift report says 41,200 tonnes against a plan of 45,000. Nobody can say where the 3,800 went. The truck hour report says the fleet was 91 percent available, which is true and completely beside the point, because availability is not utilisation and utilisation is not productive utilisation.

Every open pit has a version of this. The plan lives in the mine planning package, the assignment lives on the radio or in a fleet management system, the payloads live in the onboard scales, the fuel burn lives in the OEM telematics portal, the delays live in a paper delay code sheet, and the tonnes into the mill live in the plant historian. Six systems, no join. The join happens in a spreadsheet the technical services graduate rebuilds every morning, and it is a reconciliation, not a control system, which means it explains yesterday and changes nothing about tonight.

The operating cost of that gap is not subtle. A haul truck fleet is a queueing network, and queue time at the shovel and the tip is pure burnt diesel and paid operator hours with zero tonnes attached. Across mining and heavy earthworks projects we have delivered, the numbers that repeat are single digit percentage improvements in effective truck utilisation once queue time becomes visible in real time rather than at shift end. On a fleet costing hundreds of millions to own and run, single digit percentages are the whole business case.

Problem 1: assignment is a queueing problem the radio cannot solve

The dispatcher assigns by judgement and voice. That judgement is real and sometimes better than a naive algorithm, but it cannot compute the thing that actually matters: which shovel will be starved in eleven minutes given current cycle times, tip queue depth and the fact that truck 47 is running slow on the ramp because it is on a downrated tyre. Human dispatch optimises the truck in front of you. Fleet productivity is decided by the assignment you make three trucks ahead.

Modular Mining DISPATCH, Wenco, Hexagon and Caterpillar MineStar Fleet all solve this properly and have done for decades. This is genuinely mature software and we will not pretend otherwise. Their limitation is not the optimiser, it is the shape of the deal: the optimiser arrives bolted to that vendor's onboard hardware, their mine model and their per machine licensing, and it wants the world to look the way it looks. That is a fine trade at a large mine with a homogeneous fleet and a capital budget. It is a poor trade for a 20 machine contractor fleet moving between three sites a year, and it is a poor trade when half your value would come from data the vendor system holds but does not readily hand back.

A custom build must include, at minimum: a cycle model that treats load, haul, dump, return and queue as separate measured states rather than a single trip time, a live assignment engine that is explicitly a queueing model and not a nearest truck rule, and an override path where the dispatcher can force an assignment and the system records why. That last one decides adoption. A dispatcher who cannot override the system will find a way to defeat it by lunchtime.

Problem 2: a mixed fleet speaks four telemetry dialects

You run Caterpillar and Komatsu trucks, a Hitachi excavator, hired water carts, and third party payload scales, tyre pressure monitoring and fatigue detection cameras that came in as separate safety projects. Each has its own portal, its own login and its own definition of an engine hour. ISO 15143-3, the AEMP telematics standard, exists precisely because this problem is universal, and it gives you a common way to pull fundamentals such as hours, fuel and location across OEMs. It does not give you payload distribution, pass counts, tyre TKPH exposure or delay codes, which are the fields that actually explain a bad shift.

Fleet management vendors integrate their own ecosystem well and third party hardware selectively. The integration layer between everything else is the piece nobody owns, so it gets built as a chain of CSV exports into Power BI (Business Intelligence), which breaks whenever a vendor changes a column header. What a custom build does is own that layer deliberately: one ingestion service per source, a canonical equipment and shift model, and a single machine identity so that truck 47 is truck 47 whether the record came from the scale, the OEM feed or the operator's tablet. Timestamps are the hidden hard part. Onboard clocks drift, OEM portals report in UTC, your shift boundary is 06:00 local across a daylight saving change, and if you get this wrong the whole reconciliation is quietly nonsense.

Problem 3: reconciliation happens after the tonnes are already lost

End of shift, the graduate joins truck counts times nominal payload against the crusher weightometer and finds a 4 percent gap. Which is it: scale calibration drift, unrecorded rehandle, trucks tipping to the wrong stockpile, or a genuine plan miss? Without a cycle level record that carries the source, destination and material type for every load, the gap is unattributable and therefore permanent.

The build must record every load as a discrete event with origin block, destination, material classification, payload from the onboard scale and the operator who was in the seat. Then reconciliation stops being a monthly argument and becomes a daily variance report with named causes. Where AI earns its place is narrow and worth naming: anomaly detection over payload distributions catches a drifting scale weeks before the calibration schedule does, and classification over free text delay comments turns operator shorthand into consistent delay codes without forcing operators to scroll a dropdown of 60 options while wearing gloves. Neither is a chatbot and neither needs a large model.

Problem 4: the dispatcher only ever sees the past

Short interval control means acting inside the shift, not reporting on it. The control room needs a screen that says the north shovel will starve in eleven minutes, the crusher tip queue is three deep and rising, and moving truck 52 and 61 recovers roughly 200 tonnes before the break. That is a forecast over the next hour, computed from live cycle times, not a dashboard of what already happened.

Most fleet systems have a real time screen. What they generally will not do is combine live fleet state with your specific downstream constraint, whether that is crusher throughput, blend targets from the ore control model, or a stockpile that must not exceed a grade band. The build ties fleet state to the constraint that actually governs your revenue that shift, and it alerts on the constraint rather than on the trucks. Push those alerts to a phone or a Toughbook, not to a wallboard nobody watches at 3am.

Problem 5: the pit has no signal where you need it most

Pit wifi and private LTE cover the ramps and the dump, and then the truck drops into a cutback and loses coverage for six minutes. In cab software must be offline first: store events locally, queue them, sync on reconnect, and reconcile duplicates when a device syncs twice. Ruggedised hardware, glove usable buttons, sunlight readable screens and mounting that survives a haul road are not nice to have, they decide whether operators use the thing or ignore it. Budget for hardware selection and a real in cab trial, because a build that is elegant in the office and unusable in a 793 has failed.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape for mining fleets. A dispatch intelligence layer over an existing fleet management system, meaning ingestion from mixed OEM telematics, payload and shift sources, a canonical cycle model, daily reconciliation and short interval control alerting, runs $70,000 to $160,000 and ships in 12 to 18 weeks. A full dispatch build with in cab tablets, live assignment, offline sync and delay capture runs $250,000 to $700,000 over 9 to 18 months, and that range is wide for a reason: it is decided by fleet size, by how many sites, and by whether the system is expected to influence anything safety related.

What drives the number up specifically here: in cab hardware, because selection, mounting, power and a field trial across a full weather cycle is real work. Integration with a mine planning package or a plant historian, because OPC UA and proprietary planning file formats are specialist. Multi site rollout, since every site has its own delay code taxonomy and every site believes theirs is correct.

What keeps it down: start with one pit, one shift pattern and read only reconciliation before you attempt live assignment. You will learn more from four weeks of clean cycle data than from six months of arguing about the optimiser.

Build versus buy, and when buying is the right call

We will say this plainly because it costs us work. If you are a large open pit with a homogeneous fleet already running Modular Mining DISPATCH, Wenco, Hexagon Mining Operations, MineStar Fleet or Micromine Pitram, do not commission a replacement. Those systems are mature, their optimisers are the product of decades of operating data, and a custom rebuild is a multi year risk with an unclear upside. Build the layer around them instead, and negotiate hard for raw data access in your next licence renewal because that access is the single most valuable term in the contract.

Build the whole thing when the licence and hardware model stops making sense for your operation. A mining contractor moving fleets between client sites cannot justify per machine licensing on machines that change site twice a year. A quarry group with 30 trucks across eight sites is paying tier one prices for a problem that is mostly reconciliation and short interval control. An operation with a genuinely unusual constraint, such as a blend critical feed or a rehandle heavy layout, will find that generic optimisers assume a mine that is not yours. In those cases a focused build is cheaper over five years and you own the result.

How to choose a developer for mine dispatch software

Ask them to whiteboard the cycle model before anything else. The right answer separates load, haul, dump, return and queue as distinct states with their own timestamps and sources, and it has an opinion about clock drift and shift boundary handling. A developer who models a trip as a start time and an end time has not worked with fleet data and will discover the problem after your first month of collection.

Ask what they have actually integrated. Naming ISO 15143-3, OPC UA, a plant historian and at least one OEM telematics feed is a different answer from we do integrations. Ask which payload scale or tyre monitoring vendor they have pulled data from, and what broke.

Ask how the software behaves with no connectivity for ten minutes, and how it reconciles a device that syncs the same events twice. If that is an afterthought, your cycle data will have holes where the queues formed.

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. Given that vendor lock is the reason most operators start this conversation, accepting it again from your development partner would be an expensive irony.