Mine Fleet Dispatch Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope get written as a dashboard instead of a cycle model?

Dispatch briefs almost always describe screens. A control room wallboard, shift summaries, availability and utilisation charts. Those are the artefacts management already recognises, so they become the requirement, and the underlying model gets whatever shape makes the charts render.

What the operation runs on is the cycle, and a cycle has to be recorded as distinct states with their own timestamps and their own sources. Load, haul, dump, return and queue are five different things with five different causes. Collapse them into a trip and every subsequent question becomes unanswerable: whether the shovel was waiting or the truck was, whether the tip was congested or the ramp was slow, whether truck 47 is genuinely underperforming or is on a downrated tyre.

This is specific to mining because a haul fleet is a queueing network. Availability is not utilisation and utilisation is not productive utilisation, and the distinction is where the money sits. A fleet reported at high availability can spend a shift stacked at the crusher tip while a shovel starves in another pit.

The fix is to specify the cycle model before anything visual, and to test any developer on it. Ask them to whiteboard the states, then ask two follow ups: how they handle onboard clock drift, and what happens at a shift boundary that crosses a daylight saving change. A developer who models a trip as two timestamps has not worked with fleet data and will discover the problem after your first month of collection, which is a month you cannot get back.

What goes wrong when you reconcile historical shift and payload data?

The reconciliation everyone wants on day one is truck tonnes against the crusher weightometer. It fails on historical data for reasons that are not about the maths.

Delay codes are the first problem. Every site has a taxonomy on a paper sheet, and it has been added to by different superintendents over years until it contains overlapping categories, near duplicates and codes nobody uses. Free text comments carry the real reason in operator shorthand that only makes sense to the crew who wrote it. Import that as is and your variance analysis attributes losses to a code that means three different things.

Payload data is the second. Onboard scales drift, and historical records carry that drift silently, so a nominal payload assumption applied across a year produces a tonnage curve with a slow bias in it. Nobody recorded when calibrations happened, so you cannot correct backwards.

The fix is to rationalise the delay taxonomy with the superintendents before migration, not during, and to accept that historical delay data may only be usable at a coarse level. Establish one canonical machine identity with effective dates so a renumbered unit keeps its history. Then treat the first four weeks of new collection as the real baseline, because clean cycle data settles more design arguments than six months of debating the optimiser.

Why do mixed fleet telemetry integrations break after launch?

You run several truck makes, an excavator from a third manufacturer, hired water carts, and third party payload scales, tyre pressure monitoring and fatigue cameras that arrived as separate safety projects. Each has its own portal, its own login and its own definition of an engine hour.

The telemetry standard for construction and mining equipment gives you a common route to fundamentals such as hours, fuel and location across manufacturers, and that handles the easy half. It does not carry payload distribution, pass counts, tyre exposure or delay codes, which are the fields that actually explain a bad shift, so those remain per source integrations.

After launch the breakages are quiet. A hired unit arrives and nobody registers it, so it produces cycles with no equipment record and the data is dropped. A vendor changes a column header in an export and a chain of scheduled files stops parsing. A portal credential expires. A machine returns from a rebuild with a new device serial and its history splits in two.

The fix is one ingestion service per source with a shape expectation, alerting on volume change and field completeness rather than only on connection failure, plus a canonical equipment register with an onboarding step for hired machines. Budget integration maintenance as a standing cost. And get timestamps right at the boundary, preserving source precision alongside a normalised value, because a correlation window built on drifted clocks produces a reconciliation that is quietly nonsense.

What happens when offline operation in the pit is not covered?

Coverage reaches the ramps and the dump and then a truck drops into a cutback and loses signal for six minutes. That is normal, it is not a network defect to be fixed later, and any design that assumes connectivity will lose data exactly where the interesting events happen, because queues form in the places with the worst coverage.

The failure pattern is specific. A tablet that cannot reach the server stops recording rather than buffering, so the cycle has a hole in it. A device that syncs twice after a reconnection creates duplicate events, and a system with no reconciliation logic double counts loads. An operator who is asked to re enter something after a dropout stops entering anything at all.

The fix is offline first from the start: local persistence, an event queue, sync on reconnect and explicit duplicate reconciliation keyed on device generated event identifiers rather than server arrival order. Then budget a real in cab trial across a full weather cycle, with device selection, mounting and power treated as project scope rather than procurement detail. Dust, heat, vibration and glare each break something different, and none of them show up in a workshop test.

Should you build custom or configure what you already own?

We will say this plainly because it costs us work. If you are a large open pit with a broadly homogeneous fleet already running Modular Mining DISPATCH, Wenco, Hexagon or Caterpillar MineStar Fleet, do not commission a replacement as a first project. Those optimisers are the product of decades of operating data, and a custom rebuild is a multi year risk with an unclear upside.

The productive move with an incumbent is to get your own data out of it. Raw data access is usually the single most valuable term in that contract and it is rarely negotiated hard, because it is discussed by procurement rather than by the people who need the data. Ask for it at renewal, in writing, with a defined format and frequency. Then build the intelligence layer around the system you already own: mixed source ingestion, a canonical cycle model, daily reconciliation and short interval control alerting.

Build the whole thing when the licence and hardware model stops fitting 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 a few dozen trucks across many sites is paying for an optimiser when its actual problem is reconciliation and short interval control. And 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.

How do hidden costs get into the quote?

In cab hardware is the first and largest. Device selection, mounting, power, a field trial across a full weather cycle and the spares you will need after the first six months are all real work, and quotes that price software only are pricing half the project.

Source count is the second. Every manufacturer feed, payload scale, tyre monitoring system and fatigue camera is its own integration with its own authentication and its own maintenance. Get the full list from your maintenance planner rather than from memory, including the hired equipment.

Third is integration with a mine planning package or a plant historian, which is specialist work. Proprietary planning file formats and industrial data connectivity are not general web engineering and should be quoted by someone who names them.

Fourth is multi site rollout. Every site has its own delay code taxonomy, its own shift pattern and its own conviction that theirs is correct, so the second site is never simply a copy of the first.

Fifth is anything touching safety. If the system is expected to influence a safety related decision, the assurance and change control burden rises sharply and belongs in scope explicitly rather than as an assumption.

Ask for the estimate split into software, hardware, integrations, site rollout and assurance, each with an owner and a date, then ask what changes if a sixth telemetry source appears.

What separates a build that works from one that fails here?

Whether the dispatcher can override it. A dispatcher who cannot force an assignment will find a way to defeat the system by lunchtime, usually by going back to the radio, and once that happens the data has holes and the optimiser is arguing with reality. Build the override in from the start and record the reason, because those recorded reasons are the best source of information about where the model is wrong.

The second determinant is that the control room sees a forecast rather than a report. The screen that changes a shift says the north shovel will starve in eleven minutes, the tip queue is three deep and rising, and moving two specific trucks recovers tonnes before the break. That means tying live fleet state to the constraint that actually governs revenue that shift, whether that is crusher throughput, a blend target or a stockpile grade band, and alerting on the constraint rather than on the trucks. Push it to a phone or a rugged laptop, not to a wallboard nobody watches at 3am.

Third, use machine learning where it earns its place and nowhere else. Anomaly detection over payload distributions catches a drifting scale weeks before the calibration schedule finds it. Classification of free text delay comments turns operator shorthand into consistent codes without forcing a gloved operator to scroll sixty options. Neither needs a large model, and anything sold as an automated dispatcher should be judged on the queueing mathematics underneath it.

Finally, own the code, the data and the cloud accounts, in writing before kickoff. Vendor lock is usually the reason this conversation started, and accepting it again from a development partner would be an expensive irony.