Unified data infrastructure
GitHub Let's talk

Robotics

Fleets, telemetry and control decisions in one layer.

Robots produce high-rate state and low-rate outcomes: what the joints are doing, and what the task actually accomplished. Both matter, and neither is useful alone.

See Equipment Intelligence All of Industrial

A failed cycle resolved to the motion trace that caused it.

The story

A failed cycle resolved to the motion trace that caused it.

Where it starts

Robot state and motion

Joint positions, velocities, forces and controller state. It is the first of 4 workloads running in Robotics.

The question it raises

Outcome to trace

A failed cycle resolves to the motion trace that caused it, because both belong to the same run record.

Why one question is hard

From Configuration to Fleet

Robotics data moves through 4 stages — Configuration → Motion → Task → Fleet. The shapes in play are Time series, SQL, Events, JSON / documents, and answering one question means reading across all of them.

What PLOMID contributes

A fleet is many producers writing one truth. These are the parts that make that practical.

  • Time-ordered storage Measurements and events are stored beside the records and documents they describe, so history and current state agree.
  • One plan per request A request is planned once against the layer rather than per system, which is where cross-system glue usually accumulates.
  • Deployment is a decision Self-hosted, edge and managed topologies are design destinations of the deployment fabric, and the fabric is specified as its own part of the platform.
The environment

Robot state, motion traces, task outcomes and fleet coordination.

Motion and state data is a dense time series attached to a robot identifier. Task outcomes, exceptions and operator interventions are events with meaning. PLOMID keeps the trace and the outcome in one layer, so a fleet question resolves to the specific run that produced it.

One environment · many workloads

What runs against robotics data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

Joint positions, velocities, forces and controller state.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
The data journey

How robotics data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

A failed cycle resolved to the motion trace that caused it.

Environment

The cell

A robot cell with its tooling, calibration and controller.

SQL

Where the data goes to work

Questions the field asks daily.

Each one is a workload over the shapes above, answered from the same layer rather than from a purpose-built copy.

Outcome to trace

A failed cycle resolves to the motion trace that caused it, because both belong to the same run record.

  • SQL
  • JSON / documents

Utilisation honestly measured

Task outcomes are records rather than inferred states, so utilisation is computed from what actually completed.

  • Time series

Version-aware behaviour

Software version and calibration live beside the trace, which is what makes a behaviour change attributable.

  • Events
  • SQL

Fleet-level reads

One layer answers across cells instead of per cell controller exports.

  • SQL
  • Time series
Data models in play

The shapes, in one layer.

4 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Robotics configuration · motion · task · fleet Select a stage
Stage

Configuration

Cell layout, tooling and calibration records

SQL · JSON / documents

Workload map Robotics workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • Time series Measurements and events in time order
  • SQL Records, keys and joins
  • Events Operational events as they happen
  • JSON / documents Documents and nested objects
Workload architecture

Which workload touches which model.

The work, the shapes it names and the path a request takes — from the field to the control room.

Robotics · workload architecture
Workloads

What runs against this data.

  • Robot state and motion
  • Task outcomes
  • Fleet configuration
  • Intervention logs
Data models

The shapes those workloads read and write.

  • Time series
  • SQL
  • Events
  • JSON / documents
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
Deployment & residency

Where this data is allowed to run.

Coordinating a fleet means reads close to the cell, with the fleet record centralised.

Deployment, residency and control
What you build next

Equipment Intelligence

Machine state, component history and maintenance action in one place.

If Outcome to trace is your question, start here.

See Equipment Intelligence Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.