Why MES systems cannot run via the public cloud cover

Why MES systems cannot run via the public cloud

4 mei 2026

Darryl van der Peijl


​MES systems sit in the chain between the PLCs that control machines and the business systems that manage orders and planning. For direct line control and interlock scenarios, latency must stay as low as possible. Once you get into hundreds of milliseconds or seconds, you risk incorrect decisions, quality issues, and emergency stops.

The cost of latency

Latency in production environments is often underestimated. When MES systems process hundreds of queries per second, even a small delay stacks up. Move from local to a cloud region, and you are quickly looking at tens of milliseconds per call. Add that up across hundreds of interactions and you are in trouble within seconds.

In practice, the requirements are often even tighter. Direct line control and interlock scenarios demand sub-millisecond response times. With a connection to an external cloud region, that is simply not achievable.

Cross-region or long-distance connections always add latency. The further the cloud region, the greater the delay. For MES systems that need to communicate with machines in real time, that quickly becomes too much.

This is not theory

On a conveyor belt moving products at high speed, latency determines whether a quality check can intervene in time. In an extrusion process, latency determines whether pressure and temperature are adjusted quickly enough. Milliseconds make the difference between a good product and scrap.

One of our clients produces animal feed at locations worldwide, including remote production sites where internet connections are unreliable. A pure public cloud solution was never an option. MES systems had to run locally, close to the machines, with the low latency that production processes require.

What runs where

Azure Local deliberately separates what must run locally from what can run in the cloud. Local: MES systems, PLC communication, real-time quality checks, everything that is latency-critical. These workloads run on Azure Local hardware in the factory.

Cloud: centralized dashboards, AI model training, analytics on aggregated data, software updates. These services run in Azure.

Management layer: Azure Arc connects the local infrastructure to the cloud. This lets you manage everything from a single location, even though workloads are distributed.

Think of AI for process monitoring: the model is trained in the cloud on large datasets, but inference runs locally. Or predictive maintenance: sensor data is processed locally, only aggregated insights go to the centralized dashboard.

Want to discuss which workloads should run locally in your environment? Get in touch.

This article is part of the longread Factory of the Future.

Darryl van der Peijl

Gerelateerde blogs