VDA 5050 and the mixed fleet: what the standard covers and what it does not

In tenders and project plans for mixed fleets, the assumption that VDA 5050 makes automated guided vehicles (AGV) and autonomous mobile robots (AMR) from different manufacturers directly compatible is common. In practice that misunderstanding leads to reliable miscalculation at commissioning and in operation. VDA 5050 is not a protocol for direct machine-to-machine communication on the floor. It is a standardised interface between a master control and the individual mobile units.

Developed jointly by the German Association of the Automotive Industry (VDA) and the Mechanical Engineering Industry Association (VDMA), with support from the Institute for Material Handling and Logistics (IFL) at the Karlsruhe Institute of Technology, the specification currently stands at version 3.0.0 and defines a vendor-neutral data layer. Communication is based on MQTT with JSON-structured payloads. For a vendor-independent integrator the boundary is what matters: the interface carries commands and state values; it does not govern autonomous interaction in physical space.

• Central mediation, not swarm intelligence: under VDA 5050, robots from different manufacturers exchange no data directly at any point. Every interaction runs strictly through the central fleet manager.
• Topological guidance, not behavioural agreement: the master control assigns orders over nodes and edges. If two vehicles meet in a corridor, neither knows the other's state unless the master control has defined a precedence.
• Standardised message types: the protocol governs traffic over fixed topics for orders (order), immediate actions (instantActions), vehicle state (state), visualisation (visualization), connection checking (connection) and vehicle data sheets (factsheet) — but contains no traffic or yielding logic.

For operators this means conformity to VDA 5050 is the messaging basis for connecting a vehicle to a fleet control system. It guarantees neither coordinated yielding behaviour nor a shared spatial process on the operating floor.

VDA 5050, published jointly by VDA and VDMA, standardises the message-based protocol between a central master control and AGVs and AMRs. Technically the specification rests on MQTT and on strictly prescribed JSON schemas. A neutral integrator uses the standard to process control commands and telemetry from different manufacturers in one uniform format, rather than maintaining parallel vendor-specific protocols.

The central message topics under VDA 5050

• order: transmits driving orders from the master control to the vehicle, broken into nodes, edges, trajectories and action points.
• state: sends the robot's operating state to the control system cyclically, including coordinates, battery status, active errors and progress.
• instantActions: triggers priority actions such as pause, cancel or acknowledge immediately, outside the normal order sequence.
• connection: monitors the connection state between broker and vehicle via standardised heartbeat signals and MQTT last-will messages.
• factsheet and zoneSet: carry static vehicle parameters for system set-up, and, in version 3.0.0, structured zone definitions for release areas.

VDA and VDMA list version 3.0.0, dated March 2026, as the current specification; the VDA states plainly that “Ältere Versionen der VDA 5050 werden nicht mehr empfohlen oder weiterentwickelt” – older versions are neither recommended nor developed further. Version 3.0.0 extends the interface towards mobile robots with higher levels of autonomy, introducing a zone concept for free navigation in which zones define areas with specific movement rules, such as restricted areas, one-way routes or areas where the master control must grant explicit authorisation.

The functional cut stays strict throughout: VDA 5050 defines the syntactic structure and the transport path of data packets. It governs how commands are formulated and states reported, and deliberately says nothing about physical driving dynamics, cross-vendor yielding rules or priority in shared traffic space.

VDA 5050 standardises the exchange of information between a master control and mobile robots. It does not relieve operators of the detailed architecture on site.

This is not interpretation – it is in the document. Section 2, “Scope”, of the specification expressly removes from its scope: safety requirements (“This document does not define functional, operational, or system safety requirements and shall not be regarded or applied as a safety standard”), traffic management logic (“Strategies, algorithms, or decision making processes for traffic coordination (e.g., routing, prioritization, congestion handling, or deadlock resolution) are not included”), other communication interfaces to peripheral equipment or external IT systems, project coordination and commissioning procedures, the allocation of operational responsibilities between operators, integrators, vehicle manufacturers and fleet control providers, and cybersecurity measures.

Core operational functions of an autonomous transport system are therefore excluded. The standard plans no routes, resolves no traffic conflicts and assigns no orders; map formats and navigation methods remain largely vendor-specific. Each robot operates inside its own manufacturer's coordinate system and relies on proprietary SLAM, while the master control assigns nothing more than abstract waypoints and edges.

• Map exchange and sensor data: there is no normalised environment model. Robots from different manufacturers share no point clouds or dynamic obstacle data with each other.
• Mechanical load handling: physical pick, lift and transfer processes at stations remain vendor-specific subroutines, triggered from the control system only as generalised actions.
• Battery and charging management: the interface reports state of charge but normalises neither charging curves, nor automated docking manoeuvres, nor the allocation logic at shared chargers.
• Error semantics and diagnostics: the state message carries warnings and errors, but functional assessment, diagnostic depth and remedy vary considerably by OEM.

Functional safety sits outside the interface

The most consequential misconception in planning heterogeneous fleets concerns personnel protection. Functional safety is expressly outside the scope of VDA 5050. Emergency stop and person detection stay on the vehicle and are governed by standards such as ISO 3691-4 (“Industrial trucks – Safety requirements and verification – Part 4: Driverless industrial trucks and their systems”, December 2023), which the specification itself lists among its normative references. Where two autonomous vehicles of different design meet in a narrow corridor, no interface protocol decides who yields. Resolving spatial conflicts, deadlock management and operational safety validation remain a contractual and organisational integration task.

While VDA 5050 shapes the European market, North America has taken a different approach. The MassRobotics AMR Interoperability Standard, published in version 1.0 in May 2021, is an alternative initiative for cross-vendor fleets; MassRobotics lists version 1.0 as complete and version 2.0 as in development. Initiated by the non-profit MassRobotics, the standard pursues a deliberately narrower goal: rather than directing robots in detail through a master control, it enables the sharing of elementary state and position data.

Its architecture concentrates on telemetry and observability. According to MassRobotics, what compliant robots share is current location and future destination, a unique identifier, a timestamp of data collection, manufacturer name, model and dimensions, operational state (active/idle, available/unavailable), and speed and direction. Proprietary maps do not have to be disclosed. For an operator coordinating mobile robots from different manufacturers on the same floor, this produces a single common picture.

• Control ambition: VDA 5050 aims to run vehicles from several manufacturers under one master control, whereas the MassRobotics standard is limited to sharing basic data and expressly does not cover task management.
• System depth: in its own words, “The MassRobotics Interoperability Standard isn't a fleet management, vehicle navigation, or safety system”; compliant vehicles still need their own navigation and safety systems.
• Infrastructure: the MassRobotics working group deliberately left hardware topics such as shared chargers out of the standard, and VDA 5050 likewise governs no physical interaction at charging or transfer stations.

The two do not exclude each other in practice, but they address different layers. VDA 5050 enables end-to-end process integration; MassRobotics provides a lightweight tool for keeping sight of a mixed fleet. For operators the international comparison underlines the same finding: an interface standard replaces neither vendor-specific navigation logic nor the contractual settlement of traffic behaviour inside the building.

In practice, implementing VDA 5050 tends to produce false assumptions about vehicle autonomy. The specification standardises the exchange of orders and status messages between master control and vehicle, but it is an interface and not a control brain: route planning, traffic resolution and order allocation live in the master control's software, not in the standard. Where AMRs or AGVs from two different manufacturers meet in an awkward corridor, no standardised yielding protocol operates at sensor level.

Typical points of friction in heterogeneous fleets

• Head-on traffic and deadlocks: where vehicles from different manufacturers face each other, both safety laser scanners stop them in line with their protective fields under ISO 3691-4. Without zone locking in the master control, both systems simply stand there, because no vehicle autonomously backs off.
• Resource and charger blocking: if one manufacturer's vehicle blocks access to a shared charger or transfer station, the standard contains no native mechanism for cross-vendor prioritisation or forced rerouting.
• Divergent mapping and localisation: each manufacturer uses its own SLAM algorithms and coordinate origins. If the master control does not enforce a single authoritative map, small differences in position estimation produce wrong assumptions in zone release.

These conflicts show that interoperability does not arise from data protocols alone. Operators have to define traffic management, yielding hierarchy and mapping standards up front as an operating concept, the way a specialist integrator sets it up for cross-vendor fleets. How that looks at platform level is covered in our articles on the multi-robot coordination platform, on robot fleet management and on the multi-tenant connector platform.

Because VDA 5050 is designed as a pure communication interface between master control and individual vehicle, the physical and organisational conflict scenarios on the floor stay ungoverned. Whether a mixed fleet works productively or blocks itself in bottlenecks does not depend on the MQTT protocol. It depends on the specifications agreed between operator, integrator and the participating robot manufacturers.

Mandatory points for a multi-OEM contract

• Right of way and bottleneck management: written definition of priority zones, response times when a vehicle stands in the travel path, and standardised yielding manoeuvres in head-on traffic.
• Charging infrastructure and dwell times: rules on maximum dwell at shared or proprietary charging points, and automatic release obligations when a queue forms.
• Map authority and reference system: agreement on one leading environment map, common origins, and fixed intervals for synchronising route changes.
• Error semantics and acknowledgement: unambiguous definition of error classes, guaranteed restart times after emergency-stop events, and service level agreements per manufacturer.
• Safety boundaries under ISO 3691-4: demarcation of safety responsibility at transfer stations and at personnel interfaces in mixed operation.

Asset managers and operations leads have to anchor these parameters as hard contract clauses before rollout. Without them, every disruption turns into an unresolved question of responsibility between the manufacturers involved.

Implementing a heterogeneous fleet rarely fails at the protocol layer. It fails in the organisational and procedural gaps between manufacturers. VDA 5050 in version 3.0.0 describes uniform data structures for order and status messages, but VDA and VDMA position it expressly as a non-binding recommendation whose correct application in the individual case rests with the user. The step from interface standard to stable floor operation is made by a vendor-independent integration layer that bundles planning, procurement and commissioning across every OEM involved.

Division of labour between integrator and operator

A vendor-independent systems integrator takes on the technical and contractual harmonisation between the OEMs involved. werob builds no hardware of its own, nor does it hold regulatory operating authorisations on the operator's behalf. What integration does is close the gap between the physical vehicles and the overlying ERP or WMS systems, by resolving interface divergence in advance and aligning safety areas with one another.

• Structured alignment of all vehicle-specific action parameters and route assignments before commissioning.
• Definition of uniform escalation and error-handling routines across every OEM fleet involved.
• Delivery of the end-to-end process from technical specification to floor operation in eight weeks.

For operators and maintenance leads this shifts project risk away from unclear interface boundaries and towards defined operating contracts. Responsibility for safe and economic operation stays with the plant operator; what changes is that cross-vendor coordination now rests on a technical basis that holds.