Mixed-fleet interoperability
VDA 5050 in a Mixed AMR Fleet
What the standard guarantees, what it leaves out, and what you still have to specify.
VDA 5050 guarantees a shared language, not a working mixed fleet. Version 3.0.0 (March 2026) defines how a central fleet control and mobile robots exchange orders, instant actions, state, connection status and factsheets as JSON over MQTT. It does not define safety requirements, traffic-management logic, interfaces to doors, conveyors or your WMS, commissioning and acceptance, who is responsible for what, or cybersecurity. Much of what a real deployment needs also sits in optional fields and actions that each robot declares in its factsheet. A mixed fleet therefore still needs the version, the supported optional parameters and actions, and every excluded area pinned down in writing.
Step 1
What VDA 5050 actually standardizes
VDA 5050 is a recommendation published by the German Association of the Automotive Industry (VDA) and developed with the VDMA and the Institute for Material Handling and Logistics (IFL) at KIT. Version 3.0.0 describes itself as a standardized, vendor-neutral communication interface between a fleet control system and mobile robots, with the stated aim of letting robots from different manufacturers operate under one fleet control. Its use is explicitly optional and non-binding, and the VDA offers the current version as a free download.
The transport is MQTT, version 3.1.1 at minimum, carrying JSON messages. The specification names eight topics:
| Topic | Sent by and to | Status in 3.0.0 | Used for |
|---|---|---|---|
| order | Fleet control → robot | Mandatory | The route as a graph of nodes and edges, with actions attached |
| instantActions | Fleet control → robot | Mandatory | Actions to run immediately, such as pause, resume or cancel |
| state | Robot → fleet control | Mandatory | Position, order progress, action states and errors |
| connection | Broker or robot → fleet control | Mandatory | Online, offline and broken-connection status |
| factsheet | Robot → fleet control | Mandatory | Robot type, physical parameters and supported protocol features |
| visualization | Robot → visualization systems | Optional | High-frequency position and planned path |
| zoneSet | Fleet control → robot | Optional | Zone sets, such as blocked or speed-limited areas |
| responses | Fleet control → robot | Optional | Fleet control's answers to requests the robot raises |
An order is a segment of a node-and-edge graph: released nodes and edges (the base) that the robot may drive, and unreleased ones (the horizon) that it may not drive yet. Every robot must support three actions — cancelOrder, startPause and stopPause. Beyond those, the specification lists predefined actions such as pick, drop, startCharging and map download that a robot uses when its capabilities match, and manufacturers can define their own. If a robot loses its broker connection, it keeps its order and completes it up to the last released node.
Step 2
Optional fields and the factsheet: where “supported” is decided
Much of the interoperability question is settled in the parts the standard marks optional. In VDA 5050, an optional field is optional for the sender: fleet control shall only send optional fields that the robot supports, and a robot that receives one must not silently ignore it. If the robot cannot process an order because of an unsupported parameter, it rejects the order with an UNSUPPORTED_PARAMETER error at CRITICAL level. An order containing an action the robot cannot perform, such as a lift higher than its maximum lifting height, is rejected with an INVALID_ORDER_ACTION warning.
The factsheet is how a robot declares what it can do. Its protocolFeatures block lists the optional parameters the robot supports or requires — anything not listed is assumed unsupported — and every action it accepts, including manufacturer-specific ones, with their parameters and scopes. A separate list states which zone types the robot understands, because the specification expects some robots to handle no zones at all and others only a subset. The specification also notes that some factsheet values can only be set during system integration.
Fleet-control products document their own support in the same way. As one vendor example, Siemens' support FAQ for SIMOVE Fleetmanager 4.0.0 (April 2026) states support for VDA 5050 versions 1.1, 2.0 and partially 2.1, marks some state fields as parsed but not used, and says the factsheet topic is not supported in that release. That is one supplier's documentation for one release, not a general limitation, but it shows why a parameter-level support list, not a product-page badge, is the evidence to ask for.
Step 3
Six things the standard deliberately leaves out
Version 3.0.0 lists what it does not address. Each exclusion is work that still has an owner in your project — just not the standard.
| Left out of VDA 5050 | What that means in a mixed fleet | Name an owner for |
|---|---|---|
| Safety requirements | The document says it shall not be regarded or applied as a safety standard | Risk assessment and safety validation of the combined system |
| Traffic-management logic | Routing, prioritization, congestion handling and deadlock resolution are not defined | The fleet control's traffic rules, and how they are tested |
| Other communication interfaces | Links to peripheral equipment, infrastructure and external IT systems are excluded | Doors, lifts, conveyors, chargers and the WMS or MES connection |
| Project coordination and implementation | Integration methods, commissioning, validation and acceptance procedures are not covered | The commissioning plan and acceptance tests |
| Operational responsibilities | Responsibilities among operator, integrator, robot maker and fleet-control provider are not allocated | The split for planning, operation, maintenance and safety |
| Cybersecurity measures | Secure communication and data protection are not specified; protocol security is left to broker configuration | Broker hosting, TLS and certificate handling, network access |
Two more gaps sit inside the document rather than in its exclusion list. Route and route-network configuration are not part of it: routes can be imported in the VDMA Layout Interchange Format (LIF) or entered manually in the fleet control. And while the specification says robot communication should be secured, typically with TLS, and defines an action for updating certificates, the security design itself is yours to specify.
Step 4
Pin the version, not just the name
VDA 5050 uses semantic versioning, and its own introduction says major versions typically involve breaking changes, such as new non-optional fields. The major version also appears in the suggested MQTT topic path, for example vda5050/v3/manufacturer/serialNumber/order. The VDA lists version 3.0.0, March 2026, as current and says older versions are no longer recommended or developed further, yet robots and fleet-control releases already in service can still implement earlier versions. Record the exact version each robot and the fleet control implement, and if they differ, decide in writing how the gap is handled.
One note on sources: the project states that if the GitHub markdown or JSON schemas ever differ from the PDF on the VDA website, the PDF is the valid document.
Step 5
What to write into the contract, integration plan and acceptance tests
A vendor case study from Kollmorgen puts it plainly: implementing VDA 5050 in real environments can still involve technical complexity when aligning vehicle types, software systems and operational requirements. The list below turns the specification's own mechanics and exclusions into items to specify, so that complexity has an owner.
| Specify | Why the standard leaves it open | Evidence to ask for |
|---|---|---|
| The VDA 5050 version of each robot model and of the fleet-control release | Major versions typically involve breaking changes | The stated version per component, and a written plan if they differ |
| Optional topics and fields your workflow needs, such as visualization, zones or trajectories | Fleet control may only send optional fields the robot supports | Each robot's factsheet, compared with the fleet control's parameter support list |
| Actions the workflow depends on, including manufacturer-specific ones | Only cancelOrder, startPause and stopPause are required of every robot | The factsheet action list with parameters, and who implements anything missing |
| Maps, coordinate system and route network | Positions use a project-specific coordinate system; route configuration is outside the standard | Who builds and owns the layout (LIF import or manual), the map server and map versions |
| Traffic rules, deadlock handling and request timeouts | Traffic logic is excluded; request timeouts and retries are to be defined during integration | Written traffic and exception rules for the combined fleet |
| Doors, lifts, conveyors, chargers and WMS or MES links | Other interfaces are excluded | An interface list with one owner per connection |
| MQTT broker, network and security | Protocol security is left to broker configuration | The broker owner, a TLS and certificate plan, and network coverage evidence |
| Safety and the responsibility split | No safety requirements or responsibility allocation are defined | A named owner for the risk assessment of the mixed system |
| Protocol-level acceptance cases | Validation and acceptance procedures are excluded | Tests for order rejection, pause and cancel, connection loss and recovery on the real pairing |
Protocol-level tests belong inside the wider pilot. For the site survey, interface contracts and pilot acceptance, continue with the AMR integration guide. To test a fleet-software proposal against a specific robot-and-controller pairing, use the AMR fleet management software guide.
Scope
What this guide leaves to other pages
This guide explains what VDA 5050 version 3.0.0 does and does not cover, and what to specify around it. It does not compare fleet-management software products, and it does not list or rank vendors by VDA 5050 support. It also does not state whether HiO robots implement VDA 5050: ask for that in writing for the specific robot model, software release and protocol version you plan to buy. It is not a conformance audit or safety advice.
Buyer questions
FAQs
Is VDA 5050 a safety standard?
No. Version 3.0.0 states that it does not define functional, operational or system safety requirements and shall not be regarded or applied as a safety standard. Safety for the robots and the combined system has to be handled under the safety standards and risk assessment that apply to your site.
Does “VDA 5050 compatible” mean any robot will work with any fleet manager?
Not on its own. Both sides need to implement the same major version, the fleet control may only send optional fields the robot supports, and the actions your workflow needs have to appear in the robot's factsheet. Traffic rules, peripheral interfaces and acceptance are outside the standard altogether.
What transport and message format does VDA 5050 use?
MQTT, version 3.1.1 at minimum, carrying JSON messages. Version 3.0.0 specifies QoS level 0 for most topics and QoS level 1 for the connection topic, which uses a last-will message to signal a broken connection.
Is VDA 5050 mandatory, and where do you get it?
It is an optional, non-binding recommendation. The VDA offers the current version, 3.0.0 from March 2026, as a free download, and change proposals go through the public VDA 5050 GitHub repository.
Sources
- VDA 5050 Version 3.0.0: Interface for the Communication between Mobile Robots and a Fleet Control — VDA and VDMA, March 2026 (release 3.0.0 on the official GitHub repository). Scope, transport, topics, actions, optional fields and factsheet. Not a conformance audit.
- VDA 5050 — VDA topic page: current version and date, free download, status of older versions.
- What VDA 5050 parameters does SIMOVE Fleetmanager support? — Siemens Industry Online Support, April 16, 2026 (vendor documentation for one product release).
- One Site, Two Fleets, VDA 5050 in the Middle — Kollmorgen case study (vendor-authored).
Planning a mixed AMR fleet?
Share the robots, the fleet control and the VDA 5050 version in your plan, and ask HiO to state in writing which of the items above its offer would cover.
Discuss your fleet plan