← Back to Use Cases

Mining · Quarrying · Heavy Equipment

Mining Fleet & Autonomous Haulage

A mine isn't a single machine to monitor — it's trucks, excavators, drills and conveyors feeding a crusher and a processing plant, spread across a pit that can be kilometers wide. Relay fuses fleet telemetry with fixed-plant state so dispatch knows not just where each machine is, but what it's about to run into.

The problem: per-machine telemetry isn't situational awareness

Most fleet-management systems answer one question well: where is this truck, and what is its status. That's necessary but not sufficient for running a pit efficiently. The question that actually matters for dispatch is relational: truck 37 is approaching crusher 4, but crusher 4 is stopped, and truck 22 is blocking the alternate route. Answering that requires fusing haul-truck GPS and status with fixed-plant state — crusher and conveyor status, stockpile levels — in the same real-time picture, not two separate systems that a dispatcher has to mentally cross-reference.

The telemetry itself is heterogeneous by nature: GPS, vibration, fuel consumption, hydraulic pressure and tire pressure from a mixed fleet of trucks, excavators and drills from different manufacturers, alongside fixed-plant sensors on conveyors and crushers running industrial protocols, and increasingly LiDAR, radar and camera data from autonomous or driver-assist haulage vehicles.

How Relay fits

  • →One bus for mobile and fixed assets: haul-truck telemetry arriving over cellular or private LTE/5G and fixed-plant telemetry arriving over Modbus or OPC UA land on the same Relay cluster, so a dispatch or routing agent sees both without querying two systems.
  • →Runs at the pit or the plant, on-prem: mine sites are often remote with limited or metered backhaul; Relay's rate card and feature set don't change between a cloud region and a rack in the site's own communications room.
  • →QUIC with multipath and connection migration: a truck moving across a pit that spans multiple radio cells keeps its telemetry session alive through handoffs, rather than dropping and reconnecting.
  • →Sub-millisecond routing: a stopped-crusher or blocked-road event reaches the dispatch and routing logic fast enough to actually re-route a truck before it arrives.

A typical architecture

Trucks, excavators and drills publish GPS, vibration, fuel and hydraulic telemetry over cellular or private wireless to a Relay cluster running at the site. Fixed-plant equipment — crushers, conveyors, weighbridges — publishes over Modbus or OPC UA to the same cluster. A dispatch or routing agent subscribes to both streams and reacts to combined state: it can hold a truck, re-route it around a blocked haul road, or flag an excavator whose hydraulic pressure pattern is drifting toward a known failure signature — all from one real-time picture instead of reconciling separate fleet and plant systems by hand.

Why on-site processing matters

A haul-truck routing decision that depends on a round-trip to a distant cloud region is a decision made too late to matter — the truck has already committed to a route by the time the answer comes back. Running the fusion and routing logic on-site, on the same network as the trucks and the plant, keeps that decision inside the latency budget that dispatch actually needs, and keeps the pit running the same way whether or not the site's uplink to a corporate network happens to be up.

See it against your own architecture

Every protocol and transport on this page is available on the Free plan. Run it on your own hardware before you talk to anyone.