Braucht ein Roboter bei VDA 5050 noch eine eigene Karte?

In der Praxis fast immer, ja. Die frühen Versionen legten nahe, dass die Leitsteuerung alle Informationen hält und der Roboter ohne eigene Karte auskommt. Geblieben ist sie trotzdem, weil der Roboter Dinge braucht, die das Protokoll lange nicht übertragen hat: die Umschaltung von Sicherheitsfeldern, die Referenz zwischen Knoten und physischen Markern am Boden, flächige Geschwindigkeitszonen. Seit Version 2.1 regelt der Standard Karten auf dem Roboter ausdrücklich mit.

Teilen sich mehrere mobile Roboter dieselbe Karte?

In der Regel ja, aber nur innerhalb eines Robotertyps. Roboter desselben Typs vom selben Hersteller arbeiten meist auf derselben Karte, ein Stapler daneben bringt seine eigene mit. Eine gemischte Flotte führt deshalb nicht eine Karte, sondern mehrere Kartenwelten nebeneinander, jede mit eigenem Format und eigenem Updateweg. Gepflegt wird pro Kartenwelt, verteilt trotzdem auf jeden Roboter einzeln. Wer einen zweiten Hersteller dazuholt, sollte diese zweite Welt vor der Vergabe einplanen.

Was ist der Unterschied zwischen der Roboterkarte und LIF?

Beide stammen meist aus derselben Quelle beim Roboterhersteller, gehen aber an verschiedene Empfänger. Das Layout Interchange Format (LIF) ist das, was die Leitsteuerung braucht, um einen Roboter von A nach B zu schicken: Knoten, Kanten, Stationen, zulässige Geschwindigkeiten, Orientierungen. Version 3.0 nennt es selbst als Importweg für Fahrkurse. Die Karte dagegen beschreibt das Weltmodell des Roboters selbst und wird über mapId und mapVersion verteilt. Ein Dateiformat für sie legt der Standard nicht fest, es bleibt herstellerspezifisch. Kurz: Das LIF wandert nach oben, die Karte bleibt unten.

Seit welcher Version regelt VDA 5050 Karten auf dem Roboter?

Seit Version 2.1.0 vom 19. August 2024. Sie hat die Karte zu einem eigenen Objekt im Protokoll gemacht: Der Roboter meldet seine Karten im state mit mapId, mapVersion und mapStatus, die Leitsteuerung verwaltet sie über die Aktionen downloadMap, enableMap und deleteMap. downloadMap trägt dabei einen mapDownloadLink, die Karte liegt also auf einem Kartenserver und läuft nicht durch MQTT. Standardisiert wird der Lebenszyklus einer Karte, nicht ihr Inhalt. Version 3.0.0 vom 18. März 2026 baut darauf auf, ergänzt aber vor allem Zonen und Path-Sharing.

Was passiert, wenn ein mobiler Roboter im Fehlerfall stehenbleibt?

Der Standard regelt die eine Hälfte: Verlässt ein Roboter den erlaubten Navigationsraum, muss er anhalten und einen Fehler vom Typ OUTSIDE_OF_CORRIDOR mit dem Level CRITICAL melden. Wie er zurück in den Auftrag findet, bleibt offen. In der Praxis wird der Fehler meist auf Roboterebene behoben, weil der Roboter nah genug an einem Knoten stehen muss, um einen Auftrag wieder annehmen zu können. Im Modus MANUAL fährt er dabei unter direkter menschlicher Kontrolle, gesteuert über einen Controller.

Wer sollte die Karte pflegen, Roboterhersteller oder Betreiber?

Wichtiger als die Antwort ist, dass die Frage vor der Vergabe gestellt wird. Heute kommt die Karte meist vom Roboterhersteller, weil sie sich so beim Feintuning direkt vor Ort tauschen lässt. Für den Betreiber zählt vor allem der Updateweg: Wer eine Karte auf jedem Roboter einzeln überspielen muss, zahlt jede Layoutänderung in Stunden. Ein automatisierter Verteilweg ist deshalb ein eigenes Abnahmekriterium.

VDA 5050: Braucht der Roboter noch eine eigene Karte?

„Wo lebt eigentlich die Karte?” ist die Frage, die in Ausschreibungen fast nie auftaucht und in der Inbetriebnahme fast immer. Dabei war eine der elegantesten Ideen hinter VDA 5050 genau diese: die Karte auf dem Roboter überflüssig zu machen. Die Leitsteuerung hält alle Informationen, der Roboter bekommt seinen Weg im Auftrag mitgeschickt. In der Praxis haben wir kaum gesehen, dass jemand es so umsetzt. Dieser Beitrag zeigt, warum die Karte geblieben ist, wie viele Karten eine gemischte Flotte mitführt, seit wann der Standard sie regelt, und was passiert, wenn ein Roboter stehenbleibt. Die Grundlagen stehen in unserem Leitfaden zu VDA 5050.

Die Ursprungsidee: Trajektorie statt Karte

VDA 5050 überträgt einen Auftrag als Folge von Knoten und Kanten, und die Kante kann eine Trajektorie tragen. Ein Roboter kann so abarbeiten, wohin er soll, ohne das Gesamtlayout selbst zu kennen. Damit wandert die Logik von unten nach oben: Die Leitsteuerung weiß, wie die Halle aussieht, der Roboter weiß, was als Nächstes zu tun ist.

Wer eine Flotte von 50 mobilen Robotern in Betrieb genommen hat, weiß, warum das reizvoll ist. Ohne automatisierten Verteilweg ist eine gepflegte Karte pro Roboter kein Detail, sondern ein Inbetriebnahme-Problem.

So ausformuliert steht das nirgends im Standard, der nur Zuständigkeiten verteilt. Es ist unsere Lesart der frühen Versionen, gestützt darauf, dass wir sie bei einzelnen Herstellern genau so umgesetzt gesehen haben.

Warum die Karte trotzdem geblieben ist

Bei den meisten Projekten, die wir kennen, liegt beides vor: eine Karte auf dem Roboter und eine Pfadvorgabe von oben. Dafür gibt es vier nachvollziehbare Gründe.

Der Roboter braucht mehr, als die Schnittstelle überträgt. Die Umschaltung der Sicherheitsfelder, die Referenz zwischen einem Knoten und physischen Markern am Boden wie QR- oder Grid-Codes, Geschwindigkeitszonen für ganze Bereiche statt Kante für Kante. Dafür gab es im Protokoll lange keinen Platz.
Ein Kartenupdate ist Handarbeit. Verbinden, Verzeichnis suchen, Karte überspielen, Software neu starten: ein bis zwei Minuten pro Roboter, und das bei jedem Knoten, der verschoben wird. Bei größeren Flotten summiert sich das auf Stunden pro Layoutänderung.
Deshalb kommt die Karte meist vom Roboterhersteller. Dann lässt sie sich beim Feintuning direkt vor Ort bearbeiten und tauschen, statt über die Leitsteuerung zu laufen.
Eine Karte gehört selten zu genau einem Roboter. Roboter desselben Typs vom selben Hersteller arbeiten meist auf derselben Karte, ein Stapler daneben bringt seine eigene mit.

Eine gemischte Flotte führt mehrere Kartenwelten nebeneinander, jede mit eigenem Format und eigenem Updateweg. Gepflegt wird pro Kartenwelt, verteilt trotzdem auf jeden Roboter einzeln.

Das ist ausdrücklich kein Versäumnis der Hersteller. Die Karte ist kein Altlast-Artefakt, sondern eine funktionale Notwendigkeit: Sie trägt, was die Schnittstelle nicht übertrug. Und genau dieses Praxiswissen ist über die Arbeitskreise in den Standard zurückgeflossen.

Kurz gesagt: Die eigentliche Frage ist nicht, ob der Roboter eine Karte hat, sondern wer sie pflegt und auf welchem Weg sie aktuell bleibt.

Seit Version 2.1 ist die Karte offiziell

Der Standard hat nachgezogen, und zwar früher, als die meisten annehmen. Mit Version 2.1.0 vom 19. August 2024 ist die Karte ein eigenes Objekt im Protokoll geworden: Der Roboter meldet seine Karten im state mit mapId, mapVersion und mapStatus, die Leitsteuerung verwaltet sie über die Aktionen downloadMap, enableMap und deleteMap (Spezifikation 2.1.0). Dieselbe Version brachte die Korridore, innerhalb derer ein Roboter kontrolliert vom Pfad abweichen darf.

Zwei Details zählen in der Praxis. downloadMap trägt neben der mapId einen mapDownloadLink: Die Karte liegt auf einem Kartenserver und wird von dort geholt, sie läuft nicht durch MQTT. Genau das ist der automatisierte Verteilweg, der in der Handarbeit oben fehlt. Und löschen darf ausschließlich die Leitsteuerung. Der Roboter meldet, wenn sein Speicher voll ist, entfernen darf er eine Karte laut Spezifikation nicht selbst.

Standardisiert wird damit der Lebenszyklus, also Übertragung, Aktivierung und Löschung. Der Inhalt bleibt außen vor, ein Dateiformat legt der Standard nicht fest. Zu unterscheiden ist das vom Layout Interchange Format (LIF), das der Standard selbst als Importweg für Fahrkurse benennt. Beide stammen meist aus derselben Quelle beim Roboterhersteller, gehen aber an verschiedene Empfänger. Das LIF ist das, was die Leitsteuerung braucht, um einen Roboter von A nach B zu schicken: Knoten, Kanten, Stationen, zulässige Geschwindigkeiten, Orientierungen. Die Karte ist das Weltmodell des Roboters selbst. Das LIF wandert nach oben, die Karte bleibt unten.

Version 3.0.0 vom 18. März 2026 geht dann in eine andere Richtung: Zonen für frei navigierende Roboter und Path-Sharing, bei dem der Roboter selbst plant und den geplanten Pfad nach oben teilt (Release 3.0.0). Das kehrt die Ursprungsidee um. Für uns ist das kein Rückschritt, sondern eine Architekturfrage: Wer beide Seiten automatisiert synchron hält, bekommt beide Vorteile. Robustheit, wenn der Flottenmanager offline ist, und trotzdem die Änderung, die von oben für 30 Roboter auf einmal gilt.

Der Ernstfall: wenn ein Roboter stehenbleibt

Verlässt ein Roboter den erlaubten Navigationsraum, verlangt der Standard, dass er anhält und einen Fehler vom Typ OUTSIDE_OF_CORRIDOR mit dem Level CRITICAL meldet. Wie er zurück in den Auftrag findet, regelt er nicht.

Genau da klafft die Lücke zur Erwartung: Der Standard unterstellt, die Leitsteuerung könne einen Weg zurückrechnen. In der Praxis muss der Roboter nah genug an einem Knoten stehen, um einen Auftrag überhaupt wieder annehmen zu können. Also wird er dorthin geschoben oder gefahren. Im Modus MANUAL fährt er unter direkter menschlicher Kontrolle, gesteuert über einen Controller.

Nur liegt dieser Controller praktisch immer beim Roboterhersteller. Die Logik ist also eben doch nicht vollständig nach oben gewandert: Die Rückfallebene ist unten geblieben. Wir haben dafür in einem Projekt einen handelsüblichen Gamecontroller benutzt, und ehrlich dazu gehört, dass die Lösung nicht sicher war. Bei Verbindungsverlust sendete er weiter, ein automatischer Stopp musste nachgerüstet werden.

Was das für die Planung heißt

Aus alldem folgen drei Fragen, die in kaum einer Ausschreibung stehen: Wo lebt die Karte, und wer pflegt sie? Wie kommt eine Layoutänderung auf 30 Roboter, ohne dass jemand 30-mal an ein Gerät muss? Und bei mehreren Herstellern: Wie viele Kartenwelten entstehen, und wer hält sie auseinander? Alles drei ist vor der Vergabe zu klären und lässt sich als Abnahmekriterium formulieren.

Die teurere Frage bleibt davon unberührt: Trägt dieses Layout diese Flotte unter Spitzenlast? Das beantwortet Simulation, bevor ein Roboter bestellt ist. Unsere ist graphbasiert: Knoten, Kanten, Korridore und Zonen, wie LIF und VDA 5050 sie beschreiben, nicht die roboterinterne Pfadplanung. Für strukturierte Intralogistik ist das die passende Modelltiefe. Die Disposition im Betrieb bleibt Aufgabe des Flottenmanagements. Wir ergänzen es, wir ersetzen es nicht.

Fazit: Die Karte ist eine Architekturentscheidung

Die Ursprungsidee ist stark, umgesetzt haben wir sie kaum gesehen. Die Karte trägt Sicherheitsfelder, Marker-Referenzen und Zonen, die das Protokoll lange nicht übertrug.
Eine gemischte Flotte hat nicht eine Karte, sondern mehrere Kartenwelten nebeneinander. Der zweite Hersteller bringt seine eigene mit.
Version 2.1 hat das anerkannt und regelt seit August 2024 den Lebenszyklus der Karte, nicht ihren Inhalt. Verteilt wird sie über einen Kartenserver, gelöscht ausschließlich von der Leitsteuerung.
Path-Sharing in Version 3.0 kehrt die Ursprungsidee um. Wer beide Seiten synchron hält, gewinnt Robustheit und Änderungsgeschwindigkeit.
Die Rückfallebene im Störfall liegt praktisch immer am Roboter. Wer sie nicht einplant, plant den teuersten Tag des Projekts nicht ein.

Sie planen eine Flotte mobiler Roboter oder erweitern eine bestehende um einen zweiten Hersteller? In einem kostenlosen Erstgespräch klären wir, welche dieser Fragen für Ihr Layout offen sind. Sprechen Sie uns an.

Über den Autor

Tim Nowak

Tim Nowak ist Mitgründer und Geschäftsführer der ScaliRo GmbH. Er begleitet Betreiber, Hersteller und Integratoren bei der herstellerunabhängigen Planung und Simulation mobiler Roboterflotten.

Wie dieser Beitrag entstanden ist