Flottentelemetrie und Observability: Was jeder Roboter senden muss, bevor er ausfällt

Jeder Roboter einer Flotte sollte dieselben sechs Signalfamilien senden, auf einem festen Schema — ob es sich um einen am Boden verschraubten Sechsachser handelt oder um einen autonomen mobilen Roboter, der einen Gang quert: Energie- und Batteriezustand (Ladung, Spannung, Zelltemperatur, Gesundheit), Antriebs- und Gelenkzustand (Motorstrom, Gelenktemperatur, Schleppfehler), Aufgaben- und Auftragsstatus (was er tut, Fortschritt, Erfolg oder Fehlschlag), Lokalisierungsvertrauen (wie sicher er seine eigene Pose kennt), Sicherheits- und Beinahe-Ereignisse (Schutzhalte, Feldverletzungen, Not-Halt, Geschwindigkeitsreduktionen) und strukturierte Fehler- und Warncodes. Alles Weitere ist Detail. Kommen diese sechs laufend an — normalisiert auf ein Schema, mit Zeitstempel und Einheiten-Kennung —, können Sie eine Flotte betreiben. Fehlt eine davon, fliegen Sie in diesem Teil der Flotte blind, und Sie erfahren im ungünstigsten Moment, in welchem.

Das ist die ganze These der Flottentelemetrie; der Rest ist Ingenieurarbeit: diese Signale von Maschinen unterschiedlicher Hersteller herunterzuholen, in eine Form zu bringen und auf ein Dashboard, das die Flotte zeigt statt einen Roboter nach dem anderen. Dies ist ein Feldbericht, kein Werkzeugprospekt. Wo eine Aussage auf einem Standard beruht, nennen wir ihn; wo die Branche ein aus der Software entliehenes Konzept verkauft, sagen wir es klar.

Was genau sollte jeder Roboter senden?

Der Sinn einer festen Liste: Sie macht die Flotte vergleichbar. Wenn fünfzig Roboter dieselben sechs Familien in denselben Einheiten melden, können Sie sie sortieren, gegeneinander stellen und den einen finden, der sich von der Herde entfernt. Die Tabelle zeigt den kanonischen Satz, warum jede Familie ihre Bandbreite verdient und — für mobile Roboter — wo sie bereits in einem realen, veröffentlichten Standard verankert ist.

Signalfamilie	Was der Roboter meldet	Warum es zählt	Entsprechung in der VDA5050-Zustandsnachricht
Energie / Batterie	Ladezustand, Spannung, Zelltemperatur, Batteriegesundheit, Lade-Flag	Reichweite, Ladeplanung, thermisches Risiko	powerSupply (charge, voltage, health, charging; vormals batteryState)
Antrieb / Gelenk	Motorstrom, Gelenktemperatur, Schlepp-/Positionsfehler, Drehmoment	Frühste Signatur mechanischen Verschleißes	herstellerspezifisch (in info-/error-Feldern)
Aufgabe / Auftrag	Aktuelle Aktion, Auftragsfortschritt, erledigt vs. fehlgeschlagen	Durchsatz, Erkennung hängender Aufgaben	actionStates (SCHEDULED / RUNNING / FINISHED / FAILED)
Lokalisierungsvertrauen	Posenschätzung plus Vertrauenswert, Karten-ID	Ein Roboter, der seine Position nicht kennt, ist ein Sicherheitsproblem	agvPosition.localizationScore, positionInitialized
Sicherheit / Beinahe	Schutzhalte, Feldverletzungen, Not-Halt-Zustand, Geschwindigkeitsreduktionen	Frühindikator für Kollisionen und Layoutfehler	safetyState (eStop, fieldViolation)
Fehler / Warnungen	Codierte Fehler und Warnungen mit Schweregrad	Triage und flottenweite Mustererkennung	errors[] (leeres Array = gesund)

Zwei davon werden im Feld chronisch zu selten gemeldet. Das Lokalisierungsvertrauen vergessen Betreiber am häufigsten zu senden: Ein Roboter, der sich seiner Position nur zu 60 % sicher ist, fährt trotzdem — und es ist weit billiger, das als sinkenden Wert zu bemerken als als Kollision. Beinahe-Ereignisse sind das andere. Ein Schutzhalt, der nie zum Zwischenfall wurde, ist genau der Frühindikator, den Sie wollen, und wird meist verworfen, weil ja „nichts passiert“ ist.

Wie normalisiert man Telemetrie verschiedener Hersteller?

Gemischte Flotten sind sich über Wörter nicht einig. Ein Hersteller nennt es batteryCharge, ein anderer stateOfCharge; einer meldet Temperatur in Grad Celsius, ein anderer in rohen ADC-Zählwerten; ein Arm-Hersteller vergräbt Gelenkdaten in einem proprietären Log, während ein AMR sauberes JSON veröffentlicht. Lässt man das laufen, muss jedes Dashboard, jeder Alarm und jedes Modell jeden Lieferanten gesondert behandeln — was über zwei, drei Hersteller hinaus nicht skaliert.

Die Lösung ist ein kanonisches Schema, das Ihnen gehört: Definieren Sie die sechs Familien einmal, in Ihren Einheiten, mit Ihren Feldnamen und einer Uhr, und bilden Sie dann jeden Hersteller am Rand (Edge) darauf ab. Weiter hinten spricht alles eine Sprache. Das ist unspektakuläre Integrationsarbeit — und das Wirksamste, was Sie bauen können, weil es Ihren Observability-Stack von jedem einzelnen Lieferanten entkoppelt.

Für mobile Roboter gibt es einen realen Anker, auf den hin man normalisiert. VDA5050 ist die aus der Automobilindustrie stammende Schnittstelle (JSON über MQTT) zwischen mobilen Robotern und einer Flotten-Leitsteuerung, und ihre Zustandsnachricht ist das Nächste, was die AMR-Welt an einem standardisierten Telemetrie-Umschlag hat. Sie enthält agvPosition mit localizationScore, powerSupply (seit Revision 2.1, August 2024; vormals batteryState), einen safetyState mit Not-Halt- und Feldverletzungs-Flags, actionStates für den Aufgabenfortschritt und ein errors-Array, das bei einem gesunden Roboter leer ist. Das bildet die sechs Familien fast eins zu eins ab. Der Vorbehalt — und er ist lehrreich — ist, dass VDA5050 Felder über Versionen hinweg immer wieder umbenennt und umbaut (zuletzt mit der Großrevision v3.0.0 im März 2026); genau deshalb bilden Sie jeden Hersteller in Ihr stabiles Schema ab, statt fremde Feldnamen ungeprüft zu übernehmen. Auch Standards driften. Die Koordination gemischter Hersteller zieht sich durch den Flottenbetrieb.

Welche Transporte tragen Robotertelemetrie — DDS oder MQTT?

Beide, auf verschiedenen Ebenen; sie zu verwechseln ist ein häufiger Entwurfsfehler.

Im Roboter ist das echtzeitfähige Nervensystem meist DDS — der Data Distribution Service der Object Management Group, ein datenzentrierter Publish-Subscribe-Standard für Echtzeit- und eingebettete Systeme, mit feingranularen Dienstgüte-Regeln (Zuverlässigkeit, Fristen, Ressourcengrenzen) und einem eigenen RTPS-Interoperabilitätsprotokoll. Er ist die Standard-Middleware unter ROS 2: Knoten veröffentlichen und abonnieren benannte Topics, und DDS bewegt die Daten. Für die lokale Aufzeichnung schreibt rosbag2 diese Topics auf den Datenträger — seit ROS 2 Iron (Mai 2023) standardmäßig im MCAP-Format, die ältere SQLite-Datei (.db3) bleibt als Alternative unterstützt —, mit einer Metadaten-Beilage: der Blackbox-Rekorder, den Sie wollen, wenn ein Roboter etwas Unerklärliches tut und Sie den Topic-Strom Bild für Bild wiedergeben müssen.

Außerhalb des Roboters ist der Flottentransport meist MQTT — ein OASIS-Standard, seit 2016 zugleich ISO/IEC 20922, ein bewusst leichtgewichtiges Publish-Subscribe-Protokoll für beschränkte Geräte und dünne, unzuverlässige Verbindungen. Genau dieses Bandbreitenprofil ist der Grund, warum es — und nicht DDS — die Roboter-zu-Cloud-Telemetrie trägt, und es ist der Transport unter VDA5050. Das Denkmodell: DDS ist der hochratige Bus in der Maschine; MQTT ist der zusammengefasste Strom, der sie verlässt. Kilohertz-DDS-Verkehr schiebt man nicht in die Cloud, und eine Sicherheitsschleife fährt man nicht über MQTT.

Was bedeutet Observability, wenn man sie von Servern auf Roboter überträgt?

Observability ist eine Idee aus der Softwaretechnik, bevor sie eine der Robotik ist, und es lohnt sich, sie präzise zu importieren. Im Betrieb ruht sie auf drei Säulen: Metriken, Logs und Traces. Metriken sind billige numerische Zeitreihen — Batterieprozent, Taktzeit, CPU-Last —, die man aggregiert und auf die man alarmiert. Logs sind zeitgestempelte, überwiegend textuelle Ereignissätze: dieser Fehler trat auf, diese Aktion begann. Traces verfolgen eine einzelne Arbeitseinheit über Komponenten hinweg; bei einem Roboter einen Auftrag, der Wahrnehmung, Planung, Motorregelung und Flottenmanager durchläuft. Die entscheidende Unterscheidung: Überwachung sagt Ihnen, ob etwas Bekanntes kaputt ist; Observability ist, ob Ihre Telemetrie reich genug ist, um eine Frage zu beantworten, die Sie vorab nicht gestellt haben — ohne neuen Code auf den Roboter zu spielen.

OpenTelemetry (OTel) ist der herstellerneutrale CNCF-Standard für genau diese drei Signale in verteilter Software: ein Instrumentierungsmodell, ein Übertragungsprotokoll (OTLP), ein Collector, und man leitet an ein beliebiges Backend — das Projekt selbst erreichte am 11. Mai 2026 den Status „CNCF Graduated“, die höchste Reifestufe der Foundation. Die ehrliche Einordnung: OTel wurde für Microservices gebaut, nicht für Motoren. Es gibt Stand 2026 kein offizielles Robotik-Profil, und die hart-echtzeitfähige Regelschleife eines Roboters wird nie OTel-Spans im Kilohertz-Takt aussenden. Aber das Modell ist übertragbar, und es ist zunehmend die Form, die flottenseitige Telemetrie annimmt, sobald sie den Roboter verlassen hat und heruntergerechnet wurde. Wer Ihnen „OpenTelemetry für Roboter“ als fertiges Produkt verkauft, verkauft Ihnen die Abbildung, keine Spezifikation.

Wie kommt man vom Log eines Roboters zum Flotten-Dashboard?

Das rosbag eines einzelnen Roboters ist ein forensisches Werkzeug: Es beantwortet „Was tat diese Maschine um 14:32?“ Ein Flotten-Dashboard beantwortet eine andere Frage — „Welche meiner zweihundert Maschinen wird gleich zum Problem?“ — und dorthin kommt man nicht durch Hochskalieren von Log-Auslesen. Der Schritt geht von Sätzen zu Aggregaten.

Drei Dinge ändern sich im Flottenmaßstab. Erstens die Kardinalität: zweihundert Roboter mal Dutzende Signale sind ein Schwall, also aggregiert man in Rollups pro Einheit und pro Kohorte (mittlere Taktzeit der Flotte, Zahl der Schutzhalte pro Roboter und Stunde), statt Rohströme anzustarren. Zweitens wird der Vergleich zur primären Sicht: nützlich ist nicht die Batteriekurve eines Roboters, sondern alle übereinandergelegt, denn der Ausreißer ist die Geschichte. Drittens tragen Einheiten-Kennung und Zeitstempel das Gewicht — ohne konsistente Kennzeichnung und eine Uhr können Sie ein Ereignis auf Roboter 47 nicht mit einer gemeinsamen Ladestation oder einem bestimmten Gang in Deckung bringen. Eine Flottensicht, die nicht „zeig mir jeden Roboter, der in Zone 3 dieser Schicht einen Schutzhalt hatte“ beantworten kann, ist eine Sammlung von Dashboards, keine Flotten-Observability.

Wie erkennt man Drift und Anomalien, bevor sie zu Ausfällen werden?

Das gesuchte Signal ist fast nie ein einzelner schlechter Messwert. Es ist Drift — eine langsame Veränderung der Grundlinie eines Signals, die einem harten Fehler vorausgeht. Ein Gelenk, das jede Woche etwas mehr Strom zieht. Ein Lokalisierungs-Wert, der in einem bestimmten Gang absinkt, während Umgebung oder Sensor nachlassen. Eine Taktzeit, die bei einer Kohorte hochkriecht. Keines davon löst einen festen Schwellenwert aus, bis es fast zu spät ist — weshalb reines Schwellenwert-Alarmieren ein schwaches Netz ist.

Die Flotte macht Drift überhaupt erkennbar. Weil eine Flotte viele nahezu baugleiche Roboter in nahezu gleichen Arbeitszyklen ist, können Sie eine Grundlinie pro Kohorte bilden und die Herde als eigene Kontrollgruppe behandeln: Der Roboter, der sich vom Normalzustand seiner Kohorte entfernt, wird lange vor Erreichen einer absoluten Grenze markiert. Das ist Anomalieerkennung in ihrer belastbarsten Form — relativ, nicht absolut. Seien Sie skeptisch gegenüber „KI-Anomalieerkennung“, die Ausfälle mit gerundeten Prozentzahlen vorherzusagen verspricht; ehrlich ist, dass Trendbildung pro Kohorte die Klasse langsamer Degradation zuverlässig fängt und die konkrete Trefferquote standortabhängig und selten unabhängig geprüft ist. Der Mechanismus ist solide. Die Marketingzahlen darum herum meist nicht.

Edge oder Cloud — was läuft auf dem Roboter, was wird gesendet?

Das ist eine Bandbreiten- und Latenzentscheidung, keine Weltanschauung. Manches muss lokal rechnen, weil das Netz nicht in der Schleife sein darf; manches muss zentral sein, weil kein einzelner Roboter die Flotte sieht.

Entscheidung	Läuft auf dem Roboter (Edge)	Gesendet an Flotte / Cloud
Sicherheitskritische Schleifen (Not-Halt, Kollisionsvermeidung)	Ja — deterministisch, kein Netz in der Schleife	Ereignis melden, Schleife nie fern ausführen
Hochfrequente Rohsignale (kHz-Gelenkdaten, volle Sensorik)	Lokal aufgezeichnet (rosbag2) für Forensik	Nur heruntergerechnete Zusammenfassungen und Merkmale
Anomalieerkennung	Schnelle einheitslokale Prüfungen (Schwellen, leichte Modelle)	Flottenweit, einheitsübergreifend, schwerere Modelle
Lange Aufbewahrung und Trend-Grundlinien	Speichergebunden, kurz gehalten	Ja — das ist Aufgabe der Cloud
Was tatsächlich über MQTT geht	—	Metriken, Ereignisse, Fehler und Zustand in handhabbarer Rate

Die Voreinstellung, die Betreiber aus Schwierigkeiten hält: Sicherheit und hochratige Schleifen am Edge rechnen, Zusammenfassungen und Ereignisse senden, die vollratige Aufzeichnung lokal halten, damit Sie eine Blackbox haben, wenn etwas schiefgeht. Jedes Rohsignal in die Cloud zu streamen ist eine Rechnung und ein Engpass; alles auf dem Roboter zu rechnen macht die Flotte blind. Die Grenze zieht, was die ganze Flotte braucht, um aussagekräftig zu sein.

Wie hängt Flottentelemetrie mit der vorausschauenden Wartung zusammen?

Direkt — Telemetrie ist die Eingabe, vorausschauende Wartung eine der Ausgaben. Dieselben Motorstrom- und Gelenktemperatur-Ströme, mit denen Sie Roboter auf einem Dashboard sortieren, sind das Rohmaterial, das ein Zustandsüberwachungs-Modell liest, um zu sagen, dass ein Lager nachlässt. Ohne Flottentelemetrie keine vorausschauende Wartung; die Observability-Schicht ist die Voraussetzung, kein getrenntes Projekt. Wie aus Motorstrom- und Temperaturtrends konkret ein Wartungstermin wird, erklärt der vertiefende Beitrag zu vorausschauender Wartung für Roboterflotten. Telemetrie speist auch die Auftragsplanung (den Roboter mit wenig Ladung zur Station leiten), die Sicherheitsbewertung (welche Zonen erzeugen die meisten Beinahe-Ereignisse) und die flottenweite Software-Ausrollung (welche Kohorte ist gesund genug, zuerst zu aktualisieren). Vorausschauende Wartung ist der meistdiskutierte Ertrag, aber einer von mehreren Abnehmern des Stroms — alle behandelt im Flottenbetrieb.

Ein abschließender Hinweis, dem Bericht treu: „RobotOps“ — die Linse dieses ganzen Themas — ist ein geprägter Rahmen: DevOps- und Betriebsdenken, angewandt auf Roboterflotten, kein ISO- oder VDA-Regelwerk. Wie diese Disziplin insgesamt zusammenwirkt — von der operativen Schleife bis zum Ops-Stack —, beschreibt der Grundlagenbeitrag zu RobotOps als DevOps für Roboterflotten. Die Technik darunter ist real und standardisiert: MQTT, DDS, ROS 2, OpenTelemetry und VDA5050 sind allesamt veröffentlichte, prüfbare Spezifikationen. Was Sie tatsächlich kaufen, ist die Disziplin, sie auf eine Flotte zu richten — und kein Dashboard ersetzt die vorab getroffene Entscheidung, was genau jeder Roboter Ihnen schuldet. Ob sich diese Investition in Sensorik und Auswertung überhaupt lohnt, beantwortet die Kalkulation zur Kapitalrendite von Lagerrobotik. Die verwendeten Begriffe stehen im Glossar.