Comms Lag on Autonomous Haul Trucks Hides Stationary Faults

A haul truck that stops moving is not automatically a fault. A truck that stops moving and stops reporting is a fault that dispatch cannot see. On an autonomous haul fleet, those two conditions are separated by a communications path that includes onboard perception and control stacks, a wireless mesh or private LTE link, a fleet management system (FMS) traffic manager, and the dispatcher’s console. A break anywhere along that path produces the same symptom at the console: the truck’s last known state, frozen. If the last known state was “hauling,” the dispatcher sees a truck that appears to be working. It is stationary, and its fault is invisible.

This article dismantles one failure mode: a communications lag between autonomous haul trucks masking a stationary truck’s mechanical fault from the dispatcher. The framing is functional safety — IEC 61511 diagnostic coverage and proof-test methodology — not product claims. The sensor discussed here is a diagnostic element, not a safety device. It carries no SIL rating and no safety guarantee.

The mechanism: stale state presented as live state

Autonomous haul trucks report telemetry at a fixed cadence — position, speed, heading, payload, and a health word from the drivetrain, steering, and braking controllers. The FMS holds the last received packet and renders it. When the link degrades, packets are dropped or delayed. The console does not blank; it holds the last value. A truck moving at 25 km/h when the link failed will still read 25 km/h on the dispatcher’s screen ten minutes later, because nothing has arrived to overwrite it.

This is a classic stale-data problem. The dispatcher’s mental model is “the truck is moving.” The physical model is “the truck is stopped with a drivetrain fault, and its radio is also degraded.” Two independent failures — mechanical and communications — have combined into a single, silent condition.

The mechanical fault itself is mundane and well understood. A final drive seal fails and the gearbox loses oil pressure. A wheel motor overtemp trips. A steering accumulator bleeds down. A park brake fails to release. Any of these will stop a 300-tonne truck. None of them will stop the radio from transmitting, unless the fault also takes out the power bus or the antenna. The dangerous case is the compound one: the fault stops the truck, and a separate comms degradation hides it.

Why conventional alarms miss it

Conventional FMS alarms are edge-triggered and state-based. They fire on transitions: overspeed, overtemp, low pressure, geofence breach, loss of operator. A truck that is stationary because it is queued at a shovel, waiting on a loader, or parked for shift change is a normal state. The FMS has no alarm for “stationary” because stationary is routine.

The alarm that should catch this is a communications watchdog — a “no telemetry received” timer. But watchdogs are frequently configured with generous timeouts to avoid nuisance alarms on marginal links. A 60-second timeout on a link that drops for 90 seconds will fire; a 60-second timeout on a link that delivers one packet every 45 seconds will not. Intermittent, low-rate telemetry keeps the watchdog satisfied while the state data inside those packets is already stale.

There is a second gap. Health words are often transmitted as a single bitfield or a coarse enum. A drivetrain controller reporting “degraded” may not distinguish between “derate to 50 percent” and “stopped, do not move.” The dispatcher sees an amber icon, not a stopped truck.

Diagnostic coverage and proof-test framing

IEC 61511 treats diagnostic coverage (DC) as the fraction of dangerous failures detected by automatic diagnostics. The relevant question here is not SIL — this is a diagnostic system, not a safety instrumented function — but the DC methodology transfers directly. For the failure mode “stationary truck with mechanical fault, masked by comms lag,” what fraction of occurrences does the current architecture detect, and how quickly?

Three diagnostic layers are needed, and each must be independently testable.

**Layer 1 — link liveness with freshness stamping.** Every telemetry packet carries a monotonic timestamp from the truck’s own clock. The FMS computes age = now − timestamp. Any rendered value older than a defined threshold (for example, 3× the nominal report interval) is displayed as stale, not as live. This is a data-integrity control, not a safety claim. It converts a silent stale value into a visible one.

**Layer 2 — independent motion corroboration.** Position is corroborated against a second source: GNSS velocity, wheel odometry, or inertial measurement. If the last commanded state was “hauling” but corroborated velocity is zero for longer than a defined dwell, the FMS raises a “commanded motion not achieved” event. This is the diagnostic that catches the stationary truck even when the health word is ambiguous.

**Layer 3 — mechanical health word with discrete fault codes.** Drivetrain, steering, and brake controllers should transmit discrete, enumerated fault codes rather than a single degraded bit. “Final drive low pressure” is actionable; “degraded” is not.

Proof-test methodology applies to all three. A diagnostic that has never been exercised is an assumption, not a control. The link-freshness logic should be tested by injecting delayed packets on a bench harness. The motion-corroboration logic should be tested by commanding motion on a stationary truck in a controlled area and confirming the event fires. The health-word path should be tested by simulating each discrete fault code and confirming it reaches the dispatcher’s console with the correct priority.

What this changes for the dispatcher

The dispatcher’s job is to allocate trucks to shovels and manage the load cycle. A truck that silently stops is not just a safety exposure on the ramp; it is a production loss that compounds because no one is dispatched to recover it. The diagnostic layers above do not prevent the mechanical fault. They reduce the time between fault onset and human awareness, which is the only variable the control system can influence.

For mining reliability engineers and OT/SCADA integrators, the design implication is that telemetry freshness and mechanical health are separate data-quality dimensions and must be monitored separately. A single “truck online” indicator collapses them and hides the compound failure.

Getting started

Map your current FMS telemetry path and identify where state is held without a freshness check. Instrument packet age at the console. Add motion corroboration against a second velocity source. Replace coarse health bitfields with discrete fault codes. Then proof-test each diagnostic by injection — delayed packets, commanded-motion-against-stationary, and simulated fault codes — and record the results. Treat the output as diagnostic coverage evidence, not as a safety certification.

Source: internal-backlog — grounded in S5 engineering design notes, not a current market event.

Talk to S5 System about your site

S5 System designs and manufactures ultra-low-power industrial IoT sensors for mining, agriculture, infrastructure and utilities.

Discuss your IoT monitoring project — book a call.