VDA-5050-Nachrichtenfluss: Flottenmanager zum AGV via MQTT

Warum das für IT und OT wichtig ist

Wenn ein Flottenmanager AGVs in der Produktion koordiniert, teilen sich IT und OT genau einen Integrationspunkt: den MQTT-Broker. Jedes Kommando vom Flottenmanager an ein AGV und jede Statusmeldung des AGVs zurück fließt als VDA-5050-Telegramm über diesen Broker.

Dieser Artikel liefert den technischen Überblick, den Ihre IT braucht, um die Infrastruktur vorzubereiten: welche Topics verwendet werden, wie die Nachrichten aufgebaut sind und welche Konnektivität zwischen Flottenmanager, Broker und Fahrzeugen benötigt wird.

Weiterführend: VDA 5050: Der Standard für AGV-Kommunikation behandelt den Standard selbst. Flottenmanager als SaaS behandelt Cloud-Deployment-Varianten. Dieser Artikel konzentriert sich darauf, wie Nachrichten tatsächlich Ende-zu-Ende fließen.

Versionsabdeckung: Dieser Artikel gilt für VDA 5050 2.0, 2.1 und 3.0. Topics mit v3-Badge in den Tabellen unten sind neu in 3.0; alles andere ist über alle drei Versionen hinweg konsistent. Die Beispiele verwenden v2, weil die meisten Produktivdeployments heute noch 2.0 oder 2.1 einsetzen.

Die drei Akteure

Am Telegrammfluss sind nur drei Komponenten beteiligt:

Sowohl der Flottenmanager als auch jedes AGV sind MQTT-Clients. Der Broker ist die einzige Serverkomponente. Das ist die zentrale Erkenntnis für die IT: Der Broker ist der einzige Kommunikationsknoten, Publish/Subscribe ersetzt direkte Client-zu-Client-Verbindungen.

VDA-5050-Topic-Struktur

VDA 5050 definiert eine strikte Topic-Hierarchie, damit ein Broker viele Fahrzeuge mehrerer Hersteller ohne Kollisionen bedienen kann:

Ein konkretes Beispiel für ein Fahrzeug:

Der Flottenmanager abonniert mit Wildcards (z. B. uagv/v2/+/+/state), um den Status aller Fahrzeuge gleichzeitig zu erhalten. Jedes AGV abonniert dagegen nur Topics, die seine eigene Seriennummer enthalten.

Die VDA-5050-Topics

Nur das connection-Topic nutzt das Retained-Flag und das Last-Will-and-Testament von MQTT: Der Broker publiziert automatisch eine CONNECTION_BROKEN-Nachricht, wenn ein Fahrzeug unerwartet die Verbindung verliert. So erkennt der Flottenmanager Ausfälle innerhalb des Keep-Alive-Intervalls.

Ende-zu-Ende-Fluss: Ein Auftrag zum AGV

Ein typischer Transportauftrag wandert wie folgt:

Wie eine Nachricht aussieht

Alle VDA-5050-Payloads sind UTF-8-kodiertes JSON. Jede Nachricht teilt denselben Header:

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

Eine minimale Order-Nachricht ergänzt Nodes, Edges und optionale 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": []
    }
  ]
}

Konnektivität, die Ihre IT vorbereiten muss

Damit die Infrastruktur VDA-5050-Traffic zuverlässig trägt, richtet die IT typischerweise Folgendes ein:

Wo der Broker läuft

VDA 5050 schreibt nicht vor, wo der MQTT-Broker läuft. In einem klassischen On-Premise-Setup läuft der Broker auf demselben Server wie der Flottenmanager oder auf einem dedizierten Industrie-PC im Werksnetzwerk. Wird der Flottenmanager in der Cloud oder über mehrere Netzwerkzonen hinweg betrieben, wird die Broker-Platzierung zu einer eigenen Architekturentscheidung. Der Artikel Flottenmanager als SaaS geht auf die üblichen Varianten (Broker on-prem mit VPN, MQTT Bridge, Broker vollständig in der Cloud) und deren Trade-offs im Detail ein.

Was über alle Deployments hinweg gleich bleibt: Der Broker ist die einzige Serverkomponente, AGVs erreichen ihn über das Werksnetzwerk, und die oben beschriebene Topic-Struktur und die Nachrichtenformate sind identisch.

Checkliste für die IT

• [ ] MQTT-Broker-Version und Einsatzort festgelegt
• [ ] TLS-Zertifikate für Broker und jeden Client ausgestellt (Flottenmanager + AGVs)
• [ ] ACLs beschränken jedes AGV auf seinen eigenen Topic-Namensraum
• [ ] Firewall-Regeln zwischen Flottenmanager, Broker und AGV-Netzwerk freigeschaltet
• [ ] WLAN-Abdeckung auf allen AGV-Routen validiert
• [ ] Keep-Alive, Last-Will und QoS-Erwartungen mit dem AGV-Lieferanten dokumentiert
• [ ] Monitoring für Broker-Verfügbarkeit, Nachrichtenrate und Verbindungsabbrüche eingerichtet
• [ ] Netzwerkzonen und Bridges definiert, falls Multi-Site oder segmentiert

Kernaussagen

• VDA-5050-Telegramme sind JSON-Nachrichten auf MQTT-Topics nach der festen Hierarchie interfaceName/version/manufacturer/serial/topic.
• Flottenmanager und jedes AGV sind gleichberechtigte MQTT-Clients. Der Broker ist die einzige Serverkomponente und der einzige Integrationspunkt, den die IT absichern muss.
• Die Kern-Topics decken alles ab: order, instantActions, zoneSet und responses fließen nach unten; state, visualization, connection und factsheet fließen nach oben.
• Wo der Broker läuft, bestimmt Latenz, Firewall-Komplexität und Ausfallsicherheit. Der Artikel Flottenmanager als SaaS behandelt die Deployment-Varianten.

Ein sauber aufgesetztes VDA-5050-System ist aus IT-Sicht überraschend kompakt: ein Broker, TLS und eine Handvoll Topics. Die Intelligenz liegt im Flottenmanager und auf den Fahrzeugen; das Netz transportiert nur JSON.

Die offizielle Spezifikation und die JSON-Schemas sind unter github.com/VDA5050/VDA5050 veröffentlicht. Teilen Sie den Link neben diesem Überblick mit Ihrem AGV-Lieferanten und der IT.