What is VDA 5050?
By Dr Mohammed Aroussi·Updated 23 September 2026
VDA 5050 is an open interface standard that defines how automated guided vehicles and autonomous mobile robots from any maker exchange orders and status with a central fleet manager, using MQTT messages in JSON format.
It was developed jointly by the German Association of the Automotive Industry (VDA) and the VDMA, the German mechanical engineering association, with the Institute for Material Handling and Logistics at the Karlsruhe Institute of Technology, and it is maintained in the open on GitHub. Its stated objective is a standardised, vendor neutral communication interface that lets a central fleet control run mobile robot fleets from different manufacturers together in the same building. The current release is version 3.0.0, published on 18 March 2026.
This page explains the six message types in plain English, the transport underneath them, the version history, which robot makers and fleet managers say they support it, and how FlyWei's M4 fleet manager uses it to run mixed fleets.
Why VDA 5050 matters in a UK warehouse
Very few UK sites buy every truck from one maker. A distribution centre might run counterbalance trucks from one supplier, reach trucks from another and a handful of pallet movers from a third, chosen over years on price, lead time and what the local dealer could service. Automation tends to arrive the same way: a first automated pallet mover for dock to stock, then a stacker from a different maker for the racking, then AMRs for tote transport.
Without a common interface each maker's fleet software runs its own island. Two islands sharing the same aisles have to be kept apart with manual rules, gates or timetables, and every new vehicle brand means a new control system, a new integration to the WMS and a new set of screens for the shift supervisor. VDA 5050 gives one fleet manager one language for every automated vehicle, so traffic in shared aisles is planned once, orders come from the WMS once and the supervisor watches one map.
It is worth being clear about what the interface is not. VDA 5050 is a communication standard, not a safety standard: the truck's own safety scanners and controllers remain responsible for slowing and stopping it, and UK duties under PUWER and LOLER still apply to the equipment and the site. It also does not replace a WMS or ERP. It sits underneath them, between the fleet manager and the vehicles.
The six VDA 5050 message types
VDA 5050 defines six topics. Two flow from the fleet manager to the vehicle, three flow back, and one feeds visualisation tools. Together they cover everything a fleet manager needs to give a truck a job, watch it happen and intervene.
| Topic | Direction | In plain English |
|---|---|---|
| order | Fleet manager to vehicle | The job. A route made of nodes (positions to reach) and edges (the links between them), plus any actions to perform at each node, such as lifting or lowering the forks. |
| state | Vehicle to fleet manager | The heartbeat. Position, battery, load, errors and progress through the current order. Published when something changes and at least every 30 seconds. |
| connection | Vehicle (via the broker) to fleet manager | Online or offline. Tells the fleet manager whether the vehicle is reachable, including an unexpected drop of the connection. |
| factsheet | Vehicle to fleet manager | The vehicle's own description: its parameters and any maker specific information the fleet manager needs to set it up, such as the actions and zones it supports. |
| visualization | Vehicle to visualisation tools | High frequency position and trajectory data for live tracking on a map. Kept separate from state so it does not flood the control channel. |
| instantActions | Fleet manager to vehicle | Do this now. Commands that do not wait for the order flow, such as pausing, cancelling an order or asking the vehicle to send its factsheet. |
How an order works: nodes, edges, base and horizon
The core of an order is a segment of a node and edge graph: the nodes are the positions the vehicle must reach, the edges are the connections between consecutive nodes, and both carry sequence numbers so the vehicle knows the traversal order. The fleet manager splits the route into a base, the nodes and edges already released for the vehicle to travel, and a horizon, the part planned but not yet released. Releasing the route a few nodes at a time is how the fleet manager keeps two vehicles out of the same aisle: a truck never drives beyond what it has been given.
MQTT and JSON: the transport underneath
The specification fixes the transport as well as the messages: MQTT is the message protocol, used in combination with a JSON format. MQTT is a lightweight publish and subscribe protocol. A small server called a broker sits on the site network or in a private cloud; the fleet manager and every vehicle connect to it, publish messages to named topics and subscribe to the topics they need. Nobody has to know anybody else's IP address, and a vehicle that loses Wi-Fi for a moment simply reconnects to the broker.
The suggested topic structure is interfaceName/majorVersion/manufacturer/serialNumber/topic, so a message such as vda5050/v3/KIT/0001/order is an order for vehicle 0001 from manufacturer KIT on version 3 of the interface. Two things follow from that. Every vehicle has its own set of topics, which is what lets one broker and one fleet manager serve a mixed fleet without messages colliding. And the major version is baked into the topic, which is why the fleet manager and the vehicle must agree on it.
The payloads are JSON, which is human readable and easy to log. When a truck misbehaves, an engineer can read the last order it received and the last state it published, in plain text, with no maker specific tooling.
VDA 5050 version history
Releases as tagged on the official VDA5050 GitHub repository, checked on 23 September 2026. Earlier drafts before 2.0.0 are not listed on the releases page and are not shown here.
| Version | Date | What changed |
|---|---|---|
| 2.0.0 | Tagged 25 November 2019; released as the official VDA document in January 2020 | The version most fleets in service today were built against. |
| 2.1.0 | 19 August 2024 | Added corridors and map distribution. |
| 3.0.0 | 18 March 2026 | Support for freely navigating mobile robots (planned path sharing and a zone concept) and a complete restructuring of the document. Current release. |
| Planned | Not yet released | 3.0.1 for minor fixes and 3.1.0 for non breaking additions are on the project's milestone list; a breaking 4.0.0 is not currently planned. |
Source: VDA5050/VDA5050 repository on GitHub, releases page and README, fetched 23 September 2026.
Why it matters for mixed fleets
The practical value of VDA 5050 shows up the day you add a second brand of vehicle. With a common interface the new truck joins the existing fleet manager: it publishes its factsheet, the fleet manager learns what it can do, and from then on it receives orders and reports state like every other vehicle. Traffic planning covers the whole fleet, so two makers' trucks can share an aisle, queue for the same dock door and give way to each other without a hand written rulebook.
It also changes the commercial position of the buyer. When the fleet manager is vendor neutral, the next tender can go to whichever maker offers the right truck for the job, rather than the one that happens to speak the incumbent software's language. That is the case for asking for VDA 5050 support in writing from the first automated truck, even when the initial fleet comes from a single supplier.
The interface does not make every vehicle identical. Lift heights, load capacities, speeds and the set of supported actions still differ, and the factsheet is how each vehicle declares them. A good fleet manager reads those factsheets and assigns work accordingly, which is where the planning logic on top of the protocol earns its keep. The companion guides on AGV vs AMR and how autonomous forklifts work cover the vehicle side.
Robot makers and fleet managers that support VDA 5050
Every entry below was verified on 23 September 2026 by reading a public page on the company's own website that states VDA 5050 support. Absence from this table means we did not find such a page, not that the product lacks support. Numbers refer to the sources listed under the table.
| Company | Product | What the company's page says | Source |
|---|---|---|---|
| KUKA | Fleet management software for mixed AMR and AGV fleets | Lists ERP, MES and WMS integration over VDA 5050 among the software's benefits. | [1] |
| Linde Material Handling | Linde WMS with MATIC:move and MATIC:move+ control software | Describes the Linde WMS as VDA 5050 compatible so that vehicles and control software from different makers can talk to each other. | [2] |
| Bosch Rexroth | ROKIT components and ACTIVE Fleet Manager | Describes VDA 5050 based navigation and a VDA 5050 based fleet manager for mixed transport vehicles under one control station. | [3] |
| SYNAOS | Mobile-Robot Fleet Management | Describes the platform as VDA 5050 native, giving unified control of all mobile robots. | [4] |
| Meili Robots | Meili FMS | Lists ROS1, ROS2 and VDA 5050 compatibility for the fleet management system. | [5] |
| FlyWei | M4 fleet manager | Runs mixed fleets of autonomous forklifts and AMRs over VDA 5050 with REST integration to WMS, WCS and ERP. | [6] |
How M4 uses VDA 5050
M4 is FlyWei's fleet manager. It speaks VDA 5050 downwards to the vehicles and REST upwards to the warehouse management, warehouse control and ERP systems, so it is the layer that turns a WMS task into orders for individual trucks and reports completion back. It is designed for fleets of 1,000 or more robots per deployment, and plans conflict free routes for mixed fleets with FlyWei's own MAPF (multi agent path finding) algorithms.
Because the interface is open, M4 is not limited to the autonomous forklifts and AMRs FlyWei integrates from its manufacturing partners: it supports selected third party models on the same map and the same traffic plan. Custom dispatch rules, charging strategies and integrations with doors, lifts and conveyors can be added in Python or JavaScript without touching the core system, and the built in simulator lets a mixed fleet be tested on an ordinary computer before a single truck is delivered.
For a UK site that means one fleet manager, one WMS integration and one supervisor's screen whatever the mix of vehicles, deployed by UK based engineers in a typical 8 to 14 week programme after a free, no obligation site survey.
Free UK site survey
Running trucks from more than one maker?
Tell us what is on the floor today and what you plan to add. Our UK based engineers will map the fleet, confirm which vehicles can run over VDA 5050 and set out how M4 would run them together. No obligation.
UK-based engineers · reply within one business day
Or call 020 3576 6910 or email sales@flywei.co.uk.
Frequently asked questions: VDA 5050
Can one fleet manager run trucks from different makers?
Yes. That is the purpose of VDA 5050. Each vehicle publishes its state and factsheet, and receives orders and instant actions, on its own MQTT topics identified by manufacturer and serial number, so one fleet manager can plan routes and traffic for every VDA 5050 capable truck on the site regardless of who built it. Two conditions apply: each truck needs a VDA 5050 capable controller or an adapter supplied by its maker, and both sides must speak the same major version of the interface. FlyWei's M4 fleet manager runs mixed fleets over VDA 5050 in exactly this way.
What is the difference between VDA 5050 and a maker's own robot API?
A maker's own API is written for that maker's vehicles and usually for that maker's fleet software, so a second brand of truck means a second control system and manual rules for shared aisles. VDA 5050 is vendor neutral: it fixes the message names, the JSON fields and the MQTT transport, so any conforming vehicle can be driven by any conforming fleet manager. Makers can still add their own actions and parameters on top, which is why the factsheet message exists.
Does VDA 5050 replace a WMS or ERP?
No. VDA 5050 sits below the warehouse management system. The WMS or ERP decides what needs moving; the fleet manager turns that into VDA 5050 orders for individual vehicles and reports progress back. M4, for example, takes orders from a WMS, WCS or ERP over REST and dispatches them to trucks over VDA 5050, so the existing business systems stay in place.
Which version of VDA 5050 should we ask for in a tender?
Ask each supplier which major version their vehicles and fleet software support, because the major version is part of the MQTT topic and the two sides must match. Version 2.0.0 was tagged in November 2019 and released as the official VDA document in January 2020, 2.1.0 followed in August 2024 and 3.0.0 was released on 18 March 2026. For a new mixed fleet, specify the newest major version that every vehicle you plan to buy can actually run, and confirm it in writing.
Is VDA 5050 a safety standard?
No. VDA 5050 is a communication interface: it carries orders, state, connection status, factsheets, visualisation data and instant actions between a fleet manager and its vehicles. The truck's own safety scanners and controllers remain responsible for slowing and stopping it, and UK duties under PUWER and LOLER still apply to the equipment and the site. A site risk assessment is needed whichever interface the fleet uses.
Do our existing manual forklifts need VDA 5050?
No. VDA 5050 only concerns automated vehicles that take orders from a fleet manager. Manual trucks are unaffected. It becomes important the moment you plan to run automated trucks from more than one maker, or want the freedom to add a second maker later without replacing the fleet software, so it is worth specifying from the first automated truck onwards.
Does FlyWei M4 support VDA 5050?
Yes. M4 is FlyWei's fleet manager and it runs mixed fleets over the open VDA 5050 protocol, alongside REST integration with WMS, WCS and ERP platforms. It plans conflict free routes for large mixed fleets with FlyWei's MAPF algorithms, supports our full robot range and selected third party models, and can be extended in Python and JavaScript without changes to the core system.