Was ist dokumentiert?
InOrbit beschreibt eine Plattform für den Roboterbetrieb und die Orchestrierung. Öffentlich dargestellt werden unter anderem Diagnose, Missionssteuerung und Fernintervention. [Quelle]
Systemansatz: Roboterbetrieb und übergreifende Orchestrierung.
Vertiefte Anbieterprüfung: 21. September 2026. Produktangaben sind unten belegt; Eignung und Projektplanung sind redaktionelle Einordnungen.
Betriebsumfang und Integration
Das Angebot verbindet Betriebsübersicht und Eingriffsmöglichkeiten mit Orchestrierung. BES ergänzt die Verbindung zur betrieblichen Planung; Missions erlaubt auch konfigurationsbasierte Definitionen. Diese Leistungsumfänge stellen unterschiedliche Integrationsanforderungen. [Quelle] [Quelle]
Meine Einordnung: besonders interessant, wenn ein breiteres Betriebswerkzeug die zusätzliche Konfiguration und klare Supportzuständigkeiten rechtfertigt. Für einen deutschen Mittelstandsstandort sollten Umsetzungspartner, lokale Supportzeiten, Reaktionszusagen und Datenhaltung konkret angeboten werden. Prüfen Sie eine unterbrochene Mission einschließlich Rückmeldung an das Ursprungssystem. Der Hauptsitz allein entscheidet nicht über die Servicequalität.
Warum fällt die Einordnung so aus?
Ich ordne die Plattform als prüfenswert ein, wenn die tägliche Betreuung mehrerer Roboter eine zentrale Herausforderung ist. Eine gemeinsame Betriebssicht kann helfen, Zustände und Eingriffe systematisch zu organisieren. Dieser Nutzen hängt aber davon ab, welche Informationen tatsächlich aus den Fahrzeugen ankommen und ob daraus konkrete Handlungen folgen. Ein übersichtliches Dashboard allein belegt noch keine wirksame Transportsteuerung.
Für die Auswahl zählt, ob diese Eigenschaft ein tatsächliches Problem im eigenen Betrieb löst. Eine bereits abgedeckte Funktion ist kein zusätzlicher Nutzen. Umgekehrt kann eine einzelne fehlende Pflichtfunktion den Einsatz verhindern, auch wenn andere Merkmale überzeugen.
Missionen und betriebliche Aufträge
InOrbit Missions beschreibt Missionsdefinitionen aus WMS-Daten oder Konfigurationsdokumenten wie JSON und YAML. Das Business Execution System (BES) adressiert die Umsetzung von ERP-/WMS-Aufträgen in Roboterarbeit. [Quelle]
Das sind unterschiedliche Ebenen. Eine Mission kann festlegen, was ein Roboter ausführen soll; ein betrieblicher Auftrag ergänzt, warum und wann diese Arbeit erforderlich ist. Für eine Auswahl muss klar sein, ob nur wiederholbare Fahrzeugaktionen oder eine vollständige Verbindung zur Produktions- und Lagerplanung gebraucht werden.
Die Möglichkeit, Missionen per Konfiguration zu definieren, spricht gegen eine pauschale Behauptung, jede Nutzung müsse mit einem WMS-Projekt beginnen. Sie beweist aber noch keinen fertig eingerichteten, bedienerfreundlichen Ablauf am konkreten Standort. Lassen Sie zeigen, wie ein Mitarbeiter eine Mission startet, ihren Zustand erkennt und eine abgebrochene Ausführung behandelt.
ERP/WMS-Anbindung und bestehende Flottensysteme
BES verbindet laut Hersteller betriebliche Systeme mit der Ausführung und berücksichtigt dabei Aufträge, Bestand und Fahrzeugfähigkeiten. InOrbit nennt außerdem mehrere Anbindungswege, darunter Agent, SDK, vorhandene Flottensteuerungen und Standards. [Quelle]
Für gewachsene Anlagen kann eine übergeordnete Ebene interessant sein, wenn die vorhandenen Fahrzeugsteuerungen bereits gut funktionieren. Dann muss nicht jede lokale Funktion zwingend ersetzt werden. Der zusätzliche Abstimmungsbedarf liegt an den Übergängen: Welche Ebene darf einen Auftrag umplanen, eine Ressource reservieren oder ein Fahrzeug anhalten?
Eine eigene ERP-Anwendung kann in einer solchen Architektur Datenlieferant bleiben. Prüfen Sie jedoch, ob die benötigten Daten rechtzeitig verfügbar sind und ob Auftragsrückmeldungen wieder in die bestehende Anwendung gelangen. Bei mehreren Ebenen muss eine durchgehende Auftragskennung die Zuordnung ermöglichen. Ohne sie können Meldungen zwar sichtbar sein, im Geschäftsprozess aber schwer zugeordnet werden.
Herstellerübergreifender Betrieb und Diagnose
InOrbit beschreibt Diagnose, Störungsanalyse und Fernintervention neben der Orchestrierung. Die Entwicklerseite nennt unterschiedliche technische Wege zur Einbindung von Robotern. [Quelle]
Meine Einordnung: Das ist besonders prüfenswert, wenn das Betriebsteam nicht nur Transporte auslösen, sondern wiederkehrende Probleme über verschiedene Fahrzeuge hinweg verstehen möchte. Ein brauchbarer Ablauf verbindet die Meldung mit dem betroffenen Auftrag, einer Zuständigkeit und einer dokumentierten Lösung. Die bloße Anzahl gesammelter Messwerte ist dafür kein ausreichendes Qualitätsmerkmal.
Für gemeinsame Wege muss gesondert geklärt werden, wie zentrale Entscheidungen mit den lokalen Flottensteuerungen zusammenwirken. Eine Anzeige aller Positionen ist noch keine nachgewiesene Konfliktregelung. Lassen Sie einen Konflikt zwischen zwei unterschiedlichen Steuerungsbereichen erzeugen und prüfen Sie, wer die Entscheidung trifft und wie beide Seiten sie bestätigen.
Betriebsmodell und Eignung für kleinere Teams
Vor der Auswahl sollte das benötigte Paket eindeutig abgegrenzt werden: Beobachtung, Missionssteuerung, betriebliche Orchestrierung und Fernunterstützung können unterschiedliche Anforderungen an Einrichtung und Personal stellen. Welche Funktionen im Angebot enthalten sind und welche ergänzt werden müssen, ist eine konkrete Angebotsfrage.
Für kleine Teams liegt der mögliche Nutzen in einer gemeinsamen Sicht auf den Betrieb und nachvollziehbaren Eingriffen. Dem steht die Frage gegenüber, wer Konfigurationen pflegt und Diagnoseergebnisse tatsächlich bearbeitet. Eine leistungsfähige Datenplattform erzeugt keinen automatischen Nutzen, wenn im Betrieb niemand für die daraus entstehenden Aufgaben zuständig ist.
Prüfen Sie bei Fernzugriffen Rollen, Freigaben, Protokollierung und das Verhalten ohne Verbindung. Legen Sie fest, welche Funktionen lokal weiterlaufen und wie zwischengespeicherte Zustände später abgeglichen werden. Diese Punkte sind Prüffragen an die angebotene Lösung, keine Behauptung einer festgestellten Schwäche.
Welche Grenzen hat die Bewertung?
Bei der Auswahl muss zwischen Beobachtung, Auftragskoordination, Verkehrssteuerung und fahrzeugseitiger Navigation unterschieden werden. Für den eigenen Prozess ist festzulegen, welche Ebene InOrbit übernimmt und welche anderen Systeme erforderlich bleiben. Auch der Datenzugriff, mögliche Fernzugriffe und Verantwortlichkeiten bei Aktualisierungen gehören in die Prüfung.
Die grundsätzliche Ausrichtung auf Roboterbetrieb ist öffentlich beschrieben. Daraus leite ich keine pauschale Aussage über alle Fahrzeugadapter, lokale Verkehrsregelung oder standortübergreifende Betriebsmodelle ab.
In welchem Beispiel wäre die Lösung sinnvoll?
Ein Betreiber möchte Störungen und Auftragszustände über mehrere Roboter hinweg nachvollziehen. Der Nutzen entsteht dann, wenn das Betriebsteam daraus eine eindeutige Zuständigkeit und einen kontrollierten Wiederanlauf ableiten kann.
Das ist ein konstruiertes Entscheidungsszenario, keine Kundenreferenz. Es beschreibt die Bedingungen, unter denen die Prüfung sinnvoll ist; es behauptet keinen bereits erreichten Projekterfolg.
Was sollte die Vorführung beweisen?
Erzeugen Sie eine Störung an einem Fahrzeug. Verfolgen Sie Meldung, Zuordnung, Eingriff und Abschluss im System. Prüfen Sie außerdem, welche Daten bei einer Verbindungsunterbrechung verfügbar bleiben und wie der Zustand anschließend abgeglichen wird.
- Ausgangszustand und erwartetes Ergebnis vor der Vorführung schriftlich festlegen.
- Erfolgreiche Ausführung und Fehlerbehandlung getrennt protokollieren.
- Notwendige manuelle Eingriffe und beteiligte Systeme benennen.
- Festhalten, ob der gezeigte Funktionsumfang Bestandteil des vorgesehenen Lieferumfangs ist.
Welche Alternative sollte mitgeprüft werden?
Vergleichen Sie die Lösung sowohl mit der vorhandenen Steuerung als auch mit dem für die geplante Fahrzeuglandschaft passenden Alternativansatz. Ein Wechsel muss eine konkrete Lücke schließen; eine zusätzliche Plattform sollte keine unnötige Doppelverwaltung erzeugen.
Praktische Prüfschritte
| Prüfschritt | Beobachtung | Entscheidungsgrund |
|---|---|---|
| Normalablauf | Auftrag von der Entstehung bis zur bestätigten Übergabe verfolgen. | Alle beteiligten Systeme zeigen denselben fachlichen Zustand. |
| Störung | Last fehlt, Ziel ist belegt oder die Verbindung wird unterbrochen. | Keine unbemerkte Doppelbeauftragung; Wiederaufnahme ist für das Bedienpersonal nachvollziehbar. |
| Änderung | Station, Priorität oder zulässigen Fahrzeugtyp anpassen. | Erforderliche Rollen, externe Hilfe und erneute Prüfungen werden sichtbar. |
| Erweiterung | Ein weiteres Fahrzeug oder eine neue Auftragsquelle planen. | Zusätzliche Schnittstellen und Verantwortlichkeiten sind konkret beschrieben. |
Weiterführend: ERP/WMS, Eigenentwicklungen und Altsysteme anbinden.
Quellen & Einordnung
Prüfstand: 18. September 2026. Herstellerinformationen sind Anbieterbeschreibungen. Die redaktionelle Empfehlung ist kein unabhängiger Produkttest.
- InOrbit: ProductRoboterbetrieb und übergreifende Steuerung.
- InOrbit: MissionsMissionsdefinition, Ausführung und Auswertung; Konfiguration und WMS als unterschiedliche Eingänge.
- InOrbit: Business Execution SystemVerbindung betrieblicher Aufträge aus ERP/WMS mit Robotermissionen.
- InOrbit: Entwickler und InteroperabilitätAgent, SDK, vorhandene Flottensteuerungen und verschiedene Interoperabilitätsstandards.
- Idealworks: AboutIdealworks OS wird als Nachfolger von AnyFleet bezeichnet.
- Idealworks: Automation with the Robotics EcosystemThird-party robot partners; historical 2024 article, reviewed 2026-09-21.
- Idealworks: Pallet transportTransport configurations and local or enterprise mission triggers; reviewed 2026-09-21.
- Idealworks: Floor-to-Station Pallet TransportPublished lifting envelope; reviewed 2026-09-21.
- InOrbit: Company headquarters and operationsMountain View headquarters; reviewed 2026-09-21.
- InOrbit: Collaboration with KärcherHistorical partnership announcement; not a geographic customer breakdown. Reviewed 2026-09-21.
- SYNAOS: Warehouse ExecutionExecution scope alongside fleet management; reviewed 2026-09-21.
- SYNAOS: Intralogistics PlatformVendor-reported fleet scale and platform scope; reviewed 2026-09-21.
- SYNAOS: IntegrationsmöglichkeitenAnbindung vorhandener ERP-, WMS- und WCS-Systeme sowie individueller Schnittstellen.
- SYNAOS Academy: Frequently asked questionsAuftragsauslöser ohne ERP/WMS und Schnittstellen. Nicht durchgehend versionierte FAQ; aktuellen Lieferumfang bestätigen lassen.