← Technical papers

LP-TP-001

Reference Architecture for an Autonomous Mining Vehicle

A software decomposition for heavy mobile equipment operating inside a constrained mining operational design domain.

REV A2026-09-29LPLATESDRIVER TECHNICAL NOTE

1. Scope

An autonomous mining vehicle is not a single algorithm. It is a stack of cooperating systems that converts sensor data and mission intent into safe vehicle motion. A useful architecture keeps perception, localisation, planning, machine control and fleet supervision separate enough to test independently while retaining a well-defined machine state shared across the stack.

PERCEPTION
LOCALISATION
MISSION + PLANNING
VEHICLE CONTROL
DRIVE-BY-WIRE

2. Operational design domain

The first boundary is the operational design domain (ODD): the roads, work zones, weather, visibility, gradients, traffic types, communications assumptions and machine states in which autonomous operation is permitted. The autonomy supervisor should be able to determine whether the vehicle remains inside that envelope and transition to a defined fallback state when it does not.

3. Perception and localisation

Perception builds an estimate of free space, obstacles, lane or road boundaries, work-zone features and nearby mobile equipment. Depending on the application, this can combine camera, LiDAR and radar. Localisation fuses GNSS/RTK, inertial measurements, wheel or drivetrain information and map constraints into a continuous vehicle pose and confidence estimate.

4. Mission management and planning

Mission management describes what the vehicle should do: travel to a loader, wait in a queue, spot at a loading point, travel to a dump, clear an intersection or enter a safe hold. Motion planning describes how to execute the current mission safely inside the local environment. Keeping these layers separate makes fleet commands easier to reason about and vehicle behaviour easier to validate.

5. Vehicle control

The control layer converts the planned trajectory into steering, propulsion and braking requests while respecting machine limits. A drive-by-wire adapter then maps those requests to the electronic, hydraulic or electromechanical interfaces available on the specific machine. Safety interlocks should sit below high-level mission logic so a bad mission cannot directly bypass machine limits.

Design principleHigh-level autonomy should request behaviour; lower-level control should enforce the machine envelope.

6. State, health and fallback

A robust autonomy supervisor needs explicit states such as READY, MISSION_ACTIVE, YIELD, HOLD, DEGRADED and SAFE_STOP. Sensor health, localisation confidence, communications health and control-interface status should be inputs to these transitions rather than ad-hoc exceptions scattered through the stack.

7. Industry alignment

This architecture uses terminology common across current mining-autonomy systems: perception, path planning, autonomous management, drive-by-wire, mission management and fleet supervision. Hexagon publicly describes autonomous world perception, path planning and machine control, while Komatsu describes onboard perception, positioning and control systems managed through a fleet interface.

References