Für Software-Updates an Ihrem Roboter schreibt niemand die Regeln

Software-Update-Engineering ist kein unbearbeitetes Problem. ISO 24089:2023, Road vehicles — Software update engineering, mit 2024 veröffentlichter Änderung 1, legt Anforderungen und Empfehlungen für genau diese Tätigkeit fest, auf Organisations- wie auf Projektebene. Sie erfasst Fahrzeuge, Fahrzeugsysteme, Steuergeräte, die zugehörige Infrastruktur sowie das Zusammenstellen und Ausrollen von Update-Paketen nach der Erstentwicklung. Sie gilt für Fahrzeughersteller, Zulieferer und deren Partner. Konkrete Technologien oder Lösungen schreibt sie bewusst nicht vor.

Das ist eine gut gebaute Antwort auf die Frage, die ein Betreiber tatsächlich stellt. Es ist zugleich, laut ihrem eigenen Anwendungsbereich, eine Antwort für Straßenfahrzeuge.

Für Serviceroboter, mobile Roboter oder Humanoide gibt es kein Gegenstück. Eine Reinigungsmaschine, ein Transportroboter im Klinikflur und ein Laufroboter in der Inspektion erhalten alle verhaltensänderende Software von ihren Herstellern, und keiner von ihnen steht in einem veröffentlichten Rahmenwerk, das beschreibt, wie das entwickelt, gestuft und dokumentiert werden sollte. Das ist eine Lücke, kein Schlupfloch: Niemand umgeht hier etwas. Die Normung ist schlicht dort entstanden, wo die Fahrzeugindustrie sie brauchte, und hier bislang nicht.

Die Folge für einen Betreiber ist eng und praktisch. Wo eine Norm existiert, können Sie Konformität verlangen und es dabei belassen. Wo keine existiert, müssen Sie fragen — und die Antworten aufschreiben.

Der Reflex in einem Mischflotten-Projekt greift zu VDA 5050, der von VDA und VDMA entwickelten Schnittstellenspezifikation für die Kommunikation zwischen einer Leitsteuerung und mobilen Robotern. Sie ist eine echte technische Norm, derzeit in Version 3.0.0 mit Stand März 2026, und für das, was sie abdeckt, das richtige Werkzeug.

Sie deckt dies nicht ab. Abschnitt 2, „Scope“, nimmt ausdrücklich aus dem Anwendungsbereich heraus: Sicherheitsanforderungen — das Dokument „does not define functional, operational, or system safety requirements and shall not be regarded or applied as a safety standard“ —, Verkehrsführungslogik, weitere Kommunikationsschnittstellen zu Peripherie oder externen IT-Systemen, Projektkoordination und Inbetriebnahmeverfahren, Maßnahmen der Cybersicherheit sowie die Zuordnung betrieblicher Verantwortlichkeiten zwischen Betreibern, Integratoren, Fahrzeugherstellern und Anbietern von Flottenleitsystemen.

Der letzte Ausschluss ist hier der entscheidende. Wer das Verhalten einer Maschine auf Ihrer Fläche ändern darf und unter welchen Bedingungen, ist eine Frage der Verantwortungszuordnung. VDA 5050 sagt mit eigenen Worten, dass es sie nicht beantwortet. Was die Norm tatsächlich abdeckt und welche Vertragsgegenstände eine Mischflotte daneben braucht, steht in VDA 5050 und die gemischte Flotte.

Als Nächstes sieht ein Betreiber in die Dokumentation des Herstellers, und es lohnt sich, genau zu sein, denn der Befund ist gemischt.

Boston Dynamics pflegt eine öffentliche Entwicklerdokumentation und veröffentlicht Release Notes unter einer benannten Version — zum Zeitpunkt dieses Textes Spot 5.1.9. Diese Notes sind gehaltvoll. Sie halten neue Funktionen, Fehlerbehebungen und Abkündigungen fest und lassen einen Betreiber erkennen, was sich zwischen zwei Versionen geändert hat. Das ist mehr, als ein großer Teil dieses Marktes überhaupt veröffentlicht.

Was die Release Notes nicht enthalten, ist irgendeine der Zusagen, aus denen eine Update-Politik besteht. Wer gezielt danach sucht, findet keine Aussage dazu, wie Roboter aktualisiert werden, keine Kompatibilitätszusage, keine Erklärung, dass ein bestimmtes Release für einen genannten Zeitraum gepflegt wird, und keine Liste nicht mehr unterstützter Versionen. Das Dokument ist ein Changelog und erfüllt die Aufgabe eines Changelogs.

Dass die Änderungen real sind, lässt sich aus derselben Dokumentation belegen. Boston Dynamics hält fest, dass ab Version 3.2.1 der CORE-I/O-Software Passwort und Gruppen auf der Nutzlast vom Anwender geändert werden können. Das ist eine Zugriffseigenschaft einer im Einsatz befindlichen Nutzlast, die sich in einem Point Release ändert. Es ist eine sinnvolle Verbesserung, sie ist sauber dokumentiert, und sie ist zugleich die Art Änderung, von der die eigene Sicherheitsprüfung eines Betreibers lieber vorher gewusst hätte, als sie in einem Versionshinweis zu entdecken.

Daraus folgen zwei Dinge. Erstens schwankt die Dokumentationstiefe über die Herstellerbasis hinweg erheblich, und ob überhaupt ein versioniertes Entwicklerhandbuch existiert, lässt sich vor der Unterschrift klären. Zweitens lässt selbst der bestdokumentierte Fall dieses Segments die Unterstützungszusage offen — sie muss also von anderswoher kommen.

Das sind Fragen für eine Ausschreibung oder eine Vertragsverhandlung, nicht für ein technisches Audit. Jede lässt sich von einem Hersteller in einem Satz beantworten, und jede wird erst nützlich, wenn die Antwort schriftlich vorliegt.

• Was kann sich ohne unser Zutun ändern? Firmware, Autonomieverhalten, das Wahrnehmungsmodell, die mobile oder Web-Anwendung, der Cloud-Dienst, von dem der Roboter abhängt. Verlangen Sie die Liste, nicht die Beteuerung.
• Welche dieser Änderungen erreichen die Maschine automatisch und welche verlangen ein Handeln von uns? Ein Roboter, der sich selbst aktualisiert, und einer, der auf einen Techniker wartet, sind zwei verschiedene Betriebsrisiken.
• Können wir ein Update zurückstellen, und wie lange? Lautet die Antwort nein, ist das eine wichtige Information. Lautet sie ja, fragen Sie, was während der Zurückstellung nicht mehr funktioniert.
• Gibt es eine Version, die wir für die Dauer eines Validierungsfensters festschreiben können? Standorte mit Qualifizierungsverfahren — Kliniken, Lebensmittelproduktion, regulierte Fertigung — brauchen diese Antwort vor allen anderen.
• Wie lange wird diese Release-Linie gepflegt? Fragen Sie nach einem Datum oder einem Zeitraum. Wo der Hersteller keinen nennt, ist genau das die Antwort, und sie gehört in den Risikoteil und nicht in eine Fußnote.

Bei der letzten Frage enden die meisten dieser Gespräche, und sie ist die, bei der ein Betreiber am härtesten nachfassen sollte — denn nur ihre Antwort verändert, was die Maschine im vierten Jahr wert ist.

Die zweite Gruppe betrifft Zuständigkeit und Wiederherstellung. In einer Flotte wiegen sie schwerer als im Pilotbetrieb, denn eine Änderung, die zehn Maschinen gleichzeitig erreicht, nimmt Ihnen den Vergleich, der Ihnen gesagt hätte, dass etwas nicht stimmt.

• Wer entscheidet, dass ein Update auf unsere Maschinen kommt? Benennen Sie die Partei. Ist es der Hersteller, gehört das in den Vertrag; ist es der Betreiber, muss der Prozess des Herstellers das auch zulassen.
• Welche Vorankündigung erhalten wir, und in welcher Form? Eine auf einer Website veröffentlichte Release Note ist keine Ankündigung an einen Betreiber. Ein benannter Ansprechpartner mit Vorlauf schon.
• Können wir zurückrollen? Auf welche Version, durch wen, in welcher Zeit — und verfällt dadurch etwas.
• Was wird vor einem Produktiv-Rollout validiert, und von wem? Fragen Sie ausdrücklich, ob die Validierung auf einer Konfiguration wie Ihrer erfolgt oder nur in der Umgebung des Herstellers.
• Wessen Mangel ist es, wenn sich die Maschine nach einem Update anders verhält? Eine kaufmännische Frage mit technischer Oberfläche — im Vertrag ungleich billiger zu klären als im Störfall.
• Was geschieht mit unserer Standortkonfiguration und unseren Karten über ein Update hinweg? Erhalten, automatisch migriert oder vor Ort neu aufgenommen — die drei Antworten kosten sehr Unterschiedliches.

Wo ein gelerntes Modell statt klassischer Steuerlogik im Spiel ist, ist ein Update eine Verhaltensänderung und keine Fehlerbehebung, und das Abnahmeproblem verändert vollständig seine Form. Die daraus folgende gestufte Validierungskette — Auswertung gegen historische Daten, Schattenbetrieb, kontrollierte Freigabe — steht in Gelernte Roboter-Policies: Abnahme und Sicherheitsnachweis, und beide Texte gehören zusammen gelesen.

Eine im Termin gegebene Antwort ist keine Antwort. Ohne Norm, auf die sich verweisen ließe, ist die einzig haltbare Form die vertragliche — und die Formulierung ist nicht aufwendig.

1. Eine Update-Politik als Anlage, nicht als Klausel. Die Liste dessen, was sich ändern kann, wer entscheidet, welche Vorankündigung erfolgt und wie der Rückrollweg aussieht. Eine Seite genügt.
2. Ein benannter Pflegezeitraum für die Release-Linie, mit der Angabe, was an dessen Ende geschieht: weiterhin Sicherheitskorrekturen, ein Migrationspfad oder nichts. Alle drei sind zulässige Antworten; Schweigen ist keine.
3. Ein Recht auf Festschreibung oder Zurückstellung für Standorte, die es brauchen, mit den Bedingungen, unter denen es erlischt.
4. Der Umgang mit Standortkonfiguration und Karten über Updates hinweg, ausdrücklich geregelt statt unterstellt.
5. Wo die Verantwortung liegt, wenn sich das Verhalten ändert — damit die Frage geklärt ist, bevor sie teuer wird.

Nichts davon verlangt vom Hersteller etwas Ungewöhnliches. Es verlangt von ihm, das zu benennen, was er ohnehin tut — zu einem Zeitpunkt, an dem der Betreiber noch kaufmännisches Gewicht hat. Nach dem ersten flottenweiten Rollout ist dieses Gewicht weg.

Eine Abgrenzung gehört ausdrücklich benannt, denn das Thema lädt zur falschen Art Artikel ein.

Dies ist keine Empfehlung zur Auswahl von Update-Werkzeugen. Es gibt ein ausgereiftes Feld quelloffener und kommerzieller Software zur Auslieferung von Updates an eingebettete Geräte, und diese Systeme zu vergleichen, ist eine berechtigte Übung — für denjenigen, der den Roboter baut. Ein Betreiber mit gemischter Flotte wählt diese Schicht nicht aus, installiert sie nicht und wartet sie nicht. Sie kommt in der Maschine an, ausgewählt vom Hersteller.

werob baut und verkauft kein Update-System und bezieht keine Position dazu, welches ein Hersteller verwenden sollte. werob baut keine Hardware und keine eingebettete Software. Was ein Integrator hier leisten kann, ist eng und nützlich: dafür zu sorgen, dass die obenstehenden Fragen gestellt werden, solange noch verhandelt wird, dass die Antworten in der Spezifikation landen und nicht im Postfach, und dass dieselben Fragen jedem Hersteller einer Mischflotte gestellt werden und nicht nur dem, dessen Dokumentation am leichtesten zu lesen war.

Die verwandte Frage, wie lange die Hardware darunter überhaupt verfügbar bleibt, behandelt Das Rechenmodul in Ihrem Roboter hat ein veröffentlichtes Enddatum.