Technical architecture

Edge-first observability, not another control system.

RobotOps runs as a small edge gateway on the same network as your robots and WMS. It ingests the telemetry you already have access to—APIs, topics, logs, and reports—normalizes it into a vendor-neutral model, and pushes summarized signals into the cloud for fleet-wide analytics. It never sits in the robot control loop.

This page is for engineers, integrators, and reliability teams who want to understand exactly where RobotOps runs, how it moves data, and what it does and does not do.

High-level flow

At a high level, RobotOps follows a simple edge-first pattern:

Collect telemetry from vendor APIs, message buses, logs, and reports on your own network.
Normalize that telemetry into a unified schema for robots, missions, incidents, and sites.
Summarize and enrich signals at the edge (health, anomalies, counters, aggregates).
Send low-rate, vendor-neutral metrics and events to the cloud for dashboards, alerts, and analytics.

The edge gateway does feature extraction and buffering; the cloud focuses on cross-fleet visibility, historical analysis, reliability metrics, and alert routing.

Edge gateway responsibilities

The edge gateway runs on-premise, typically on an industrial PC or VM in the same VLAN as your robots and WMS.

Connects to vendor APIs and webhooks for robot state, missions, alarms, and battery.
Subscribes to message buses you already operate (MQTT, Kafka, etc.) for robot and mission events.
Ingests logs, DB tables, and batch exports from OEM systems.
Performs lightweight aggregation (counters, rates, rolling windows, anomaly flags).
Buffers telemetry locally so short network blips do not cause data loss.

RobotOps does not packet-sniff proprietary protocols or bypass OEM safety layers. If an OEM exposes no telemetry, we show that gap instead of pretending it is observable.

Cloud responsibilities

The cloud turns normalized signals into fleet-wide observability:

Multi-site, multi-vendor time series for robot, mission, and incident metrics.
Health and reliability scores (MTBF, MTTR, fault rates, stranded events) per robot/vendor/site.
Performance views for throughput, queue times, blocked time, and idle vs. productive time.
Incident detection based on patterns in telemetry, not raw fault codes.
APIs and export endpoints for data warehouses or BI tools.

Telemetry model & observability primitives

RobotOps builds a vendor-neutral model on top of the signals you already own.

Robots — identity, vendor, model, site, capabilities, lifecycle state.
Missions / work units — tasks, orders, jobs moving through your facility.
Health — faults, aborted missions, stranded robots, MTBF/MTTR.
Performance — missions per hour, queue times, blocked vs. productive time.
Environment & infra — charging behavior, Wi-Fi issues, congestion paths.
Incidents — derived objects that tell operators “this robot/site needs attention now.”

These primitives power dashboards, alerts, and APIs for operations and reliability teams.

Integration patterns

RobotOps fits into your existing integrations without replacing them.

HTTP / REST APIs — pull robot, mission, fault data from OEMs.
MQTT / Kafka topics — subscribe to robot and mission streams.
Batch exports — watch folders or S3 for CSV/Parquet data.
WMS / WES bridges — correlate robot activity with orders and dock activity.
Custom adapters — send normalized events instead of raw protocols.

The goal is one vendor-neutral telemetry layer, so you can decide without rewriting every integration.

Safety and non-control path

RobotOps is observability-first—never a control system.

Does not send commands to robots or intervene safety loops.
Does not require routing mission traffic through a new orchestrator.
Connects only to telemetry interfaces and data exhaust.
Keeps control logic and PLCs out of scope.
Provides evidence to negotiate data access with OEMs.

For engineers & integrators

RobotOps is transparent and extensible for integration and automation teams.

What you configure

Data sources (APIs, topics, batch feeds).
Mapping into the RobotOps schema.
Metrics, tags, health signals for your team.
Alert routing destinations.

What you can extend

Custom connectors that emit normalized telemetry.
Derived health/performance metrics.
Export jobs to your lakehouse or BI stack.

What we intentionally don't do

We do not replace your WMS, WES, or robot orchestration platforms.
We do not own your control loops or safety systems.
We do not promise full coverage where OEMs expose no telemetry.

RobotOps stays focused on visibility and reliability.