Industrial Data Platform: What It Is and How to Build One

An industrial data platform is the architectural layer that captures data from machines, sensors and plant systems, normalises it at the source and makes it available to any business application (MES, ERP, dashboards, AI models) through a single point of access. It is not a product you buy, but an architecture you build in layers: edge, broker, data layer and consumption. In this guide we look at what distinguishes it from an MES, a SCADA or a historian, how it is assembled without replacing what already works, and when it makes sense for an industrial SME.

What an industrial data platform is

In most plants, the data exists but does not circulate. The PLC counts parts, the drive knows the energy consumption, the vision system knows which batch passed inspection; each stores it in its own format, on its own network, at its own pace. When the business needs that information to calculate an OEE, close out a production order or feed a maintenance model, someone extracts it by hand, copies it via USB or builds a point-to-point integration that breaks with the next change.

The industrial data platform (sometimes called an industrial IoT platform or IIoT platform) is the architectural answer to that problem. Its statement fits in one sentence: data is captured once, normalised once and consumed as many times as needed. Everything else is machinery in service of that idea: protocols, brokers, databases, dashboards.

Three properties define a well-built platform:

• Decoupling. Producers and consumers do not know each other; both talk to the platform. Adding a new application does not touch the machines, and adding a machine does not touch the applications.
• Normalisation at the source. Units, scales, business names and timestamps are resolved at the edge, once, instead of being reinterpreted in each consumer.
• Technology neutrality. The platform imposes no brand of PLC, sensor or ERP: it translates what is there. That is why it can coexist with a machine fleet spanning several decades and several manufacturers.

Platform vs MES vs SCADA vs historian

The most common confusion when evaluating an industrial data platform is comparing it with systems that solve something else. All four coexist, but each occupies a different place:

The SCADA supervises and controls the process. It is the operator's tool: mimic screens, alarms, setpoints, real-time command over a line or an installation. Its horizon is immediate operation and its scope is the OT network. A SCADA is not designed to serve data to twenty corporate applications, and forcing it into that role turns it into a bottleneck. In the platform, the SCADA is one more producer and consumer, not the backbone; its development remains a discipline of its own, that of PLC, SCADA and HMI programming.

The MES manages production execution. Work orders, batch traceability, quality management, resource allocation: the MES lives between the ERP and the shop floor and its unit of work is the order, not the signal. An MES needs machine data to work well, and that is where the platform serves it: instead of the MES integrating machine by machine, it subscribes to data that is already normalised.

The historian stores process time series. It is a database optimised for writing millions of timestamped values and querying them later. It is a valuable piece, but it is storage, not distribution: the classic historian keeps the data, it does not move it in real time to whoever needs it. In a platform architecture, the historian is a consumer that subscribes and persists.

The platform is the circulatory system. It does not supervise the process, it does not manage orders and it is not a warehouse: it connects all of the above to each other and to the rest of the business. The practical test for telling it apart is asking what happens when you add a new consumer: if you have to open another integration against the SCADA, the MES or the historian, there is no platform; if subscribing is enough, there is.

Architecture: from edge to consumption

A modern industrial data platform is organised in four layers, and the discipline of keeping them separate is what makes it maintainable. The distribution pattern that binds them is the unified namespace: a single topic tree where everything is published and from which everything is consumed. We dedicate a full guide to it, unified namespace and MQTT Sparkplug B, and here we place it within the whole.

This layered organisation is, in practice, the plant's manufacturing data architecture: the complete journey from the moment the PLC produces a value until a dashboard or a model consumes it. What holds it together is not any tool, but a canonical data model: an agreed asset hierarchy (plant, area, line, machine, signal) and a signal dictionary with the same business name, unit and semantics across all equivalent machines. That model is decided before connecting the second machine and is the same across all four layers; the process of enriching each value with it is developed in the guide to industrial data contextualisation.

Layer 1: the edge, where data is born

Edge gateways live in the OT network, close to the machines, and do the work no other layer can do: speak each machine's language. A single project may require reading Modbus from a veteran PLC, OPC UA from a recent machine, a robot's proprietary API and a hardwired analogue signal. That variety is the territory of PLC connectivity, sensor connectivity, robot connectivity and machine vision connectivity.

Beyond translating, the edge validates, adds a source timestamp and unit, and stores in a persistent local buffer so that a network outage does not open gaps in the historian. That combination of capture, normalisation, buffering and publishing is what in our catalogue we call edge ingestion, and its sizing details are in the guide to industrial edge with buffering and QoS.

Layer 2: the broker, the backbone

The MQTT broker is the meeting point: gateways publish to it and consumers subscribe to it. With Sparkplug B on top, each node announces its state and its typed metrics, and any consumer knows whether a value is live or stale information. Connecting each system to the broker, the MQTT integration, is a bounded project precisely because the contract is always the same: the namespace. Designing that bridge between the plant network and corporate systems is the core of OT/IT integration.

Layer 3: the data layer

From the broker, data moves on to persistence and refinement: a time-series database or plant data historian for process detail, an analytical store for aggregates and indicators, and the transformations that turn raw signals into functional business data (line status, counters per shift, OEE). As business consumers appear, each published dataset is best treated as an explicit contract of schema, units and frequency; we develop that step in the guide to industrial data contracts.

Layer 4: consumption and applications

At the very top sit the applications that justify the investment: plant dashboards, the MES, the analytical models and, with a suitable connector, the ERP. ERP integration stops being the dreaded project of the year because the ERP no longer talks to twenty machines: it talks to the platform. And when two systems from different vendors have to exchange data with each other, the platform is the neutral ground that makes industrial interoperability possible without coupling them directly.

How it is built without rip-and-replace

The most reasonable objection to any platform is the fear of replacement: nobody is going to stop production to swap out systems that work. The good news is that the architecture described does not ask for that. The platform is built alongside what exists, not on top of its ruins:

• The machines are not touched. The edge gateway listens to them over the protocol they already speak and publishes on their behalf. A PLC from the nineties participates just like a new machine.
• Existing systems are not switched off. The SCADA keeps supervising, the MES keeps managing orders and the old historian keeps recording while the new data is validated in parallel. Only when the platform proves it serves the same data better is each old integration retired, one by one and with no forced deadline.
• Rollout is incremental. You start with one line or one area with clear value, validate the pattern end to end and scale. Connecting machine twenty costs a fraction of what the first one cost, because the architecture already exists.
• The gateway only listens. It does not write setpoints and does not interfere with control: the operational risk of the capture phase is minimal, and production continues even if the broker, the WAN or the entire IT layer disappears.

Common mistakes when building the platform

Starting with the dashboard. It is tempting to buy the visualisation tool first and "connect the machines later". The result is dashboards fed with manual extracts that nobody maintains. The correct order is bottom-up: reliable data first, consumption second.

Confusing platform with product. No software installed in one go turns a plant into a connected plant. Products (brokers, databases, visualisation tools) are pieces; the platform is the design that binds them and the decisions on names, contracts and ownership that govern it.

Skipping naming governance. A namespace without a written, agreed convention degenerates into the same chaos it was meant to solve, just inside a broker. The hierarchy is agreed before connecting the second machine, not after the twentieth.

Ignoring buffering. A platform that loses data every time the network blinks is not a platform: it is a demo. Persistent store-and-forward at the edge is not optional if the historian has to be complete.

"Provisional" point-to-point integrations. Every direct connector opened "just for now" between two systems is debt the platform will have to absorb later. The discipline of routing everything through the namespace is uncomfortable the first week and profitable every year after.

Leaving security for the end. Connecting the OT network to corporate systems widens the exposure surface if done carelessly. Outbound connections with TLS, authentication and zone segmentation are part of the design from day one; the guide to zero trust in industrial OT walks through that approach.

When it makes sense for an SME

An industrial data platform sounds like a large-corporation project, but the architecture scales down better than the alternatives. For an SME, the question is not whether it can afford a platform, but whether it can afford the opposite pattern: every point-to-point integration signed today is a recurring maintenance cost tomorrow.

It also helps to name the goal properly. What most SMEs are after when they say they want to centralise production data is not a new system that replaces the ERP or the MES, but exactly what this guide describes: a single point where data from machines, meters and existing systems is captured once and made available to everyone, with no rip-and-replace and without tying the plant to a single vendor. The platform is the way to centralise without starting over.

Signs that the moment has arrived:

• Data is already requested and copied by hand. If someone fills in production reports in a spreadsheet or exports CSVs from the SCADA every week, the demand for data exists; only the channel is missing.
• More than one initiative is waiting for the same data. A management dashboard, an OEE calculation and a maintenance project that need the same signals justify capturing them once, well, instead of three times, poorly.
• The ERP or the MES is asking for plant data. When integration with business systems is already on the table, doing it against a platform costs about the same as doing it point to point, and it leaves reusable infrastructure behind instead of another fragile connector.

The key for an SME is the entry scope: you do not need to connect the whole plant to have a platform. One gateway, one well-configured broker, an agreed naming hierarchy and one line connected end to end already are an industrial data platform: small, but with the right architecture. Growing from there means adding branches to the tree, not redesigning. Starting big with improvised names, on the other hand, does not scale at any size.

Frequently asked questions about industrial data platforms

If you are weighing up how to turn your plant's scattered data into a single foundation for production, maintenance and business, at Captia Connect we build exactly this architecture: from edge ingestion and OT/IT integration to the connection with your business systems. You can see how we build it with Captia Connect and Captia.ai on our industrial data platform page. The first step is a mapping of what you have and where the first value lies.