Mining fleet management: from GPS pings to cycle times
A mining or haulage fleet management system turns raw GPS and telematics pings into operational events: trips, loading, hauling, dumping, queuing, idle time and the cycle time of every haul truck and machine, then compares them with the dispatch plan. Mirage builds that layer on the telematics and dispatch systems a mine, quarry, port or logistics fleet already runs; at Transwin it is one of five systems in production across 550 trucks and more than 100 machines.
The problem
Having GPS dots on a map does not mean you understand the operation. For a large fleet the real questions are: where did the truck actually go, what was it carrying, when did it load, how long did it wait, why did the cycle take longer than usual, and which assets are underused.
Raw GPS pings answer none of that on their own. A position every ten seconds is not a trip, a stop is not a loading event, and a slow cycle has no cause attached. They have to be turned into operational events first, against the geography of your own sites.
What we deploy
A system that transforms raw GPS and operational data into operational events: trips, loading, unloading, waiting, idle time, deviations and cycle times, reconstructed automatically instead of inferred by eye from a map. It reads from the telematics provider, the dispatch tool and the ERP or TMS you already run, rather than adding another tracking platform.
Inputs, outputs, systems
| Reads | Produces | Connected through |
|---|---|---|
| GPS positions, speed, heading and ignition from the telematics units, typically every 5 to 30 seconds | Trips with start, end, distance and duration; stops classified as loading, dumping, queuing, refuelling, workshop or unexplained | Telematics provider API or scheduled export |
| Geofences for pits, loading points, crushers, stockpiles, dumps, workshops and fuel bays | Time in each zone per asset and per shift; queue time at each loading point | Drawn with your dispatchers from the site plan, maintained as the site changes |
| Dispatch assignments and shift plans | Planned versus actual per shift: cycles planned, cycles done, variance and its cause where readable | Dispatch or fleet management system API, or the shift sheet as it exists |
| Load records: weighbridge tickets, loader payload, truck factors | Tonnes per trip and per shift; a flag when tonnage, trip count and payload disagree | Weighbridge software, OEM payload systems, or the Mirage weighbridge module |
| Engine hours, fuel transactions, fault codes | Idle fuel burn, consumption per tonne-kilometre, assets with abnormal idle | Telematics, fuel systems or the Mirage fuel module |
| Asset master, operators, cost per hour from the ERP | Utilisation by asset, cost per cycle and per tonne, events written back to the ERP or TMS | ERP connector (SAP, Oracle, Microsoft Dynamics, Sage and others) |
Geofencing and event rules are configured around your sites and routes. Outputs are written where the team works: the dispatcher's screen, the shift report, the maintenance queue, the ERP.
How it works
Mirage ingests raw position data from the telematics provider alongside dispatch, ERP or TMS and load records, then applies geofencing and pattern detection to reconstruct what each asset was doing: which stops were loading events and which were queuing, how long each stage of the cycle took, and where the planned route or schedule diverged from what happened. The output is a structured event history per asset, not a GPS trail.
The rules are written with your dispatchers. A stop inside the loader geofence longer than ninety seconds is a loading event; a stop in the same geofence before it is queue time; a stop outside every geofence longer than ten minutes is unexplained and goes to the shift supervisor. Every threshold is yours and can be changed.
A haul cycle, worked through
An illustrative example with invented figures, to show what the system returns for one truck on one morning. Nothing here is a client's data.
| Stage | From the pings | Duration | Flag |
|---|---|---|---|
| Queue at loader 2 | Stopped inside the loader geofence, 06:12 to 06:21, loader busy with another truck | 9 min | Queue above the 5 min threshold |
| Loading | Stopped at the loader, payload rises to 38 t on the OEM system | 3 min | None |
| Haul, loaded | Pit to crusher, 4.2 km, average 18 km/h | 14 min | None |
| Dump | Stopped inside the crusher geofence, payload falls to 0 | 2 min | None |
| Return, empty | Crusher to pit, 4.2 km, average 26 km/h | 10 min | None |
| Unexplained stop | Stopped 1.1 km from the pit, outside every geofence, ignition on | 12 min | Sent to the shift supervisor |
| Cycle total | 06:12 to 07:02 | 50 min, of which 21 min not hauling | Idle fuel estimated from engine hours |
Over a shift, the same table for every truck gives the loader queue by hour, the trucks with the most unexplained stops and the cycle time by route, which is what dispatch adjusts the next day.
Operational interface
- Fleet map with reconstructed trips
- Cycle times per asset, per route and per shift
- Queues, loading and unloading events by loading point
- Utilisation by asset, hours hauling against hours available
- Route deviations, unexplained stops and alerts
- Plan vs actual per shift
How it is deployed
Forward-deployed: engineers on your site, with your dispatchers and fleet managers. The proof of concept usually runs on one month of telematics exports and the matching shift sheets, so you see your own cycles reconstructed before any commitment.
- First reply
- Within two business hours, from an engineer.
- Proof of concept
- On your own data (a telematics export, a transaction log, weighbridge tickets, dispatch records), one week after the first meeting.
- Pilot
- Fixed price, on one site or one fleet, with Mirage engineers deployed with your team. You can stop after it.
- Production
- The first workflow runs in 4 to 6 weeks. A system that spans several sites or a lot of field equipment is scoped at the first meeting and can take longer.
- After go-live
- Mirage operates, monitors and improves the system in production; your team keeps the decision on every exception. More than 200 systems have been connected so far.
- Price
- An annual subscription priced by volume after the pilot, from $10,000 to launch and $1,000 a month, quoted in the first conversation.
Transwin started with one document workflow and now runs five systems in production, fleet and fuel among them, with 12% lower fleet diesel consumption published in its case study.
FAQ
See what Mirage can run in your operations
Get a custom automation plan
Tell us where your operations lose time. We send back a written plan: which workflows are worth automating, what a deployment looks like on your systems, and the shortest path to production. No commitment.
Prefer to talk it through? Book a call