Multi-Vendor Robot Fleet Interoperability

Why Mixed Fleets Happen, and Why They Break

A mixed fleet is rarely a strategic choice. It is the residue of three decisions made at different times: a cleaning fleet bought for throughput, a delivery fleet bought for a specific elevator integration, and a reception unit bought because a particular pilot demanded it. Each purchase was rational. Together they create an operations problem, because each brand's software assumes it owns the building's map and the operator's attention.

The break is not physical. The robots coexist on the floor well enough. The break is in the coordination layer: overlapping cleaning routes, conflicting elevator reservations, three separate incident inboxes, and no single answer to the question "what did the fleet do last night". The integration work that fixes this is a software problem with a defined set of standards, not a matter of hoping the vendors cooperate.

The starting point is to treat the fleet as an integration project with its own architecture, in the same way a single-brand fleet is treated as a management problem in the fleet management overview. Mixed brands simply raise the integration stakes.

VDA5050 and ISO 3691-4: The Standards That Matter

Two standards do most of the work. VDA5050 is a communication interface that standardises how a fleet control system talks to an automated guided vehicle or AMR, regardless of who built it. ISO 3691-4 is the safety standard for driverless industrial trucks and their systems, and it governs the safety floor the fleet must not compromise. Together they define both the data language and the safety envelope.

Layer	Standard	What it gives you	What it does not
Communication	VDA5050	Standard order, state, and connection messages between fleet manager and vehicle	Does not define map format or path planning
Safety	ISO 3691-4	Required safety functions, protective stops, and system acceptance	Does not define fleet coordination logic
Orchestration	Open-RMF	Open framework for cross-vendor task and traffic coordination	Adoption is uneven across vendors
Data model	Vendor API	Brand-specific telemetry and job control	Not portable, the source of lock-in

The practical rule: if every unit in the fleet speaks VDA5050, the fleet manager can issue orders through one interface and read state back through one interface. If a vendor does not support VDA5050, its integration runs through a proprietary API, which is where the cost and the lock-in live. Ask for the protocol matrix before the order, not after the first integration sprint.

The safety layer is not negotiable for interoperability. A vendor-neutral coordinator must respect each unit's ISO 3691-4 protective functions and must not override a safety stop to satisfy an optimiser. The same principle governs the data and privacy boundaries covered in the fleet cybersecurity and data privacy guide.

Building the Vendor-Neutral Data Layer

The data layer is what makes a mixed fleet feel like one fleet. It sits between the operators and the vendor systems and normalises everything to a single model. Build it in four steps.

• Normalise identity. Every unit gets one internal ID, mapped to every vendor identifier it carries, so a report never splits one robot into two rows.
• Normalise location. Convert each vendor's coordinate frame into the site's floor plan, so "aisle 3" means the same place on every dashboard.
• Normalise state. Map each vendor's status vocabulary onto one set, charging, cleaning, idle, fault, so availability is comparable across brands.
• Normalise events. Route every brand's alarms into one incident stream, so the on-call operator watches one queue rather than three.

The layer should be owned by the buyer, not by any single vendor. That ownership is the thing that makes the exit plan possible, and it is the practical counterpart to the API-access clauses set out in the data ownership and API interoperability guide. If the vendor-neutral layer is bolted onto one brand's platform, the fleet has traded a three-app problem for a one-vendor problem.

The Integration Cost Model

Integration cost is not one number. It is the sum of four recurring cost lines, and the model should be built before the second brand is ordered because it decides whether unification pays.

Cost line	What drives it	Recurring or one-off
Interface build	Whether the vendor supports VDA5050 or needs a proprietary adapter	One-off per brand
Map maintenance	Number of distinct map formats to keep in sync after a floor change	Recurring, every layout change
Operator load	Number of dashboards and incident queues the team must watch	Recurring, labour
Vendor change	Cost to swap out one brand without rebuilding the layer	One-off, on exit

Two signals tell you unification is paying. First, operator load: if the on-call team watches more than one incident queue, the coordination cost is already being paid in labour. Second, map churn: if a single floor change forces you to re-map more than one system, the maintenance cost compounds with every brand. When either signal is present, the vendor-neutral layer pays for itself. When both are absent and the fleet is stable, keep the apps separate and revisit at the next acquisition.

Right-sizing the fleet that the layer coordinates is the other half of the economics, and the arithmetic is set out in the guide to fleet right-sizing.

The Interoperability Exit Plan

Interoperability is not only about making the current fleet work. It is about being able to change the fleet without starting over. The exit plan has three clauses, and all three belong in the contract.

• Protocol commitment. The vendor commits in writing to VDA5050 support and to a version-support window, so a protocol upgrade does not silently break the fleet.
• Data portability. Telemetry and job history export in an open format on demand, so leaving does not mean abandoning the operational record.
• Layer ownership. The buyer owns the vendor-neutral layer and its mappings, so a brand change is a re-point rather than a rebuild.

Without these, a mixed fleet quietly becomes a single-vendor fleet with extra steps, because the cost of leaving any one brand rises with every integration built on top of its proprietary API. The same lock-in risk appears in the fleet software integration detail set out in the software integration guide and the selection criteria in the fleet management software buyer's guide.

Common Ways Mixed-Fleet Projects Stall

The failures repeat. Each is cheaper to avoid at specification time than to unwind at integration time.

• Protocol matrix skipped. The buyer discovers after ordering that a vendor speaks only a proprietary API, and the integration cost triples.
• Layer owned by a vendor. The coordinator is licensed from one brand, so the fleet is unified only as long as that brand stays.
• Safety overridden. An optimiser tries to route around a protective stop, which breaks ISO 3691-4 compliance for a marginal throughput gain.
• No map normalisation. Three coordinate frames mean the same aisle has three names and no report reconciles.
• No exit clause. The data cannot be exported and the layer cannot be re-pointed, so the mixed fleet is a lock-in with extra licences.

Handled this way, a multi-vendor fleet stops being an accidental architecture and becomes a designed one: a standard protocol, a company-owned data layer, a costed integration model, and a written exit route that keeps every future brand decision open.