The problem
The data is there in the controller: states, counters, temperatures, faults. But only someone standing at the machine can use it. For service, product development and your customers it is invisible.
First attempts often end as a pilot on one machine: a script, a database, a dashboard. As soon as the second plant is added, the connection drops or someone renames a value, the solution stops holding up.
How machine data gets into the database via OPC UA
It starts with the data model: which values, with which names, units and timestamps, for which plant types. We define it with your engineers before we write code.
A Python service on the edge device reads the values from the controller via OPC UA, or the controller publishes them via MQTT. The messages pass through a message broker (RabbitMQ or an MQTT broker). Telegraf writes them into a time-series database, and Grafana displays them. A REST interface (FastAPI) makes the data available to your other systems.
This works for machines at your customers’ sites just as well as for your own plants and modules that you want to monitor yourself.
Since 12 September 2026, under the Data Act, manufacturers of newly placed connected products must give users access to the data those products generate. Whether your product falls under it is a legal question. Technically, a data pipeline with an interface is the basis for it.
What you get
- a documented data model for your plant types
- data capture on the edge device, with buffering when the connection drops
- message broker, time-series database and dashboards
- an interface for ERP, service software or customer portals
- code and configuration in your repository
Limits
We read data from the controller, we do not program it. If an interface, sensors or wiring are missing, your PLC engineers or our automation partner take care of that.