The Flexibility Problem: Why ISO 23725 Doesn't Tell You Who Does What

By: Wenco International Mining Systems Ltd.

ISO 23725:2024 defines clear interfaces between Fleet Management Systems and Autonomous Haulage Systems. It specifies what messages get passed, what data formats to use, and how systems communicate. What it deliberately doesn't specify is where specific responsibilities should live. Who generates trajectories? Who manages lane-level traffic rules? Who handles vehicle interaction policies? The standard leaves these questions open.

This drives implementers crazy. You're trying to design a system architecture, and the standard that's supposed to guide interoperability won't tell you which side of the interface should handle what. But this ambiguity isn't a bug—it's the feature that makes open autonomy possible.

The Interface Isn't the Architecture

ISO 23725 is an interface standard, not an architecture prescription. Think of it as defining the shape of a connector between two systems without dictating what goes on inside either one. This distinction matters because mining operations deploying autonomous systems aren't starting from blank slates.

Some mines already have established Fleet Management Systems handling dispatch, production planning, and equipment tracking. Adding autonomy means introducing an AHS that needs to work with that existing FMS—but the FMS vendor might want to keep certain responsibilities they already handle well.

Other sites might have an autonomous vehicle provider as their entry point into both autonomy and comprehensive fleet management. That AHS vendor might naturally take on responsibilities that would otherwise sit with an FMS.

If the standard dictated exactly which system handles trajectory generation, or traffic rule management, or vehicle-to-vehicle coordination, it would immediately break compatibility with one of these scenarios. The flexibility isn't sloppiness—it's what lets the standard work across fundamentally different deployment contexts.

What Actually Drives the Splits

When implementing open autonomy solutions with different autonomous vehicle providers, responsibility boundaries get negotiated based on practical factors:

Who was there first often determines a lot. If a mine 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.

Vehicle capabilities shape what makes sense to centralize versus distribute. An autonomous haul truck with substantial onboard computing might handle local trajectory planning more effectively than constantly requesting paths from a remote system. But a simpler retrofit kit might push more intelligence to the fleet controller. The standard accommodates both approaches.

Network connectivity constraints become real architectural drivers. Most autonomous systems are latency-sensitive operations requiring local decisions, so architecture often accounts for connectivity limitations. The standard accommodates different approaches based on these operational realities.

Safety certification and rating boundaries matter significantly. Different jurisdictions and operations have varying requirements for what needs to be validated—whether through formal certification, safety ratings, or demonstrated behavior in specific operational cases. Where those boundaries fall influences where it makes sense to place safety-critical decision-making. If your AHS has certain certified behaviors or demonstrated safety ratings, you might keep related responsibilities within that validated scope rather than splitting them across the interface.

Patterns Emerging From Real Deployments

While ISO 23725 doesn't prescribe architectures, patterns are emerging from actual implementations. These aren't rules—they're observations about what tends to work.

Fleet Management Systems handle higher-level route optimization and production-oriented vehicle assignment. The FMS controls the planning when balancing truck assignments across multiple loading areas while considering crusher throughput and blend requirements. As the source of truth for production data—including production targets, equipment availability, and operational constraints—the FMS drives these strategic decisions that align autonomous operations with mine planning objectives.

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. This puts time-critical decisions close to the vehicle where they need to happen.

It's worth noting that in many architectures, the FMS is viewed as a component within the broader AHS ecosystem rather than as separate, equal partners. This perspective acknowledges that autonomous operations ultimately depend on fleet-level coordination and production alignment—functions that the FMS provides. However, even with this architectural view, implementations vary based on specific technical and operational contexts.

The Questions You Should Actually Ask

If you're planning an open autonomy implementation, the ambiguity in ISO 23725 means you need to be explicit about questions the standard leaves open:

1. Do both vendors commit to following the ISO 23725 standard? This foundational question needs explicit confirmation. Without shared commitment to the standard's interfaces and principles, you don't have a basis for open autonomy integration.

2. What responsibilities does each vendor expect to handle? Get this clear early. The FMS should be established as the source of truth for production data and coordination functions. If your AHS vendor has built their system expecting to own functions that properly belong with the FMS, you'll discover the conflict eventually. Better to surface it during architecture discussions than integration testing.

3. Where do safety-critical decisions happen, and how are they validated? The interfaces defined in ISO 23725 need to support safe operation regardless of how you split responsibilities. Make sure you're explicit about how safety functions map to system components and how that aligns with certification requirements.

4. What happens when capabilities overlap? You might have an FMS that could handle certain traffic management functions and an AHS that also includes those capabilities. How do you prevent conflicts? Who has final authority if systems disagree? These aren't technical questions the standard can answer—they're operational decisions you need to make.

5. How do you document the agreed architecture? ISO 23725 defines interface requirements, but your specific implementation needs documentation beyond that. What messages will you actually use? What optional features are you implementing? How are you interpreting areas where the standard allows flexibility? Writing this down prevents confusion when vendors change teams or systems get upgraded.

6. 
   

Why This Matters for Open Autonomy

Closed autonomy systems ostensibly don't have this interface negotiation problem because one vendor controls the entire stack from vehicle control through fleet management. However, in practice, these closed systems still face similar architectural questions internally—they simply don't expose those decisions or allow customers to influence them. When that vendor decides internally how to split responsibilities, customers have no visibility or input into those choices.

That architectural opacity comes with the trade-offs that open autonomy exists to address. You're locked into that vendor's ecosystem—their choice of vehicles, their fleet management approach, their upgrade path. Some closed-stack providers can now fit their autonomy to vehicles outside their own equipment lines, but you're still committed to their complete technology stack. Want to use a different fleet management system? You're replacing the entire autonomy solution.

The flexibility in ISO 23725—the thing that makes it frustrating when you're trying to nail down who owns trajectory generation—is what enables true vendor choice. It's what lets a mine keep their existing fleet management system while adding autonomy. It's what allows an autonomous vehicle provider to work with multiple different fleet controllers. It's what makes it possible for new entrants to design systems that interoperate with existing deployments rather than requiring total replacement.

Yes, it means more upfront architecture work. You can't just follow a standard recipe because the standard deliberately doesn't provide one—though it certainly provides helpful guidance and frameworks. But that work—explicitly deciding how to split responsibilities based on your specific technical capabilities, operational needs, and existing systems—is what gives you the flexibility to build a solution that actually fits your situation instead of forcing your operation to conform to someone else's architectural assumptions.

This architectural flexibility doesn't mean vendors share their proprietary technology. The standard defines interfaces—the messages and protocols between systems—while each vendor retains their intellectual property in how their systems actually work internally. An FMS vendor's sophisticated 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. This is how vendors differentiate: through superior performance, better algorithms, domain expertise, and innovation within their protected technology stack.

The Real Work Ahead

This architectural flexibility doesn't mean vendors share their proprietary technology. The standard defines interfaces—the messages and protocols between systems—while each vendor retains their intellectual property in how their systems actually work internally. An FMS vendor's sophisticated 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. This is how vendors differentiate: through superior performance, better algorithms, domain expertise, and innovation within their protected technology stack.

As more organizations implement ISO 23725, the industry would benefit from shared understanding of integration patterns and architectural decision frameworks—not proprietary algorithms or competitive technology, but the practical lessons about how to structure these multi-vendor implementations. What questions have proven important in real deployments? What responsibility splits have worked well in different contexts? Where have teams encountered unexpected complications?

That collective knowledge exists in bits and pieces across different implementations, but it's not systematically captured or shared. As open autonomy moves from early deployments to broader adoption, building that shared understanding becomes increasingly valuable.

The standard gives us interoperability at the interface level. The next step is developing shared wisdom about implementation approaches that work—while preserving the flexibility that makes vendor choice possible in the first place.