VDA 5050 Message Flow: Fleet Manager to AGV via MQTT

Why This Matters for IT and OT

When a fleet manager coordinates AGVs on the shop floor, IT and OT teams share one integration point: the MQTT broker. Every command the fleet manager sends to an AGV and every status the AGV reports back flows as a VDA 5050 telegram through that broker.

This article gives your IT colleagues the technical overview they need to prepare the infrastructure: what topics are used, what the messages look like, and what connectivity is required between the fleet manager, the broker, and the vehicles.

Related reading: VDA 5050: The Standard for AGV Communication covers the standard itself. Fleet Manager as SaaS covers cloud deployment variants. This article focuses on how messages actually travel end-to-end.

Version coverage: This article applies to VDA 5050 2.0, 2.1, and 3.0. Topics tagged with a v3 badge below are new in 3.0; everything else is consistent across all three versions. Examples use v2 because most production deployments today still run 2.0 or 2.1.

The Three Actors

Only three components are involved in the telegram flow:

Both the fleet manager and every AGV are MQTT clients. The broker is the only server component. This is the core insight for IT: the broker is the single point of communication, and publish/subscribe replaces direct client-to-client connections.

VDA 5050 Topic Structure

VDA 5050 defines a strict topic hierarchy so that one broker can serve many vehicles from many manufacturers without collisions:

A concrete example for one vehicle:

The fleet manager subscribes with wildcards (e.g., uagv/v2/+/+/state) to receive state updates from every vehicle at once, while each AGV subscribes only to topics carrying its own serial number.

The VDA 5050 Topics

The connection topic is the only one that uses MQTT's retained flag and last-will-and-testament: the broker automatically publishes a CONNECTION_BROKEN message if a vehicle disconnects unexpectedly, so the fleet manager learns about dropouts within the keep-alive interval.

End-to-End Flow: One Order to the AGV

A typical transport order travels like this:

What a Message Actually Looks Like

All VDA 5050 payloads are UTF-8 encoded JSON. Every message shares a common header:

{
  "headerId": 1234,
  "timestamp": "2026-04-24T09:15:32.041Z",
  "version": "2.0.0",
  "manufacturer": "acme",
  "serialNumber": "AGV-0017",
  ...
}

A minimal order message adds nodes, edges, and optional actions:

{
  "headerId": 1235,
  "timestamp": "2026-04-24T09:15:33.122Z",
  "version": "2.0.0",
  "manufacturer": "acme",
  "serialNumber": "AGV-0017",
  "orderId": "ORD-7781",
  "orderUpdateId": 0,
  "nodes": [
    { "nodeId": "N-101", "sequenceId": 0, "released": true, "actions": [] },
    {
      "nodeId": "N-204",
      "sequenceId": 2,
      "released": true,
      "actions": [{ "actionType": "pick", "actionId": "a-1", "blockingType": "HARD" }]
    }
  ],
  "edges": [
    {
      "edgeId": "E-101-204",
      "sequenceId": 1,
      "released": true,
      "startNodeId": "N-101",
      "endNodeId": "N-204",
      "actions": []
    }
  ]
}

Connectivity Your IT Team Needs to Prepare

For the infrastructure to carry VDA 5050 traffic reliably, IT typically sets up the following:

Where the Broker Runs

VDA 5050 does not prescribe where the MQTT broker runs. In a classic on-premise setup, the broker lives on the same server as the fleet manager or on a dedicated industrial PC inside the plant network. When the fleet manager is deployed in the cloud or spans multiple network zones, broker placement becomes its own architectural decision. The Fleet Manager as SaaS article walks through the common variants (broker on-prem with VPN, MQTT bridge, full-cloud broker) and their trade-offs.

What stays constant across all deployments: the broker is the only server component, AGVs reach it over the plant network, and the topic structure and message formats described above are identical.

Checklist for the IT Team

• [ ] MQTT broker version and deployment location decided
• [ ] TLS certificates issued for broker and every client (fleet manager + AGVs)
• [ ] ACLs restrict each AGV to its own topic namespace
• [ ] Firewall rules opened between fleet manager, broker, and the AGV network
• [ ] Plant WiFi coverage validated on all AGV routes
• [ ] Keep-alive, last-will, and QoS expectations documented with the AGV vendor
• [ ] Monitoring in place for broker uptime, message rate, and connection drops
• [ ] Network zones and bridges defined if multi-site or segmented

Takeaways

• VDA 5050 telegrams are JSON messages published to MQTT topics following a fixed hierarchy of interfaceName/version/manufacturer/serial/topic.
• The fleet manager and every AGV are equal MQTT clients. The broker is the only server and the sole integration point IT needs to secure.
• The core topics cover everything: order, instantActions, zoneSet, and responses flow down; state, visualization, connection, and factsheet flow up.
• Where the broker runs determines latency, firewall complexity, and resilience. Fleet Manager as SaaS covers those deployment variants.

A well-run VDA 5050 setup is surprisingly small from an IT perspective: one broker, TLS, and a handful of topics. The intelligence lives in the fleet manager and on the vehicles; the network just moves JSON.

The authoritative specification and JSON schemas are published at github.com/VDA5050/VDA5050. Share the link with your AGV vendor and the IT team alongside this overview.