How implementation works

This is the framework we use internally. Two of the phases can route a site backwards.

The phase sequence

Implementation runs as a sequence of named phases. They are a project sequence. They are not environments, and there is no separate sandbox to promote work through.

Phase 0

Initiation and pre-implementation design. Scope, sites, and the design work that has to exist before anything is connected. One decision taken here carries commercial weight: whether the MQTT infrastructure is client-managed or provider-deployed.

Phase 0.5

Network and machine connectivity assessment. A survey of what is physically reachable on the floor, and what is not. This phase exists to find the blockers described further down while they are still cheap.

Phase 1

AI and data infrastructure readiness. A go/no-go gate, covered in the next section.

Phase 1A

Data backbone. Runs only where the readiness gate finds gaps: universal namespace architecture, asset modelling, the integration blueprint, and governance.

Phase 2

Module implementation and configuration, run per site, ending at a hard integration-validation gate.

Data validation, pilot, rollout, sustainability

The closing sequence. Validate the data that is now flowing, prove the modules against one area, extend to the rest of the site or the rest of the estate, then move to a steady operating state.

Phase 1: the readiness gate

Phase 1 is a genuine go/no-go. A site either clears it or it does not, and the assessment produces two outputs: a readiness score and a site tier.

A site that does not clear the gate does not proceed to module implementation. It goes to Phase 1A instead, and the data backbone gets built before anything is configured on top of it. This is deliberate. Configuring modules over a data foundation that was never assessed is how a programme produces confident output from unreliable input.

The tier is what that fork is called. Tier 1, Fully Ready proceeds to Phase 2. Tier 2, Conditionally Ready routes to Phase 1A, and it is a conditional pass rather than a rejection: the site is viable, the backbone under it is not ready yet.

For a multi-site programme, the tier is what tells you where each site actually stands. Sites in the same company routinely land in different tiers, because the floor equipment and the network posture differ plant by plant.

Phase 1A: the data backbone

Phase 1A runs where the readiness gate finds gaps.

• Universal namespace architecture. The naming and topic structure that everything downstream depends on.
• Asset modelling. Describing the plant as structured assets rather than a list of tags.
• Integration blueprint. Which systems feed which data, along which path. It also settles the middleware bridge, built by your team or bought from mode40, which is the same fork Phase 0 raises.
• Governance and access controls. The rules for who owns and changes what.
• Verification and site readiness gate. Phase 1A closes at a formal gate into Phase 2 rather than trailing off, so the backbone is checked before modules are configured on top of it.

The governance workstream is where the customer sets its own role definitions, retention policy, purge policy, escalation workflows, firewall and VLAN posture, and MQTT topic access rules. Those are customer decisions, and mode40 does not supply defaults for them. Your data covers the retention and purge side.

Phase 2 and the integration-validation gate

Phase 2 is module implementation and configuration, done per site rather than once for the whole estate.

The phase closes at a hard integration-validation gate. Integration has to be validated before the phase is complete, which means a site can sit in Phase 2 while a single unresolved connection is chased down. Treat that gate as a real schedule risk when you are planning a rollout across several plants, because one site stalling in Phase 2 does not stop the others, but it does stop that site.

Connecting the machines takes the longest

The longest task in an implementation is usually physical. Getting a machine to emit data reliably takes more calendar time than configuring the modules that consume it, and almost none of that work happens in software.

Blockers seen in live engagements:

• A legacy controller behind a NAT. The machine is capable, but it is unreachable until a firewall change is made. That change belongs to the customer’s network team and moves at the speed of the customer’s change control.
• A serial-only machine. No modern protocol at all. It needs protocol reverse-engineering before it produces anything a system can consume, and the effort is specific to that machine.
• An OPC UA server not yet installed on a PLC. The controller is reachable and still unreadable, because the software layer that would expose its data was never put on it.

None of the three is solved by the platform, and none is solved by scheduling harder. Each is a physical or network task, and most of that work is yours. Phase 0.5 exists to surface these early, and the realistic way to plan a site is around the slowest machine on the list rather than the average one.

What you bring

• An on-site MQTT client, correctly configured, publishing every device that is meant to report.
• Data formatted to the data model agreed for that machine type. That means field mapping, type conversion, populating the mandatory fields, and validating the result.
• Outbound internet from your own infrastructure. The connection runs outbound, so no inbound opening is required.
• In the governance workstream: role definitions, retention policy, purge policy, escalation workflows, firewall and VLAN posture, and MQTT topic access rules.

Ignition on site is the recommended collection hub, and it is the shape mode40’s own architecture assumes. How systems connect has the protocol detail.

The middleware choice

The bridge between your ERP and the platform can be built by your team, or bought from mode40 as a custom development service at additional cost. It changes both cost and schedule.

Buying it is a separate engagement rather than something the licence covers. Build it in-house and you own the maintenance of it. Neither answer is wrong. Deciding it late is what hurts, because the ERP bridge tends to sit on the critical path.

It surfaces twice in the sequence. Phase 0 raises it as part of pre-implementation design, in the same conversation as whether the MQTT infrastructure is client-managed or provider-deployed. The Phase 1A integration blueprint then revisits it with the real integration list in hand. If it is still open when Phase 2 starts, it is late.

What we bring

• The cloud platform and the licensed modules.
• Configuration and onboarding support through the phases above.
• Secure hosting and application monitoring.
• Credentials and certificates, issued during onboarding.
• Standard software updates.