Retrofit machine data: four routes for assets without an interface

In most plants, retrofit machine data does not mean buying an interface. It means deciding on which of four levels you reach the data of an existing machine: through the controller itself, through the fieldbus, through retrofitted signals and sensors, or through the operator's entry. Which level carries the job is decided by an inventory of the machine, not by a gateway vendor's catalogue. Capturing the data is the smaller part of the work; the larger part is the context that turns a runtime signal into a metric.

The starting question: what can your machine actually give you?

What your machine can give you is rarely stated in the machine builder's quotation. It is in the control cabinet and in the documentation. Before you think about an IIoT gateway for the retrofit or an additional sensor, every machine needs a short inventory: controller and year of manufacture, network socket, fieldbus, spare digital outputs, signal tower, counters, cabinet access, and documents that identify variables and terminals. The result decides the level - not a supplier's preference.

For brownfield connectivity in production this is the normal case: a machine fleet spanning three decades and five controller generations. The inventory is not a project but a walk-through by maintenance and a qualified electrician at the open cabinet. Without it, every machine data acquisition retrofit becomes guesswork: you buy a gateway for level 1 and discover on site that the firmware ships no OPC UA server.

Level 1: the controller already speaks - OPC UA or a vendor protocol

The comfortable case applies when the controller already runs an OPC UA server or speaks a vendor protocol for which a documented client exists. You recognise it by three things: firmware that includes the server, a licence that unlocks it, and a list of the variables it exposes. If one of them is missing, you are in level 2, however modern the nameplate looks.

Level 1 rarely fails because of the technology; it fails because of meaning. An OPC UA server that offers 400 variables with names such as M12.3 or DB40.DBW12 delivers data without semantics. You need the programmer or the symbol table to know which bit means "automatic mode running" and which is only an auxiliary flag. In practice, this clarification regularly costs more time than the connection itself.

Whether OPC UA or a lightweight transport such as MQTT suits your landscape depends on semantics, security requirements and the target system; the trade-off is set out in OPC UA or MQTT as a decision guide. For Siemens controllers, and for why optimised data blocks block access, read reading S7 data with an OPC UA server and Snap7.

Level 2: reading fieldbus and controller variables

If the controller offers no approved high-level protocol, what remains is read access to controller variables over the fieldbus or the programming interface. On third-party and legacy controllers this is often Modbus, because it is openly documented and because many variable-frequency drives, energy meters and compact controllers speak it anyway.

The MODBUS Application Protocol Specification V1.1b3 issued by the Modbus Organization defines four data tables: discrete inputs and coils as single bits, input registers and holding registers as 16-bit words. Reading uses function codes 01 (coils), 02 (discrete inputs), 03 (holding registers) and 04 (input registers); one request covers at most 125 registers or 2,000 coils. The classic trap: in the protocol data unit registers are addressed from zero, in the data model from one - register 108 is requested as address 107.

Second trap: word order. Within a register Modbus transmits the high-order byte first; how two registers combine into a 32-bit value is left open by the specification - the mapping between the data model and the device application is, per the specification, entirely vendor-specific. Without a register table, a swapped word produces plausible but wrong numbers. Third trap: every cyclic request costs computing time in the PLC. Start with long polling intervals and measure the scan cycle time before and after you connect.

• —Written approval from the machine builder for read access over the specific interface, including a statement on warranty
• —Variable or register list with data type, unit, scaling, word order and meaning
• —Maximum permitted polling rate and scan cycle reserve; which variables are part of a handshake logic
• —Network prerequisites: IP addressing, VLAN, the manufacturer's existing remote maintenance connection

Level 3: retrofitting signals and sensors

If the controller is closed or access is not approved, you collect the information where the machine already emits it anyway: at digital outputs, at the signal tower, at the main drive, at a counter. Anyone who wants to read machine data without an interface almost always ends up here. It is the route most suppliers mean when they talk about digitalising legacy machines - more robust than its reputation suggests, as long as you know the limits.

The signal tower is the simplest source. Its drive signal is available as a 24 V signal in the cabinet; a tap through a coupling relay feeds it to a recording module without any feedback effect. You receive the states the machine builder defined: green running, amber waiting, red fault. What amber means in detail appears only in the machine documentation - material shortage, open door or warm-up all look the same on the tower.

A current sensor on the main drive needs no intervention in the controller at all. A current transformer around the supply line delivers the current draw; with thresholds you distinguish three states: off, idling, under load. A current sensor for the machine state therefore yields dependable runtimes and downtimes, often cycles too, when the load peaks per stroke are recognisable. It says nothing about order, article or scrap, and the thresholds have to be calibrated for each machine.

Counters, energy meters, vibration and temperature sensors complete the picture. The Mittelstand-Digital Zentrum Chemnitz describes retrofit as the modernisation of existing machines by adding and upgrading equipment, names temperature, pressure, speed and vibration as the basis for conclusions about operating states, and points out that the information can be passed on to higher-level systems via MQTT or OPC UA, right through to calculating OEE. Capturing is therefore solved; what you can derive from it is shown in Tab. 02.

Level 4: people as a data source - terminal and operator entry

Where neither the controller nor a sensor delivers the information, the operator remains. Downtime reason, setup start, order change and scrap quantity are known to the operator - and in many plants are already written down, only on paper. A terminal at the workplace turns that into operating data with a timestamp. Operator entry and automatic machine data acquisition are two different things, and in most plants the automatic signal comes first and the manual reason second. Operator entry fails not because of the software but because of what it asks of people: an entry that takes longer than the stoppage it describes will simply not happen.

• —Few fields: reason, order if needed, done. Everything else comes from the system.
• —Preselection instead of free text: a short list of reasons agreed with the team; free text optional only.
• —Automatic trigger: the terminal asks for the reason when the current sensor or signal tower reports a stoppage above a minimum duration.
• —Late entry allowed: a stoppage explained only after the fault has been cleared is better than none at all.
• —Feedback: whoever records reasons must see the analysis - otherwise the entry becomes surveillance rather than a tool.

The data quality of this level is only as good as motivation and usability. Combined with an automatic runtime signal from level 3 it becomes dependable, because the signal supplies the moment and the duration and the operator only supplies the reason. Level 4 is therefore almost always a supplement, rarely a substitute.

The hard part: context instead of raw values

A runtime signal without context is a curve, not a metric. To turn "the machine ran for 6 h 40 min" into an availability figure, a performance rate or an energy-per-piece value, you need five assignments: shift, order, article, target time per piece, and the periods that were deliberately not scheduled. None of them comes from the machine. They come from the ERP system, from the shift plan or from the operator.

The assignment stands or falls with the timestamps. If gateway, terminal and ERP hold three different clock times, you will attribute stoppages to the wrong order. Synchronise every recording device by NTP against the same time source, store timestamps in UTC and convert to local time only in the analysis. The second building block is naming: a tag called GW03_DI2 will mean nothing to anyone a year from now, whereas a tag carrying site, line, machine and measured quantity can be analysed without asking around. How to build that structure along ISA-95 is described in Unified Namespace with a concrete ISA-95 topic scheme.

Resilience: what happens when the network drops out?

A retrofitted gateway often hangs on a Wi-Fi link nobody ever considered critical. If the connection fails, data must not be lost, and the outage must not look like a machine stoppage. The OASIS standard MQTT 5.0 defines the mechanisms for this: with QoS 1 messages arrive at least once, with QoS 2 exactly once; if the session expiry interval is greater than zero, client and server must store the session state after the connection breaks. If a client sends nothing for longer than 1.5 times the keep-alive period, the server closes the connection; the will message then published makes a silent gateway distinguishable from a machine that has genuinely stopped.

Only when signal, context and time fit together is the metric worth calculating. How to derive OEE from it, and which stoppages drop out as planned, is set out in calculating OEE with the formula and a worked example.

Risks no data sheet mentions

Warranty and substantial modification

An intervention in the control cabinet or the controller without the manufacturer's approval can affect warranty and service agreements; whether it does is a matter for your contract. Obtain the approval in writing and describe in it what will be connected and that access will be read-only. Wiring work is done by a qualified electrician, and every tap is added to the circuit diagram.

Alongside that stands product safety. The interpretation paper on substantial modification of machinery (Interpretationspapier "Wesentliche Veränderung von Maschinen") of the Bundesministerium für Arbeit und Soziales (the German Federal Ministry of Labour and Social Affairs), announced on 9 April 2015 in GMBl 2015 p. 183, turns on whether the modification gives rise to new hazards or increases an existing risk; if neither is the case, the machine continues to count as safe. Where a substantial modification does exist, the person responsible for it becomes the manufacturer and has to carry out the conformity assessment procedure. In practice, purely read-only data acquisition falls under the first case; you must still carry out and document the assessment, though, before the current transformer goes onto the drive.

Network separation and remote maintenance

A gateway that sends machine data into office IT or a cloud connects two networks that were previously separate. In Industrial Control System Security: Top 10 Bedrohungen und Gegenmaßnahmen 2022 - the top 10 threats and countermeasures published by the BSI, the German Federal Office for Information Security - the countermeasures named include maximum isolation of networks through segmentation with firewalls and VPN solutions, remote maintenance access points in a demilitarised zone, and routing every remote access through a firewall that permits only the required addresses, ports and systems. For a retrofit that means: the gateway sits in its own segment, opens outbound connections only, and the machine builder's existing remote maintenance access is inventoried rather than left quietly running.

Works council co-determination

As soon as recorded data can be related to individual employees - downtime reasons per operator, entries with a personnel number - the works council must be involved. Section 87(1) no. 6 of the Betriebsverfassungsgesetz (the German Works Constitution Act) provides for co-determination in, among other things:

Whether a specific machine data acquisition falls under that depends on the personal reference in the individual case and is a question for the works council and legal advisers. In practice, an early works agreement with a clear purpose limitation - machine state, not personal performance - settles the topic before the topic settles the project.

Retrofit machine data: decision path and pilot approach

The decision path follows the inventory from the most comfortable to the most demanding level. You walk it once per machine and record the outcome, so that the next machine goes faster.

1. 01

   Fix the metric

   One metric you will genuinely use over the coming weeks: availability of a bottleneck machine, downtime reasons on a line, energy per piece. It determines which signal is sufficient.

2. 02

   Check level 1

   Is there an OPC UA server the manufacturer has approved, or a documented vendor protocol with a variable list? Yes: level 1. No, or the licence and the semantics are missing: move on.

3. 03

   Check level 2

   Is there a fieldbus or programming interface for which the machine builder grants read access and supplies a register list? Yes: level 2, with a scan cycle measurement. No: move on.

4. 04

   Check level 3

   Can the metric be derived from the signal tower, digital outputs, a current sensor or a counter (Tab. 02)? Yes: level 3, with an assessment against the interpretation paper and a qualified electrician.

5. 05

   Add level 4

   Everything that needs a reason or an order reference comes from the operator. Agree the list of reasons with the team and couple the prompt to the automatic stoppage signal.

6. 06

   Accept the pilot or change level

   One machine, a fixed period, comparison against today's shift log. If the pilot meets the criteria set in advance, roll it out; if it fails them after two rounds of rework, change the level.

• —Completeness: share of operating time with a valid signal - network outages included
• —Agreement: deviation of the recorded running and downtime from the manually kept shift log
• —Context rate: share of stoppages above the minimum duration that have a reason and an order assigned
• —Freedom from feedback effects: unchanged scan cycle time in the controller, no communication error caused by the recording

When do you change level? If the signal cannot yield the metric in principle - a current sensor never delivers a scrap reason - no amount of tuning helps. If the semantics are missing, do not change the technology; obtain the variable list. If the manufacturer's approval never arrives, level 3 is the pragmatic answer, not a fight over level 2.

Legal framework: what the EU Data Act changes for existing and new machines

For existing machines the EU Data Act creates no obligation to retrofit - but it does create a right, and that right of access has applied to them too since 12 September 2025. According to the European Commission, Regulation (EU) 2023/2854 has applied since that date; since then users of connected products have a right of access to the data generated by their use - including on machines that have been running for years. Since 12 September 2026, Article 3(1) adds the design obligation: connected products placed on the market after that date must, according to the DIHK, be designed so that the data are directly and automatically accessible. Existing products do not have to be retrofitted for this.

The consequence for procurement is a technical one: data access belongs in the specification for every new machine, with protocol, variable list and semantics - otherwise you buy a machine today that you will be retrofitting in two years. Scope, exceptions and enforcement of that right are a legal question rather than a technical one. The statements here rest on the Commission page and the DIHK assessment, as at 21 September 2026, and are no substitute for legal advice.

Conclusion: inventory first, then the level, then the context

Retrofitting machine data is not a hardware question but a sequence: take the inventory, choose the level, connect read-only, establish the context, accept the pilot. Capturing the data is solvable on all four levels; what makes projects fail is missing semantics, unsynchronised timestamps, missing approvals, and a works council that was asked too late.

Start with one machine and one metric, and accept the pilot against your own shift log. How recorded machine and order data come together into an analysis is shown by the solutions from ralwo, along the path from signal to metric.