Using machine data: from the machine to the decision

Machine data becomes useful when it answers a concrete production question: why is the line down? How many good parts does a shift produce? When is a fault building up? The way there leads through data capture at the machine, a production network separated from the office network, and an evaluation that shift supervisors and management understand without explanation.

Many manufacturers have machines that could long since be supplying data, but nobody reads it. Part counts are noted on paper, downtime is entered from memory at the end of the shift, and the question of which machine causes the most problems is answered by the foreman's gut feeling. The goal is not to collect as much data as possible, but to make better decisions – with figures from your own shop floor.

Which machine data actually matters for an SME?

A modern controller can deliver many values. For most decisions a few are enough: is the machine running, idle or in fault? How many parts were produced, and how many were scrap? Which fault message occurred when? From these basics you can read availability, downtime reasons and utilisation – exactly the questions that keep coming up in meetings.

• Machine state: running, idle, fault, changeover
• Part counts and scrap per order or shift
• Fault messages with timestamp and duration
• Process values where they are critical for quality, such as temperature or pressure
• Energy consumption, if it is to be recorded per machine

How is machine data captured: OPC UA, MQTT or retrofitting?

OPC UA is an industrial standard for exchanging data with machines and controllers. Many newer machines come with an OPC UA server that provides values in a structured, described form. MQTT is a lightweight messaging protocol: devices send their values to a central broker, and other systems pick them up there. In practice the two are often combined – OPC UA at the machine, MQTT for forwarding to the database and evaluation.

Older machines often speak only vendor-specific protocols, or none at all. In that case protocol converters or retrofitted sensors help, for example a current sensor that detects whether a machine is running, or a signal from the stack light. For the question of when and for how long a machine stops, that is often enough. A gateway at the edge of the production network collects the data and passes it on in a controlled way.

Why must the production network stay separate from the office network?

The production network, often called the OT network (operational technology), and the office network (IT) have different requirements. Machine controllers often run operating systems that no longer receive security updates, and an outage stops production rather than just one workstation. Data capture must not weaken this separation. The usual approach: the gateway sits in its own zone between OT and IT, the firewall only allows the connections needed for data capture, and data flows away from the machine, not towards it.

• Production and office networks on separate VLANs or physically separate networks with a firewall
• Gateway or data collector in its own zone between OT and IT
• Data flow in one direction wherever possible: from the machine to the evaluation
• No direct access from the internet to machines or controllers
• Remote maintenance by machine vendors time-limited and logged

Where is the data stored and how does it become visible?

Machine data is time-series data: values with timestamps that keep coming in. Time-series databases store such data and make it quick to query. Evaluation happens through dashboards, for example with a tool like Grafana, or through reports sent automatically to shift supervisors. What matters more than a nice chart is that the right person sees the right figure at the right time: the shift supervisor the current status at the line, management the trend over a longer period. How to build such a KPI dashboard is covered in a separate article.

Machine data can be stored and evaluated entirely on site. A cloud solution can make sense when several sites are brought together or remote access is needed. The decision depends on data volume, access requirements and security needs, not on a trend.

What are sensible first steps?

1. 01Define one question: which decision should machine data improve? For example: why does line X stop so often?
2. 02Choose one machine: the one where the question is most pressing, not the most modern one.
3. 03Check the interfaces: does the controller offer OPC UA or another protocol, or is retrofitting needed?
4. 04Prepare the network: separate or review the production network, place the gateway in its own zone, define firewall rules.
5. 05Capture a few signals: state, part count, fault message – plus the downtime reason from the operator.
6. 06Build a simple display that shift supervisors and foremen actually use day to day.
7. 07After a while, review together what the data shows, and only then connect the next machine.

What role do AI and predictions play?

Predictive maintenance and AI-based analysis require a clean data foundation over a longer period. If you do not yet know when your machines stop, you benefit first from reliable capture and a clear display. AI can later help identify patterns in faults, but it does not replace understanding the process. Here too, AI starts at the wrong end when the data underneath is missing.

How NDVDL makes machine data usable in your business

NDVDL brings together the areas that meet in machine data capture: networking, security, data capture and software. Networking is our everyday work; over 300 switches are in use at our customers. From our work with Smartenic in IoT, networking and digital signage, we know how to connect distributed devices to a central system.

We come to your shop floor, clarify with you which decision should get better, and look at the machines, controllers and network. You then receive a written proposal for a small start with one machine. After implementation, NDVDL operates and maintains the network, gateway, database and evaluation. You have one fixed contact person for all of it.