Why connectivity is the long pole

Software projects slip for software reasons, and everybody involved has a mental model for that. Connecting a plant slips for reasons that have nothing to do with code, and the mental model is usually missing.

Connecting a plant is physical work. It is a person walking to a panel, a change window negotiated with somebody who does not report to the project, a cable, a firewall rule, a controller that has to be touched while production is not running. None of that gets faster because the platform is good.

Why it is physical work

The data path from a plant is short to describe. Controllers publish to a collection hub on site, over OPC UA, Modbus or BACnet. That hub publishes outbound over MQTT to the cloud. Connection is outbound from the plant network, so no inbound hole in the firewall is required.

Every step in that sentence is a physical dependency. The controller has to be reachable from the hub. The hub has to be installed somewhere with a route to both the controllers and the internet. The outbound path has to be permitted by whoever owns the network. Each of those is somebody else’s approval, somebody else’s change window, and frequently somebody else’s budget.

This is why the timeline for an implementation is set here rather than in the configuration work that follows. Configuration is predictable. Getting a machine to say anything at all is not.

What a blocker actually looks like

All three of these show up in real engagements. None of them is exotic and all of them cost weeks.

A legacy controller behind a NAT boundary

The machine is on a network and running fine. It is simply not reachable from where collection happens, and making it reachable means a firewall change. The technical work is small. The approval, the change window and the security review around it are not, and none of them are inside the project’s control.

A serial-only machine

It communicates over a serial link with no documented protocol, so the protocol has to be reverse-engineered before the machine says anything usable. That is bench work of genuinely unknown duration. It might resolve in days. It might not resolve at all, in which case the answer is a sensor retrofit or a decision to leave that asset out of scope.

A controller with no OPC UA server on it

The machine is modern, networked and perfectly capable. The server is just not installed on it yet, so there is nothing for the collection hub to subscribe to. Installing it means touching a controller that is currently running production, which means a scheduled window, which means the plant’s calendar rather than the project’s.

The engineering is rarely the hard part. The hard part is that each fix depends on access, permission and a moment when the line can be interrupted.

Why the connectivity assessment is its own phase

Implementation opens with Phase 0, initiation and pre-implementation design. Immediately after it, before anything is configured, comes Phase 0.5: a network and machine connectivity assessment.

Giving that its own phase is a deliberate admission. It says the answer to what can be connected here is not known in advance, is not inferable from a machine list, and is expensive enough to be worth finding out before anyone commits to a schedule. A project that skips it does not avoid the discovery. It just makes it in month three, with a date already promised.

The readiness gate, and what happens if it fails

Phase 1 is the AI and data infrastructure readiness gate. It is a real go/no-go, and it produces a readiness score and a site tier.

A gate that can only pass is not a gate. If the readiness assessment finds gaps, the site moves into Phase 1A, the data backbone work: unified namespace architecture, asset modelling, an integration blueprint, and governance. Only then does Phase 2 begin, module implementation and configuration per site, which carries a hard integration-validation gate of its own. After that comes data validation, then pilot, then rollout and sustainability.

The readiness gate and the integration-validation gate can each send a site backwards, and both sit before the interesting work. That is uncomfortable to sell and much cheaper to live through.

Plan around the slowest machine, not the average

An average tells you almost nothing here, because the machines are not interchangeable and the work does not parallelize the way an average implies. Most of a line can connect cleanly in a week while one asset on it sits behind a serial link nobody has documentation for. The average across that line looks healthy. The line is not usable for anything that needs the whole line.

So the honest way to scope this is to find the worst machine first and plan the schedule around it. That reorders the work in a way that feels wrong at first, because the instinct is to start with the easy connections and build momentum. The easy connections were never the risk. Starting with the hardest asset means the unknown duration starts running on day one, in parallel with everything predictable, instead of surfacing at the end when there is nowhere left to absorb it.

It also changes what a status report means. Counting connected machines rewards the easy ones. Reporting on the slowest unresolved blocker tells you when the line will actually be live.

What the plant has to bring

Most of the schedule risk sits with the customer, and naming it early prevents a bad-fit engagement.

• An on-site MQTT client, correctly configured, publishing every reporting device. Ignition is the recommended collection hub for this.
• Outbound internet access from the plant infrastructure.
• Firewall and VLAN posture settled, including the MQTT topic access rules.
• Data formatted to the data models agreed for each machine type: field mapping, type conversion, mandatory fields populated, validation.
• The plant’s own decisions on role definitions, retention policy, purge policy and escalation workflows.

Credentials and certificates for the connection are issued by mode40, per site, which means provisioning is a manual step rather than something a site does for itself.

What this should change about your plan

Walk the floor before the schedule is written, and mark every asset by how it communicates rather than by how important it is. Put the unknowns at the front. Treat the connectivity assessment as the thing that produces your date, not as a formality on the way to it. And when a vendor gives you a timeline before they have seen your controllers, ask which machine on your floor they think will be the hard one. The answer tells you whether they have done this before.

Keep reading