Connecting Robots from Different Vendors: What Can You Share?
When a warehouse or factory operates mobile robots (AGVs/AMRs) from multiple vendors, each vendor ships its own map view, status schema, and log format. Reporting fleet status to a warehouse management system (WMS/WCS) requires a separate integration per vendor.
Introducing a managed cloud MQTT broker centralizes transport and device authentication, but it does not normalize vendor schemas, discard stale commands after a Wi-Fi drop, or resolve deadlocks at intersections. This article uses public Japanese reference architectures to separate what AWS and Azure managed services handle from what you must still build in your own adapter and fleet-control layers.
Separation of Responsibilities by Layer
| Failure mode on the floor | What you must design and implement |
|---|---|
| Managing MQTT broker uptime and TLS certificates becomes harder as fleet size grows | Migration to AWS IoT Core or Azure Event Grid MQTT, plus per-device certificate lifecycle and topic ACLs |
| Vendors use incompatible coordinate frames, battery metrics, and error codes | A canonical telemetry schema (units, coordinate transform, timestamps) and per-vendor API adapters |
| A motion command sent during a Wi-Fi drop arrives minutes later and executes unexpectedly | Command TTL (e.g., MQTT 5 Message Expiry Interval or payload timestamps) and stale-command rejection |
| All robots appear on one dashboard, but still deadlock in narrow aisles and intersections | Spatial mutexes, multi-agent pathfinding, and task assignment |
A prerequisite for any integration is that each vendor’s robot or local controller exposes a telemetry and command API. Putting an MQTT broker in the cloud cannot extract state that the hardware keeps locked inside a proprietary controller.
Comparing AWS and Azure Messaging Layers
When robots or edge adapters speak MQTT 3.1.1 or 5, AWS IoT Core and Azure Event Grid MQTT are the primary managed cloud brokers. If the site also needs to ingest data from OPC UA factory equipment (such as PLCs), Azure IoT Operations runs on-site on Azure Arc-enabled Kubernetes and bridges local traffic to Event Grid (Microsoft architecture overview).
| Service | Execution environment | Primary role |
|---|---|---|
| AWS IoT Core | Cloud | Device authentication, MQTT message routing, device state shadows |
| Azure Event Grid MQTT | Cloud | Pub/Sub routing between MQTT clients and forwarding to Azure Event Hubs / services |
| Azure IoT Operations | On-site Azure Arc-enabled Kubernetes | Ingesting data from local OPC UA equipment and processing local MQTT data flows |
Both AWS IoT Core and Event Grid support MQTT 3.1.1 and MQTT 5, but their authentication models, session expiry defaults, offline queue limits, and topic filter rules differ. Migrating from a self-hosted broker like Mosquitto usually requires more than swapping the broker hostname (AWS IoT Core MQTT specs, Event Grid MQTT specs, IoT Operations overview).
Three Public Reference Cases in Japan
The following public cases from Japanese trials and enterprises illustrate how messaging and control responsibilities split in practice (none of these are BreakAI customer engagements).
1. Digital Agency: Separating Event Grid Telemetry from Spatial Occupancy APIs
In a multi-robot coordination trial published by Japan’s Digital Agency, robots publish MQTT telemetry to Azure Event Grid, which forwards messages to Event Hubs for downstream storage and visualization (Technical Report, pp. 23–24).
Crucially, the architecture separates the telemetry pipeline from the API that manages spatial occupancy (reserving shared corridors and elevators). Streaming robot coordinates over MQTT does not decide which robot enters a narrow passage first; that requires a dedicated coordination service.
2. KYB: Consolidating Non-Real-Time Predictive Maintenance in the Cloud
KYB collects factory equipment telemetry through AWS IoT Core for predictive maintenance. During early development, the team ran anomaly detection on-site using AWS IoT Greengrass. Because predictive maintenance looks for gradual degradation rather than triggering millisecond emergency stops, KYB later removed the edge compute layer and consolidated analysis in the cloud to reduce on-site operational overhead (AWS case study).
Latency requirements dictate placement: keep safety interlocks and local collision avoidance on the floor, and push trend analysis and fleet reporting to the cloud.
3. Kawasaki Heavy Industries: Adopting Azure IoT Operations in a Robotics Platform
A Microsoft case study published on September 30, 2026 reports that Kawasaki Heavy Industries adopted Azure IoT Operations alongside AKS and Cosmos DB for a robotics platform currently under development (Microsoft case study). Because the article describes a platform in development and does not disclose device counts or OPC UA scope, it should be read as an architectural direction rather than a large-scale production benchmark.
Verification Checklist for MQTT Brokers
When evaluating a managed broker for robot fleets, test failure modes rather than happy-path connectivity:
- Certificate rotation and topic ACLs: How are X.509 device certificates rotated in the field, and do topic ACLs prevent Robot A from publishing to Robot B’s command topic?
- Disconnections and command TTL: How many offline messages does the broker queue during a Wi-Fi drop, and how do you prevent a five-minute-old move command from executing upon reconnect?
- QoS 1 duplicates and command idempotency: MQTT QoS 1 delivers messages at least once, meaning network retries will deliver duplicate commands. Furthermore, a broker PUBACK only confirms message delivery, not physical robot completion. You must design command IDs, deduplication, and execution-result replies at the application layer (QoS and session specs).
- Fan-out cost model: Calculate monthly costs based on device count × publish frequency (e.g., 1 Hz vs. 10 Hz pose updates) × payload size × number of subscribing clients.
- On-site Kubernetes ownership: If you deploy Azure IoT Operations, define which team patches, monitors, and recovers the on-premise Arc-enabled Kubernetes cluster.
Boundary Between Messaging and Traffic Control (Rovnou)
AWS IoT Core and Azure Event Grid move bytes reliably between robots and servers. Rovnou, the traffic-control system we develop at BreakAI, operates on the layer above: computing task assignment, collision-free multi-agent routes, and passage timing across shared aisles.
Swapping out an MQTT broker will not stop robots from waiting on each other at intersections. We start by auditing existing operational logs and network constraints to pinpoint where robots stall, and then scope traffic-control validation around those bottlenecks.
(Research cutoff: October 29, 2026.)