Industrial Data — Acquiring, storing and using machine data

Machines and sensors produce data constantly — temperatures, pressures, flows, speeds, states, counts, vibration. On its own, that data is fleeting: a value that is true for a moment and then gone. Industrial data work is about reliably getting that data off the equipment, keeping it without gaps, and turning it into something you can look back on and reason with.

The idea sounds simple. The difficulty is in the details: equipment speaks many different protocols, data can arrive faster than it can be casually handled, a dropped sample can hide the very event you needed to see, and querying months of history has to stay fast. Getting those right is the engineering.

What industrial data is

Industrial (or “operational”) data is what plant equipment, controllers and sensors generate as they run. It is usually time-series data — a value paired with a timestamp — produced by many heterogeneous sources: PLCs, sensors, drives, meters, instruments and machines. Some of it changes slowly (a daily total); some changes thousands of times a second (vibration, electrical signals). Handling that range is part of the problem.

How it works: the pipeline

Most industrial-data systems are a pipeline from the equipment to the people and tools that use the data.

Sources and protocols

Equipment rarely speaks one common language. Three protocols show up constantly:

Modbus — a long-established protocol used over serial links and TCP. It exposes coils/discrete values and registers, but carries relatively little semantic context compared with richer information models.
OPC UA — a modern industrial interoperability standard with a structured, self-describing address space, data typing and built-in security. It is heavier than Modbus but far richer, and is designed for cross-vendor interoperability.
MQTT — a lightweight publish/subscribe messaging protocol built around a broker. It suits many devices reporting over unreliable networks, and is common at the edge and in IoT. MQTT carries the message; a payload convention on top defines what the data means.

Acquisition, buffering, storage, access

Acquisition reads from those sources — either by polling (asking on a schedule) or by subscription (being told when values change) — and timestamps what it reads.
Buffering absorbs bursts and network interruptions so that a momentary outage does not become lost data.
Storage keeps the history. Time-series databases and process historians are designed for timestamped data, often with compression and retention policies. Where every sample matters, the acquisition and storage path must be explicitly designed and verified for lossless capture rather than assuming the historian preserves everything.
Access is where the value is realised: historical playback, queries, trend charts, dashboards, and feeding analysis or machine-learning tools.

What it enables

Once the data is captured and kept, it supports things live readings alone cannot:

Look back — replay exactly what the equipment was doing in the seconds before a fault, instead of guessing.
Trend and compare — see drift, cycles and slow degradation over weeks or months.
Support condition-based and predictive maintenance — preserve trends and patterns that may indicate degradation before failure.
Optimise and report — quantify throughput, energy use, downtime and quality.
Feed analytics — provide the clean, historical basis that any analysis or model depends on.

The hard parts

This is where industrial-data projects succeed or struggle:

Rate and volume. High-rate sources produce enormous amounts of data; the system must keep up at capture time and stay queryable afterwards.
Not losing anything. Lossless capture and buffering across outages matter most precisely when something is going wrong — the moment you most want the data.
Accurate time. Correlating sources requires trustworthy, synchronised timestamps; without them, ordering and cause-and-effect blur.
Meaning, not just numbers. A raw register value is not self-describing; context (units, scaling, what it represents) has to be carried alongside it.
Retention vs. cost. How much history, at what resolution, for how long, is a deliberate trade-off.
Security. Operational networks control physical processes. Acquisition should read without weakening segmentation or exposing control systems (see NIST SP 800-82).

Representative applications

The same capability — capture, keep, and make usable — applies across domains:

Manufacturing: line monitoring, quality and downtime analysis, maintenance.
Energy and utilities: generation, distribution and metering data.
Water and infrastructure: pumps, flows, levels and remote sites.
Buildings and facilities: HVAC, energy and equipment monitoring.
Marine and vessels: machinery and sensor data at sea, often with intermittent connectivity.
Test rigs and R&D: high-rate data acquisition for experiments and development.

These are examples, not a fixed list — anywhere equipment produces data worth keeping is a candidate.

Combining with other technologies

With edge computing: acquire, buffer and even pre-process data near the source, so a network gap does not lose data and only what matters travels onward.
With analytics and machine learning: a clean, lossless history is the foundation detection, prediction and optimisation are built on.
With imaging and sensing: correlating process data with images or other sensors (for example, timestamped visual inspection alongside machine data) gives a fuller picture than either alone.

Limitations and cautions

Captured data is only as good as its timestamps, units and context — poor metadata makes a large archive hard to trust or use.
Lossy shortcuts (aggressive sampling or averaging at capture) can quietly discard the transient events that mattered; whether that is acceptable is a deliberate decision, not a default.
More data is not automatically more insight — retention and resolution should match the questions being asked.
Reading from operational systems must respect OT security and safety; data collection should never become a path into control.

Example explored by Mansonix

Nexora is a Mansonix product in development for high-rate industrial data acquisition, storage and playback. It is being built to take in high-volume sensor and machine data from sources such as Modbus, OPC UA and MQTT, with lossless capture, efficient storage and fast historical playback, feeding a UI and analysis path.

The way these parts fit together is shown as an architecture diagram on the Products page. That diagram is explanatory — it describes the intended design, not a measured benchmark. No throughput, latency or capacity figures are claimed here; those are the kind of results that need real, reproducible measurement before they are stated.

Sources & further reading

The protocols and concepts above are defined by their standards bodies and covered in depth in data-systems literature:

Modbus Organization, Modbus Application Protocol Specification — the Modbus standard.
OPC Foundation, OPC Unified Architecture (OPC UA) Specifications — the OPC UA standard.
OASIS, MQTT (also at mqtt.org) — the MQTT messaging standard.
Kleppmann, M., Designing Data-Intensive Applications, O’Reilly, 2017 — storage, time-series and streaming data fundamentals.
NIST, SP 800-82: Guide to Operational Technology (OT) Security — securing the systems industrial data is read from.