A warehouse with ten robots from three vendors is not a fleet — it's three fleets that happen to share a floor. Each vendor ships its own control software, its own message format, its own idea of what "go to station 4" means. Integrating them means writing a bespoke adapter for every pair, and every new robot reopens the wound.
VDA 5050 exists to make that problem disappear. It's an open communication standard — published by the German Association of the Automotive Industry (VDA) together with the VDMA — that defines a single runtime interface between a central master control and any AGV or AMR, regardless of who built it.
The architecture: one master, many robots
VDA 5050 is deliberately centralized. One master control (the fleet manager) talks to every vehicle through a shared broker. The vehicles never talk to each other directly. This is the opposite of a peer-to-peer mesh, and the choice matters.
| Design choice | Why it matters |
|---|---|
| Centralized master control | One place owns routing, task assignment, and traffic deconfliction |
| Vehicles are passive executors | A vehicle reports state and follows orders; it never decides the plan |
| Broker-mediated (MQTT) | Loose coupling — a vehicle can drop off and rejoin without the master changing |
The master is the only party that sees the whole floor. That's what lets it prevent two robots from being sent onto the same corridor segment in the first place — a property that becomes the backbone of traffic control later in the series.
MQTT as the transport
The standard rides on MQTT (3.1.1 in most deployments), a publish/subscribe protocol built for exactly this shape of problem: many devices, unreliable links, low bandwidth. A vehicle publishes its state to a topic; the master subscribes. The master publishes an order to a topic; the vehicle subscribes.
uagv/v2/<manufacturer>/<serialNumber>/order
uagv/v2/<manufacturer>/<serialNumber>/state
The topic hierarchy encodes identity — interface name, protocol version, manufacturer, and a per-vehicle serial number. Two vehicles from different vendors can coexist on the same broker because their topics never collide.
The five message topics
Everything VDA 5050 does reduces to five topics (a sixth, optional visualization stream exists for high-rate pose data; many fleets omit it). Four are live message streams; the fifth, factsheet, is a retained capability declaration — and connection is retained too, so late subscribers always see the current status.
| Topic | Direction | Purpose |
|---|---|---|
order |
master → vehicle | A transport order: the route, the nodes, the actions |
state |
vehicle → master | Where the vehicle is, what it's doing, what's wrong |
instantActions |
master → vehicle | Immediate commands: pause, cancel, start charging |
connection |
vehicle → master | Online / offline / connection-broken status, backed by the broker's last-will |
factsheet |
vehicle → master | Static capabilities: speed, size, supported actions |
The factsheet is the quiet hero. Before the master ever sends an order, it reads the vehicle's factsheet to learn what that vehicle can do — its kinematics, its speed limits, its supported actions. A forklift and a tugger declare different capabilities, and the master plans accordingly. Interoperability isn't a hope; it's a machine-readable contract.
Why this matters for a real fleet
The value of VDA 5050 isn't theoretical. It's the difference between a warehouse that can add a fourth vendor's robot next quarter and one that can't. It's the difference between a fleet manager that treats every vehicle as a generic "truck" and one that hard-codes assumptions about a single manufacturer.
The rest of this series goes field-by-field through the wire protocol, the order lifecycle, the safety-relevant connection watchdog, and finally how it all comes together in a working fleet with traffic control and deadlock handling.
Next: MQTT Topics & Message Schemas — the exact field set that separates a correct implementation from one that only looks correct.