The edge is becoming the factory’s operational backbone

Manufacturers spent much of the last decade pushing data out of plants and into centralized platforms, but the pendulum is beginning to move again. Cloud remains essential for large-scale analytics and model training, yet the factory cannot always wait for a remote system to tell it what to do. As AI becomes part of production, the edge is starting to carry more of the intelligence and resilience that day-to-day operations depend on.

Dave McMorran, CTO at Litmus, sees the debate moving beyond the question of whether plant data should leave the factory. The more important issue is what the factory must still be able to do before and after that data leaves, particularly when operational decisions cannot depend on an external connection remaining available. That is changing the role of infrastructure that once existed mainly to move information elsewhere.

“The original way of getting data to the cloud was basically a gateway, doing protocol transformation and then sending raw data,” McMorran says. “What we are seeing now is more compute at the edge. You are starting to see machine learning, distilled AI and anomaly detection running locally, alongside the calculations you would traditionally associate with MES. The payoff is faster decisions and more resilience, while being smarter about what data you need to send to the cloud.”

Where the workload belongs

Moving more compute back toward production can sound like a reversal of cloud strategy, particularly after years in which manufacturers were encouraged to centralize data and applications. McMorran rejects that either-or interpretation because the useful dividing line is not architectural fashion but the operating requirement of the application. Some workloads gain from centralized scale, while others depend on conditions that only exist close to the process.

“One of the questions I get from customers all the time is, where should I do it?” he says. “They look at it as a binary choice between the edge and the cloud, but it is hybrid. Where do the inputs live, and does the application have to survive if I lose the cloud connection? You also must look at the cost, because very high-frequency data can become expensive to move, and sometimes it makes much more sense to preprocess that at the edge.”

That division becomes more important as manufacturers introduce AI into production. Training a machine-learning model can still take place in the cloud, where scalable compute is available, while inference can run closer to the process when a delay would undermine the use case. McMorran sees more manufacturers moving toward that split, particularly where local decisions must be made quickly or where sending every data point upstream adds cost without adding value.

Connectivity failures expose the difference between workloads that can tolerate delay and those that cannot. A reporting process can wait for a connection to return, but an application directly involved in keeping production running may have no such margin. Manufacturers therefore need to decide in advance which functions can pause safely and which must continue operating locally.

“That is not an if question. It is a when,” McMorran says. “Manufacturing must keep running. If an application is critical to making whatever you are making, keep that at the edge. The data that needs to get to the cloud can be stored locally and synchronized later.”

Standardize the data before scaling it

Brownfield manufacturing adds another layer of difficulty because production environments have usually evolved over many years, often plant by plant rather than according to a single enterprise architecture. Equipment from different generations and suppliers can coexist within the same estate, while local decisions made over time shape how each site operates. Creating a scalable edge strategy therefore starts with understanding the environment manufacturers already have.

“One of the biggest challenges is just knowing what you have,” McMorran says. “How many PLCs are there, what version are they, what SCADA systems and historians do you have? Then you find that even the same type of system can have different tag names because two different machine builders implemented it differently. You must find the data, normalize it and then decide what the model should look like so you can replicate that consistently across the enterprise.”

Once that inventory exists, the harder question is whether a machine state or production measure means the same thing at every site. Comparisons become unreliable if local systems use different names or calculate the same KPI differently, and those differences become more consequential when the data is reused by enterprise analytics or AI. McMorran argues that the point of normalization is to resolve those inconsistencies before they spread into downstream applications.

“If you are just sending raw data to the cloud, you are moving your mess from on-premise to the cloud,” he says. “You want to create the data model for what you need, agree the KPIs and calculations in one place, lock that in for the enterprise and then be able to replicate it quickly.”

Once data has been normalized and modeled consistently, manufacturers still need to know how it reached the enterprise layer and what happened to it along the way. McMorran sees that lineage as an important part of governance because teams need to understand which transformations took place between the PLC and the cloud, and whether the resulting information still represents the source correctly. Being able to trace a figure back through the industrial architecture gives plants a clearer basis for accepting common enterprise measures rather than simply being asked to trust a centralized number.

Creating that consistency across multiple plants also requires more than a centrally defined technical standard. Established PLC and SCADA tag names may already support local applications, so McMorran cautions against changing them simply to satisfy an enterprise model and instead favors normalization within the edge layer. He also sees value in having a local champion at each facility who understands the plant and can work with the enterprise team, allowing common models to be introduced without disrupting the operational dependencies that have developed around existing systems.

From local projects to operational infrastructure

Individual plants can prove the value of connected data with locally developed applications, but enterprise scale changes the problem. What works as a one-off project becomes harder to sustain when dozens of sites need the same model and updates must be governed consistently. McMorran says manufacturers often reach this point after an initial success has already demonstrated that the data is valuable, leaving them to work out how to reproduce the result without rebuilding it site by site.

Niagara Bottling is one example he points to, with more than 50 sites operating on one architecture. JLR followed a similar path at speed, moving from pilot to 126 edge deployments in six weeks once the underlying approach had been agreed. For McMorran, those examples reinforce the importance of settling the operating model around the data before treating technology as the answer to scale.

That operating discipline becomes even more important once manufacturers begin distributing machine learning and distilled AI models across production sites. A model that works at one plant has limited enterprise value if every deployment requires custom engineering or depends on data structured differently from the site before it. Consistent edge infrastructure gives manufacturers a way to replicate those workloads across the business while still accommodating the local systems and operating conditions beneath them.

“Edge is production infrastructure,” McMorran says. “Over the next three to five years, I think the edge is going to become the default operational infrastructure. It will still leverage the cloud, and it will leverage AI and machine learning whether those run in the cloud or on-premise, but that operational infrastructure needs to live at the edge because manufacturing is too critical to rely entirely on external systems.”

McMorran’s model still leaves a substantial role for the cloud, but it changes the division of labor between centralized and local infrastructure. Cloud platforms can provide the scale required for model training and wider enterprise analysis, while the edge supports the parts of production that depend on immediacy or must continue through a connectivity failure. As manufacturers expect AI to influence more operational decisions, the boundary between those environments becomes an engineering decision rather than a debate about which architecture should dominate.

For manufacturers developing an enterprise-wide strategy, McMorran advises beginning with a small number of agreed performance measures and use cases rather than jumping immediately to the most ambitious AI deployment. Once the organization has a common model for the data and a repeatable way to deploy it, more sophisticated workloads can follow without recreating the foundations at every site. The edge then stops being a technical waypoint between machine and cloud and becomes the operational layer through which manufacturing data can be governed and intelligence delivered reliably at scale.