AMR interoperability is not one checkbox

Order replay and rejection evidence — method added 13 October 2026

A successful dispatch demonstration leaves a practical buying question unanswered: what happens when the same update arrives again, or an older update arrives after a newer one? Keep that scenario separate from the happy-path result. Ask for evidence from the proposed robot and fleet software pair, under an authorised test plan, before using a broad interoperability claim in an acceptance decision.

The pinned VDA 5050 3.0.0 source distinguishes an outdated update from a repeated update. For the same order identifier with a lower update identifier, it describes retaining and continuing the previous order while reporting OUTDATED_ORDER_UPDATE. With matching order and update identifiers, it distinguishes unchanged content, which is ignored, from changed content, which produces SAME_ORDER_UPDATE_ID. These are documented expectations for that specification revision, not observations of a supplier implementation.

The official release notes also highlight the repeated-ID check and distinguish resending the same message from reusing its update identifier with different content. That makes the content reference material evidence, not an optional annotation. Record the specification revision and implementation builds; do not silently borrow a result from a different version or assume the release notes certify a product.

Build the review around two separate questions: what response was reported, and what happened to the previous order? A warning in a log can answer the first while leaving the second unresolved. Put the prior accepted order reference, incoming update reference, expected handling, response trace and observed prior-order state on the same dated record. Keep missing or contradictory observations visible.

For example, a hypothetical test report could contain the expected error name but no evidence of whether the prior order continued. The useful next step is a specific evidence request to the integration owner, not a blanket pass. Conversely, a recorded continuation does not prove the expected error was correctly reported. Neither observation should stand in for the other.

The buyer and integration owner should agree the scenario, permitted test environment, evidence capture and acceptance boundary before any test. This guide does not direct anyone to inject messages into a live fleet or repeat an operational command. Safety, permissions and operating controls remain with the responsible owners. The local worksheet sends no commands and reads no broker traffic.

Use the exported record to preserve a reviewer disposition: accepted within a stated boundary, evidence still requested, or progression withheld. Filling every field only assembles the record; it does not inspect traces or issue conformance certification. Reopen affected evidence when the software pair, protocol revision, message profile or tested assumptions change. This dated method extends the existing guide without changing its original publication and review dates.

Start with the information or control that must cross the boundary

An AMR can support an interoperability specification and still fail the customer's integration need. The useful requirement is not simply "interoperable". It is the exact exchange required: who creates missions, who coordinates traffic, which status and map data are shared, which business systems connect, and what happens when communications fail.

RobotAtom therefore treats interoperability as several requirements with named owners, directions, versions, operating conditions and acceptance tests. Support for one interface is evidence for that interface's published scope, not proof that a complete mixed-fleet deployment will work.

Four commonly grouped interfaces solve different problems

• VDA 5050 version 3.0.0 defines operational communication between a central fleet control and mobile robots. It uses MQTT and JSON and adds zones and path sharing for freely navigating robots, but its scope excludes traffic-management algorithms, safety requirements, cybersecurity controls, peripheral and external IT interfaces, and commissioning methods.
• MassRobotics AMR Interoperability Standard 1.0 focuses on sharing information so different mobile robots can coexist. The working group explicitly says it does not address AMR safety; its published material describes status and location sharing rather than a universal fleet controller.
• OPC UA for Robotics Part 1 version 1.02 provides an information model for representing a motion-device system to higher-level control and evaluation systems. That can support asset, operating-state and condition data, but it is not the same contract as VDA 5050 order dispatch.
• ROS 2 provides software interfaces and middleware choices inside distributed robot systems. Compatible message definitions, middleware, discovery, quality-of-service and security settings still need to be agreed; a product statement that it "supports ROS 2" does not define a fleet integration.

Put the version and profile into the requirement brief

For each boundary, record the protocol and version, message or information model, mandatory and optional fields, coordinate frame, units, update rate, latency, authentication, network path, error handling and control authority. Also name the system of record for missions, maps, traffic rules, charging and operational history.

This turns a broad compatibility claim into something providers can answer consistently. It also exposes gaps early—for example, two products may both list VDA 5050 while requiring different optional actions, map arrangements or master-control behaviour.

Make the acceptance test operational

• Run the exact robot software, fleet manager and interface versions proposed for the site.
• Test representative missions, load transfers, shared zones, blocked routes and priority rules.
• Measure status freshness, command acknowledgement, recovery time and behaviour during network loss or delayed messages.
• Verify identity, permissions, logging, key ownership and the approved remote-support path.
• Confirm which behaviours are standard, vendor extensions or site-specific integration work.
• Retest the agreed scenarios after relevant robot, fleet or interface upgrades.

8 October addition: name the software pair before comparing test evidence

A demonstration can be useful without covering the purchase you are about to make. Ask for the robot model and software build, the fleet-manager build, the interface document revision and the tested message profile on the same record. A brochure label cannot tell you whether that particular pair was tested.

In the VDA 5050 3.0.0 source checked on 8 October 2026, the suggested MQTT topic structure includes a major-version level, while message headers identify a full protocol version. Its communication table separates mandatory and optional topics. Its optional-field section says fleet control should send only optional fields supported by the robot, with support communicated through the factsheet. The buyer's brief therefore needs more than a version label: name the features used by the required exchange.

Keep a requirement column and a tested-evidence column. In the first, describe the message direction, required fields, optional features and any vendor extensions. In the second, record what the named software pair actually exchanged, the scenario and environment, the date, and the log or report reference. Leave an untested requirement open instead of borrowing evidence from a different pair.

For example, a hypothetical test may demonstrate that a robot publishes a valid status message to a receiver. That is not evidence that a fleet manager can dispatch the buyer's required mission to that robot. The distinction matters before awarding an integration contract: the test needs to answer the purchase requirement, not a nearby capability.

MassRobotics' 2022 implementation steps make another useful boundary explicit. They describe shared location, speed, direction, health and availability information, and testing populated messages with a standard-compliant receiver's schema checks. The material does not require suppliers to surrender fleet management or use a common map. Do not convert that evidence into a claim that one controller manages every fleet.

Ask the integration owner to reconcile each difference: a new robot build, a different fleet-manager build, a changed interface document or an added extension. Record whether the earlier evidence still applies and which scenarios need another test. This is a procurement evidence method, not a specification-mandated retest schedule or an automatic compatibility decision.

The interface test-evidence tool below keeps these two records separate and exports their open fields. Filling every box only assembles a review record. It does not verify the contents, issue conformance certification, send robot commands or approve an operating cell. The original article's publication and review dates remain unchanged; this dated addition is limited to the sources and method above.

Treat supplier support as a claim until the agreed exchange is tested

The scopes above come from the organisations that publish the specifications. They do not independently verify that a particular manufacturer has implemented a specification completely or that two named products will interoperate at a customer site.

RobotAtom records a supplier's support statement as supplier-provided evidence tied to the exact product and software version. A site test or other independent evidence should verify the material exchange before procurement or scale-up. None of these interfaces replaces the applicable safety assessment, engineering review or operational controls.