Connecting existing machines to modern software: a practical guide for manufacturers

Many manufacturers want better visibility of their production: where time is lost, why scrap rises on certain shifts, which machines need attention before they fail. A common assumption is that this requires new equipment. In most plants it does not. The machines already on the floor can usually provide the data, and the work is in connecting them in a way that is reliable, secure and useful to the people who run the plant.

This guide describes the approach we recommend.

Start with a question, not a platform

Projects that begin with “we need an Industry 4.0 platform” tend to collect a great deal of data and answer very few questions. Projects that begin with a specific question tend to deliver value early. For example:

• Why does line 2 produce less per shift than line 1?
• How much unplanned downtime do we have, and what causes it?
• Which products generate the most scrap, and at which step?

A clear question tells you which machines to connect first, which signals matter, and what the first dashboard should show.

Take stock of what you have

Before any software is written, walk the floor and list every machine involved in the question. For each one, note:

• the controller (for example, the PLC model and firmware version)
• the communication options it supports
• whether it is on a network today, and which one
• who maintains it, and whether changes require the equipment supplier

Newer equipment often supports OPC UA, an open standard for industrial data exchange. Many older controllers speak Modbus or a vendor-specific protocol. Some machines have no digital interface at all. That is not a dead end: a simple sensor or current clamp, wired to an I/O module, can tell you whether a machine is running, idle or stopped, which is often enough to start measuring availability.

Use a gateway between the floor and the rest of the business

We rarely connect business software directly to machine controllers. Instead, a small industrial computer on the plant network acts as a gateway. It reads data from each machine in its native protocol, adds accurate timestamps and a consistent structure, and forwards it to the systems that need it, typically over MQTT, a lightweight messaging protocol widely used for this purpose.

This separation has practical benefits. Controllers are only read, never written to. The gateway can buffer data if the connection to the server drops. And when a machine is replaced, only one integration changes.

Agree on a data model early

Raw signals such as DB10.DBW4 = 1 mean little to anyone outside maintenance. Give every signal a clear name and place it in a hierarchy that mirrors the plant: site, area, line, machine. The ISA-95 standard offers a well-established structure for this. Decide early how you will represent machine states (running, idle, stopped, in changeover) and how you will record the reason for a stop. These decisions shape every report that follows.

Show the data where decisions are made

The first output should be simple and visible: a screen next to the line showing current status, output against target and the reasons for the last stops. Supervisors and operators will quickly tell you what is wrong with the data, which is exactly what you need at this stage.

Once the data is trusted, connect it to the systems the business already uses. Production counts can flow into the ERP. Quality results can be linked to batches. Maintenance can receive alerts based on run hours rather than calendar dates.

Treat security as part of the design

Connecting machines to wider networks introduces risk if it is done carelessly. A few principles go a long way:

• Keep production equipment on a separate network segment, with only the gateway able to reach it.
• Start with read-only access to controllers.
• Avoid inbound connections from the internet to the plant network; let the gateway connect outwards.
• Keep an inventory of every connected device and who is responsible for it.

The IEC 62443 series of standards provides a framework for industrial cybersecurity and is a useful reference when agreeing requirements with IT and equipment suppliers.

Pilot one line, then scale

Choose one line, answer one question well, and measure the result. A pilot of this kind typically shows where the data is unreliable, which signals are missing and what people actually use. With those lessons in place, extending the approach to further lines becomes a repeatable process rather than a new project each time.

Common mistakes to avoid

• Collecting every available signal “in case it is useful”, which creates cost and noise without answers.
• Building dashboards before agreeing on definitions, so that two reports show different numbers for the same shift.
• Leaving operators out of the process, which leads to stop reasons that are never entered or always set to “other”.
• Writing to controllers from business software, which creates safety and support problems.

How we can help

We help manufacturers connect existing equipment, build the data model and dashboards, and integrate production data with ERP and quality systems. If you are considering a project like this, get in touch. A short discovery workshop is usually enough to identify the right first question and the machines to start with.