VDA 5050: A Practical Introduction to Multi-Vendor Robot Fleets

What VDA 5050 is

VDA 5050 is a recommendation for a vendor-neutral communication interface between fleet control and mobile robots. Developed by VDA and VDMA, it addresses a practical integration problem: a controller and robots from different manufacturers need agreed meanings for jobs and status, rather than a different communication model for every pairing.

Sources: official VDA publication and v3.0.0 foreword.

For a reader comparing systems, the key distinction is between a common interface and a finished integration. FleetMesh recommends treating the version, supported capabilities and actual behavior as separate things to verify.

The controller / robot relationship

Fleet control coordinates work and routes at fleet level. The mobile robot localizes itself, follows its assigned movement instructions, performs actions and reports its state. The interface connects those responsibilities; it does not turn the controller into the robot's onboard navigation stack.

Source: VDA 5050 v3.0.0, sections 5.3 and 5.4.

V3 accommodates both line-guided and freely navigating robots. Its zone and path-sharing concepts let fleet control constrain movement while supporting more planning on the robot. This is still a defined exchange of responsibilities, not an instruction to give every robot unrestricted autonomy.

Source: VDA's announcement of version 3.0.

MQTT carries the messages; JSON describes them

VDA 5050 uses MQTT with JSON-formatted payloads. Publishers send messages through a broker to subscribers on named topics. For a local broker, the specification proposes a topic hierarchy containing the interface, major version, manufacturer, serial number and message topic.

interfaceName/majorVersion/manufacturer/serialNumber/topic

Illustrative topic (not a live endpoint):
vda5050/v3/ExampleMaker/Robot001/order

The path identifies a channel. The JSON payload carries the data associated with that message family. Validate a payload against the matching release's schema, and also check the protocol's sequencing and behavioral rules. Passing JSON Schema validation alone cannot demonstrate correct fleet behavior.

Sources: transport protocol and official v3.0.0 JSON schemas. The validation distinction is FleetMesh engineering guidance.

V3.0.0 specifies MQTT QoS 0 for the ordinary message topics and QoS 1 for connection. Integration testing therefore needs to account for missing messages and disconnections; do not mistake a broker delivery setting for proof that an order was executed.

Source: VDA 5050 v3.0.0, section 4.1.

The message families to know

Source: VDA 5050 v3.0.0, section 4.3.

Orders: nodes, edges and actions

An order describes a route using nodes and connecting edges, with actions attached where appropriate. orderId identifies the order; orderUpdateId distinguishes updates. Released nodes and edges form the base the robot can execute. An unreleased horizon can describe work ahead without yet releasing it for execution.

For example, a controller could release the path to a waiting position while keeping a later shared segment unreleased. Deciding when that segment is available is a controller policy, not an algorithm supplied by the message format.

Source: VDA 5050 v3.0.0, section 6.1; the waiting-position example is illustrative.

State: progress, not just position

state is where fleet control observes order progress, robot operating information, actions and errors. In v3, route-related, instant and zone actions have separate state arrays. A controller should correlate the received state with the intended order and actions rather than infer completion from successful publication to MQTT.

Sources: state semantics and v3 action-state changes. Completion checking is FleetMesh implementation guidance.

Instant actions: a separate action channel

instantActions carries actions that are not tied to reaching a route node or traversing an edge. A factsheet request is one example. An instant action still has execution and reporting rules: the word "instant" does not establish a hard real-time deadline or a safety-rated stop mechanism.

Source: VDA 5050 v3.0.0, section 6.2.1; see also section 2 for safety scope.

Visualization: faster observations where needed

The optional visualization topic provides position, velocity and trajectory information at a rate chosen during integration. In v3 it can also support higher-frequency path sharing, so it is not restricted to drawing a user interface.

Source: VDA 5050 v3.0.0, sections 6.7 and 6.8.

Factsheet: ask what the robot supports

The JSON factsheet describes characteristics of a robot type, supported features and protocol limits. Fleet control can request it using factsheetRequest. Some values require project-specific configuration during integration; a factsheet is useful evidence, not a substitute for testing the intended workflow.

Source: VDA 5050 v3.0.0, section 6.10; testing advice is FleetMesh guidance.

Connection: transport status is not robot health

The connection topic uses the robot's connection messages and MQTT's Last Will mechanism to signal broker connectivity, including unexpected disconnects. An online MQTT client is not evidence that the robot is ready, localized or able to accept work. Use the appropriate operating and execution state as well.

Source: VDA 5050 v3.0.0, section 6.5 and the topic table in section 4.3.

An illustrative transport workflow

This sequence is a reading aid, not a complete commissioning procedure or a runnable example.

1. Agree capabilities. Establish the protocol version, robot identity, coordinate conventions and supported actions; inspect the factsheet.
2. Publish an order. Fleet control sends nodes, edges and required actions, with a clearly identified released base.
3. Observe execution. Correlate incoming state with the order and action identifiers. Check progress and errors.
4. Extend or recover. Send valid order updates as more work is released, or follow an explicitly designed cancellation and recovery policy.

FleetMesh synthesis based on section 5, order semantics and state semantics.

What VDA 5050 does not solve

The specification explicitly excludes traffic-management decision logic, safety requirements, cybersecurity mechanisms, unrelated infrastructure interfaces and project acceptance procedures. It also does not allocate operational responsibility between the parties implementing a system.

Source: VDA 5050 v3.0.0, section 2.

• Traffic decisions: a shared message structure is not a deadlock-resolution or scheduling algorithm.
• Security: identity, access control, network design and broker configuration need their own engineering decisions.
• Safety: neither an MQTT connection nor an action message should be presented as a safety certification.
• Interoperability: versions, optional features and application assumptions still need to line up.

FleetMesh interpretation of the documented scope and optional-field rules.

Questions for an integration review

FleetMesh recommends collecting evidence around these questions before calling a controller and robot compatible:

1. Which exact specification and schema versions does each side implement?
2. Which required actions and optional fields are supported, and where are the limits documented?
3. How are map identifiers, coordinates and route assumptions aligned?
4. What does each side do after a lost connection, an outdated update or an action failure?
5. Who owns traffic policy, recovery, security configuration and acceptance testing?

Record observed behavior alongside documentation. This guide does not certify any implementation or claim that FleetMesh has tested a particular robot or controller.

Primary sources and version record

• VDA publication: VDA 5050

  The publisher's publication page and official recommendation.

• Official specification, tag 3.0.0

  Normative details referenced throughout this independent introduction.

  Tag commit: e9ba560b0e2d3f66526550ad5d61b8a2ad936172

• JSON schemas, tag 3.0.0

  Machine-readable message definitions for the same version.

• Official v3.0.0 release notes

  Changes to compare when reading older v2 material.

Sources checked 8 October 2026. Text and explanatory examples are FleetMesh's own summaries. FleetMesh is not affiliated with VDA or VDMA. The official specification takes precedence over this introduction.