VDA 5050 und die gemischte Flotte: was die Schnittstelle regelt und was nicht

In Ausschreibungen und Projektplanungen für gemischte Flotten herrscht häufig die Annahme vor, der Standard VDA 5050 mache fahrerlose Transportfahrzeuge (FTF) und autonome mobile Roboter (AMR) verschiedener Hersteller direkt miteinander kompatibel. In der Praxis führt dieses Missverständnis regelmäßig zu Fehlkalkulationen bei Inbetriebnahme und Betrieb. Die VDA 5050 ist kein Protokoll für eine direkte Maschine-zu-Maschine-Kommunikation auf dem Hallenboden, sondern eine standardisierte Schnittstelle zwischen einer übergeordneten Leitsteuerung (Master Control) und den einzelnen mobilen Einheiten.

Gemeinsam entwickelt vom Verband der Automobilindustrie (VDA) und dem Verband Deutscher Maschinen- und Anlagenbau (VDMA) mit Unterstützung des Instituts für Fördertechnik und Logistiksysteme am Karlsruher Institut für Technologie (KIT IFL), liegt die Spezifikation aktuell in der Version 3.0.0 vor und definiert eine herstellerunabhängige Datenebene. Die Kommunikation basiert auf dem Protokoll Message Queuing Telemetry Transport (MQTT) mit JSON-strukturierten Datenstrukturen. Für einen herstellerunabhängigen Systemintegrator ist die Abgrenzung entscheidend: Die Schnittstelle transportiert Befehle und Statuswerte, regelt aber kein autonomes Zusammenwirken im physischen Raum.

• Zentrale Vermittlung statt Schwarmintelligenz: Roboter verschiedener Hersteller tauschen unter VDA 5050 zu keinem Zeitpunkt direkte Daten aus. Jede Interaktion läuft strikt über den zentralen Flottenmanager.
• Topologische Führung statt Verhaltensabgleich: Die Leitsteuerung weist Aufträge über Knoten und Kanten zu. Begegnen sich zwei Fahrzeuge in einem Korridor, weiß kein Fahrzeug vom Status des anderen, sofern die Leitsteuerung keinen Vorrang definiert hat.
• Standardisierte Nachrichtentypen: Das Protokoll regelt den Nachrichtenverkehr über feste Kanäle für Aufträge (order), Sofortaktionen (instantActions), Fahrzeugzustände (state), Visualisierung (visualization), Verbindungsprüfung (connection) und Fahrzeugsteckbriefe (factsheet), enthält jedoch keine Verkehrs- oder Ausweichlogiken.

Für Betreiber bedeutet dies: Die Konformität eines FTF oder AMR zur VDA 5050 ist die nachrichtentechnische Basis für die Anbindung an eine Flottensteuerung. Sie garantiert jedoch weder ein abgestimmtes Ausweichverhalten noch eine gemeinsame räumliche Prozessharmonisierung auf der Betriebsfläche.

Die Schnittstelle VDA 5050, gemeinsam herausgegeben vom Verband der Automobilindustrie (VDA) und dem VDMA, standardisiert das nachrichtenbasierte Protokoll zwischen einer zentralen Leitsteuerung und fahrerlosen Transportfahrzeugen (FTF) sowie autonomen mobilen Robotern (AMR). Technisch basiert die Spezifikation auf dem Netzwerkprotokoll MQTT (Message Queuing Telemetry Transport) und strikt vorgegebenen JSON-Schemata. Ein neutraler Systemintegrator nutzt diesen Standard, um Steuerbefehle und Telemetriedaten verschiedener Hersteller in einem einheitlichen Format zu verarbeiten, statt parallele herstellerspezifische Protokolle zu pflegen.

Die zentralen Nachrichten-Topics nach VDA 5050

• order: Übermittelt Fahraufträge von der Leitsteuerung an das Fahrzeug, aufgeteilt in Knoten (Nodes), Kanten (Edges), Trajektorien und anzufahrende Aktionspunkte.
• state: Sendet zyklisch den Betriebszustand des Roboters an das Leitsystem, einschließlich Koordinaten, Batteriestatus, aktiver Fehler und Bearbeitungsfortschritt.
• instantActions: Ermöglicht das unverzügliche Auslösen vorrangiger Aktionen wie Pausieren, Abbrechen oder Quittieren außerhalb der normalen Auftragsabfolge.
• connection: Überwacht den Verbindungsstatus zwischen Broker und Fahrzeug über standardisierte Heartbeat-Signale und MQTT-Last-Will-Meldungen.
• factsheet und zoneSet: Überträgt statische Fahrzeugparameter zur Systemeinrichtung sowie in Version 3.0.0 strukturierte Zonendefinitionen für Freigabebereiche.

Als aktuelle Empfehlung führen VDA und VDMA die Spezifikationsversion 3.0.0 mit Stand März 2026; ältere Versionen werden ausdrücklich nicht mehr empfohlen oder weiterentwickelt. Der funktionale Zuschnitt bleibt dabei strikt abgegrenzt: Die VDA 5050 definiert die syntaktische Struktur und den Transportweg von Datenpaketen. Sie regelt verbindlich, wie Befehle formuliert und Zustände gemeldet werden, trifft jedoch bewusst keine Aussagen über physikalische Fahrdynamiken, herstellerübergreifende Ausweichregeln oder die Priorisierung im gemeinsamen Verkehrsraum.

Die Schnittstelle VDA 5050 standardisiert den nachrichtentechnischen Informationsaustausch zwischen einer Leitsteuerung und mobilen Robotern, entbindet Betreiber jedoch nicht von der Detailarchitektur vor Ort. Das ist keine Auslegung, sondern steht so im Dokument: Abschnitt 2 „Scope“ der Spezifikation nimmt Sicherheitsanforderungen, Verkehrsmanagement-Logik, Schnittstellen zu Peripherie und externen IT-Systemen, Projektabwicklung, die Zuweisung betrieblicher Verantwortlichkeiten sowie Cybersicherheit ausdrücklich aus dem Geltungsbereich heraus. Wesentliche operative Kernfunktionen autonomer Transportsysteme sind damit ausgeklammert: Der Standard plant keine Routen, löst keine Verkehrskonflikte und vergibt keine Aufträge, und Kartenformate sowie Navigationsverfahren bleiben weitgehend herstellerspezifisch. Jeder Roboter agiert innerhalb seines herstellereigenen Koordinatensystems und stützt sich auf proprietäre SLAM-Verfahren, während die übergeordnete Steuerung lediglich abstrakte Wegpunkte und Kanten als Fahrbefehle zuweist.

• Kartenabgleich und Sensordaten: Es existiert kein normiertes Umgebungsmodell. Roboter verschiedener Hersteller teilen keine Punktwolken oder dynamische Hindernisdaten direkt untereinander.
• Mechanische Lasthandhabung: Physische Aufnahme-, Hub- und Übergabeprozesse an Stationen bleiben herstellerspezifische Subroutinen, die im Leitstand lediglich als generalisierte Aktionen getriggert werden.
• Batterie- und Lademanagement: Die Schnittstelle meldet Ladestände, normiert jedoch weder Ladekurven, automatisierte Andockmanöver noch die Zuweisungslogik an geteilten Ladesäulen.
• Fehlersemantik und Diagnose: Das Zustandsprotokoll übermittelt Warnungen und Fehler, doch die funktionale Bewertung, Diagnosetiefe und Fehlerbehebung variieren je nach OEM erheblich.

Funktionale Sicherheit steht außerhalb der Schnittstelle

Der folgenschwerste Trugschluss bei der Planung heterogener Flotten betrifft den Personenschutz: Funktionale Sicherheit liegt ausdrücklich außerhalb des Geltungsbereichs der VDA 5050. Not-Halt und Personenerkennung verbleiben am Fahrzeug und werden durch Normen wie die ISO 3691-4 geregelt. Die ISO 3691-4 ist die zentrale Sicherheitsnorm für fahrerlose Flurförderzeuge und definiert unter anderem die Performance Level der Sicherheitsfunktionen, etwa für die Personenerkennung. Treffen zwei autonome Fahrzeuge unterschiedlicher Bauart in einem engen Betriebskorridor aufeinander, entscheidet kein Schnittstellenprotokoll über das Ausweichverhalten. Die Auflösung räumlicher Konflikte, das Deadlock-Management sowie die betriebliche Sicherheitsvalidierung verbleiben als vertragliche und organisatorische Integrationsaufgabe für den Systemintegrator.

Während die VDA 5050 den europäischen Markt prägt, verfolgt der nordamerikanische Raum eine andere Philosophie. Mit dem im Mai 2021 in Version 1.0 veröffentlichten MassRobotics AMR Interoperability Standard existiert eine alternative Initiative für herstellerübergreifende Flotten; MassRobotics führt Version 1.0 als abgeschlossen und Version 2.0 als in Entwicklung. Der von der Non-Profit-Organisation MassRobotics initiierte Standard verfolgt ein bewusst reduziertes Ziel: Statt Roboter über eine übergeordnete Leitsteuerung im Detail zu führen, ermöglicht er das Teilen elementarer Zustands- und Positionsdaten.

Die Architektur von MassRobotics konzentriert sich auf Telemetrie und Beobachtbarkeit. Geteilt werden nach Angaben von MassRobotics die aktuelle Position und das nächste Ziel, eine eindeutige Kennung, ein Zeitstempel, Herstellername, Modell und Abmessungen, der Betriebszustand sowie Geschwindigkeit und Fahrtrichtung. Herstellereigene Karten müssen dafür nicht offengelegt werden. Für Betreiber, die mobile Roboter verschiedener Hersteller auf derselben Fläche koordinieren, entsteht so ein einheitliches Lagebild.

• Steuerungsanspruch: Die VDA 5050 zielt darauf, Fahrzeuge mehrerer Hersteller unter einer gemeinsamen Leitsteuerung zu betreiben, während der MassRobotics-Standard auf das Teilen von Basisdaten begrenzt ist und ausdrücklich kein Aufgabenmanagement umfasst.
• Systemtiefe: MassRobotics ist nach eigener Darstellung kein Flottenmanagement-, Navigations- oder Sicherheitssystem; konforme Fahrzeuge benötigen weiterhin eigene Navigations- und Sicherheitssysteme.
• Infrastruktur: Hardwarethemen wie geteilte Ladestationen hat die MassRobotics-Arbeitsgruppe bewusst aus dem Standard ausgeklammert, und auch die VDA 5050 regelt keine physische Interaktion an Lade- oder Übergabestationen.

In der Praxis schließen sich beide Konzepte nicht aus, adressieren aber unterschiedliche Ebenen. Während die VDA 5050 eine durchgängige Prozessintegration ermöglicht, liefert MassRobotics ein leichtgewichtiges Werkzeug zur Übersicht gemischter Flotten. Für Betreiber unterstreicht der internationale Vergleich den Kernbefund: Eine Schnittstellennorm ersetzt weder die herstellerspezifische Navigationslogik noch die vertragliche Festlegung des Verkehrsverhaltens im Gebäude.

In der betrieblichen Praxis führt die Implementierung der VDA 5050 häufig zu falschen Annahmen bezüglich der Fahrzeugautonomie. Die von VDA und VDMA herausgegebene Spezifikation standardisiert den Austausch von Aufträgen und Statusmeldungen zwischen Leitsteuerung und Fahrzeug, ist aber eine Schnittstelle und kein Steuerungsgehirn: Routenplanung, Verkehrsauflösung und Auftragszuweisung liegen in der Software der Leitsteuerung, nicht im Standard. Treffen autonome mobile Roboter (AMR) oder fahrerlose Transportfahrzeuge (FTF) zweier verschiedener Hersteller in einem unübersichtlichen Korridor aufeinander, greift kein genormtes Ausweichprotokoll auf Sensorebene.

Typische Reibungspunkte in heterogenen Flotten

• Begegnungsverkehr und Deadlocks: Stehen sich Fahrzeuge unterschiedlicher Hersteller gegenüber, stoppen beide Sicherheitslaserscanner gemäß den Schutzfeldern nach ISO 3691-4. Ohne übergeordnete Zonensperren in der Leitsteuerung verharren beide Systeme im Stillstand, da kein FTF autonom den Rückzug antritt.
• Ressourcen- und Ladeblockaden: Blockiert ein Fahrzeug eines Herstellers die Zufahrt zu einer universellen Ladestation oder Übergabestation, existiert im Standard kein nativer Mechanismus zur herstellerübergreifenden Priorisierung oder Zwangsumleitung.
• Abweichende Kartierung und Lokalisierung: Jeder Hersteller nutzt eigene SLAM-Algorithmen und Koordinatenursprünge. Wenn die Leitsteuerung keine einheitliche Master-Karte erzwingt, führen millimeterfeine Differenzen in der Positionsbestimmung zu Fehlannahmen bei der Zonenfreigabe.

Diese operativen Konflikte verdeutlichen, dass Interoperabilität nicht allein durch Datenprotokolle entsteht. Betreiber müssen das Verkehrsmanagement, Ausweichhierarchien und Kartierungsstandards vorab als Betriebskonzept definieren, wie es ein spezialisierter Systemintegrator für herstellerübergreifende Flotten aufsetzt. Wie sich das auf der Plattformebene abbildet, beschreiben unsere Beiträge zur Multi-Roboter-Koordinationsplattform und zur Multi-Tenant-Connector-Plattform.

Weil die VDA 5050 als reine Kommunikationsschnittstelle zwischen Leitsteuerung und Einzelfahrzeug konzipiert ist, bleiben die physikalischen und organisatorischen Konfliktszenarien auf der Fläche, wie sie oben beschrieben sind, ungeregelt. Ob eine gemischte Flotte produktiv arbeitet oder sich in Engpässen gegenseitig blockiert, hängt nicht am MQTT-Protokoll, sondern an den Pflichtenheften zwischen Betreiber, Systemintegrator und den beteiligten Roboterherstellern.

Operative Pflichtpunkte für den Multi-OEM-Vertrag

• Vorfahrt und Engpassmanagement: Schriftliche Festlegung von Vorrangzonen, Reaktionszeiten beim Stillstand im Fahrweg und standardisierten Ausweichmanövern bei Begegnungsverkehr.
• Ladeinfrastruktur und Standzeiten: Regeln für die maximale Verweildauer an geteilten oder proprietären Ladepunkten sowie automatisierte Freigabepflichten bei Ladestau.
• Kartenhoheit und Referenzsystem: Vereinbarung einer führenden Master-Umgebungskarte, einheitlicher Nullpunkte und fester Intervalle für die Synchronisation von Streckenänderungen.
• Fehlersemantik und Quittierung: Eindeutige Definition von Fehlerklassen, garantierten Wiederanlaufzeiten nach Not-Halt-Ereignissen und vertraglichen Service-Level-Agreements (SLAs) je Hersteller.
• Verkehrssicherheit nach ISO 3691-4: Abgrenzung der sicherheitstechnischen Verantwortung an Übergabestationen und personellen Schnittstellen im Mischbetrieb.

Asset-Manager und Betriebsverantwortliche müssen diese Parameter vor dem Rollout als harte Vertragsklauseln verankern. Fehlen diese Vereinbarungen, führt jede Betriebsstörung unweigerlich zu ungeklärten Zuständigkeiten zwischen den verschiedenen Herstellern.

Die praktische Umsetzung einer heterogenen Flotte scheitert selten an der reinen Protokollebene, sondern an den organisatorischen und prozessualen Lücken zwischen den Herstellern. Die VDA 5050 beschreibt in der aktuellen Version 3.0.0 einheitliche Datenstrukturen für Auftrags- und Statusmeldungen, ist von VDA und VDMA aber ausdrücklich als unverbindliche Empfehlung angelegt, deren richtige Anwendung im Einzelfall beim Anwender liegt. Den Schritt vom Schnittstellenstandard zum stabilen Hallenbetrieb leistet erst ein herstellerunabhängiger Integrationslayer, der Planung, Beschaffung und Inbetriebnahme über alle beteiligten OEMs hinweg bündelt.

Aufgabenteilung zwischen Integrator und Betreiber

Ein herstellerunabhängiger Systemintegrator übernimmt dabei die technische und vertragliche Harmonisierung zwischen den beteiligten OEMs. werob baut weder eigene Hardware noch hält das Unternehmen die behördlichen Betriebsgenehmigungen für den Betreiber. Stattdessen schließt die Integrationsarbeit die Lücke zwischen den physikalischen Fahrzeugen und den übergeordneten ERP- oder WMS-Systemen, indem Schnittstellendivergenzen vorab gelöst und Sicherheitsbereiche aufeinander abgestimmt werden.

• Strukturierte Abstimmung aller fahrzeugspezifischen Aktionsparameter und Fahrkurszuweisungen vor der Inbetriebnahme
• Definition einheitlicher Eskalations- und Fehlerbehandlungsroutinen über alle beteiligten OEM-Flotten hinweg
• Realisierung des End-to-End-Prozesses von der technischen Spezifikation bis zum operativen Flächenbetrieb innerhalb von acht Wochen

Für Betreiber und Instandhaltungsverantwortliche verlagert dieser Ansatz das Projektrisiko von unklaren Schnittstellengrenzen hin zu definierten Betriebsverträgen. Die Verantwortung für den sicheren und wirtschaftlichen Betrieb verbleibt beim Anlagenbetreiber, während die herstellerübergreifende Koordination der Teilsysteme auf einer belastbaren technischen Basis steht.