Herstellerausfall in der Servicerobotik: Betreiber-Leitfaden

Die Insolvenz eines Herstellers von Servicerobotern beendet Herstellergarantien mit sofortiger Wirkung, kappt den Zugang zu proprietären Ersatzteilen und bindet Betreiber weiterhin an laufende Leasingverträge für nicht mehr einsatzfähige Hardware. Während mechanische Standardkomponenten oft über Drittanbieter beschafft werden können, lassen sich speziell angefertigte Module nach einem Produktionsstopp kaum ersetzen.

Bei der Bewertung physischer Risiken müssen Betreiber strikt zwischen handelsüblicher Standardhardware (Commercial Off-The-Shelf, COTS) und herstellerspezifischen Komponenten unterscheiden. Standard-LiDAR-Sensoren, universelle Lithium-Ionen-Akkupacks, Industrieräder und Verbindungselemente sind in der Regel über den Fachhandel beziehbar. Im Gegensatz dazu erfordern kundenspezifische Gelenkantriebe, integrierte Getriebe, proprietäre Kameragehäuse und herstellereigene Platinen (PCBs) bei einem Ausfall eine Neukonstruktion der Firmware und der mechanischen Basis.

Dass selbst solide finanzierte Pioniere scheitern können, zeigte das Aus des Robotikherstellers Rethink Robotics im Oktober 2018: Das 2008 gegründete Unternehmen stellte den Betrieb ein, nachdem es in seiner zehnjährigen Geschichte knapp 150 Millionen US-Dollar an Investorengeldern eingesammelt hatte^[1]. Die Schließung stoppte die Weiterentwicklung und den direkten Herstellerservice für die kollaborativen Modelle Baxter und Sawyer schlagartig, bis die Schutzrechte später von einem Drittanbieter übernommen wurden.

Komponenten-Kategorie	Marktverfügbarkeit	Folge bei Herstellerausfall	Maßnahme für Betreiber
Proprietäre Antriebe und Gelenke	Keine Drittanbieter-Verfügbarkeit	Ein defektes Gelenk legt den gesamten Roboter still	Mechanischen Treuhandvertrag schließen oder Ersatzgeräte vorhalten
Hauptplatinen und Sensor-PCBs	Herstellerspezifisches Layout	Keine direkt einsetzbaren Ersatzmodule am freien Markt	Schaltpläne und Firmware-Flash-Tools vertraglich sichern
LiDAR, Ultraschall und Tiefenkameras	Industrieller Standardmarkt	Kompatible COTS-Modelle sind meist weiter beziehbar	Schnittstellenprotokolle und Spannungswerte dokumentieren
Akkus und Ladekontakte	Gemischt (Standardzellen in Sondergehäusen)	Zellen sind neu konfektionierbar, das proprietäre BMS nicht	Offenlegung der Spezifikationen des Batteriemanagementsystems verlangen

Finanziell bleiben Betreiber meist zur Zahlung der monatlichen Raten verpflichtet, da Leasing- und Finanzierungsverträge überwiegend mit externen Finanzinstituten und nicht mit dem Hersteller selbst geschlossen werden. Verweigert der Roboter mangels Software-Unterstützung oder Ersatzteilen den Dienst, behält die Leasinggesellschaft ihren vertraglichen Zahlungsanspruch, während gesetzliche Gewährleistungs- und Serviceansprüche gegen den insolventen Hersteller lediglich zu ungesicherten Insolvenzforderungen werden.

Das Ausbleiben regelmäßiger Firmware-Patches verwandelt vernetzte autonome Serviceroboter in dauerhafte Sicherheitslücken innerhalb der IT-Infrastruktur von Pflegeheimen und Kliniken. Ohne ein aktives Entwicklerteam zur Behebung neu entdeckter Schwachstellen (Common Vulnerabilities and Exposures, CVEs) verletzen die Geräte schnell die IT-Sicherheitsrichtlinien des Unternehmens.

Serviceroboter im kommerziellen Betrieb fungieren als vollwertige Netzwerk-Endpunkte. Sie kommunizieren über das lokale WLAN, greifen auf Gebäudemanagementsysteme zu, steuern Aufzüge an und erfassen kontinuierlich Raumdaten über Kameras und Sensoren. Stellt der Hersteller den Betrieb ein, erhalten das zugrunde liegende Linux-Betriebssystem, Kommunikationsbibliotheken (wie ROS oder WebRTC-Stacks) und kryptografische Schlüssel keine Aktualisierungen mehr.

• Ungepatchte Netzwerkdienste: Lokale Schnittstellen und Fernwartungstools bleiben dauerhaft anfällig für Remote-Code-Execution-Angriffe und seitliche Bewegungen im internen Netz.
• Abgelaufene Sicherheitszertifikate: In der Firmware hinterlegte TLS-Zertifikate können nicht mehr erneuert werden, wodurch die verschlüsselte Authentifizierung an Unternehmensproxys fehlschlägt.
• Compliance- und Haftungsrisiken: Der Betrieb ungepatchter Systeme widerspricht Standards wie ISO/IEC 27001 und gesetzlichen Vorgaben wie der NIS-2-Richtlinie, die ein aktives Schwachstellenmanagement fordern.
• Dilemma der Netzwerkisolierung: Das Verschieben des Roboters in ein isoliertes VLAN trennt häufig kritische Schnittstellen zu Brandschutztüren, Aufzugsteuerungen und Dispositions-Workflows ab.

In hochregulierten Umgebungen wie Seniorenresidenzen und Krankenhäusern können IT-Sicherheitsverantwortliche den Weiterbetrieb nicht gewarteter Netzwerkgeräte nicht tolerieren. Häufig muss technisch intakte Hardware vollständig stillgelegt werden, um Audit-Verstöße und Sicherheitsvorfälle im Vorfeld auszuschließen.

Viele moderne Serviceroboter nutzen eine hybride Architektur, bei der wesentliche Rechenprozesse nicht lokal auf dem Gerät, sondern auf Cloud-Servern des Herstellers ausgeführt werden. Wird die Cloud-Infrastruktur im Rahmen einer Insolvenz abgeschaltet, fallen diese Kernfunktionen schlagartig aus.

Die Cloud-Abhängigkeit betrifft meist die zentrale Einsatzsteuerung, Flottenkoordination, Kartenberechnung (SLAM), Sprachverarbeitung sowie Teleoperations-Schnittstellen. Ohne aktiven Serverkontakt verweigern viele Systeme bereits den Systemstart, da Lizenzprüfungen oder Token-Aktualisierungen ins Leere laufen.

Welche drastischen Folgen ein Server-Shutdown hat, zeigte sich bei Embodied: Nach der Geschäftsaufgabe im Dezember 2024 wurden die KI-gestützten Moxie-Roboter zum Preis von 799 US-Dollar für Kunden vollständig unbrauchbar, da alle Kernfunktionen an den Cloud-Servern des Herstellers hingen^[2]. Auch der Insolvenzantrag nach Chapter 11 des Traditionsherstellers iRobot im Dezember 2025 unterstreicht die anhaltende Volatilität auf den Robotikmärkten.

1. Kartenverwaltung und SLAM: Die Synchronisation neuer Etagenpläne und Sperrzonen schlägt fehl, wenn Kartendaten zentral in der Cloud gespeichert werden.
2. Aufzug- und Türen-Integration: Cloud-zu-Cloud-Schnittstellen zu Gebäudeleitsystemen werden unterbrochen, wodurch Roboter keine Stockwerke mehr wechseln können.
3. Aufgaben-Dispatching: Workflows aus externen ERP- oder Pflegedokumentationssystemen erreichen die Roboterflotte nicht mehr.
4. Teleoperation: Fernzugriffe zur manuellen Fehlerbehebung bei Blockaden im Flur brechen ohne Relayserver ab.

Klassische Quellcode-Hinterlegungen (Software Escrow) reichen in der Servicerobotik selten aus, um den Betrieb nach einer Herstellerpleite fortzuführen. Betreiber benötigen vertraglich zugesicherte Rechte zum vollständigen Aufbau und zur Ausführung der Software-Infrastruktur auf eigener Hardware.

Ein wirksamer Treuhandvertrag muss neben dem reinen Source Code auch Container-Images, Build-Skripte, Compiler-Toolchains, Konfigurationsdateien und private Signaturschlüssel umfassen. Nur mit diesen Komponenten kann ein internes Team oder ein unabhängiger Dienstleister Updates kompilieren und direkt auf die Geräte aufspielen.

Ebenso entscheidend ist die dauerhafte Sicherung der Datensouveränität. Raumkarten, Wegpunkte, Reinigungspläne und telemetrische Leistungsdaten müssen in offenen, standardisierten Formaten lokal exportierbar sein. Werden Kartenformate proprietär verschlüsselt, geht bei einem Herstellerausfall die gesamte Einrichtungsarbeit verloren und muss bei einem Systemwechsel von Grund auf neu durchgeführt werden.

Voraussetzungen für wirksame Software-Treuhand

• Vollständige Build-Umgebungen: Hinterlegung aller Skripte und Container, die zur Erzeugung lauffähiger Firmware-Binaries erforderlich sind.
• Firmware-Flash-Tools: Bereitstellung herstellerunabhängiger Werkzeuge zur lokalen Installation von Software über USB oder Service-Ports.
• API-Spezifikationen: Dokumentation aller internen Schnittstellen zwischen Navigationsmodul, Sensorik und Aktorik.
• Kryptografische Schlüssel: Treuhänderische Verwahrung von Root-Zertifikaten und Bootloader-Signaturen zur Entsperrung der Hardware.

Um sich gegen plötzliche Ausfälle abzusichern, müssen Betreiber bereits bei der Beschaffung präventive Klauseln in Kauf-, Miet- und Serviceverträge aufnehmen. Diese Klauseln definieren klare Notfallrechte bei Eintritt definierter Auslöser (Trigger Events) wie Zahlungsunfähigkeit, Geschäftsaufgabe oder nachhaltiger Verletzung von Service Level Agreements.

Dazu gehört eine mechanische Treuhandvereinbarung, die den Zugriff auf CAD-Zeichnungen, Schaltpläne, Stücklisten (BOM) und Pinbelegungen regelt. Betreiber erhalten dadurch das Recht, mechanische Verschleißteile im 3D-Druck oder über lokale Lohnfertiger nachzuproduzieren, ohne gewerbliche Schutzrechte zu verletzen.

Wichtige vertragliche Schutzmechanismen

• Eigenreparaturrecht: Explizite Erlaubnis zur Durchführung von Wartungen und Reparaturen durch eigene Techniker oder Drittanbieter ohne Verlust von Nutzungsrechten.
• Puffer für kritische Ersatzteile: Vereinbarung über ein obligatorisches Vor-Ort-Kontingent an Antriebsmotoren, Akkus und Hauptplatinen.
• Sonderkündigungsrecht für Leasingverträge: Kopplung des Hardware-Leasings an die tatsächliche Funktionsfähigkeit der Steuerungssoftware mit vorzeitiger Ausstiegsmöglichkeit bei OEM-Ausfall.
• Offene Diagnoseschnittstellen: Verpflichtung des Herstellers zur Bereitstellung lokaler Fehlerauslese-Tools ohne Cloud-Zwang.

Das größte Betriebsrisiko in der Servicerobotik entsteht durch eine monokulturelle Flottenstruktur. Setzt eine Pflegeeinrichtung oder ein Klinikverbund für Reinigung, Transport und Service ausschließlich auf die Modelle eines einzelnen Anbieters, führt dessen Insolvenz zum totalen Stillstand der Automatisierung.

Eine Multi-OEM-Strategie diversifiziert dieses Risiko, indem Aufgabenbereiche auf unterschiedliche Hersteller verteilt werden. Fällt ein Lieferant aus, bleibt der Großteil der betrieblichen Prozesse intakt, während betroffene Einheiten schrittweise ersetzt werden können.

Damit eine gemischte Flotte effizient gesteuert werden kann, ist der Einsatz offener Standards unerlässlich. Über standardisierte Protokolle und herstellerunabhängige Schnittstellen kommunizieren Roboter verschiedener Marken mit derselben Gebäudeinfrastruktur, teilen sich Aufzüge und koordinieren Fahrwege ohne Konflikte. Eine herstellerübergreifende Multi-Roboter-Plattform verhindert Silos und entkoppelt den operativen Betrieb vollständig von den proprietären Systemen einzelner Hardware-Produzenten.

Die langfristige Absicherung autonomer Flotten erfordert eine klare Trennung zwischen physischer Hardware und übergeordneter Betriebslogik. Eine neutrale Integrationsschicht schützt Betreiber vor Abhängigkeiten und stellt sicher, dass Workflows auch bei Marktbereinigungen unterbrechungsfrei weiterlaufen.

Hier setzt die werob Platform an: Sie fungiert als herstellerunabhängige Integrationsschicht, die Roboterhardware, Gebäudeleitsysteme und betriebliche Software nahtlos miteinander verbindet. Mit Werkzeugen wie der Spec Engine werden Einsatzabläufe präzise spezifiziert und in standardisierte Aktionsgraphen übersetzt, die flexibel auf verschiedene Robotermodelle übertragbar sind.

Über das zentrale Dashboard behalten Betreiber den vollständigen Überblick über den Status, Sicherheitszertifikate und Wartungszyklen aller eingesetzten Einheiten im werob Cockpit. Sollte ein Hersteller ausfallen, können bestehende Workflows ohne Neuprogrammierung der Gebäudeleittechnik auf alternative Robotermodelle umgeroutet werden. Mit flexiblen Beschaffungsmodellen wie Robot as a Service sichern Betreiber ihre Investitionen dauerhaft ab und gewährleisten maximale Ausfallsicherheit im täglichen Betrieb.