Data Acquisition & Analytics

Where it pays off

The return on a data pipeline shows up when it moves an argument from intuition to measurement. “This line slows down on the evening shift” becomes a maintenance plan when there are downtime records behind it; without them it stays a difference of opinion between shift supervisors.

The work we see most often:

• Downtime and OEE measurement. Recording why the line stopped, reason by reason, and separating losses that come from availability from those that come from speed.
• Traceability. Working backwards from a batch number to find which recipe, which raw material lot and which process values went into a given product.
• Shift and production reports. Replacing hand-filled forms with reports fed automatically from the field and distributed on their own at the end of a shift.
• Energy and consumption tracking. Relating electricity, compressed air and water use to production volume — consumption per unit produced is far more useful than a total.
• Reporting on top of an existing SCADA. Built as a read-only pipeline, without touching the control layer.

How we work

We start by writing down the question to be answered. “Let’s collect data” is not a requirement; “we want to see the reason and duration of every stop, broken down by shift” is. The second one determines by itself which tags are needed, how often they must be sampled and what input has to be asked of the floor.

Then comes the tag dictionary: address, unit, scaling, sampling interval and deadband for every measurement. We review that table together with the customer, because only the site team knows which tank the tag called TT_014 actually belongs to.

In the acquisition layer OPC UA is the first choice — directly if the PLC side supports it, otherwise over Modbus or through a gateway. For installations spread across many points we prefer MQTT Sparkplug B: republishing state after a dropped connection is defined by the specification there, rather than being a mechanism you write by hand.

Data is written at full resolution into a time-series database (InfluxDB or TimescaleDB), while production summaries, batch records and downtime classifications live on the relational side (PostgreSQL). Raw data is downsampled after a defined period — keeping five years of one-second samples is pure disk cost if nothing ever queries them.

On the dashboard side we keep the separation strict. The operator view fits on one screen, is readable from a distance and shows the current state. The shift view compares. The management summary shows trends and does not exceed a single page. Trying to fit all three needs into one dashboard produces a screen nobody opens.

Where a plant already runs MES or ERP, we build the data pipeline alongside it rather than in its place. The exchange is usually narrow and bidirectional: production orders and recipe data come down, actual output, scrap and consumption go up. We prefer to keep that interface small from the start — integrations built without writing down which fields flow in which direction end up as arguments about two systems showing the same record differently.

What we watch for

Clock synchronisation comes first. If the PLC, the SCADA server and the database server do not follow the same NTP source, correlation is impossible: you cannot say whether the alarm came before or after the stop, and the whole of downtime analysis rests on that question.

An unclassified stop is an unmeasured stop. When the system is built without deciding who enters the reason, where, and in how many seconds, most stops end up in the “unclassified” bucket and the report loses its meaning.

Acquisition must not slow the control layer. We read only, we leave no unnecessary subscriptions on the PLC, and during commissioning we test that the process is unaffected when the collector service goes down.

Report definitions are written. Which periods “availability” counts as planned downtime, whether breaks are included — if that definition never reaches a document, two departments read two different results off the same screen.

How this connects to the other solution areas

The quality of this pipeline depends on the data the control layer beneath it produces; in a system where the tag dictionary was never built properly, the reporting layer counts wrongly. That is why we often plan data work together with industrial automation. Connecting distributed field points and remote access belongs to industrial communication systems, while using the collected history for forecasting and anomaly detection moves over to artificial intelligence and machine learning — though the order matters: no model gets built without clean, labelled history behind it.