Connecting legacy machines: a practical path from isolated equipment to usable data

Start with an asset-by-asset assessment

The first deliverable is a connectivity register: one row per asset, recording the controller make and model, firmware where known, available ports, supported protocols, the data that already exists in the controller, and who owns the machine. In practice most assets fall into one of four groups.

The register also shows which assets are not yet worth connecting. Data collection should follow the decisions it is meant to support, not the other way round.

Choose the protocol by purpose

Three protocols come up repeatedly in shop-floor connectivity work. They solve different problems and are often used together.

A common pattern is to read Modbus or a manufacturer protocol at the asset, translate it in a gateway, and publish upward through OPC UA or MQTT. The choice at each hop should follow the consumer’s need: structured, browsable machine data favours OPC UA, while distributing events to many consumers favours MQTT.

Collect less, with context

The first data set should support the first decisions. For most plants that means machine state (running, stopped, faulted), part counts, cycle time and stop reasons: enough to calculate availability and performance and to see the loss split described in our guide to measuring OEE.

Raw signals become useful only with context: which asset, on which line, in which shift, making which product. Modelling assets in an equipment hierarchy consistent with ISA-95 (site, area, line and cell), and attaching the shift calendar and product context, is what turns counts into OEE.

Collecting every available tag at high frequency is a common early mistake. It increases storage and network load and produces data with no owner. Further signals can be added once the first use case is in daily use.

Secure the path before you scale

Connecting a machine creates a path into the control environment. The ISA/IEC 62443 series is the international reference for the security of industrial automation and control systems. Its zones-and-conduits model groups assets with common security requirements into zones, controls communication between zones through defined conduits, and assigns each a target security level, from SL 1 to SL 4, based on risk.

NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security, published in September 2023, provides complementary guidance on OT threats, vulnerabilities and safeguards, including the convergence of IT and OT networks.

A practical baseline for a first deployment:

• Never expose controllers directly to the internet. Route data through a segmented zone between the plant network and the enterprise network.
• Prefer read-only access for monitoring. Keep write access to control logic out of scope unless there is an engineered case for it.
• Replace default credentials on gateways and devices, and keep an inventory of every connected asset and its firmware.
• Agree patching and change-control responsibilities between operations, IT and machine builders before go-live.
• Where a cloud service is involved, prefer connections initiated outbound from the plant side.

Prove on one line, then templatise

Connect one line end to end, put the data into daily use, and then capture what was learned as a connection template per machine type: protocol, gateway configuration, tag list, mapping to the asset model, and security settings. The template, not the pilot, is what makes each subsequent line faster to connect than the first. Our article on scaling beyond the pilot covers the organisational side of that step.

How OrbitX approaches this

Protocol and hardware choices are made asset by asset and recorded in the register with the reasoning, so they can be challenged. Where a machine builder restricts access to a controller, we document the restriction and choose a non-intrusive route rather than work around it. See our machine connectivity and integration capability.