Published: 20 May 2026
A practical guide for operations teams working through the architectural decisions the standard deliberately leaves open.
Two years on from publication, ISO 23725:2024 has settled into the mining technology conversation as the international standard for autonomous haulage interoperability. Most teams working with it now understand what it does. Fewer have thought carefully about what it deliberately doesn't do, and why that matters more than the published specification suggests.
The standard defines the interface between Fleet Management Systems (FMS) and Autonomous Haulage Systems (AHS) in surface mining: how the two systems talk, what messages they exchange, how mine maps and dispatching information move between them. What it deliberately doesn't define is who, on either side of that interface, owns which operational responsibility. Who generates trajectories? Who manages traffic rules on the haul road? Who handles vehicle-to-vehicle interaction policies? Those questions are left open.
If you're scoping an autonomous haulage deployment and looking to the standard for direction, that can feel like an unfinished section of a specification. It isn't. The ambiguity is the feature that makes open autonomy possible across the very different starting points mines actually have, and getting comfortable with it is part of the implementation work.
The interface is not the architecture
Think of ISO 23725 as defining the shape of a connector between two systems without dictating what goes on inside either one. The connector has to be specified precisely (message formats, protocols, the structure of a mine map exchange) so that any FMS and any AHS implementing the standard can plug into each other. What sits behind the connector on either side, and which side of it owns which responsibility, is left to the operation and its chosen partners.
That distinction matters because mining operations deploying autonomous systems aren't starting from a blank slate. Your operation may already have a mature FMS handling dispatch, production tracking, equipment assignment, material movement, and operational reporting, and adding autonomy means introducing an AHS that has to work with that existing FMS without disrupting workflows people already depend on. A neighbouring operation may be entering both autonomy and comprehensive fleet management through an AHS provider, in which case that vendor often takes on functions that would otherwise sit with an FMS. A third operation may be preparing a mixed-fleet environment with multiple OEMs and technology partners, where responsibility allocation is one of the harder questions the integration team will face.
If the standard dictated exactly which system handles trajectory generation, traffic rule management, or vehicle-to-vehicle coordination, it would break compatibility with at least one of those starting points. The flexibility isn't sloppiness. It's what lets the standard work across fundamentally different deployment contexts.
Responsibility allocation isn't the only deliberate gap, either. The standard explicitly leaves two related areas outside its scope: computer system authentication, authorization, and cybersecurity (the rationale being that mature IT practice already covers these well); and the specific requirements for safe operation of machines, which the standard treats as part of the agreement between the FMS and AHS supplier rather than something that can be specified once for every site. The architectural ambiguity discussed in this piece is the third, and the one that surfaces most often in implementation planning conversations.
What actually drives the responsibility split
When operations teams and vendors negotiate responsibility boundaries in real deployments, four factors tend to do most of the work.
Who was there first. If your operation has an established FMS handling certain functions, the AHS typically integrates around those existing capabilities rather than duplicating them. The incumbent advantage isn't about territory; it's about not disrupting systems that already work for the people who run shifts.
Vehicle capabilities. An autonomous haul truck with substantial onboard computing might handle local trajectory planning more effectively than constantly requesting paths from a remote system. A simpler retrofit kit might push more intelligence to the fleet controller. The standard accommodates both approaches; the choice depends on the truck, not the standard.
Network connectivity. Most autonomous systems are latency-sensitive and require local decisions. Architectural choices have to account for the connectivity that exists, not the connectivity that would be ideal, particularly in operations with challenging coverage at the pit floor or in transition zones.
Safety certification and rating boundaries. Different jurisdictions and operations have varying requirements for what needs to be validated (through formal certification, safety ratings, or demonstrated behaviour). Where those boundaries fall influences where it makes sense to place safety-critical decision-making. If your AHS has certified behaviours or demonstrated safety ratings, you'll likely keep related responsibilities within that validated scope rather than splitting them across the interface. This is also where the standard's deliberate hand-off to the FMS-AHS supplier safety agreement becomes operationally significant.
Patterns emerging from real deployments
ISO 23725 doesn't prescribe architectures, but patterns are emerging from actual implementations. These aren't rules. They're observations about what tends to work in the deployments visible across the industry.
Fleet Management Systems usually handle higher-level route optimization and production-oriented vehicle assignment. The FMS plans truck assignments across multiple loading areas while considering crusher throughput and blend requirements. As the source of truth for production data (targets, equipment availability, operational constraints), the FMS drives the strategic decisions that align autonomous operations with the broader mine plan.
Autonomous Haulage Systems typically handle local trajectory planning and immediate obstacle response. Once an AHS receives a segment or waypoint assignment, it usually plans its specific path considering the vehicle's current state, local conditions, and immediate obstacles. Time-critical decisions stay close to the vehicle, where they need to happen.
How those two layers relate to each other architecturally varies between implementations. Sometimes they sit as peers across the ISO 23725 interface, with a clear handshake at the boundary. Sometimes the FMS sits as a higher-level coordination layer above the AHS. Either pattern can work; the standard is intentionally agnostic on which, and the right choice for your site depends on which factors from the previous section weigh most heavily for your operation.
The implementation planning conversation
This is the conversation worth having early, before integration testing, ideally before vendor selection is final. Because ISO 23725 leaves responsibility allocation to the parties involved, the architecture work doesn't get easier by waiting. It gets harder.
Seven questions worth pressing on with each vendor under consideration, and worth answering jointly with the vendors you've chosen once selection is settled:
- Which system will remain the source of truth for mine maps, equipment locations, and production status? Production data has gravity. Wherever it already lives well is usually where it should keep living.
- Which system will assign autonomous haulage tasks? Task assignment is the function ISO 23725 most explicitly defines an interface for, but the question of which side originates the assignment is left to you.
- Where will traffic management decisions be made? Static rules (haul road priorities, exclusion zones) and dynamic decisions (live conflicts at intersections, queue management at the loader) may sit in different layers.
- Which system will handle route constraints, exceptions, and changes during the shift? A road grader's position, a closed bench, a weather-related restriction: these change during the shift, and the rule for who decides matters.
- How will autonomous and non-autonomous equipment interact in shared operating areas? Transition zones, manned light vehicles, and supervised work crews are usually where architectural responsibilities are most consequential and where the published safety case has to be most explicit.
- What data needs to flow back into planning, reporting, maintenance, and continuous-improvement processes? The autonomous fleet is generating telemetry continuously; deciding which streams go where, in what format, on what schedule, is part of the architecture, not an afterthought.
- How will responsibility boundaries change as the operation adds more autonomous equipment, new pits, or additional vendors? An architecture that works for the initial deployment may not be the one that works at scale. Building room for the architecture to evolve is itself a planning question.
These questions aren't signs the standard is incomplete. They're the design decisions that make autonomy work in a live mining environment: the ones that, if left unresolved, surface during commissioning rather than during planning. Better the architecture discussion than the integration test.
Document the answers. ISO 23725 defines the interface requirements; your implementation needs documentation beyond that. Which optional features are you implementing? How are you interpreting the areas where the standard allows flexibility? Which messages will you actually use? Writing those decisions down now prevents confusion when vendors change teams, when the FMS or AHS is upgraded, or when a new partner needs to integrate with the architecture you've built.
Why the flexibility is worth the work
A single-vendor closed stack avoids the interface-negotiation work described above because one supplier controls the architecture from vehicle control through fleet management. The same architectural decisions still get made (someone has to decide who handles trajectory generation, traffic rules, and the rest); they just get made internally, without exposure to or input from the customer.
That's a legitimate engineering choice, and the closed-stack approach has produced well-engineered, well-supported autonomous operations at scale. The trade-off it asks you to accept is that the architectural decisions, the choice of vehicles, the fleet management approach, and the upgrade path are coupled. Changing one tends to mean changing the others.
The flexibility in ISO 23725 (the thing that can feel frustrating when you're trying to nail down who owns trajectory generation) is part of what enables a different deal. It's the architectural condition that allows an operation to keep an existing fleet management system while adding autonomy, lets autonomous vehicle providers work with multiple fleet controllers, and gives new entrants room to design systems that interoperate with existing deployments rather than requiring total replacement.
None of those outcomes are delivered by the standard alone. They depend on partnerships, on commissioning quality, on the FMS-AHS safety agreement, and on the implementation planning work the previous section described. The standard makes them possible. The work makes them real.
Open at the handshake, not the algorithms
It's worth being clear about what "open" doesn't mean. Architectural flexibility under ISO 23725 doesn't require vendors to share proprietary technology. The standard defines interfaces (the messages and protocols between systems), while each vendor retains the intellectual property in how their systems actually work internally. An FMS vendor's optimization algorithms remain proprietary. An AHS provider's obstacle detection and trajectory planning methods stay competitive advantages. What gets standardized is the handshake between systems, not the intelligence within them. Vendors still differentiate on performance, algorithms, domain expertise, and innovation inside their protected technology stack.
The work ahead, and Wenco's part in it
ISO 23725 reached publication in August 2024 after several years of working-group effort across the industry. Wenco championed that work because we believed (and continue to believe) that the FMS-AHS interface is the place where standardization creates the most value for mining operations: it removes a blocker that was previously addressed through bespoke integration on every site, while leaving the architectural decisions where they belong, with the operation and its chosen partners.
The standard is the foundation. The shared understanding of what works at the implementation level (which responsibility splits hold up in different operational contexts, which patterns to be wary of, which questions to ask before signing) is being built deployment by deployment, often in partnership conversations that don't show up in the public record. Some of that work is being captured publicly at OpenAutonomy.com, where contributors from across the ecosystem are writing up what they've learned. The rest is in the planning conversations happening at sites right now.
If you're working through these questions for your own operation, the questions are the right ones whether or not Wenco is your FMS vendor. The flexibility in the standard is what lets you build an architecture fitted to your operation rather than conforming to someone else's assumptions about how your mine should work. That flexibility is also what makes the planning work non-optional, and worth doing carefully.
ABOUT THIS PIECE
Wenco championed ISO 23725 through the working group that brought it to publication in August 2024 and is a founding contributor to OpenAutonomy.com (the vendor-neutral, contributor-led platform) where this piece first appeared on 30 December 2025. If you're working through the implementation planning questions described above, the team behind Wencomine (Wenco's fleet management system) is happy to talk through what we've learned from the deployments we've supported. Get in touch at info@wencomine.com.
Published: 20 May 2026
Last Updated: 20 May 2026