Roboterflotten-Interoperabilität: Warum eine gemischte AMR-Flotte VDA5050 und Open-RMF braucht

Eine gemischte AMR-Flotte aus Fahrzeugen mehrerer Hersteller lässt sich zentral betreiben — aber nur, wenn drei Ebenen sauber getrennt bleiben. Die erste ist die Gerätekommunikation zwischen Roboter und Leitsteuerung: Hier setzt VDA5050 an. Die zweite ist die flottenübergreifende Koordination von Verkehr und Aufträgen: Dafür steht Open-RMF. Die dritte ist die Sicherheitszulassung (ISO 3691-4) — sie ist von den ersten beiden unabhängig. Kein einzelner Standard löst die Roboterflotten-Interoperabilität allein. Wer das im Einkauf verwechselt, tauscht nur einen Hersteller-Lock-in gegen den nächsten.

Dieser Field Report ordnet die Bausteine, benennt die realen Grenzen und zeigt, wo die Normen Stand Mitte 2026 an ihre Grenzen stoßen. Eingebettet ist Interoperabilität dabei in die größere RobotOps-Disziplin, die der Grundlagenbeitrag zu RobotOps als DevOps für Roboterflotten beschreibt.

Was bedeutet Roboterflotten-Interoperabilität — und warum reicht ein Standard nicht?

Interoperabilität heißt hier: Fahrzeuge verschiedener Marken teilen sich Fläche, Verkehrswege und einen gemeinsamen Auftragspool, ohne dass pro Marke ein eigenes Leitsystem im Lager steht. Das klingt nach einem Problem — es sind aber drei. Die Marketingsprache wirft sie gern in einen Topf; im Betrieb bleiben sie getrennt:

1. Gerätekommunikation — wie ein Roboter mit einer Leitsteuerung spricht. Standards: VDA5050, der MassRobotics-Standard.
2. Flottenübergreifende Orchestrierung — wie sich mehrere Flotten und Roboter Fläche und Ressourcen teilen. Systeme: Open-RMF, openTCS, kommerzielle RoboOps-Plattformen.
3. Sicherheitszertifizierung — unabhängig von beidem. Normen: ISO 3691-4, ANSI/RIA R15.08.

Diese Dreiteilung ist kein Zitat aus einer Norm, sondern eine Einordnung aus der Betriebspraxis. Sie erklärt aber, warum „VDA5050-fähig“ und „interoperabel“ nicht dasselbe sind: VDA5050 regelt Ebene 1, nicht Ebene 2.

Warum scheitert die Bindung an einen einzigen Hersteller mit wachsender Flotte?

Solange eine Anlage mit zehn baugleichen Fahrzeugen eines Anbieters läuft, genügt der herstellereigene Flottenmanager. Der Bruch kommt beim Wachstum: ein zweiter Robotertyp für Paletten, ein dritter für Kleinladungsträger, dazu ein Alt-System aus einer früheren Ausbaustufe. Ohne gemeinsame Schnittstelle bräuchte jede Marke ihre eigene Leitsteuerung — und keine davon kennt die Fahrwege der anderen. Zwei Flotten, die dieselbe Kreuzung nicht kennen, blockieren sich.

Genau hier setzt die Idee einer herstellerunabhängigen Leitsteuerung an: Eine zentrale Instanz koordiniert alle Fahrzeuge über eine offene Schnittstelle, statt pro Marke einen proprietären Regler zu betreiben. Dass dieser Ansatz aus Deutschland kommt, ist kein Zufall. Nach Analysen von Interact Analysis waren deutsche Automobilhersteller — Audi, VW, BMW — früh die treibende Kraft: Teils finanzierten oder gründeten sie Firmen, die VDA5050-konforme Leitsteuerungen für die eigenen Werke bauten. Dieser Eigenbedarf hat die Verbreitung des Standards mit angeschoben.

Was ist VDA5050 — und was regelt der Standard wirklich?

VDA5050 ist eine offene, herstellerunabhängige Schnittstelle für die Kommunikation zwischen fahrerlosen Transportfahrzeugen (FTF/AMR) und einer zentralen Leitsteuerung. Technisch: JSON-Nachrichten über das MQTT-Protokoll. Herausgegeben wird der Standard gemeinsam vom VDA (Verband der Automobilindustrie) und vom VDMA (Verband Deutscher Maschinen- und Anlagenbau), mit Beiträgen des Instituts für Fördertechnik und Logistiksysteme (IFL) am Karlsruher Institut für Technologie (KIT) und Herstellern mobiler Roboter.

Der Kern in einem Satz: VDA5050 sorgt dafür, dass Fahrzeuge unterschiedlicher Marken von einem gemeinsamen Flottenmanager gesteuert werden können — statt von je einem proprietären Regler pro Marke. Was der Standard nicht leistet: Er ist kein Verkehrsmanagement über mehrere Flotten und keine Sicherheitsfreigabe.

In der Praxis heißt „VDA5050-fähig“ meist: Der Hersteller liefert einen Adapter. Mobile Industrial Robots (MiR) etwa hat einen VDA5050-Adapter veröffentlicht, um die eigenen Fahrzeuge an fremde Flottenmanager anzubinden; OTTO Motors (die AMR-Sparte von Rockwell Automation) publiziert einen VDA5050-Interoperabilitätsleitfaden; auch BlueBotics gilt als VDA5050-konform. Seegrid wurde als Kandidat genannt, der VDA5050-Konformität „bis 2026“ anstrebt — das ist eine Absichtserklärung, kein bestätigter Stand.

Was ändert sich mit VDA5050 3.0? (Stand Mitte 2026)

Version 2.1.0 (veröffentlicht im August 2024) brachte einen Schritt hin zu größeren, heterogenen Flotten. Am 18.–19. März 2026 folgte die Hauptversion 3.0.0, die ausdrücklich nicht abwärtskompatibel ist. Neuerungen:

• Roboter können ihren geplanten bzw. zwischenzeitlichen Fahrweg teilen.
• Neue Zonen (konturbasiert und bezogen auf das kinematische Zentrum), um die Navigation zu beeinflussen.
• Neue Fehlerstufen CRITICAL und URGENT.
• Optionales Feld für den Batteriestrom in den Zustandsmeldungen.
• Zeitstempel-Auflösung von 1/100 s auf 1/1000 s erhöht.
• NURBS-Definition an den Industriestandard angepasst.
• Das Feld batteryState wurde in powerSupply umbenannt.
• startNode/endNode wurden aus der Edge-Struktur entfernt.

Der Bruch der Kompatibilität ist der eigentliche Knackpunkt für den Betrieb: Ein Sprung auf 3.0 ist kein Update, sondern eine Migration — prüfen Sie vor der Umstellung die aktuelle Spezifikation im offiziellen VDA5050-Repository. Wie aus solchen Zustandsmeldungen echte Flottentelemetrie und Observability werden, beschreibt der vertiefende Beitrag zu Flottentelemetrie und Observability.

Was ist Open-RMF — die Verkehrsleitzentrale für gemischte Flotten?

Open-RMF (Open Robotics Middleware Framework) ist ein quelloffenes Framework auf Basis von ROS 2 für genau die Ebene, die VDA5050 offenlässt: die Koordination zwischen heterogenen Flotten. Es übernimmt Verkehrsmanagement (geteilte Flächen, Korridore), die Anbindung der Gebäudeinfrastruktur (Aufzüge, Türen), die Aufgabenverteilung und die Konfliktauflösung zwischen Robotern verschiedener Anbieter.

Technisch baut Open-RMF auf ROS 2 auf (aktuelle Distributionen: Jazzy Jalisco und, seit dem 23. Mai 2025 allgemein verfügbar, Kilted Kaiju) und integriert den Navigations-Stack Nav2, damit gemischte Flotten Karten und Fahrpläne teilen können. Ein oft genanntes Merkmal sind Mutex Groups: virtuelle Sperren für Routen oder Orte, sodass immer nur ein Roboter eine umkämpfte Ressource belegt — im Prinzip eine Flugsicherung für Engstellen. Die exakte Versionsnummer dieses Merkmals ist nicht unabhängig bestätigt; behandeln Sie sie als groben Richtwert.

Zur Einordnung: In der Fachberichterstattung wird Open-RMF als Versuch beschrieben, „das ROS des Flottenmanagements“ zu werden — ein offenes Rückgrat für Interoperabilität und Verkehrssteuerung, klar abgegrenzt vom engeren Gerätekommunikations-Protokoll VDA5050. Zur Governance: Das Projekt entstand bei Open Robotics / OSRF und wird von Intrinsic getragen, einem Alphabet-Unternehmen, das die Open Source Robotics Corporation übernahm; seit 2024 liegt die Projekt-Governance laut Charta bei der Open Source Robotics Alliance (OSRA) — übereinstimmend bestätigt durch Open Robotics, Intrinsic und unabhängige Fachpresse.

VDA5050, Open-RMF und MassRobotics: Wer macht was?

Ebene	Standard / System	Zuständigkeit	Herausgeber	Charakter
Gerätekommunikation	VDA5050	Roboter ↔ eine Leitsteuerung (JSON über MQTT)	VDA + VDMA (mit IFL/KIT)	offen
Gerätekommunikation	MassRobotics AMR Interoperability Standard	Roboter tauschen Status untereinander aus	MassRobotics (US)	offen
Flottenorchestrierung	Open-RMF	Verkehr, Aufzüge/Türen, Aufträge über mehrere Flotten	Open Robotics / OSRA	offen (ROS 2)
Flottenorchestrierung	openTCS	herstellerunabhängige Leitsteuerung	Fraunhofer IML	offen (Java)
Flottenorchestrierung	RoboOps-Plattformen (InOrbit, Formant …)	Vermittler zwischen OEM-Flottenmanagern	diverse Anbieter	proprietär
Sicherheit	ISO 3691-4 / ANSI-RIA R15.08	Sicherheitszulassung FTF/AMR	ISO / A3 (RIA)	Norm

Der MassRobotics AMR Interoperability Standard (US-Non-Profit, v1.0 Mai 2021, v2.0 seit rund 2022 diskutiert) betrifft eine noch engere Ebene als VDA5050: Er lässt AMR, FTF und automatisierte Stapler verschiedener Marken untereinander Standort, Geschwindigkeit, Richtung, Zustand und Aufgaben- bzw. Verfügbarkeitsstatus austauschen — für die schlichte Koexistenz. MassRobotics stellt selbst klar, was der Standard nicht ist: kein Navigations-, kein Flottenmanagement- und kein Sicherheitssystem. Proprietäre Karten müssen Hersteller nicht offenlegen.

Dass die Idee der herstellerunabhängigen Leitsteuerung älter ist als VDA5050, zeigt openTCS — ein freies, quelloffenes „open Transportation Control System“ in Java, gepflegt vom Fraunhofer-Institut für Materialfluss und Logistik (IML). Es verteilt Routen und Aufträge und koordiniert eine Flotte verschiedener Hersteller über austauschbare Fahrzeugtreiber-Module — konzeptionell ein Vorläufer der VDA5050-basierten Leitsteuerung.

Wie orchestriert man in der Praxis Roboter verschiedener Hersteller?

Neben den offenen Standards existiert ein kommerzieller Markt für Vermittler — in der Fachpresse „Cloud Robotics“ oder „RoboOps“ (Begriff von InOrbit geprägt). Plattformen wie InOrbit, Formant, Cogniteam und Brain Corp binden Roboter vieler Hersteller an und nutzen VDA5050, den MassRobotics-Standard und/oder Open-RMF als Brücken.

Entscheidend für den Betrieb ist die Kontrolltiefe. Interact Analysis unterscheidet zwei Ansätze:

• Regelung auf niedriger Ebene (Low-Level): Das Drittsystem spricht direkt mit den einzelnen Robotern und übernimmt faktisch deren Regelschleife.
• Regelung auf hoher Ebene (High-Level): Das Drittsystem übergibt nur übergeordnete Aufträge an den herstellereigenen Flottenmanager, der die Low-Level-Kontrolle behält.

Diese Wahl ist folgenreich: High-Level belässt Sicherheits- und Fahrlogik beim OEM und hält damit dessen Zulassung intakt; Low-Level gibt mehr Kontrolle, verlagert aber Verantwortung und Haftung.

Eine eigene, proprietäre Schicht darüber legt NVIDIA mit „Mega“ an — einem Omniverse-„Blueprint“ für digitale Zwillinge, um Roboterflotten vor dem realen Einsatz zu entwickeln, zu testen und zu optimieren (vorgestellt auf der CES, Januar 2025; erster genannter Anwender: die KION Group mit Accenture und NVIDIA). Mega ist ROS-nativ und nutzt USD (Universal Scene Description). Wichtig für die nüchterne Einordnung: Das ist eine kommerzielle Simulations- und Orchestrierungsschicht, keine offene Norm — und die Interoperabilitäts-Aussagen sind NVIDIAs eigene Darstellung, nicht unabhängig als „Standard“ bestätigt.

Wo die Standards noch versagen

Der ehrliche Teil des Briefings: Auch mit VDA5050 und Open-RMF bleibt die Roboterflotten-Interoperabilität unvollständig. Drei Lücken sind im Betrieb spürbar:

1. Kartenmaterial. Kein Standard zwingt Hersteller, ihre proprietären Karten offenzulegen — MassRobotics sagt das selbst. Ohne geteilte Karten bleibt gemeinsame Wegplanung Stückwerk.
2. Lokalisierung und Koordinatensysteme. Der präzise Abgleich der Koordinatensysteme zwischen Fahrzeugen verschiedener Anbieter ist nicht durchgängig gelöst; jede Marke lokalisiert nach eigener Logik.
3. Flottenweite Sicherheitszulassung. Es gibt keine Zertifizierung, die eine gemischte Flotte als Ganzes freigibt.

Hier lohnt sich die Abgrenzung zu den Sicherheitsnormen, die oft mit Kommunikationsstandards verwechselt werden. ISO 3691-4 ist die internationale Sicherheitsnorm für fahrerlose Flurförderzeuge (AGV/AMR); ANSI/RIA R15.08 ist das US-Pendant, komplementär dazu — Teil 2 (R15.08-2-2023) spiegelt den Trend zu größeren, integrierten Multi-Roboter-Anlagen wider. Beides sind Sicherheitsnormen, keine Interoperabilitätsnormen: Sie lösen die Multi-Vendor-Orchestrierung nicht. Normungsgremien diskutieren Berichten zufolge neue Normungsvorhaben für bislang nicht abgedeckte Aspekte automatisierter mobiler Maschinen — der genaue Stand ist aber nicht sauber durch zwei unabhängige Quellen belegt und daher als offen zu behandeln.

Dass diese Einordnung als „noch nicht gelöst“ trägt, stützt sich qualitativ auf zwei Punkte: den ausdrücklichen Hinweis von MassRobotics zum Geltungsbereich und die Low-/High-Level-Unterscheidung von Interact Analysis. Eine Norm, die diese Lücke formal benennt, gibt es (noch) nicht — die Einordnung ist eine Betriebs-Einschätzung, kein Zitat.

Was sagen die Marktzahlen — und was nicht?

Vorsicht bei Marktzahlen: Die Schätzungen für den AMR-Markt gehen je nach Marktforschungsinstitut und Marktdefinition weit auseinander, grob 3–5 Mrd. USD für 2025/2026. Grand View Research nennt etwa 4,74 Mrd. USD (2025) bzw. 5,49 Mrd. (2026) und rund 14,04 Mrd. bis 2033 (~14,4 % CAGR); Mordor Intelligence rund 4,49 bzw. 5,18 Mrd.; Global Market Insights rund 3,1 bzw. 3,4 Mrd.; MarketsandMarkets rund 7,07 Mrd. bis 2032. Diese Zahlen sind nicht miteinander abgeglichen — behandeln Sie sie als Größenordnungen, nicht als Fakten.

Interessanter für die Interoperabilität ist ein schmales Teilsegment: Die Software für Multi-Flotten- bzw. Drittanbieter-Orchestrierung soll laut Interact Analysis zwischen 2021 und 2027 um rund 138 % pro Jahr wachsen. Das ist eine einzelne Primärquelle, mehrfach von der Fachpresse aufgegriffen — nicht vier unabhängige Bestätigungen. Die Richtung ist plausibel, die exakte Zahl mit Vorsicht zu genießen. Ob sich eine solche Multi-Vendor-Orchestrierung für den einzelnen Lagerbetreiber überhaupt rechnet, beantwortet die Kalkulation zur Kapitalrendite von Lagerrobotik.

Field Report: Was das für den Flottenbetrieb bedeutet

Für die Praxis lässt sich das Briefing auf wenige Punkte eindampfen:

• Trennen Sie die drei Ebenen im Lastenheft. „VDA5050-fähig“ beantwortet nur die Kommunikationsfrage, nicht das Verkehrsmanagement und nicht die Sicherheit.
• Klären Sie die Kontrolltiefe. High-Level-Steuerung erhält die OEM-Zulassung; Low-Level verlagert Verantwortung auf Sie.
• Behandeln Sie den Versionssprung als Migration. VDA5050 3.0 ist als nicht abwärtskompatibel gemeldet — die Versionsstände aller Fahrzeuge und der Leitsteuerung gehören ins Pflichtenheft, mit Blick auf die tagesaktuelle Spezifikation.
• Erwarten Sie keine geteilten Karten. Solange proprietäres Kartenmaterial nicht offengelegt wird, bleibt gemeinsame Wegplanung begrenzt.

Interoperabilität für die gemischte AMR-Flotte ist 2026 real, aber unfertig: VDA5050 und Open-RMF lösen zwei verschiedene Probleme, kein einzelnes Produkt löst beide, und die Sicherheit läuft auf einer dritten Spur. Wer diese Landkarte kennt, kauft nüchterner ein. Mehr zum Thema im Hub RobotOps: Flottenbetrieb; Begriffe wie Leitsteuerung und FTF erklärt das Glossar.