Developers
A pre-flight for the engineer who will own the connection: what gets assessed before configuration starts, what your own team has to decide, and what actually holds a plant up.
An implementation does not begin with configuration. It begins by finding out whether the site can carry the data path at all, because that is the thing most likely to be wrong and the thing most expensive to discover late.
Read this before a date is agreed rather than after. Most of what follows is work at your site, on your equipment, on your network, and every item on it has a lead time that belongs to your organization rather than to mode40.
Before any configuration, implementation runs a dedicated network and machine connectivity assessment. It maps which machine assets can be reached and how, and establishes whether the site can carry the MQTT path and the namespace above it.
What that produces is a real inventory rather than an assumption: which machines expose signals today, over which of OPC UA, Modbus or BACnet, which are reachable from where the collection hub will run, and which are not reachable at all yet. The machines in the last group are the schedule.
The assessment runs against its own workbook, and it is a hard precondition for the readiness gate rather than something that can run alongside it. Readiness is then scored on connectivity confirmed machine by machine instead of connectivity assumed at scoping.
After the assessment comes a genuine go or no-go. The readiness gate produces a readiness score and a site tier, and it is the point at which a site either proceeds to configuration or does the data backbone work first.
A readiness scorecard, with its own workbook behind it, carries the scoring. It covers data infrastructure, integration capability, floor connectivity, governance, change readiness and machine data readiness. Integration capability is the widest of those: ERP, QMS and SCADA integration, the extraction pathway off each of them, and MQTT connectivity that has been confirmed rather than assumed.
The tier is the part that decides what happens next. Tier 1, Fully Ready proceeds to configuration. Tier 2, Conditionally Ready is not a failure, it routes the site into the data backbone work below and configuration waits until that closes. Plan a rollout so a Tier 2 result is survivable, because a site can come out of the gate with a phase of work in front of it rather than a start date.
It is worth treating this as a gate rather than a formality. A site that passes it has a namespace, an asset model, and a connection path that already work. A site that does not has at least one of those to build, and building it inside a configuration phase is how implementations slip.
Where the gate finds gaps, a data backbone phase runs to close them before configuration starts. It carries the UNS architecture, the asset modelling, the integration blueprint, and the governance work.
The first two are covered in Asset model, because they are the ones that decide how the operation is addressed for the life of the deployment. The integration blueprint settles which systems connect, over which protocol, in which direction. The governance work is described below, because most of it is yours.
The governance work asks your organization to state things only your organization can state. None of it is a platform setting, and none of it can be filled in on your behalf.
Do these early. They are the items most often left until the week a phase starts, and they are the ones that need a security team, a compliance owner, and a decision rather than an afternoon.
The single most useful thing to know before scheduling an implementation is that the work that runs long is not software. What has actually held sites up, on live engagements:
None of those is solved by the platform. Each one consumes site time, usually a change window, and frequently a vendor. Count the machines in each of these states during the connectivity assessment and put them on the plan as their own line items rather than folding them into a phase.
There is no development, test and production separation and no sandbox. The implementation framework has phases, which is a project sequence rather than a set of environments, so a phase gate is not a place to try something reversibly.
There is also no on-premise install, no air-gapped deployment, and no deployment into cloud infrastructure a customer controls. The only customer-premise component is the on-site MQTT client. If a mandate requires otherwise, settle it in the first conversation rather than at the readiness gate.
How implementation works has the full phase sequence. Connecting a site is the data path itself, end to end, and Division of responsibilities is the full split of who does what.
We use cookies to understand how the site is used and to connect form submissions to earlier visits. No analytics or marketing cookies are set until you choose. Privacy Policy