InOrbit: assessment and use cases

What is documented?

InOrbit describes operational visibility, mission management, diagnostics, remote intervention and orchestration. Missions can be defined from configuration, while BES connects business orders to robot execution. [Source]

Focused vendor review: 21 September 2026. Product facts are linked below; suitability and project-planning recommendations are editorial assessments.

Operational scope and integration

The offering combines operational visibility and intervention with orchestration. BES adds the connection to business planning; Missions also accepts configuration-based definitions. These are different scopes of work, with different integration requirements. [Source] [Source]

My assessment: a strong candidate when a broader operational toolkit can justify additional configuration and support ownership. For SMEs in Germany, request named implementation contacts, support hours in the local time zone, response commitments and the offered data-hosting region. Test an interrupted mission and the return of its final status to the originating system. Headquarters alone does not settle service quality.

Why this assessment?

A common operational view can be useful when daily support of several robots is the main challenge. Its value depends on the data actually received and on whether the team can turn it into an accountable action. An attractive dashboard by itself is not evidence of effective material-flow control.

A capability matters when it solves a real problem in the intended operation. A function already covered elsewhere adds little, while one missing mandatory requirement can rule out an otherwise capable system.

Missions and business orders

InOrbit Missions describes definitions supplied through a WMS or configuration documents such as JSON and YAML. BES addresses the conversion of ERP/WMS work into physical robot tasks. [Source]

These are different layers. A mission describes what a robot should do; the business order adds why and when it is required. Decide whether the project needs repeatable vehicle actions or a continuous connection to production and inventory planning.

Configuration-based mission definition is a reason not to assume every deployment must begin with a WMS project. It does not prove that a complete operator-friendly workflow is already configured for the site. Ask an operator to start, monitor and recover a mission using the proposed interface.

ERP/WMS and existing fleet systems

BES describes coordination between enterprise orders and robot execution. InOrbit also documents several connection routes, including an agent, SDK, existing fleet software and interoperability standards. [Source] [Source]

A supervisory layer can be relevant in an established plant where local vehicle controllers already work well. Local functions may remain in place, while coordination crosses their boundaries. The additional work lies in deciding which layer may reschedule an order, reserve a shared resource or intervene in execution.

An in-house ERP can remain a data source if it provides the required information in time and accepts execution feedback. A consistent order identifier should connect the layers. Without one, an event can be visible on a dashboard yet difficult to reconcile with the original business request.

Cross-vendor operations and fault diagnosis

The operational tooling is relevant when the team needs to investigate recurring incidents rather than merely launch transports. An effective workflow links the notification to an order, a responsible person and a recorded resolution. The number of captured data points alone is a poor measure of that usefulness.

For shared routes, verify how supervisory decisions interact with local fleet controllers. Displaying every robot’s position is not the same as demonstrating conflict resolution. Create a conflict involving robots from two different control areas and identify who decides, who acknowledges and what happens if one side does not respond.

Remote intervention should also return the robot to a known mission state. After helping a robot move around an obstacle, the operator must know whether its load, destination and remaining work still match the order.

Deployment scope and small operational teams

Clarify the required package before comparing proposals. Observability, missions, business orchestration and remote assistance can introduce different setup and staffing needs. Confirm included capabilities and any additional components rather than treating the platform name as a complete specification.

For a small team, a shared operational view can simplify coordination, but someone must still maintain configurations and act on findings. A capable data platform does not produce an operational benefit when no one owns the resulting tasks.

For remote access, check roles, approval, logging and disconnected operation. Agree which functions continue locally and how stored events are reconciled afterwards. These are procurement questions, not claims that a particular deficiency has been found.

Limits of the assessment

Distinguish monitoring, mission dispatch, traffic coordination and vehicle navigation. Define which layer InOrbit supplies and which local systems remain necessary. Also confirm the modules and adapters included in the proposal.

This assessment uses manufacturer information and editorial analysis, not a controlled head-to-head product test. Confirm the vehicle, version and operating scope in the actual proposal.

Example decision scenario

An operator needs to trace faults and mission states across different robots and turn them into clear responsibilities and a controlled restart.

This is an illustrative procurement scenario, not a claimed customer deployment. It describes conditions worth testing rather than a result already achieved.

What should a demonstration establish?

Create a vehicle fault and follow notification, assignment, intervention and closure. Disconnect the link, inspect available information and check how state is reconciled afterwards.

Agree the initial state and expected result before the test.
Record successful work and fault recovery separately.
Identify manual intervention and each participating system.
Confirm that the demonstrated functions are part of the offered scope.

Which alternatives should also be considered?

Compare the proposal with the current controller and with the alternative architecture suited to the planned fleet. A switch should close a real gap; an additional layer should have a clear responsibility.

Compare use cases and alternatives.

Practical checks

Acceptance evidence from your own process
Test	Observe	Decision criterion
Normal operation	Follow the order through physical handover.	The participating systems agree on its business state.
Disruption	Remove a load, occupy a destination or interrupt a connection.	No unintended duplicate work; recovery is understandable.
Change	Modify a station, priority or permitted vehicle type.	Required permissions and external assistance are visible.
Expansion	Plan another vehicle or order source.	Additional interfaces and ownership are identified.

ERP/WMS and legacy-system integration guide.

Sources and context

Base review: 18 September 2026. Focused vendor review: 21 September 2026. Manufacturer information is not an independent comparative test.