Connecting the shop floor: which signals to start with, and why

Most connectivity projects stall for the same reason: they are scoped as an inventory exercise. Someone lists every machine in the plant, discovers that a third of them predate the century, and the estimate that comes back is large enough to postpone the whole thing.

The way out is to stop treating connectivity as coverage and start treating it as sequencing. You do not need every signal. You need the ones that answer a question somebody is already asking, and you need them in an order where each step pays for the next.

Start with the signals that are already being written down by hand

The best first candidates are not the most sophisticated machines. They are the readings someone currently walks over to check, writes on a clipboard, and types into a system later. Cold room temperatures. Differential pressure in a cleanroom. Water and power meters read at the end of a shift.

Those signals have three properties that make them ideal starting points: the manual process already proves someone needs the data, the transcription step is a known source of error, and the equipment is usually simple enough that connecting it is a matter of a sensor rather than a controls project.

If a number is being copied by hand today, it has already justified its own connection. Start there.

What each protocol is actually for

Protocol choice is usually decided by the equipment, not by preference. The useful thing is to know what each one is good at, so you can tell which conversation you are in.

• OPC-UA — the modern standard for automation. If a PLC or SCADA system was specified in the last decade or so, this is the path. It carries a status code and a source timestamp alongside the value, which matters more than it sounds: it is the difference between recording a reading and recording a reading you can defend.
• OPC-DA — the classic predecessor, still running on a great deal of installed equipment. Worth supporting precisely because the alternative is replacing hardware that works.
• MQTT — publish/subscribe, lightweight, and the lingua franca of edge gateways and industrial IoT brokers. Well suited to devices that report when something changes rather than answering polls.
• LoRaWAN — long range, low power, no cabling. This is what makes a warehouse corner or an outdoor tank farm connectable without pulling network into it, and one transmission can carry several measurements at once.
• HTTP / REST — the escape hatch. Any system that can make a POST can contribute data, which covers lab instruments, proprietary gateways and one-off scripts.

When a vendor speaks none of these — and some will not — the answer should be configuration rather than a development ticket. A declarative codec that translates the vendor payload into measurements keeps a single non-standard device from becoming a project of its own.

The mistake that makes the second phase expensive

The common failure is not technical. It is that the first integration gets built point to point: this sensor writes to that dashboard, that PLC feeds this report. Each one works. Then the fifth consumer arrives and needs data from four sources that were never designed to be read by anyone else, and the integration cost starts growing with the square of the number of systems.

The structural answer is to land everything in one place first, with context attached — a process historian organised as a shared hierarchy of plant, area and asset. New consumers then subscribe to a model that already exists instead of negotiating a new integration. This is what a Unified Namespace means in practice, and it is the difference between a second phase that is cheap and one that is another project.

A sequence that works

1. Connect the manually transcribed readings. Cheap sensors, immediate payback, and the transcription error disappears.
2. Give them context. Naming a reading as belonging to a specific asset in a specific area is what makes it useful to someone who was not involved in installing it.
3. Add the equipment that already speaks a standard. PLCs and SCADA over OPC-UA are usually low effort once the historian is in place.
4. Only then tackle the awkward ones — proprietary formats, legacy controllers — where a codec or a gateway is needed.
5. Feed the consumers. Batch records, quality investigations, equipment performance — all reading from the same source rather than each collecting its own.

What connected data has to be worth

A connected plant is only an improvement if the data can be trusted. That means keeping the quality code the protocol gave you, preserving the origin timestamp rather than the ingestion time, and storing the raw event as it arrived. Those are the same properties that data integrity and the ALCOA+ principles demand of any regulated record — which is convenient, because it means doing connectivity properly and doing compliance properly are the same work.

For a first project, environmental monitoring is usually the least disruptive place to prove the approach: wireless sensors land readings into the historian without touching a single control system. The wider picture is in our industrial IoT solution.