VDA 5050 explained: a common language for AGVs and AMRs

"We run VDA 5050" is heard more and more often when driverless trucks and mobile robots are discussed. Just as often we meet the idea that VDA 5050 is a ready-made programming language or a piece of software you install, after which robots from different manufacturers automatically work together. It isn't that simple. Here we clear up what the standard actually is, how it is structured and what it means for you.

Short answer: VDA 5050 is a common language, not a program

VDA 5050 is an interface specification. It describes which messages a master control system (often called a fleet manager) and a vehicle send to each other, what those messages contain and in what order they are sent.

The standard is developed jointly by the German industry associations VDA and VDMA. It is open and freely available, and development happens publicly on GitHub. The latest version, 3.0.0, was adopted in early 2026 and is the first to fully account for freely navigating AMRs, not just classic guided AGVs.

So there is no code to download that "is" VDA 5050. What exists is an agreement on the format. The software that speaks the standard is written by vehicle manufacturers, system vendors and integrators, in whatever programming language they choose.

A good comparison is the power socket in the wall. The standard defines what the plug and the socket look like, but not which appliance you connect or what it does. In the same way, VDA 5050 defines how vehicles and control systems talk to each other, but not how the vehicle navigates, how it stays safe or how your logistics should be planned.

How the standard is structured

VDA 5050 rests on three building blocks.

1. MQTT as transport. All messages are sent over MQTT, a lightweight messaging protocol common in IoT. Control system and vehicles don't talk directly to each other; they publish and subscribe to messages via a central server called a broker.

2. JSON as format. Every message is a JSON object with a fixed structure. The standard publishes JSON schemas so both sides can verify that messages are correct.

3. A small set of fixed message types (topics). This is where the standard itself lives. Each topic has a clear purpose and direction.

To the vehicle:

• order: the driving order itself. It describes the route as nodes and edges, and which actions to perform along the way.
• instantActions: commands to execute immediately, such as pausing, cancelling an order or starting to charge.

From the vehicle:

• state: the vehicle's current status. Position, which order it is working on, completed actions, errors and battery level.
• visualization: position and velocity at a higher rate, for showing vehicles live in a user interface.
• connection: whether the vehicle is online or not.
• factsheet: the vehicle's "data sheet", i.e. what it can do, its dimensions and which actions it supports.

The order: nodes, edges and actions

The heart of VDA 5050 is the order. Instead of sending "drive to station 7", the control system describes the route as a graph of nodes (points) and edges (the path between points). Actions can be attached to nodes and edges, for example raising the forks, picking a pallet or opening a door.

The order is split into two parts:

• Base: the part of the route that has been released. The vehicle may drive here.
• Horizon: the planned continuation. The vehicle knows where it is heading, but may not enter it until the control system releases it.

This lets the control system release vehicles step by step and resolve traffic between several vehicles, even when they come from different manufacturers.

Version 3.0.0 improves support for freely navigating robots. An AMR can share the path it has planned itself with the control system, and the control system can describe zones with traffic rules the robot must follow.

What VDA 5050 does not do

It is just as important to understand what the standard leaves out:

• It doesn't plan your logistics. Which transports happen, when and in what order is decided in the fleet manager and in your business systems such as WMS, MES and ERP.
• It doesn't navigate the vehicle. Localisation, obstacle handling and driving are handled by the vehicle's own controller.
• It doesn't make the site safe. VDA 5050 is a communication interface and contains no safety functions.
• It doesn't guarantee instant interoperability. Two vehicles can both be "VDA 5050 compatible" yet support different versions, different parts of the standard or different manufacturer-specific actions. That has to be verified in every project.

Safety is governed by EN ISO 3691-4

When driverless trucks and mobile robots move among people, EN ISO 3691-4 applies. The standard sets safety requirements for driverless industrial trucks and their systems: personnel protection, safety-rated scanners, speed limitation, operating zones, warnings and how interaction with the surroundings must be risk-assessed.

The key point is the division of responsibility. Safety lives in the vehicles and in how the site is designed, not in the messages between control system and vehicle. A control system sending an order per VDA 5050 does not make the operation safe. That's why every installation must be risk-assessed as a whole: vehicles, routes, zones, doors, lifts, charging stations and people moving in the same environment.

How SE Automation helps you

At SE Automation we integrate systems that use VDA 5050 for driverless trucks and mobile robots, and we do it in accordance with EN ISO 3691-4. In practice that means we can:

• connect vehicles from different manufacturers to a common control system via VDA 5050,
• integrate the fleet manager with your existing systems such as WMS, MES and ERP,
• verify which versions and features each vehicle actually supports before you invest,
• risk-assess and document the entire installation according to EN ISO 3691-4.

Thinking about mixing vehicles from several suppliers, or want to know whether your existing fleet can speak VDA 5050? Contact us and we'll go through your flow together.

Sources: VDA 5050 on GitHub, KIT IFL on VDA 5050, Idealworks on version 3.0.0.