Operating robots from different vendors does not require one central AI to drive every machine. A practical architecture lets an upper layer coordinate missions, routes, doors, elevators and chargers, while each vendor controller retains local navigation, collision avoidance and emergency stopping. A common API is only the start: coordinate frames, state and error semantics, least-privilege security, data rules and failure isolation must also align.
Icons on one dashboard do not prove fleet interoperability
A dashboard may show Vendor A's AMRs beside Vendor B's service robots while neither can hand off a task or reserve the same elevator safely. That is unified monitoring, not necessarily unified operation. Multi-vendor coordination requires capability descriptions, supervisory task assignment and common meanings for execution state and failure.
The official Open-RMF website describes Open Robotics Middleware Framework as a free, open-source modular system for sharing and interoperability across fleets, doors, elevators and building management systems. It began in healthcare and can also apply to offices, airports, ports, malls, factories and logistics. A framework providing integration points is not a promise of plug-and-play compatibility at a specific site.
| Layer | Normalize across the site | Keep local to vendor or facility |
|---|---|---|
| Work | Mission types, priority, completion and cancellation semantics | Robot-specific capabilities and limits |
| Movement and resources | Map frame, path conflicts, door, elevator and charger reservations | Local obstacle avoidance and real-time safety control |
| State and faults | Waiting, running, stopped and recovering states plus fault severity | Vendor diagnostics and maintenance procedures |
| Control | Identity, authorization, audit and data policy | Device keys, safety certification and site emergency stop |
Supervisory missions and real-time safety belong on different layers
A supervisor can assign a mission such as “move medication from the 3rd-floor store to the lab” to an eligible fleet and coordinate shared routes and resources. Wheel rpm and the ms required to stop after detecting a person belong to the onboard controller and independent safety system.
This boundary lets the robot avoid people and stop safely during a brief network outage. If a central server directly controls wheels or joints in real time, network and server delay become immediate physical hazards. The upper layer must not have authority to bypass vendor safety functions.
Supervisory commands need expiry. Executing a “enter corridor” command received 10 seconds earlier after connectivity returns can collide with a machine that has since entered. The robot should report current state and wait for new authorization.
Adapters must translate coordinates, states and failures—not just messages
Two robots may share a map while using different origins, floor heights and doorway-clearance assumptions. Vendor A may call a destination reached within 20cm, while Vendor B uses 1m. Without common transformations, tolerances, footprints and speed limits, a robot can look arrived on screen but remain out of reach of the workstation.
State names also need translation. “Paused” may mean a safety stop or an operator hold; “failed” may mean automatic retry or field recovery. An adapter must map state transitions and recoverability, not only syntax. An unknown new fault code should enter quarantine, never silently map to healthy.
Versioning is part of the adapter. Firmware or API changes can alter status codes and route responses. Maintain supported versions, compatibility tests and rollback-ready adapter packages per robot so an overnight update does not halt the entire fleet.
Capability negotiation should precede dispatch. Two transport robots can differ in payload, width, floors, docking and refrigeration. Assign from current reported capability and state rather than a fixed model name, and reject stale or incomplete claims. When capability descriptions change, retest both adapter and dispatch rules.
Deadlocks usually appear at doors, elevators and chargers
The hardest multi-vendor issue may be sharing scarce infrastructure rather than messaging between robots. Fleets can reserve the same elevator from different floors, or several low-battery robots can converge on one charger. Model corridors, doors, lifts and workstations as reservable resources.
A reservation needs start, expiry, owner and failure-release rules. If a robot loses communication inside an elevator and its reservation persists forever, other fleets stop too. If expiry is too short, it can lose permission mid-transit. Set windows from measured travel-time distributions and worst cases.
Priority must reflect operations. Emergency specimens in a hospital should not queue identically with waste, but continuous high-priority work must not starve normal missions. Define maximum wait and manual adjustment.
Begin deadlock tests with two robots waiting for each other at opposite ends of a narrow aisle. If neither can yield, the supervisor needs safe waiting and rerouting. When one robot holds elevator and charger reservations together, impose an acquisition order or release rule. Avoiding a site-wide stop matters more than maximizing short-term throughput.
Open APIs still require least privilege, identity and signed commands
Open does not mean every system can send every command. An order service may create missions, a building service may publish door and elevator state, and a maintenance account may diagnose designated robots. Driving commands and emergency-stop reset require stronger approval.
Issue a unique identity to each device and service and use mutually authenticated communications. Bind sender, target, time, expiry and signature to commands so replay and tampering can be detected. A compromised supplier account should isolate that fleet without stopping every other robot.
Adapters and plugins are supply-chain attack paths. Verify package provenance and signatures, inventory network and file privileges, and run new versions on an isolated test fleet. Software asset and deployment lineage should reveal immediately which robots and servers use a vulnerable release.
The official Fujitsu Japan physical AI collaboration announcement says that on July 16, 2026 Fujitsu began exploring a collaborative-control platform integrating technologies from FANUC, Yaskawa Electric, Kawasaki Heavy Industries and NVIDIA. It explicitly notes growing risks from cyberattack, system-wide outages or malfunction and confidential-data leakage. The announcement describes development and standardization direction, not commercial performance of a finished universal platform.
Sovereign data control extends beyond the server's country
Data sovereignty is broader than selecting a storage country. It covers who can see raw sensor data, whether a supplier may use it for diagnosis or model training, whether derived features and models can cross borders, and how deletion works after a contract ends.
Fujitsu says it aims to develop an open collaborative-control foundation that connects digital and physical worlds while preserving sovereignty. Manufacturing, logistics and healthcare expose process secrets, inventory and patient movement. Even robot coordinates can reveal production volume and site layout, so protecting video alone is insufficient.
| Data type | Contractual and technical control | Evidence to inspect |
|---|---|---|
| Live location and state | Authorized users, retention and external-transfer scope | Permission matrix and access audit |
| Raw video and sensors | Data minimization, masking and consent for learning | Lineage and tested deletion |
| Fault and maintenance logs | Supplier-specific access and incident-sharing scope | Per-incident viewing and export records |
| Derived data and models | Ownership, reuse, cross-border transfer and contract exit | Versioned provenance and destruction confirmation |
The SEER Robotics WRC 2026 strategy announcement also presents a direction connecting robot models, control and fleet layers, and data networks. A supplier's integration vision is useful context, but customer contracts and working APIs must separately establish data rights and exportability.
A fault in one fleet must not cascade into every vendor
Integration failure can stop every robot at once. Define whether in-progress missions finish or stop after the central scheduler fails, which zones close when a door server is unavailable, and how one slow vendor API avoids blocking the full queue.
Use circuit breakers and timeouts per fleet. Isolate unresponsive robots while continuing other work. After recovery, query actual robot position and mission state rather than overwriting them with stale server state. Field observation outranks the last normal packet.
Bound offline operation. A robot may avoid local obstacles without communication but must not enter an elevator or narrow aisle that requires a shared reservation. Emergency stop must remain network-independent, and only a person who has checked the site should reset it.
Validate shared meaning and recovery with two robots before scaling
Start with one robot from each of two vendors and one shared facility resource. Repeat the same pickup-and-drop-off mission at least 50 times, logging coordinate error, state transitions, resource waits and remote intervention. After nominal success, deliberately introduce link loss, a nonresponsive door, low battery and an unknown fault code to test isolation and recovery.
Open-RMF multi-robot integration, the VDA 5050 3.0 guide and VIO versus SLAM provide implementation context for facility interfaces, message standards and localization.
Before expansion, price the adapter engineering, compatibility testing, security review and recovery training for one new robot. Inspect actual message versions, optional functions and vendor fault mappings rather than a “standard supported” checkbox. Check that price, support and data terms do not conflict across suppliers.
After expansion, monitor isolation as well as throughput. Fleet-wide totals can hide long waits or starvation for one vendor. Place success, waiting, adapter error, resource conflict and manual recovery by vendor beside the aggregate, and check regression by fleet after updates.
Security metrics should include blocked commands, expired certificates, excessive privileges and anomalous data export. Test sovereign-data deletion and export blocks in practice. During failure drills, disconnect the central server, one vendor cloud and the building system in turn and measure both safe state and continued service.
Multi-vendor maturity is not the number of logos on a screen. It is the ability to add a supplier without losing common meaning, isolate one failure and preserve the site owner's control of commands and data.
Frequently asked questions
Does one dashboard mean a site has multi-vendor robot integration?
It may be unified monitoring, but operations also need shared mission assignment, state and error meanings, resource reservations and recovery across suppliers.
Does Open-RMF or VDA 5050 support guarantee interoperability?
No. Test the exact standard version, optional features, coordinate frames, state transitions, vendor fault codes and safety ownership through real messages. Implementations under the same label can differ.
Do open robot APIs make a fleet inherently insecure?
No. Security depends on device identity, least privilege, signed and expiring commands, audit trails and fleet-level isolation. Openness can remain tightly controlled.
Official sources checked
- Official Fujitsu Japan physical AI collaboration announcement
- Official Open-RMF website
- SEER Robotics WRC 2026 strategy announcement
Last checked: August 23, 2026