Mit einer Robot-Fleet-Management-Software behält ein Team viele Roboter gleichzeitig im Blick und steuert sie: wo jeder Roboter ist, wie viel Akku er noch hat, an welcher Aufgabe er arbeitet und was schiefging, als er stehen blieb. Ein einzelner Roboter bringt seine eigene App mit. Ein Dutzend Roboter von drei Herstellern bringt drei Apps, drei Karten und drei Alarm-Postfächer mit, und meist ist das der Moment, in dem Betreiber nach einer Robot-Fleet-Management-Plattform suchen.

Was Käufern oft erst später auffällt: Roboter sind nicht das Einzige auf dem Gelände, das zählt. Türen, Laderampen, Lecksensoren und Alarmanlagen verfügen über Informationen, die die Roboter nie sehen. Ob die Flotte diese Informationen nutzen kann, entscheidet viel darüber, wie nützlich sie wird.

Kurz erklärt

  • Robot-Fleet-Management-Software erfasst Status, Akkustand, Position, Aufgaben und Störungen vieler Roboter und entscheidet, welcher Roboter welchen Auftrag übernimmt.
  • Die meisten Roboterhersteller liefern Flottensoftware für ihre eigene Marke. Gemischte Flotten brauchen eine Ebene, die über APIs, MQTT oder einen Schnittstellenstandard wie VDA 5050 mit jeder Marke kommuniziert.
  • Der größere Schritt ist, der Flotte denselben Kontext wie dem Gebäude zu geben, damit aus einem Sensorereignis eine Aufgabe für einen Roboter werden kann.
  • Befehle laufen über Hersteller- und Protokollgrenzen hinweg, deshalb wird jedes Szenario mit simulierten Antworten getestet, bevor es auf echten Robotern läuft.

Wie funktioniert Flottenmanagement für mobile Roboter?

Bei mobilen Robotern unterscheidet man grob zwei Arten. Fahrerlose Transportfahrzeuge (AGVs) folgen festen Routen, die durch Leitdrähte, Magnetband oder Markierungen vorgegeben sind. Autonome mobile Roboter (AMRs) erstellen eine Karte und planen ihren Weg um Hindernisse selbst. Beide melden laufend ihren Zustand an einen Flottenserver: Position auf einer Karte, Akkustand, aktuelle Aufgabe, Geschwindigkeit, Fehlercodes und ob sie fahren, laden, im Leerlauf oder blockiert sind. Der Flottenserver macht aus diesem Datenstrom drei Aufgaben: Überblick, Auftragsvergabe sowie Verkehr und Laden.

Überblick heißt: eine Karte mit der Position jedes Roboters, eine Liste, welche Roboter arbeiten, laden oder gestört sind, und ein Verlauf dessen, was jeder Roboter während der Schicht getan hat.

Bei der Auftragsvergabe kommen Aufgaben aus einem Lagerverwaltungssystem, einem Bestellsystem im Krankenhaus, von einem Rufknopf an der Wand oder von einer Person mit Tablet, und die Flottensoftware entscheidet, welcher Roboter welche Aufgabe übernimmt. Einfache Systeme wählen den nächstgelegenen freien Roboter. Leistungsfähigere berücksichtigen Akkustand, Nutzlast und die Länge der Warteschlange am Ziel.

Verkehr und Laden werden zum Thema, sobald sich Roboter Flächen teilen. Zwei Roboter, die denselben schmalen Gang ansteuern, brauchen eine Regel, wer zuerst fährt. Und eine Flotte, deren Akkus alle zur selben Stunde zur Neige gehen, braucht einen Ladeplan, der genug Roboter im Einsatz hält.

Wegplanung und Hindernisvermeidung bleiben auf dem Roboter. Der Flottenserver sagt, wohin und wann; die eigene Software des Roboters findet heraus, wie er dorthin kommt, ohne irgendwo anzustoßen. Diese Aufteilung ist wichtig, wenn Sie Produkte vergleichen, denn „Flottenmanagement“ kann beim einen Anbieter die tiefe Steuerung der eigenen Roboter bedeuten, beim anderen ein leichteres Monitoring über mehrere Marken hinweg.

Beim Laden wird es mit Zahlen am anschaulichsten. Angenommen, ein Lager betreibt 12 AMRs 16 Stunden am Tag, und jeder Roboter braucht für vier Stunden Fahrt etwa eine Stunde an der Ladestation. Das sind 20 % der Zeit jedes Roboters, also laden im Schnitt zu jedem Zeitpunkt etwa 2,4 der 12 Roboter, und rund 9,6 bleiben verfügbar. Braucht die Abendspitze 11 fahrende Roboter, schafft die Flotte das nur, wenn die Software die Akkus in den ruhigen Stunden vor der Spitze nachlädt.

Herstellerübergreifendes Robot Fleet Management

Die meisten Roboterhersteller liefern Flottensoftware mit ihren Robotern aus, und für eine einzelne Marke erfüllt sie ihren Zweck meist gut. Schwierig wird es, wenn ein Standort eine zweite Marke hinzunimmt: einen Schlepper vom einen Unternehmen, einen Patrouillenroboter vom nächsten, ein paar AMRs von einem dritten. Jeder hat sein eigenes Kartenformat, seine eigenen Statuscodes und seine eigene Vorstellung davon, was als Fehler gilt.

Es gibt drei gängige Wege, eine gemischte Flotte zusammenzuführen:

  1. Hersteller-APIs. Die meisten kommerziellen Roboter bieten für Status und Aufgaben eine REST- oder WebSocket-API, einige veröffentlichen auch über MQTT. Eine herstellerübergreifende Ebene ruft jede davon auf und übersetzt die Ergebnisse in ein gemeinsames Modell. Das ist heute der häufigste Weg, und der größte Aufwand steckt in dieser Übersetzung.
  2. Schnittstellenstandards. VDA 5050, veröffentlicht vom Verband der Automobilindustrie (VDA) gemeinsam mit dem Maschinenbauverband VDMA, legt fest, wie eine Leitsteuerung Aufträge an fahrerlose Fahrzeuge sendet und wie die Fahrzeuge ihren Zustand melden, und zwar mit JSON-Nachrichten über einen MQTT-Broker. Fahrzeuge, die den Standard umsetzen, können sich eine Steuerung ohne individuelle Adapter teilen. Der Standard regelt die Nachrichten, nicht aber, wie ein Fahrzeug seinen Weg plant.
  3. Middleware auf dem Roboter. Teams, die eigene Roboter bauen, betreiben darauf oft ROS 2 und leiten die Daten des Roboters über eine Brücke an die Flottenebene weiter.

Alle drei Wege münden in ein gemeinsames Modell: eine einzige Definition für Akkustand, Position, Aufgabenstatus und Störung, auf die jede Marke abgebildet wird. Der Integrationsaufwand für jeden neuen Roboter steckt in dieser Abbildung.

Karten brauchen dieselbe Behandlung. Jede Robotermarke erstellt ihre Karte in ihrem eigenen Koordinatensystem, mit eigenem Ursprung, eigener Ausrichtung und manchmal eigenem Maßstab. Um alle Roboter auf einem Standortplan zu zeigen, müssen die Koordinaten jedes Herstellers in ein gemeinsames System umgerechnet werden, meist über einige Referenzpunkte, die alle Karten gemeinsam haben, etwa eine Türöffnung oder eine Säule. Liegt diese Ausrichtung um einen Meter daneben, scheinen Roboter in der gemeinsamen Ansicht durch Wände zu fahren, obwohl jeder genau dort ist, wo seine eigene Software ihn vermutet.

Wer nach Anbietern von Robot-Fleet-Management-Software sucht, findet zwei Gruppen. Roboterhersteller bündeln einen Flottenmanager mit ihren eigenen Maschinen, was bei einer Flotte aus nur einer Marke oft die günstige Lösung für das Robot Fleet Management ist. Unabhängige Anbieter von Software für das Flottenmanagement mehrerer Roboter verkaufen eine Ebene, die über mehreren Marken liegt. Listen mit Titeln wie „Top 10 Robot Fleet Management Software 2025“ mischen beide Gruppen und nehmen außerdem Flottensoftware für Industrieroboter mit auf, also für fest montierte Arme und Fertigungszellen. Sie löst ein anderes Problem. Wenn Sie die führenden Anbieter von Robot-Fleet-Management-Software vergleichen, fragen Sie jeden, welche Robotermodelle er bereits integriert hat, welche Daten er von jedem abruft und wer die Integration pflegt, wenn sich die Firmware eines Roboters ändert.

Was sollte ein Dashboard für Robot Fleet Management zeigen?

Ein gutes Dashboard für Robot Fleet Management beantwortet die Fragen der Schichtleitung, ohne dass jemand eine zweite App öffnen muss.

Frage Was das Dashboard zeigt Warum es wichtig ist
Wo ist jeder Roboter? Live-Position auf dem Standortplan, Zeitpunkt der letzten Aktualisierung Ein Roboter, dessen letzte Aktualisierung lange zurückliegt, steckt vielleicht fest oder ist offline
Kann er weiterarbeiten? Akkustand, Ladezustand, Zeit bis zur nächsten Ladung Zeigt, ob die Arbeit der nächsten Stunde abgedeckt ist
Was macht er gerade? Aktuelle Aufgabe, Länge der Warteschlange, Dauer der Aufgabe Lange Aufgabenzeiten deuten auf blockierte Wege oder schlechte Zuweisungen hin
Was ist schiefgegangen? Aktive Störungen, Not-Halts, verlorene Lokalisierung, fehlgeschlagenes Andocken Zeigt, wohin jemand gehen und was er beheben muss
Wie steht die Flotte insgesamt da? Aufgaben pro Stunde, Auslastung, Eingriffe pro Schicht Zeigt, ob zusätzliche Roboter oder bessere Prozesse mehr bringen

Beginnen Sie mit den Eingriffen pro Schicht. Ein Eingriff ist jede Situation, in der ein Mensch einspringen muss: einen blockierten Gang räumen, einen Roboter schieben, der seine Position verloren hat, ihn wieder richtig auf die Ladestation setzen. Pro Roboter und Bereich ausgewertet, zeigen die Eingriffe, wo das eigentliche Problem liegt. Passieren die meisten in einem bestimmten Gang, braucht dieser Gang Aufmerksamkeit, und zusätzliche Roboter würden dort nur die Warteschlange verlängern.

Vorfälle mit Robotern konkurrieren außerdem mit allen anderen Alarmen auf dem Gelände. Eine Schichtleitung, die Flottenstörungen in einem Postfach und Gebäudealarme in einem anderen bekommt, übersieht am Ende eines von beiden. Deshalb lohnt es sich, früh zu entscheiden, welche Vorfälle an dieselben Personen gehen wie die Alarme des Gebäudes.

Für genau diese gemeinsame Ansicht entwickeln wir Kilo, ergänzend zum Flottenmanager, den der Roboterhersteller mitliefert. Nimmt ein Roboter Befehle über MQTT an, direkt oder über eine kleine Brücke zu seiner API, können Sie ihn mit den LoRaWAN-, mioty- und MQTT-Sensoren des Gebäudes verbinden und eine Regel schreiben, die aus einem Sensorereignis eine Roboteraufgabe macht. Ein Lecksensor unter einem Regal meldet nachts Wasser, und eine einzige Regel alarmiert die Haustechnik und schickt zugleich einen Roboter mit Kamera in diesen Gang. Bevor die Regel jemals einen echten Roboter bewegt, gehen Sie sie im Debugger von Kilo Schritt für Schritt durch, mit simulierter Antwort des Roboters. Sensoren, Türen, Maschinen und Roboter, die sich auf diese Weise einen Kontext teilen: Das meinen wir mit Physical AI für vernetzte Standorte.

Wie führt man Robot Fleet Management ein?

Reibungslose Einführungen folgen meist ungefähr dieser Reihenfolge, egal welches Werkzeug Sie wählen:

  1. Flotte und Schnittstellen erfassen. Notieren Sie für jedes Robotermodell, was es bereitstellt (REST-API, MQTT, VDA 5050, ROS 2), welche Daten Sie auslesen können (Position, Akkustand, Aufgabe, Störungen) und welche Befehle es annimmt, etwa einen Ort anfahren, andocken oder pausieren.
  2. Ein Datenmodell festlegen. Einigen Sie sich auf Feldnamen, Einheiten und Zustände und bilden Sie dann die Codes jedes Herstellers darauf ab.
  3. Klären, wer Aufgaben vergibt. Oft regelt der Flottenmanager des Herstellers weiterhin den Verkehr innerhalb seiner Marke, und Ihre Ebene übergibt ihm Aufträge und liest die Ergebnisse zurück.
  4. Einen Bereich eine Schicht lang pilotieren. Messen Sie Aufgaben pro Stunde und Eingriffe, bevor Sie skalieren, damit Sie eine Vergleichsbasis haben.
  5. Das Gebäude anbinden. Türen, Rampen, Sensoren und Alarme gehören ins selbe Bild wie die Roboter.
  6. Jedes Szenario abseits des laufenden Betriebs proben. Lassen Sie neue Aufgabenlogik in einem Testbereich oder gegen einen Simulator laufen, bevor sie einen Roboter im Produktivbetrieb erreicht, denn eine Aufgabe über Hersteller- und Protokollgrenzen hinweg durchläuft mehr Systeme als eine innerhalb einer einzigen Marke.

Häufige Fragen zum Robot Fleet Management

Was kostet eine Robot-Fleet-Management-Software?

Die Preismodelle sind unterschiedlich. Roboterhersteller schließen ihre Flottensoftware oft in Kauf oder Leasing der Roboter ein, während unabhängige Plattformen meist ein Abonnement pro Roboter oder pro Standort berechnen. Der Integrationsaufwand für jedes neue Robotermodell wird häufig separat abgerechnet, fragen Sie deshalb neben dem Lizenzpreis auch nach diesen Kosten.

Ist AGV-Flottenmanagement dasselbe wie Flottenmanagement für mobile Roboter?

Beides überschneidet sich, aber der Schwerpunkt ist ein anderer. AGV-Flottensoftware verwaltet feste Streckenabschnitte und sperrt einen Abschnitt, solange ein Fahrzeug ihn belegt. AMR-Flottensoftware steckt mehr Aufwand in Zonen, Auftragsvergabe und Staus, weil jeder Roboter seine Route selbst wählt.

Läuft Robot-Fleet-Management-Software in der Cloud oder vor Ort?

Beides gibt es. Die Verkehrssteuerung für Roboter, die sich Gänge teilen, läuft oft auf einem Server vor Ort, weil sie nicht von einer Internetverbindung abhängen darf, während Berichte und standortübergreifende Ansichten oft in der Cloud laufen. Fällt das Netzwerk aus, führen Roboter ihre aktuelle Bewegung in der Regel zu Ende und warten auf neue Anweisungen, bis es wieder da ist.

Ein Roboter, der seinen Status bereits über MQTT veröffentlicht, genügt, um die gemeinsame Ansicht auszuprobieren. Registrieren Sie seinen Akkustand und seinen Aufgabenstatus als Gerät in Kilo, ergänzen Sie einen Kontakt am Rampentor, an dem er am häufigsten vorbeifährt, und stellen Sie beides in einem Dashboard dar. Schreiben Sie dann eine Regel, die die Schichtleitung alarmiert, wenn der Roboter einen Not-Halt meldet. Zwei Geräte und diese eine Regel laufen im kostenlosen Tarif, und Daten aus einer Woche zeigen, wie oft die Stopps des Roboters mit der Aktivität am Tor zusammenfallen.