Autonomous Underground Rail Haulage: Architecture and Readiness Checklist

What is an autonomous underground rail-haulage system?

It is an operational system that assigns and supervises train movements inside a defined mine environment. It may coordinate onboard traction and braking control, train integrity inputs, route and switch status, localization, obstacle or intrusion detection, loading and unloading interfaces, wireless communications, central dispatch, alarms, logs and human intervention. The exact boundary must be written down because safety and performance gaps often appear between supplier packages.

Automation level should be described through permitted tasks and operating conditions, not a marketing label such as driverless. State who or what authorizes a movement, how the route is proved, what the train does when communication or localization quality degrades, and when an operator must intervene. The system also needs a controlled method for people, maintenance vehicles and manual trains to enter the automated area.

Why is system readiness a current procurement issue?

In September 2026, CNMC reported final acceptance and routine operation of an autonomous electric locomotive haulage project at Zambia's Chambishi Copper Mine. The announcement describes dual-train operation, automated loading and unloading, mobile communications, dispatch/protection and power-management integration. Those are project-specific claims from the project owner; they are useful here because they show that successful deployment is an integration and operating-model problem rather than a single-vehicle feature.

At the standards level, ISO/TC 82/SC 8 covers automated and autonomous mining systems and lists current work on reference architecture and communication interfaces. ISO 23725:2024 defines fleet-management/autonomous-haulage interfaces for surface haul trucks, not underground rail. Its scope limitation matters: it can inform interface thinking, but it must not be presented as an underground locomotive compliance standard.

Engineering note: Source discipline: current industry examples identify questions to ask; they do not prove that another mine, route or ShaoLi configuration will achieve the same outcome.

Which readiness gates should be closed before procurement?

A gate is closed only when evidence exists and the responsible mine authority accepts it. A supplier presentation, simulation or successful factory demonstration does not by itself prove underground route coverage, switch behavior, stopping performance, human exclusion or production integration at the site.

1. Approve the operating concept, automation boundary and production scenarios.
2. Complete route, rolling-stock, braking, power and hazard baselines.
3. Define position, train-integrity, switch and intrusion information required for every movement.
4. Survey communications and specify service levels for control, safety, monitoring and maintenance traffic.
5. Assign every interface and safe state to an accountable system owner.
6. Design manual, maintenance, degraded and emergency modes before normal automation logic.
7. Create FAT, site integration, commissioning and operational-acceptance evidence with pass/fail values.

How should communications and positioning be specified?

Start from message criticality. Movement authority, emergency commands, machine status, alarms, voice, video and maintenance data do not necessarily need the same latency, availability or bandwidth. Define which functions must continue through a single failure, which may degrade, and which require a controlled stop. Epiroc's published underground automation material recommends dedicated network segmentation, quality-of-service for time-sensitive traffic and sufficient coverage; the mine still needs a site-specific design and validation plan.

Positioning should be specified by what the control logic must safely decide. Include route coverage, block and switch transitions, stopping points, direction, confidence or quality indication, update behavior and loss-of-position response. Do not state one accuracy number without tying it to vehicle dimensions, stopping tolerance, route geometry and the protection concept.

What must happen when the system is no longer fully healthy?

List credible faults: lost communications, uncertain position, unproved switch, occupied block, obstacle alarm, overspeed, failed train-integrity input, braking fault, power loss, stalled train, inconsistent database state and unavailable supervision. For each, define detection, immediate response, permitted movement, alarm, operator role, recovery authority and evidence recorded.

A safe state is context-dependent. Stopping immediately may be appropriate in one block but may create another hazard at a crossing, loading point or grade. The risk assessment should determine the controlled response. The NSW autonomous mobile plant guideline emphasizes lifecycle risk management, interaction with people and other plant, operating modes, control-system integrity and change management—principles that remain relevant even though a rail project needs its own detailed engineering.

How do people remain part of an autonomous system?

Automation changes work rather than removing accountability. Dispatchers need a clear operational picture, alarm priorities and authority boundaries. Maintainers need isolation, test and controlled-entry procedures. Production teams need rules for loading, dumping and abnormal material flow. Emergency teams need access and recovery plans that remain usable when communications or power are impaired.

The HMI should explain mode, authority, route, vehicle status, alarms and required action without forcing operators to infer system state from raw data. Training must cover normal, degraded, maintenance and emergency modes, followed by competency assessment and periodic drills. Access control should prevent a train from receiving authority into an area released for people or other equipment.

What is a practical implementation sequence?

Do not compress these stages into a single commissioning event. Each open assumption should have an owner and closure date. Software version, route database, vehicle configuration and safety-related parameters should be controlled so that an accepted result can be traced to the configuration that enters production.

Which acceptance evidence should procurement require?

Tie payments and handover milestones to agreed evidence rather than broad statements such as system operational. Define who witnesses each test, acceptable results, retest rules and treatment of deferred functions. This gives both buyer and supplier a stable completion boundary.

• Requirements-to-test traceability for normal, degraded, maintenance and emergency scenarios.
• Route and communications coverage results with test conditions and unresolved exclusions.
• Positioning, block, switch and train-detection behavior at boundaries and failure conditions.
• Braking, stopping, holding and overspeed evidence for the approved train and grade cases.
• Interface tests for loading, unloading, power, signalling, dispatch and external systems.
• Alarm, event, command and configuration records suitable for incident reconstruction.
• Cybersecurity responsibilities, remote-access controls, backups and recovery arrangements.
• Manuals, training, spares, support escalation and configuration/change-control records.

Is retrofit or a new-build system the better starting point?

A retrofit may preserve rolling stock and reduce physical change, but legacy braking, control, wiring, documentation and interface access can limit automation. A new locomotive may provide cleaner integration, yet route infrastructure, mine processes and other rolling stock still require work. Compare both options through the same functional and acceptance requirements.

Begin with a bounded pilot only when the pilot architecture can grow without bypassing safety and configuration controls. A pilot that uses temporary coverage, manual workarounds or undocumented interfaces may demonstrate motion but not production readiness. Define what evidence is transferable to later routes and what must be repeated.

What should an automation RFQ include?

ShaoLi's autonomous transportation material and published case can support an initial technical discussion. The project team should still treat every proposed function, interface and performance value as configuration-specific until it is captured in approved project documentation.

• Current route and operating process, train formations, production targets and expansion plan.
• Vehicle, braking, switch, signalling, loading, unloading and power-system information.
• Automation boundary, required modes, human access and mixed-traffic assumptions.
• Communications architecture, coverage data, cybersecurity policy and remote-access rules.
• Applicable mine rules, local approvals, risk process and document language.
• Interface list, ownership matrix, acceptance scenarios, support model and change-control expectations.