Industrial IoT: connecting machines that were never designed to be connected

Start from the decision, not from the machine

Connectivity programmes that begin with a survey of equipment produce a large collection point count and no change in behaviour. Begin instead with a question somebody needs answered: why the constraint stops, whether a utility bill matches production, which changeover is slowest, whether a bearing is degrading. Each question names a small number of signals and a person who will act on them. That framing keeps the scope honest, gives an early result to defend the next phase with, and avoids the outcome where a plant is streaming thousands of values into storage while its shift meetings still run on a whiteboard.

Getting a signal out of equipment that has no interface

Options exist along a spectrum of intrusiveness. Non-contact approaches — a current transformer around a motor supply, an added vibration or temperature sensor, a counter watching an existing indicator lamp, a camera reading a display — collect data without touching the machine's own control and without engaging the builder or their warranty. Reading directly from the controller yields far richer information but means adding a network connection and, on older equipment, a protocol converter. Whichever route, agree explicitly that nothing may write back to the control system, because a monitoring project that can alter machine behaviour is no longer a monitoring project.

Connecting a machine changes its exposure

Equipment that was safe because it was isolated stops being safe once it has a route to the rest of the plant, and the machines least able to defend themselves are the old ones you most want to instrument. Practical measures are architectural: segment the control network, allow data to flow outward through a controlled point rather than opening inbound access, keep supplier remote connections deliberate and logged, and inventory what is actually connected because nobody can protect an estate they cannot list. National cyber security agencies publish guidance aimed specifically at operational technology, and the international framework for industrial control security is IEC 62443.

Read the data clause before the technical specification

Modern machines frequently arrive with connectivity that sends operating data to the builder. That can be genuinely useful for support and warranty, and it is also a commercial arrangement about your production information. Establish before purchase what is transmitted, where it is stored, who else may see it, whether you receive the same data in a usable form, what happens to it if you change supplier, and whether machine functionality degrades if the connection is refused. Plants that skip this find their own process data available to them only through the builder's portal, on a subscription, in a format they cannot export.

The unglamorous work that decides whether any of it is usable

A signal becomes information when it is named consistently, timestamped against a synchronised clock, and associated with what was being produced at that moment. Without that context a value is a number nobody can interpret six months later. Equally important is deciding what happens when a connection drops: buffered locally and forwarded, or simply lost, leaving a hole that undermines every subsequent analysis. Settle naming, time synchronisation, buffering and retention at the pilot stage, because retrofitting these onto a live estate means reprocessing everything already collected or accepting that the early history is unusable.

Frequently asked questions

Can we monitor old machines without involving the builder?

Usually yes, by adding your own sensing rather than reading from the machine's control. Current measurement on the supply, added vibration or temperature devices, an optical counter watching an existing indicator, or a switch detecting a moving element will answer most questions about running, stopped, cycling and loaded. This avoids warranty arguments and avoids touching control logic. The limitation is that you learn about behaviour rather than about internal state, so fault codes and set-points remain out of reach without a proper interface.

Should machine data go to the supplier's platform or stay on site?

It depends on what you are buying. Supplier platforms provide analysis built on their fleet experience, which can be genuinely better than anything you would build. What matters is that the arrangement is reciprocal and reversible: you receive your own data in an exportable form, you know what is shared and with whom, the machine still runs if the link is cut, and you can end the arrangement without losing history. Negotiate that at order stage, while you still have bargaining power.

Why do connectivity projects stall after the pilot?

Most often because the pilot proved that data could be collected without proving that anyone would act on it. The technical result is a dashboard nobody opens. Programmes that continue are the ones tied to a named decision and a named owner, where the first phase visibly changed something — a stoppage cause identified and removed, a utility charge explained. Fund the second phase on that evidence rather than on collection volume, and be willing to switch off feeds nobody uses.