How to put production machine and sensor data to use

Production machine data is put to use by reading it from the systems that already hold it, not by installing new sensors. In most factories the measurements already exist in the machines' control logic (PLC), the supervisory system (SCADA), production management (MES) or the equipment vendor's cloud. They just stay there, even though a standard interface would be enough to move them without opening the plant network. New data is only needed if the decisive measurement is missing altogether.

Where is production data and why does it go unused?

Production data is usually spread across several systems, each with its own owner. It goes unused because these systems were built to control production, not to share information. When nobody is responsible for moving the data onwards, it stays where it was created.

A typical situation: the production manager sees yesterday's output from MES at the morning meeting, but the reason for the slow shift is in the SCADA alarm log that nobody opened. It is the same problem as with CRM data that is not enough on its own: each system shows its own part, and the insight only appears when they are combined.

OPC UA, MQTT, API or CSV: which interface fits which case?

On newer machines and SCADA systems OPC UA is usually the easiest route, MQTT fits when there are many scattered measurement points, and the vendor's API is the only way when the data already sits in the vendor's cloud. A CSV export is not a bad choice if the data is needed once a shift rather than every second. In industrial IoT (IIoT), the choice follows what the equipment already supports.

On older lines the answer is often a combination: newer machines are read over OPC UA, the oldest one provides a scheduled file export, and orders come from MES. Choosing the interface is the same question as choosing between a no-code tool and a custom integration: the more critical the use, the more important it is that an outage is noticed and data does not disappear silently.

How do you use production data without opening the plant network?

Production data can be used securely when the connection is read-only, it is opened from inside the plant outwards, and the control network is kept separate from the office network. No analytics or AI writes back to a PLC. With these three principles, the OT manager does not need to open a single inbound port in the firewall.

In practice this means:

• Read-only access. A dedicated user is created on the OPC UA server that can read selected tags but cannot change anything.
• Outbound connection. A gateway at the edge of the plant (an edge gateway or a server in a DMZ) reads the data and sends it to the cloud. The cloud never connects into the plant.
• Network segmentation. The control network, the gateway layer and the office network sit in separate zones. Zoning is also a core principle of the IEC 62443 series of standards.
• Logging and ownership. Every connection leaves a trace, and every interface has a named owner.

There is a legal side too. In Finland, the obligations of the Cybersecurity Act (the national implementation of the NIS2 Directive) came into force on 8 April 2025, and they also cover part of manufacturing industry. A new data connection from the plant to the cloud is therefore a risk management matter, not just a technical question for IT.

We deliver secure integrations between the plant and the cloud on Microsoft Azure, so the data stays in a chosen EU region and every transfer is visible in the logs.

When is existing data enough and when is it not?

Existing data is enough when it measures the right thing often enough and can be linked to an order, batch or shift. It is not enough if the decisive phenomenon is not measured at all. Before considering new sensors, check four things:

1. Sampling interval. Historians often store only changes or a one-minute average. Bearing vibration needs denser measurement, energy consumption or line utilisation does not.
2. Timestamps. If the PLC and MES clocks disagree, measurements cannot be reliably linked to a specific batch.
3. Context. A temperature reading without knowing which product was running on the line tells you little. Context usually comes from MES or ERP.
4. Missing measurement. If a quality defect is caused by humidity that nobody measures, no integration will fix it.

The Metsä Board case shows why context matters. The transport sensor data showed location and conditions, but the point on the route where damage happened was found only when it was combined with damage records logged at storage points. See how sensor data and damage records were combined.

The boundary is clear: we put to use the data that equipment already produces. If the check shows that the decisive measurement is missing, we say so directly, and buying a sensor is a separate decision. The difference from a machine's own control is explained in our article on physical AI.

Where should you start using production data?

Start with one decision the data would change, not with all of the plant's data. A good first target is a recurring situation where someone now gathers information by hand or notices a problem too late. Operational AI only creates value once the data is combined and someone acts on it.

1. Pick a decision. For example: why the shift's output fell short of target, or when a machine needs maintenance.
2. List the tags you need. Often 10-30 measurements are enough, not thousands.
3. Open one read-only connection. One line or machine, one interface.
4. Link it to order and batch data. This is the point where a measurement turns into an insight.

Once the first target works, the same connection can be extended one line at a time.

---

Empirica Finland is a Finnish provider of operational AI and automation that builds automations from the data produced by a company's systems as well as its devices and sensors, and is responsible for keeping those automations running. Empirica is a Claude Partner Network member and a Microsoft partner.

← Back to homepage