Every cloud manufacturing platform works beautifully on a good connection. That is not where the engineering is.
The engineering is in the twenty minutes when the site uplink is gone, three shifts are still producing, operators are still confirming work, and the system has to behave in a way that does not lose production data or create phantom inventory when the link returns.
If you are evaluating or building in this space, here is what that actually requires.
The tiering, restated as a constraint
Three tiers, and the assignment is not a preference.
Controller tier — deterministic control, interlocks, safety. Never depends on anything off-premises. Not negotiable, not a transitional arrangement.
Edge tier — protocol translation, local buffering, operator-facing interfaces that must work offline, and latency-sensitive inference such as visual inspection at line speed.
Cloud tier — history, analytics, training, optimisation, cross-site comparison, integration with systems of record.
The interesting consequence: your operator terminal is an edge application that syncs, not a web client that happens to be cached. Those are different products, and vendors frequently blur the distinction until you ask directly.
Store-and-forward, specifically
The naive version — queue requests, replay them on reconnect — fails on contact with reality in three ways.
Ordering. Confirmations for the same work order must replay in the order they were made, or a partial-quantity sequence produces the wrong end state. A global FIFO queue is heavier than you need; partition by aggregate root — usually work order — and preserve order within the partition only.
Duplication. Retries are guaranteed. Duplicate postings are not acceptable, because a duplicate production confirmation is phantom inventory that somebody will reconcile by hand at month end. Generate an idempotency key at the edge, deterministically from the business event, and require the cloud to deduplicate on it. Do not rely on the ERP downstream to catch this; most will not.
Bounded buffers. A four-hour outage on a busy line generates a lot of events. Define the retention policy before it matters: how much local storage, what happens when it fills, which classes of event are dropped first. Telemetry can be decimated. Confirmations cannot be dropped at all, which means you need a hard cap on telemetry buffering to guarantee space for transactions.
Clocks, and why they will hurt you
Edge devices drift, get reimaged, and occasionally come up with a clock set to the epoch.
Never use edge wall-clock time as authoritative for ordering. Carry both: a monotonic sequence number per device, which is what you order by, and the device's wall-clock reading, which is what you display and treat as advisory. On reconnect, the cloud can reconcile device time against its own and flag implausible skew rather than silently accepting timestamps that put last night's production in 1970.
Reconciliation as a first-class feature
Store-and-forward gets you eventual delivery. It does not get you agreement.
Run a continuous reconciliation job comparing edge-recorded output against cloud-posted quantities for each work order and shift, and alert on drift. The failure you are guarding against is not dramatic — it is a slow divergence caused by a dropped batch, a rejected posting that was never surfaced, or a device that has been buffering to a full disk for two days while appearing healthy.
Discovering that at month end is a bad month. Discovering it within an hour is a ticket.
Conflict rules you have to decide in advance
Two systems will eventually disagree about the same work order. Write down the rule now.
The one that has held up for us: the edge wins on what physically happened, the cloud and ERP win on what was authorised. If an operator confirms more output than the order authorised, record the reality and raise an exception. The parts exist. Rejecting the confirmation does not un-manufacture them, it just loses the record.
The same principle covers material consumption exceeding the planned quantity, and operations confirmed out of routing sequence. Record, flag, do not reject.
What to require in a vendor demo
Ask for these specifically, in this order.
- Disconnect the uplink physically, mid-shift, with operators mid-task. Watch what the terminal does.
- Continue confirming work for several minutes while disconnected.
- Reconnect and verify every confirmation arrived exactly once, in order.
- Submit the same confirmation twice and observe the deduplication.
- Ask what happens when the local buffer fills, and what the buffer size actually is.
Vendors who handle all five have thought about this properly. Vendors who decline the first one have answered the question.
The edge inference case
Visual inspection is where this architecture is least negotiable and most obviously worth it.
Inference runs next to the camera, because a reject decision at line speed cannot wait on a round trip. Training, labelling, versioning and rollout run centrally, because those benefit from pooled data and central governance.
The loop that works: capture at the edge, infer locally, ship uncertain cases upward with their images, retrain centrally on accumulated hard cases, push updated models down with staged rollout and a rollback path.
Treat models as deployable artefacts with the same rigour as any other release. Teams that ship a model without staged rollout eventually ship one that quietly raises false rejects on the night shift, and nobody notices for a week. We covered the build considerations in more depth in our piece on computer vision for business.
Protocols, briefly
Between the architecture and your plant sits thirty years of accumulated machinery. Some speaks OPC UA cleanly, some speaks Modbus through a converter, some writes a CSV to a share, and at least one critical asset has a controller whose vendor no longer exists.
Two decisions reduce the pain permanently: standardise on MQTT with a structured namespace for anything new, so adding an asset is configuration rather than a project, and put an edge gateway between the machines and everything else so that translation, buffering and security policy live in one governed place.
Budget seriously for this layer. In our experience connectivity is routinely a third of total effort on a first deployment, and estimates that ignore it are the ones that overrun.
Frequently Asked Questions
What is the hardest requirement in cloud MES?
Correct behaviour during connectivity loss — continuing to accept operator input, buffering in order, and reconciling on reconnect without duplicates or gaps.
How should idempotency be handled?
Generate a deterministic key at the edge from the business event and deduplicate in the cloud on that key. Do not assume downstream systems will catch duplicates.
Can edge timestamps be trusted for ordering?
No. Order by a monotonic per-device sequence number and treat device wall-clock time as advisory, flagging implausible skew on reconnect.
What should happen if an operator confirms more output than authorised?
Record the physical reality and raise an exception. Rejecting the confirmation loses production data without changing what was made.
How much effort does machine connectivity take?
Frequently around a third of total first-deployment effort. Audit every asset, its protocol and its data rate before committing to a timeline.
Full version with multi-plant patterns and a ninety-day pilot design: Cloud Manufacturing Software in 2026.
Top comments (0)