AMR interoperability is not one checkbox

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.

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.