ISO 23725 has no third-party verification. So what can a buyer check?
By the OpenAutonomy.com Editorial Team
As demand for interoperable system capabilities grows, we expect more commercial proposals to claim support for ISO 23725. Some may phrase it as “compliant with”; others as “aligned to”.
It’s unlikely that those words mean what a buyer hopes they mean, and that is not the vendor's fault. It is a gap in the industry's state of maturity regarding standardised interoperability.
ISO 23725 was published in August 2024. It defines the interface between a fleet management system and an autonomous haulage system in surface mining: the communication, the message structures and their meaning, map sharing, truck dispatching, telemetry and production monitoring. ISO approved the project in December 2020, building on groundwork that began when ISO/TC 82/SC 8 was formed in 2018.
What hasn’t been built alongside it is the apparatus that normally follows a standard into the world. There is no published test suite. There is no accredited test laboratory. There is no reference implementation or simulator a vendor can run their system against. There is no “plugfest” where implementations meet and exchange messages under observation. There is no public register of what has been tested and passed.
In practice, that means when a vendor says their system supports ISO 23725, there is no independent certification behind that statement, so buyers need to examine the evidence supporting the vendor’s claim.
What other industries built, and why
Other industries have solved this problem, and the solutions are not exotic.
ODVA runs conformance testing for EtherNet/IP devices, because industrial networks with multi-vendor devices stop working otherwise. The FIDO Alliance requires implementers to pass conformance self-validation and then attend interoperability events where their implementation is tested against the other participants' implementations. The IEC 61850 community, which deals with substation automation, uses test labs accredited through the UCA International Users Group, because varying interpretations of a complex standard are a known risk when the people testing the equipment are also the people who designed it.
That last community also learned something mining should absorb before it repeats the mistake. Certification against the standard does not guarantee interoperability with any particular third-party system. Two certified devices can still fail to work together, because timing behaviour and other design variables sit outside what the standard specifies. Conformance and interoperability are separate properties, and you need to test for both.
Mining currently has no common test for either.
The boundaries the standard draws around itself
The standard is also honest about what it does not cover, and buyers should read those exclusions rather than skip them.
Authentication, authorisation and cyber security are explicitly outside its scope, on the reasoning that these are handled by normal IT practice. Reasonable as a drafting decision, but it means conformance tells you nothing about whether the interface is secure.
More significant is the second exclusion. The standard states that the specific requirements for safe operation, including the execution of task assignments issued by the FMS to the AHS, depend on additional information agreed between the FMS supplier and the AHS supplier, and that this agreement sits outside the document.
Read that carefully, because it is the most commercially important sentence in the standard. Two fully conformant systems can still require a private bilateral agreement before they can safely run a mine. Conformance gets you a common language. It does not by itself get you a working pair, and it certainly does not get you a pair that can be swapped.
None of this makes the standard less valuable. It makes it a floor rather than a guarantee, and a buyer who treats it as a guarantee will be disappointed at a moment not of their own choosing.
That does not mean interoperability cannot be demonstrated today. It means the demonstration is currently the vendor's job rather than a certificate's. A vendor with a genuine implementation can show it: a clause-by-clause implementation statement, integration testing against other suppliers' systems, regression testing across software releases, and time in production at an operating mine. That is not a substitute for independent assessment, but it does distinguish an implementation that has been built and run from one that has only been described. The checks below are designed to draw that evidence out, and a vendor who has it should find them easy to answer.
Six things a buyer can ask for
Ask for a written implementation statement, requirement by requirement. Any standard of this kind contains requirements and recommendations, and a system can implement some and not others while still using the word “supports”. Ask which clauses are implemented, which are partially implemented, and which are not. A vendor who cannot produce that document in a fortnight has not thought about conformance as carefully as their proposal implies.
Ask what it has been tested against, by name. Not whether it supports the standard. Which systems from which other vendors it has exchanged live messages with, at which sites, on what dates, and whether that was a laboratory, a demonstration or a production operation. The gap between those three is enormous and the word “tested” covers all of them.
Ask for the interface documentation before contract award. If the interface control document is only available after signing, or only under an NDA that survives the relationship, you have learned something useful about how the rest of the contract will go.
Run a witnessed test at acceptance and test the failures. A second system or a simulator, exercising dispatch, map update, task assignment and telemetry. Then break things deliberately: message loss, a malformed or partial map, a version mismatch, one side restarting mid-cycle, clock drift between the two. The happy path always works in a demonstration. Most of what goes wrong on a live site goes wrong in the other cases.
Make the bilateral safety agreement a deliverable. Since the standard says safe task execution depends on information agreed between the two suppliers, ask for that agreement as a named, versioned document you receive a copy of. If it exists only as an understanding between two engineering teams, it will leave when they do.
Require retesting on version change. Conformance is a state at a moment, not a permanent property of a product. A minor release on either side can break it silently, and you will find out during a shift rather than during a test. Put the retest obligation in the support agreement.
Someone should build the missing part
The industry has the standard and not the scaffolding, and the scaffolding is the cheaper half. A published test suite, a reference implementation or simulator that vendors can run against without involving a competitor, a periodic interoperability event, and a public register of what has been tested. Every one of those exists in other sectors and none of them required inventing anything.
The Global Mining Guidelines Group, already a formal liaison to the ISO subcommittee and having done the work of turning regional practice into international guidance on autonomous systems, is one natural home for it. Until something like it exists, the burden of verification sits with individual buyers, who each have to reinvent the test, one procurement at a time, without the leverage or the expertise to do it well.
If you operate a mine or supply systems on either side of this interface, and you would support a shared test framework, the OpenAutonomy.com editorial team would like to hear from you.
