Manufacturing & Maintenance 9 min read

Shop floor data integration: getting machine data into the systems that decide things.

Collecting the data is the easy half. Landing it — reliably, in a shape ERP, BI and people can use — is where most projects quietly stop.

By Frank Guo · Technology & Product Leadership, addanode

TL;DR — Shop floor data integration is the layer between machines and the systems that make decisions (ERP, MES, BI, maintenance). There are four practical methods: direct protocol reads (Modbus, OPC-UA, vendor drivers), an edge gateway that normalises and buffers, a broker or middleware layer (typically MQTT, often organised as a unified namespace), and file or database bridges for systems that offer nothing better. A workable architecture keeps three rules: read-only at the controller, buffer at the edge so an outage costs no data, and one canonical name per signal so "Line 1 count" means the same thing in every downstream system. The most expensive mistake is integrating to a single vendor's cloud with no local buffer — under South African conditions that architecture loses data every time the link or the power drops.

Why integration, not collection, is where projects stall

Most plants can get a number off a machine. What breaks is everything after that: the number arrives in a format nobody agreed on, under a name that means something different in the ERP, at a moment when the network was down, and with no way to tell a missing reading from a zero. Six months later there are three sources of truth for production count and a standing argument about which is right.

That is an integration problem, not a sensor problem. It is worth separating clearly from shop floor data collection, which is about getting a trustworthy signal in the first place. Collection asks "is this number real?" Integration asks "can every system that needs this number get it, name it the same way, and know when it is missing?"

The distinction drawn above, side by side. Collection asks whether the number is real; integration asks whether everyone can agree on it — and it is the second question that is still open six months later.

The four integration methods

Method	When it fits	What it costs you
Direct protocol read Modbus TCP/RTU, OPC-UA, EtherNet/IP, vendor drivers	The machine has an accessible controller and you want the least translation between reality and record.	Tag-by-tag mapping work, and a dependency on someone documenting what each tag means.
Edge gateway	Almost always. It normalises mixed protocols, buffers through outages, and keeps the plant network separate from anything outbound.	Hardware per area, and a configuration that must be version-controlled rather than living in one engineer's head.
Broker / middleware MQTT, often as a unified namespace	More than a handful of consumers — MES, BI, maintenance, a dashboard — so publishers stop knowing about subscribers.	A naming convention you must actually govern; a broker to keep alive.
File / database bridge CSV drops, SQL views, scheduled exports	Legacy systems that expose nothing else, and ERP imports that expect batch files.	Latency and silent failure — a stopped export looks exactly like a quiet plant. Needs its own heartbeat check.

A reference architecture that survives local conditions

From the machine outward, in four hops:

Machine layer. Controllers, meters and retrofit sensors. Read-only, always: no writes to a PLC from an integration layer, and no integration project that requires changing machine logic.
Edge layer. A gateway per area that normalises protocols, timestamps at source, applies the canonical name, and buffers locally. This is the hop that makes the architecture survivable here — during load shedding or a network drop, data accumulates and back-fills instead of vanishing.
Transport and namespace. Outbound-only from plant to platform, typically over MQTT with a consistent topic structure. Whether or not you formally adopt a unified namespace, adopt its useful half: one canonical name per signal, organised by site/area/line/asset/measure, so a rename is a governance decision rather than a search-and-replace across five systems.
Consumption layer. OEE and dashboards, ERP or MES, maintenance systems, and BI tools like Power BI — each subscribing to the same canonical signals rather than each running its own extract. Export in open formats (CSV, SQL) must be part of the design, not a paid feature.

The rule that saves the most pain later: timestamp at the edge, not on arrival. If the cloud stamps the time, every outage silently compresses hours of production into the minute the link came back — and your downtime analysis becomes fiction exactly for the periods you most need to study.

Choosing integration tools without buying a problem

Five questions separate tools that will still be working in year three from those that won't:

Does it read your actual machines? Not "supports OPC-UA" in the brochure — your machines, including the 1998 filler with a serial port.
Does it buffer locally, and for how long? Ask for the buffer depth in hours at your data rate. Under South African conditions this is a primary specification, not a detail.
Can you get your data out in full? Open export, no per-export fees, no proprietary archive you cannot read without a licence. Data lock-in is the most expensive form of vendor lock-in because it grows.
Who maintains the mapping? If tag mapping lives in a consultant's laptop, your integration has a single point of failure with a car.
What does it do at the network boundary? Outbound-only, no inbound ports to the plant network, no exposed controllers — see connecting a plant without exposing the PLCs.

Where it lands: analytics that people actually use

Integration exists so that decisions can be made, and the two decisions it feeds most often are simple: what stopped, and what did it cost? Manufacturing analytics has a habit of skipping past those to demand forecasting and machine learning, on data foundations that cannot yet reconcile a shift count. Get the canonical signals right, get OEE and reason-coded downtime trustworthy, and the analytics that follow will at least be built on numbers the plant believes. That sequencing — and why dashboards fail without it — is covered in why production dashboards fail.

FAQ

Shop floor data integration — common questions

What is shop floor data integration?

The layer that moves machine-level data — counts, run states, stop reasons, energy, quality results — into the systems that use it: OEE and dashboards, ERP or MES, maintenance systems and BI tools. It covers the transport, the naming and the reliability guarantees, as distinct from data collection, which is about getting a trustworthy signal off the machine in the first place.

What are the main shop floor integration methods?

Four: direct protocol reads (Modbus, OPC-UA, EtherNet/IP, vendor drivers); an edge gateway that normalises and buffers; a broker or middleware layer, usually MQTT and often organised as a unified namespace; and file or database bridges for systems that expose nothing better. Most real plants use three of the four at once, because their equipment spans decades.

What does a good integration architecture look like?

Machine layer read-only; an edge gateway per area that timestamps at source and buffers locally; outbound-only transport with one canonical name per signal organised by site/area/line/asset/measure; and a consumption layer where OEE, ERP, maintenance and BI all subscribe to the same signals instead of each running a private extract.

Can shop floor data feed Power BI?

Yes — and it is a common and reasonable destination for management reporting. Feed it from the same canonical signals the OEE system uses, via a database or API rather than a separate extract, so the dashboard and the plant floor cannot disagree. Where Power BI is a poor fit is real-time operational response: a report refreshed every fifteen minutes is not how you catch a line that just stopped.

Do we need a unified namespace?

You need its discipline more than its branding. A single, governed naming scheme for every signal — so "Line 1 good count" means one thing everywhere — delivers most of the benefit. The full event-driven unified namespace pattern pays off once you have many publishers and many consumers; for a plant with two lines and one dashboard, it is architecture you will maintain without needing.

How do we integrate machines that have no controller at all?

By instrumenting them: proximity or photo-eye counting, current sensing for run state, and an operator terminal for the facts only a human knows, such as stop reasons. Those signals enter the same edge gateway and get the same canonical names as PLC tags, so downstream systems cannot tell — and should not care — which machines were modern.

Primary sources

One canonical number, everywhere it's needed.

We build the collection and integration layer on the machines you already own — read-only, buffered through outages, exported in full whenever you ask.

Start a Conversation See the platform →