RobotOps: DevOps-Disziplin für den Roboterflottenbetrieb

RobotOps ist die Anwendung der DevOps-Disziplin auf den Roboterflottenbetrieb: erprobte Praktiken aus der Softwareauslieferung – CI/CD, Infrastructure-as-Code, Beobachtbarkeit, GitOps, geregelte Vorfallreaktion – übertragen auf Entwicklung, Bereitstellung, Überwachung und Wartung vieler physischer Roboter im Dauerbetrieb. Die These dahinter ist einfach und zugleich unbequem: Einen einzelnen Roboter zu bauen ist ein Engineering-Problem. Fünfzig, fünfhundert oder – wie bei den größten Betreibern – eine Million Roboter verlässlich laufen zu lassen ist ein Betriebsproblem. Und Betrieb hat eigene Werkzeuge, eigene Kennzahlen und eine eigene Fehlerkultur.

Dieser Text ist ein operatives Briefing, kein Werbeprospekt. Es geht nicht darum, dass „Roboter uns ersetzen“, sondern darum, warum eine Flotte im Feld anders funktioniert als ein Prototyp im Labor – und welche Werkzeuge, Normen und Kennzahlen den Unterschied zwischen einer beeindruckenden Demo und einem Betrieb ausmachen, der drei Schichten am Stück durchhält. Der Begriff selbst ist jung: „RobotOps“ wird Mitte 2026 von Robotik-Beratungen, Fachblogs und einzelnen Anbietern verwendet, ist aber nicht standardisiert; keine Normungsstelle verwaltet oder definiert ihn formal. Die zugrunde liegenden Praktiken sind hingegen alles andere als neu – sie stammen aus rund fünfzehn Jahren DevOps und Site-Reliability-Engineering.

Dieser Beitrag ist der Ausgangspunkt des Themenclusters Roboterflottenbetrieb. Zentrale Begriffe sind im Glossar erklärt.

Was ist RobotOps – und was ist es ausdrücklich nicht?

RobotOps – im Kern DevOps für Roboter – verlagert den Schwerpunkt vom Bauen zum Betreiben. Die Grundidee: Ein Roboter ist kein fertiges Produkt, das man ausliefert und vergisst, sondern ein System, das man wie einen Dienst betreibt. Software wird kontinuierlich integriert und ausgeliefert, Konfiguration wird als Code versioniert, der Zustand jeder Einheit wird durchgängig gemessen, und Störungen werden nach festen Verfahren bearbeitet statt improvisiert. Was in der Cloud der Server ist, ist in der Robotik der Roboter im Regalgang – nur dass dieser Server Räder hat, sich bewegt, Batterien altern lässt und mit Menschen im selben Raum arbeitet.

RobotOps ist ausdrücklich kein Ersatz für Robotik-Forschung und ‑Entwicklung. Es beantwortet nicht die Frage, wie ein Greifarm eine unbekannte Kiste fasst, sondern die Frage, wie fünfhundert Greifarme das an sieben Tagen die Woche tun, wie man ein fehlerhaftes Wahrnehmungsmodell zurückrollt, ohne die Schicht zu stoppen, und wie man merkt, dass Roboter Nummer 214 seit drei Tagen langsam schlechter wird. RobotOps ist auch kein Produkt, das man kauft, sondern eine Disziplin – eine Kombination aus Werkzeugen, Kennzahlen und Verfahren. Wer den Begriff als Verkaufsargument liest, hat ihn falsch verstanden.

Warum ist der Betrieb einer Flotte eine eigene Disziplin, getrennt vom Bau eines Roboters?

Weil sich die schwierigen Probleme verschieben, sobald die Stückzahl steigt. Beim Bau eines einzelnen Roboters lautet die Leitfrage: Funktioniert es überhaupt? Im Flottenbetrieb lautet sie: Funktioniert es immer, überall und gleichzeitig – und was passiert, wenn nicht? Das ist kein größeres, sondern ein anderes Problem. Ein Prototyp darf im Labor scheitern; eine Flotte, die den Wareneingang bedient, darf es nicht. Der Unterschied zwischen „läuft im Labor“ und „läuft im Betrieb“ ist genau der Raum, den RobotOps ausfüllt.

Die Größenordnung, um die es geht, ist real. Amazon meldete für seine Roboterflotte über 750.000 Einheiten (Stand Juni 2025) und den millionsten ausgelieferten Roboter Anfang Juli 2025, verteilt auf über 300 Logistikstandorte – darunter Proteus-AMR, Sparrow-Kommissionierarme, das Sequoia-Bestandssystem und aus Kiva abgeleitete Fahreinheiten. Zur Koordination dieser Bewegungen führte das Unternehmen „DeepFleet“ ein, ein KI-Foundation-Model für den Robotik-Verkehr, das die Wegeffizienz nach eigener Angabe um rund 10 % verbessert. Diese Zahlen stammen vom Unternehmen selbst und wurden nicht unabhängig geprüft – aber sie zeigen die Art von Problemen, für die Flottenmanagement in der Robotik überhaupt existiert: Verkehrssteuerung, Deadlock-Vermeidung und Auslastung über Zehntausende Einheiten hinweg.

Ein einzelner Roboter kennt keine Schwarmphänomene. Eine Flotte schon. Sobald sich viele autonome Einheiten dieselben Flächen, Aufzüge, Ladepunkte und Türen teilen, entstehen Staus, Verklemmungen und Prioritätskonflikte, die keine Einzelmaschine je erlebt. Der Bau löst diese Probleme nicht – er verursacht sie. Deshalb ist Flottenkoordination eine eigene Software-Ebene mit eigenen Fehlermodi: zwei Roboter, die sich gegenseitig den Weg blockieren, sind kein Sensorfehler, sondern ein Systemfehler.

Hinzu kommt die Heterogenität. Kaum eine reale Flotte besteht aus identischer Hardware desselben Herstellers. Es gibt alte und neue Baureihen, unterschiedliche Firmware-Stände, verschiedene Anbieter. Wer den Betrieb ernst nimmt, muss diese Vielfalt orchestrieren, statt sie wegzuwünschen – und genau dafür sind herstellerübergreifende Standards entstanden, auf die dieser Text weiter unten eingeht. Der Bau eines Roboters ist ein geschlossenes Problem. Der Betrieb einer Flotte ist ein offenes.

Warum ist eine polierte Demo noch kein Feldbetrieb?

Weil eine Demo zeigt, dass etwas funktionieren kann, und der Betrieb beweisen muss, dass es verlässlich funktioniert. Dazwischen liegt der berüchtigte lange Fehlerschwanz (Long Tail): die seltenen, unübersichtlichen Fälle, die im Video herausgeschnitten werden. Eine Demo läuft unter kontrollierten Bedingungen, mit vorbereiteter Umgebung, aufgeladenen Batterien und einem Ingenieur mit der Hand am Not-Aus. Der Feldbetrieb läuft bei schlechtem Licht, mit verschmutzten Sensoren, halbleeren Akkus, unerwarteten Hindernissen und ohne, dass jemand danebensteht. Die erste Situation ist eine Inszenierung. Die zweite ist Statistik.

Besonders deutlich wird das bei den aktuellen Physical-AI-Modellen. Vision-Language-Action-Modelle (VLA) übersetzen Kamerabild und Sprachbefehl direkt in Roboteraktionen und liefern beeindruckende Demonstrationen. Nvidia stellte im März 2025 mit Isaac GR00T N1 nach eigener Darstellung das „erste offene, vollständig anpassbare Foundation Model für generalisierte humanoide Roboter“ vor – ein VLA-Modell mit zweiteiliger Architektur (Wahrnehmungsmodul plus Diffusions-Transformer für Aktionen), trainiert auf realen Robotertrajektorien, menschlichen Videos und synthetischen Daten, Berichten zufolge demonstriert auf den Humanoiden Fourier GR-1 und 1X, was in dieser Recherche nicht unabhängig verifiziert werden konnte. Die inkrementelle Nachfolgeversion N1.5 erreichte laut Nvidia 38,3 % Erfolgsrate gegenüber 13,1 % bei N1 auf einem zwölf Aufgaben umfassenden Benchmark (DreamGen); seit April 2026 ist zudem N1.7 im Early Access verfügbar, mit einem neuen Cosmos-Reason2-2B/Qwen3-VL-Backbone, vortrainiert auf rund 20.854 Stunden egozentrischem Video. Diese Zahlen sind Herstellerangaben und wurden nicht unabhängig repliziert.

Genau hier setzt der Betriebsblick an: Ein Benchmark ist kein SLA. Eine berichtete Erfolgsrate von 38,3 % ist ein respektables Forschungsergebnis – und zugleich meilenweit von einer Verfügbarkeit entfernt, mit der man einen Schichtbetrieb planen könnte. Ähnliches gilt für Google DeepMinds RT-2 (Juli 2023), das Roboteraktionen als Text-Token behandelt, und für das offene Modell OpenVLA (7 Milliarden Parameter, Fachartikel Juni 2024), das SigLIP- und DINOv2-Bildencoder mit einem Llama-2-Backbone kombiniert, auf rund 970.000 Roboterdemonstrationen aus dem Open-X-Embodiment-Datensatz trainiert wurde und laut eigener Veröffentlichung das deutlich größere, geschlossene RT-2-X (55 Milliarden Parameter) über 29 Aufgaben hinweg um 16,5 Prozentpunkte absolut schlägt – bei einem Siebtel der Parameter. Auch das ist eine vom Anbieter selbst berichtete Kennzahl ohne unabhängige Replikation.

Die eigentliche Kluft heißt sim-to-real: Was in der Simulation und im Benchmark überzeugt, überträgt sich nicht eins zu eins auf die physische Welt mit ihrer Reibung, ihrem Sensorrauschen und ihren Ausnahmen. RobotOps akzeptiert diese Kluft als Ausgangspunkt, statt sie zu leugnen. Die operative Konsequenz ist nüchtern: Ein Modell, das in der Demo glänzt, wird im Betrieb kontinuierlich gemessen, schrittweise ausgerollt und lässt sich jederzeit zurücknehmen. Vertrauen entsteht nicht aus dem Video, sondern aus der Telemetrie.

Wie sieht die operative Schleife eines Roboters aus?

Jeder autonome Roboter durchläuft ununterbrochen dieselbe Schleife: Wahrnehmen, Planen, Handeln, Überwachen, Eskalieren. Die ersten drei Schritte sind die klassische Sense-Plan-Act-Schleife der Robotik. Die letzten beiden sind das, was RobotOps hinzufügt – und was den Unterschied zwischen einem Roboter und einem betreibbaren Roboter ausmacht. Ohne Überwachung weiß niemand, dass etwas schiefläuft; ohne Eskalation blockiert ein einzelner festgefahrener Roboter im schlimmsten Fall den gesamten Betrieb.

Entscheidend ist, dass jede Phase eigene Signale erzeugt und eigene Fehlermodi kennt. Wer diese Schleife als Betriebsmodell versteht, weiß, welche Telemetrie er sammeln muss und wo eine Störung wahrscheinlich entsteht. Die folgende Tabelle ordnet die fünf Phasen den typischen Ops-Signalen und Ausfallmodi zu.

Phase	Was passiert	Typisches Ops-Signal	Typischer Ausfallmodus
Wahrnehmen (Perceive)	Sensorfusion aus Kamera, Lidar, Tiefensensoren	Bildrate, Sensorlatenz, Ausfallzähler	Sensor blind oder verschmutzt, Kalibrierung driftet
Planen (Plan)	Pfad- und Aufgabenplanung, Verkehrsauflösung	Planungszeit, Umplanungsrate	Deadlock, Stau, endlose Umplanung
Handeln (Act)	Ansteuerung von Antrieb und Aktuatorik	Motorstrom, Positionsfehler, Geschwindigkeit	Verklemmung, Schlupf, Beinahe-Kollision
Überwachen (Monitor)	Selbst- und Flottenüberwachung	Heartbeat, Zustandswert (Health-Score)	stille Degradation ohne Alarm
Eskalieren (Escalate)	Übergabe an Mensch oder Leitstand	Interventionsrate, MTTR	keine Eskalation → Roboter blockiert Betrieb

Die Eskalationsphase verdient besondere Aufmerksamkeit, weil sie dem Anti-Hype-Kern von RobotOps entspricht: Der Mensch bleibt in der Schleife. Ein reifer Flottenbetrieb misst nicht, ob Roboter jemals eingreifen müssen, sondern wie oft und wie teuer – die Interventionsrate ist eine der ehrlichsten Kennzahlen der ganzen Disziplin. Ein Roboter, der nie eskaliert, ist verdächtig, kein Fortschritt; meist bedeutet es, dass er stattdessen still stehen bleibt und wartet.

Was ist Flottentelemetrie – und welche Signale zählen wirklich?

Flottentelemetrie ist die kontinuierliche, strukturierte Erfassung des Zustands jeder Einheit und der Flotte als Ganzes. Sie ist das Fundament, auf dem alles andere in RobotOps steht: Ohne belastbare Telemetrie sind Verfügbarkeitsziele Ratespiele, vorausschauende Wartung unmöglich und Vorfallreaktion blind. Die Faustregel aus dem Site-Reliability-Engineering gilt unverändert: Man kann nur betreiben, was man messen kann.

Nützlich ist die Unterscheidung zwischen zwei Ebenen. Auf der Einheiten-Ebene (auf dem Roboter selbst, am Edge) zählen Batteriezustand und Ladezyklen, Motorströme und Temperaturen, Sensorlatenz und Bildraten, Positionsfehler, Rechen- und Speicherauslastung sowie die Firmware- und Modellversion. Auf der Flotten-Ebene zählen aggregierte Kennzahlen: Verfügbarkeit je Baureihe, Auftragsdurchsatz, Interventionsrate, mittlere Reparaturzeit (MTTR), Stau-Hotspots und die Verteilung der Software-Stände über die Flotte. Ein einzelner Roboter, der langsamer wird, ist ein Wartungsfall; zwanzig Roboter derselben Baureihe, die gleichzeitig langsamer werden, sind ein Flottensignal – vermutlich ein fehlerhaftes Update.

Nicht jede Zahl ist ein Signal. Die häufigste Falle heißt Kardinalität: Wer alles in maximaler Auflösung von Tausenden Einheiten sammelt, erzeugt Datenberge, Kosten und Alarmmüdigkeit – aber keine Klarheit. RobotOps übernimmt hier den Reifegrad der Cloud-Beobachtbarkeit: aussagekräftige Kennzahlen statt aller Kennzahlen, Alarme an Symptomen (Auftrag scheitert) statt an Ursachen, und ein Zustandswert je Roboter, der viele Rohsignale zu einer betriebstauglichen Aussage verdichtet. Das wichtigste Telemetriesignal überhaupt ist oft das einfachste: der Heartbeat. Ein Roboter, dessen Lebenszeichen ausbleibt, ist per Definition ausgefallen – ob er stillsteht, abgestürzt oder nur offline ist, klärt die zweite Frage.

Wie definiert man Verfügbarkeit und SLAs für Roboterflotten?

Verfügbarkeit (Uptime) ist der Anteil der geplanten Einsatzzeit, in dem ein Roboter tatsächlich arbeitsfähig ist. Wichtig – und oft missverstanden: Sie wird sinnvollerweise an den Betriebsstunden gemessen, nicht an der Kalenderzeit. Ein Roboter, der nur in zwei Schichten läuft, ist nachts nicht „ausgefallen“, sondern außer Betrieb. Ein belastbares Service-Level-Agreement (SLA) für eine Flotte besteht deshalb nie nur aus einer Verfügbarkeitszahl, sondern aus mehreren Größen: Verfügbarkeit, mittlere Reparaturzeit (MTTR), Interventionsrate und Durchsatz. Wer nur die Verfügbarkeit vereinbart, kauft eine Kennzahl, die sich schönrechnen lässt.

Die folgende Tabelle macht konkret, was Verfügbarkeitsziele bedeuten. Die Ausfallzeit ist reine Arithmetik und dient der Anschauung – die Prozentwerte selbst sind, wie darunter erläutert, illustrativ.

Verfügbarkeit	Ausfall je 1.000 Betriebsstunden	Einordnung
99,0 %	10 Stunden	in der Branche oft genannter Richtwert für „gut“
99,5 %	5 Stunden	Zielbereich reifer Flotten mit Wartungsprogramm
99,6 %	4 Stunden	in Fallberichten führender Flotten genannt
99,9 %	1 Stunde	selten, meist nur mit hoher Redundanz erreichbar

Diese Richtwerte sind anekdotische Branchen- und Herstellerangaben, kein kodifizierter Standard. In der Lager- und AMR-Praxis werden rund 99 % Verfügbarkeit häufig als gute Ausgangsbasis genannt; führende Flotten berichten nach Einführung vorausschauender Wartung von 99,5 bis 99,6 % – ein zitierter Fall nennt eine 60-Einheiten-Flotte, die im zwölften Monat 99,6 % erreichte. Als gängige Betriebspraxis gilt zudem, 5 bis 10 % der Flotte als Hot-Spare-Reserve – einsatzbereite Ersatzeinheiten – vorzuhalten, um SLAs von 98 bis 99 % zu halten. Man sollte diese Zahlen als illustrativ behandeln, nicht als verbürgte Norm.

Der wichtigste, meist übersehene Punkt betrifft die Mathematik der Flotte: Flottenverfügbarkeit verhält sich anders als Einzelverfügbarkeit. Wenn hundert Roboter je 99 % Verfügbarkeit erreichen, ist zu jedem Zeitpunkt im Schnitt etwa einer außer Gefecht – das ist im Zweifel egal. Kritisch wird es, wenn eine Aufgabe mehrere Roboter gleichzeitig benötigt. Vereinfacht und unter der Annahme unabhängiger Ausfälle liegt die kombinierte Verfügbarkeit bei etwa p hoch N: Zehn Roboter mit je 99 % ergeben nur noch rund 90 % Wahrscheinlichkeit, dass alle zehn gleichzeitig verfügbar sind (0,99¹⁰ ≈ 0,904). Diese Rechnung ist idealisiert – reale Ausfälle sind korreliert, etwa durch ein gemeinsames Update oder einen gemeinsamen Ladepunkt –, aber sie erklärt, warum Redundanz und Hot Spares im Flottenbetrieb keine Kür sind, sondern Voraussetzung.

Woraus besteht der RobotOps-Stack?

Der RobotOps-Stack ist die Werkzeugkette, mit der man eine Flotte betreibt. Er bildet die etablierten DevOps-Bausteine auf die physische Welt ab – und ergänzt sie um das, was Software allein nicht hat: Verschleiß, Sicherheit im physischen Raum und Hardware, die man nicht einfach neu startet. Sechs Bausteine bilden den Kern.

Beobachtbarkeit: Wie behält man Tausende Einheiten im Blick?

Beobachtbarkeit (Observability) ist die Fähigkeit, aus den Ausgabesignalen eines Systems auf seinen inneren Zustand zu schließen – ohne jede Einheit einzeln aufzumachen. Sie besteht aus drei Säulen: Metriken (Zeitreihen wie Batterie oder Latenz), Logs (Ereignisprotokolle) und Traces (der Weg eines einzelnen Auftrags durch das System). Für Flotten kommt eine vierte, physische Dimension hinzu: die räumliche Sicht – wo stehen die Roboter, wo entstehen Staus. Ein Leitstand ohne Karte ist im Flottenbetrieb blind. Beobachtbarkeit ist nicht dasselbe wie Überwachung: Überwachung beantwortet bekannte Fragen („ist die Batterie leer?“), Beobachtbarkeit erlaubt neue Fragen an Daten, die man schon gesammelt hat, wenn ein unerwarteter Fehler auftritt. Welche sechs Signalfamilien dafür laufend ankommen müssen, beschreibt der vertiefende Beitrag zu Flottentelemetrie und Observability.

OTA-Updates: Wie liefert man Software sicher auf fahrende Hardware aus?

Over-the-Air-Updates (OTA) sind die Fähigkeit, Software und Modelle aus der Ferne auf die Flotte auszurollen. Sie sind unverzichtbar – niemand flasht tausend Roboter von Hand – und zugleich der gefährlichste Baustein: Ein fehlerhaftes Update erreicht die gesamte Flotte in Minuten. RobotOps überträgt hier die Regeln sicherer Softwareauslieferung: gestaffelter Rollout (erst wenige Einheiten, dann Wellen), Zustandsprüfung nach jeder Welle und jederzeit ein Rollback (Rücknahme) auf den letzten funktionierenden Stand.

Weil ein kompromittiertes Update eine physische Maschine übernehmen kann, ist die Absicherung der Auslieferung selbst ein eigenes Thema. Als Referenzarchitektur dient Uptane, ein offenes Sicherheits-Framework für Softwareupdates (Linux Foundation, entworfen von Forschenden aus NYU, SwRI und UMTRI mit der Industrie), ursprünglich für Automotive-OTA. Uptane verteilt die Rollen bewusst auf mehrere Instanzen – root, director, timestamp, release und targets –, sodass die Kompromittierung eines einzelnen Schlüssels nicht die ganze Flotte gefährdet. Der regulatorische Rahmen dazu kommt aus dem Fahrzeugumfeld und ist übertragbar: UNECE UN R155 (Management von Cybersicherheit) und UN R156 (Management von Softwareupdates) sowie die Norm ISO/SAE 21434. Wer OTA ohne dieses Fundament betreibt, baut eine Fernsteuerung für Angreifer. Die Mechanik von Canary-Rollout, A/B-Partitionen und automatischem Rollback im Detail erklärt der Beitrag zu OTA-Updates für Roboterflotten.

CI/CD und die sim-to-real-Pipeline: Wie testet man, bevor die Flotte es merkt?

Continuous Integration und Continuous Delivery (CI/CD) bedeuten in der Robotik mehr als grüne Testläufe. Weil physische Tests langsam, teuer und riskant sind, verschiebt RobotOps möglichst viel in die Simulation: Ein neues Modell durchläuft erst tausende simulierte Szenarien, dann eine kleine Referenzflotte, dann den gestaffelten Rollout. Diese sim-to-real-Pipeline ist nie perfekt, aber sie fängt die groben Fehler ab, bevor sie die Hardware erreichen.

Zum CI/CD-Alltag gehört auch das Lebenszyklus-Management der Plattform. Die meisten Flotten bauen auf ROS 2 auf, dessen Distributionen einem festen Rhythmus folgen: LTS-Versionen (gerade Jahre, fünf Jahre Support) wechseln sich mit Standard-Versionen (ungerade Jahre, rund 18 Monate Support) ab. Jazzy Jalisco ist die LTS-Version vom Mai 2024 mit Support bis Ende Mai 2029; Kilted Kaiju ist die Standard-Version vom Mai 2025 mit Support bis November 2026; die nächste benannte Version, Lyrical Luth, erschien im Mai 2026 als LTS mit Support bis Mai 2031. Für den Betrieb heißt das konkret: Eine Flotte auf Kilted Kaiju braucht 2026 einen Migrationsplan, sonst erreicht sie ungeplant das Support-Ende. Das ist dieselbe Disziplin wie das Management von Betriebssystem- und Abhängigkeitsständen im klassischen DevOps – nur dass hier physische Maschinen an den veralteten Ständen hängen.

Vorfallreaktion: Was passiert, wenn ein Roboter ausfällt?

Vorfallreaktion (Incident Response) ist der geregelte Umgang mit Störungen – und das direkte Gegenstück zur Eskalationsphase der operativen Schleife. Reife Flotten improvisieren nicht, sondern folgen Verfahren: klare Alarmierung, definierte Zuständigkeiten, Runbooks für wiederkehrende Fälle, ein Leitstand, der aus der Ferne eingreifen kann, und – entscheidend – eine vorwurfsfreie Nachbereitung (Post-mortem), die den Fehler in die Telemetrie und die Runbooks zurückspeist. Die Leitkennzahl ist die mittlere Reparaturzeit (MTTR): Nicht das Vermeiden jedes Ausfalls entscheidet über den Betrieb, sondern die Geschwindigkeit der Wiederherstellung. Eine Flotte, die schnell wieder hochkommt, schlägt eine, die selten, aber lange ausfällt.

Vorausschauende Wartung: Wie repariert man, bevor etwas bricht?

Vorausschauende Wartung (Predictive Maintenance) nutzt Telemetrie, um Verschleiß zu erkennen, bevor er zum Ausfall führt – der Punkt, an dem sich RobotOps am deutlichsten von reiner Software unterscheidet. Motoren, Lager, Räder und Batterien altern; ein driftender Motorstrom oder eine sinkende Batteriekapazität kündigt ein Problem oft Tage im Voraus an. Statt nach festem Kalender (zu früh, zu teuer) oder nach dem Ausfall (zu spät, zu teuer) zu warten, planen reife Betreiber Wartungsfenster nach Zustand. Genau dieser Ansatz steht hinter den zitierten Verfügbarkeitssprüngen auf 99,5 bis 99,6 %. Welche Sensordaten dafür konkret ausgewertet werden, vertieft der Beitrag zu vorausschauender Wartung für Roboterflotten.

Die Marktzahlen zu diesem Bereich sollte man mit Vorsicht lesen. Schätzungen zur Größe des Predictive-Maintenance-Markts schwanken je nach Zuschnitt erheblich – von rund 2,5 Mrd. USD (robotikspezifisch, 2026-Schätzung) bis rund 14 Mrd. USD (allgemeine vorausschauende Wartung), mit prognostizierten Wachstumsraten zwischen 11 und 34 %. Ähnlich uneinheitlich fällt der Markt für Flottenmanagement-Software für die Robotik aus: grob 3 bis 4 Mrd. USD für 2025/2026 und Langfristprognosen bis 12–15 Mrd. USD für 2035 (CAGR ~11–18 %), je nach Report (u. a. Custom Market Insights, WiseGuyReports, Market Research Future). Es gibt keine einzelne belastbare Zahl – jede Angabe ist eine quellenabhängige Schätzung und als solche zu kennzeichnen.

Interoperabilität: Wie arbeiten Roboter verschiedener Hersteller zusammen?

Interoperabilität ist die Fähigkeit, Roboter unterschiedlicher Hersteller in einer Flotte zu koordinieren. Sie ist kein Nice-to-have, sondern die Voraussetzung dafür, dass ein Betreiber nicht von einem einzigen Anbieter abhängig ist. Drei Standards prägen dieses Feld – und sie konkurrieren weniger, als dass sie sich ergänzen.

Standard	Träger	Transport	Zweck	Ausdrücklich nicht
VDA 5050	VDA + VDMA (Deutschland)	JSON über MQTT	Schnittstelle zwischen AGV/AMR und Leitsteuerung (Master Control)	–
MassRobotics AMR Interoperability	MassRobotics-Konsortium	WebSocket-API	Statusaustausch zwischen AMR verschiedener Hersteller (Position, Geschwindigkeit, Zustand, Auftragsstatus)	kein Navigations-, Flottenmanagement- oder Sicherheitssystem
Open-RMF	OSRF + Intrinsic	ROS 2	Koordination heterogener Multi-Vendor-Flotten (gemeinsame Flächen, Aufzüge, Türen)	–

VDA 5050, definiert vom VDA (Verband der Automobilindustrie) und VDMA (Verband Deutscher Maschinen- und Anlagenbau), ist die im DACH-Raum prägende offene Schnittstelle zwischen fahrerlosen Transportfahrzeugen und der Leitsteuerung; sie nutzt JSON-Nachrichten über MQTT. Version 2.1.0 erschien im August 2024; im März 2026 folgte die Großrevision v3.0.0 mit neuen Fehlerstufen CRITICAL/URGENT und Navigationszonen — den genauen Versionsstand sollte man dennoch zum Zeitpunkt der Umsetzung prüfen. Mehrere AMR-Anbieter unterstützen den Standard – OTTO Motors (Rockwell Automation) veröffentlichte 2023 einen quelloffenen VDA-5050-Konnektor.

Der MassRobotics AMR Interoperability Standard ergänzt VDA 5050, statt mit ihm zu konkurrieren: Er definiert eine WebSocket-API, über die autonome mobile Roboter verschiedener Hersteller Position, Geschwindigkeit, Zustand und Auftragsstatus teilen – ausdrücklich kein Navigations-, Flottenmanagement- oder Sicherheitssystem. Version 2.0 ergänzte Elemente für Laden/Energie und Missionskommunikation. Open-RMF (Open Robotics Middleware Framework), getragen von der OSRF und Intrinsic und auf ROS 2 aufgebaut, koordiniert heterogene Flotten mehrerer Anbieter, die sich Flächen, Aufzüge und Türen teilen; die Funktion „Mutex Groups“ entschärft Verkehrskonflikte. Open-RMF will nach eigenem Anspruch „das ROS des Flottenmanagements“ werden. Für Betreiber ist die Botschaft klar: Diese Standards adressieren verschiedene Ebenen – Schnittstelle, Statusaustausch, Koordination – und lassen sich kombinieren. Wie VDA 5050 und Open-RMF im Zusammenspiel eine gemischte AMR-Flotte tatsächlich koordinieren, zeigt der vertiefende Field Report zu VDA 5050 und Open-RMF in der gemischten AMR-Flotte.

Welche Rolle spielen Sicherheitsnormen im Roboterflottenbetrieb?

Eine zentrale, weil sie definiert, was ein Betreiber überhaupt aus der Ferne verändern darf. Im Februar 2025 veröffentlichte die ISO die überarbeiteten Normen ISO 10218‑1:2025 und ISO 10218‑2:2025 („Robotics – Safety requirements“) und ersetzte damit die Ausgaben von 2011; die Revision dauerte rund acht Jahre und band Fachleute aus über zwanzig Ländern ein. Drei Änderungen sind für RobotOps unmittelbar relevant: erstens explizite Anforderungen an die funktionale Sicherheit; zweitens ein neues Zwei-Klassen-System für Industrieroboter (Klasse 1 = geringeres Gefährdungspotenzial, reduzierte Steuerungsanforderungen, typischerweise Performance Level b); drittens – erstmals – ausdrückliche Cybersicherheitsanforderungen an die Robotersicherheit. Zusätzlich wurde die frühere ISO/TS 15066 zur Leistungs- und Kraftbegrenzung (Power and Force Limiting, für kollaborierende Roboter) in die konsolidierte ISO-10218-Reihe überführt.

Die operative Konsequenz ist unbequem, aber grundlegend: Man kann nicht beliebige OTA-Updates auf einen sicherheitsbewerteten Roboter aufspielen. Ändert ein Update eine sicherheitsrelevante Funktion, ist das kein reines Software-Release, sondern kann die Sicherheitsbewertung berühren. RobotOps trennt deshalb sauber zwischen sicherheitskritischer und nicht sicherheitskritischer Software und behandelt beide mit unterschiedlichen Freigabeprozessen. Dass die neuen Normen Cybersicherheit ausdrücklich in die Robotersicherheit aufnehmen, ist dabei kein Zufall, sondern schließt genau den Kreis zu Uptane und UN R155/R156: In der physischen Welt ist Sicherheit im Sinne von Safety nicht mehr von Sicherheit im Sinne von Security zu trennen.

Wie fängt man mit RobotOps an?

Nicht mit dem Kauf einer Plattform, sondern mit dem Messen. Die pragmatische Reihenfolge lautet: erst Telemetrie und Beobachtbarkeit, dann Kennzahlen, dann Automatisierung. Wer nicht weiß, wie hoch seine Interventionsrate und seine MTTR heute sind, kann keinen Fortschritt behaupten – und keine SLA verantworten. Der erste Schritt ist deshalb, den Zustand jeder Einheit und der Flotte sichtbar zu machen und zwei, drei ehrliche Kennzahlen zu etablieren, bevor irgendetwas „autonom“ heißen darf.

Der zweite Schritt ist, die Flotte als das zu behandeln, was sie ist: ein verteiltes System aus unzuverlässigen Knoten. Alle harten Lektionen aus fünfzehn Jahren verteilter Software gelten – gestaffelte Rollouts, Rollbacks, Redundanz, vorwurfsfreie Post-mortems – nur dass die Knoten hier Räder, Batterien und Sicherheitsfunktionen haben. Der dritte Schritt ist, Interoperabilität von Anfang an mitzudenken, damit die Flotte nicht an einen einzigen Anbieter gekettet ist. Und der vierte, unbequemste Schritt ist, den Menschen bewusst in der Schleife zu halten: Der Leitstand, die Eskalation, die Intervention sind keine Übergangslösung bis zur „echten“ Autonomie, sondern fester Bestandteil eines verantwortbaren Betriebs.

RobotOps ist Mitte 2026 ein junger Begriff für eine alte Wahrheit: Der Bau eines Roboters ist ein Projekt, der Betrieb einer Flotte ist ein Dienst. Wer diesen Unterschied ernst nimmt – mit Telemetrie statt Vertrauen, mit Kennzahlen statt Demos, mit Verfahren statt Improvisation –, betreibt Roboter, die nicht nur im Video, sondern in der dritten Nachtschicht funktionieren. Alles andere ist ein Prototyp mit gutem Schnitt.