Autonomous Haulage Is a Network Problem Too

Search for autonomous mining trucks and the results are about perception: lidar and radar coverage, camera fusion, obstacle classification, how the truck sees. It is difficult engineering, and it is not the part that decides whether the system can be operated at a real mine.

The people who built one of these systems and put it into a working mine describe something different. In a paper presented at the 37th International Symposium on Automation and Robotics in Construction in 2020, engineers from Hitachi Construction Machinery set out the safety concept and architecture of the autonomous haulage system their company developed. What they describe is a distributed control system: software in an office, software on the truck, a wireless communication system holding the two halves together, and a safety layer designed to act regardless of failures in the main autonomy functions, while assuming, as the paper says plainly, that the site’s own user-level protections are working. Perception is one subsystem inside that, not the frame around it. That changes what testing an autonomous machine means.

The Published Architecture

The paper names four subsystems and says which side of the link each lives on. In the office sit the Fleet Management System, which issues dispatch instructions telling each truck which loading or dumping location to head for, and the Traffic Control System, which converts those into smaller driving instructions; per the paper, a dispatch instruction is passed through the traffic control layer before a truck acts on it.

The TCS is where a group of vehicles becomes a system. It communicates wirelessly with the autonomous trucks and with the manned vehicles working in the same area, and prevents interference between the autonomous trucks by dividing each route into sections and permitting each section exclusively to one truck at a time. When a truck’s permitted section overlaps the buffer area ahead of a manned vehicle, that vehicle’s operator is warned through an interface in the cab and the TCS simultaneously issues a deceleration or stop instruction to the truck.

On the truck sits the Vehicle Control System, which drives the machine to the assigned destination within the permitted section, comparing route map data received from the TCS in advance against its own position estimated from GNSS and an inertial measurement unit, and detecting obstacles with an environment recognition sensor. Joining all of it is the Communication System, which carries traffic between the other three subsystems and the manned-vehicle interface and monitors communication status, including the wireless link itself.

The Trade-off That Makes This a Network Problem

The paper frames the design choice as a spectrum. At one end is full centralisation, in which even actuator control could run on a server: fewer devices on the truck, easier software updates. Then the cost. Because vehicle responsiveness depends on communication performance with the central system, “system scale and operation are limited when the wireless communication infrastructure is not sufficient”. A centralised fleet is only as large as its radio coverage. At the other end, full decentralisation reduces that dependence and costs coordination, because the spread of independent decisions grows and fleet-level efficiency suffers.

What they built is neither. It is described as an intermediate approach achieving overall efficiency “by giving each vehicle a certain degree of autonomy”. Read that as an engineering requirement, not a philosophy: the truck gets autonomy in proportion to how much the link cannot be trusted.

So failures here are not mostly perception failures. The paper’s hazard table includes a truck deviating from its route due to an abnormality in the vehicle control, traffic control or communication subsystems, and its hazard identification names the loss of an operating instruction due to a communication error. Among the protective measures devised against the extracted hazards, one is stated plainly: “AHT will stop within the given permit section if the next permit is not obtained.” (AHT is the paper’s term for the autonomous haul truck.) That one line is the degraded-mode requirement in its entirety, and it is testable.

One architectural fact follows from that. The authors classify three top-level safety functions in their protection scheme; the two that operate during autonomous running, an approach speed limit when a manned vehicle comes close and a remote stop an operator or site personnel can trigger, do not ride the main communication system at all. The paper states that the channel carrying those signals is provided independently of it and used only for safety, so it is unaffected by the state or malfunction of the main control. Two networks, deliberately, with different obligations.

This Is Production Reality, Not a Research Programme

The same paper reports a trial at an Australian coal mine followed by commercial deployment at a second one, with the safety concept reported to and validated by mine safety managers and state regulators before operation was permitted. The authors name ISO 17757, the international standard for autonomous and semi-autonomous machine system safety in earth-moving and mining, as the basis for that concept.

The scale evidence sits with another manufacturer: Komatsu’s own published figures for its system describe seventeen-plus years of service and hundreds of commissioned trucks, and our sector pillar carries those numbers in full. Those are Komatsu’s figures about Komatsu’s system, and none of the manufacturers named in this article are cited as customers; this is industry framing drawn from their own published material. Seventeen-plus years and hundreds of machines is not a pilot; a deployed architecture with a service history says the questions above are settled somewhere and wide open everywhere else.

What Runs inside the Truck

The paper treats the truck as a subsystem and stops there, so what follows is our reading rather than the authors’.

An autonomous haul truck is still a haul truck. Underneath the autonomy layer sits the machine architecture our sector pillar sets out: a SAE J1939 backbone carrying engine, transmission, hydraulic, aftertreatment and diagnostic traffic, with higher-bandwidth links arriving beside it for workloads a small CAN payload was never meant to carry. The autonomy stack does not replace that. It sits on top and must reach through it, because the safety functions the paper describes end in physical action on the base machine: speed limit control, and braking on receipt of a remote stop.

So one truck holds at least three timing regimes answering to different physics. The machine control network is deterministic and periodic by design. The perception and autonomy path is high-bandwidth and continuous. The wireless backhaul is variable, weather-affected and topology-dependent in ways neither of the others is. Add the separate safety channel and there are four, sharing one vehicle and one set of consequences.

That is the practical reason autonomy is a network topic: the discipline that keeps a deterministic bus honest is not the one that keeps a variable wireless link honest, and an autonomous machine makes a team hold both at once.

The Bench Consequence

You cannot test a fleet in a pit first. Truck-side behaviour has to be established against a bench that stands in for a system the truck is not connected to, and the published architecture tells you what that bench must supply.

Rest bus simulation supplies the missing office. The Vehicle Control System expects dispatch, route map data, section permissions and manned-vehicle position information from subsystems that do not exist on your bench. Something has to send them, correctly and on time, or the controller never leaves its startup state. The build discipline is the one we set out for rest bus simulation on Ethernet-based vehicles, including the trap that post’s whole argument turns on.

Fault injection tests the degraded mode, which is the whole point. The intermediate-autonomy design is, restated, a specification for behaviour when the office goes quiet, so the campaign writes itself. Stop sending permissions and confirm the truck halts inside its current section rather than running on its last instruction. Delay a permission and check whether the truck treats late as absent or as valid. Corrupt a route update and see whether it is rejected or acted on. Drop the link mid-section and watch recovery, including whether stale instructions are discarded. Each row needs a written expected behaviour and observable before the fault is applied, which is the campaign structure in our guide to fault injection in HIL. The independent safety channel gets its own row: what the remote stop does when the main communication system is dead is the design claim, not an edge case.

Capture is the evidence, and here it is more than hygiene. The ISARC authors note that mining companies deploying autonomous systems report safety plans to state inspectors, and that a system integrator may be asked for its architecture, safety concept and functional safety study before operation is approved. A pass in a spreadsheet is weak there; correlated captures of what the bench sent, when it stopped and how the machine-side network responded are strong. Where the capture point goes, and what it quietly changes, is the subject of our post on capturing in-vehicle traffic.

Where an Indian Team Starts

The CII-BCG study prescribes a four-layer adoption path for autonomy in India, summarised in our sector pillar; its first two layers are connecting machines and capturing data, then adding operator assistance and collision avoidance. The same page of the study names remote-operation systems and safety-certified components, whose standards side our ISO 19014 explainer unpacks, as capabilities India will need to build or partner to acquire (Source: CII-BCG, Pressing the Throttle, July 2026, p. 27).

The study makes no claim about test benches, network capture or validation method, and we are not putting words into it. The step from its adoption path to what a team does on a bench is our reading. That reading is simple: layers one and two are bench-buildable today by teams with no autonomous fleet in sight. Layer one is data capture on the machine, a J1939 and Ethernet instrumentation problem. Layer two is structurally the approach speed limit function from the ISARC paper, a position exchange and a proximity determination ending in an action on the base machine. Both can be specified, simulated, fault-injected and evidenced on a bench, and that competence is what layers three and four consume.

Where GSAS Fits

GSAS Micro Systems is an engineering partner, and the part of autonomy work we are useful for is the half nobody photographs: the bench that proves what a machine does when its network misbehaves. The sector view sits on our construction and mining solutions page.

For teams working on autonomy or assistance functions, three conversations come up. The first is bench design for degraded communications: standing up the missing half of a distributed system convincingly enough that removing it proves something. The second is capture and correlation across a mixed machine, where a control bus and a higher-bandwidth link have to be observed against a shared timebase before any cross-network claim is credible. The third is evidence that holds up inside a customer’s safety case; the fleet-data version of that is in how machine data reaches a fleet portal.

Degraded-comms bench work runs from our offices in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR. Request a consultation with the function you are validating and the half of the system you do not have, and the reply will be a bench and fault-campaign outline for exactly that half.

References

• H. Ishimoto and T. Hamada (Mining Solutions Division, Hitachi Construction Machinery Co. Ltd), “Safety Concept and Architecture for Autonomous Haulage System in Mining”, Proceedings of the 37th International Symposium on Automation and Robotics in Construction (ISARC 2020), pp. 377-384: https://www.iaarc.org/publications/fulltext/ISARC_2020_Paper_197.pdf
• ISO 17757, “Earth-moving machinery and mining, Autonomous and semi-autonomous machine system safety”, cited at title level as the standard the ISARC authors name as the basis for their safety concept
• Komatsu, autonomous haulage system product page, figures as published October 2025: https://www.komatsu.com/en-us/technology/smart-mining/loading-and-haulage/autonomous-haulage-system
• Confederation of Indian Industry and Boston Consulting Group, “Pressing the Throttle: How India’s Mining and Construction Equipment Industry can support domestic ambitions and become a global force”, July 2026, p. 27