Is Physical AI the Next Level for MES? I Think It Is

After more than twenty-two years around manufacturing and industrial systems, I’ve asked myself this more than once: if a plant already has PLCs running the machines and SCADA or a DCS supervising them (often decades of it, deeply reliable) why did anyone ever buy an MES on top of that?

The honest answer is that control and execution are two different jobs. A PLC keeps the process running correctly right now. ISA-95 draws the layers: sensors and actuators at the bottom, PLCs and SCADA/DCS doing real-time control above them, MES sitting at Level 3, ERP at the top. MES was never about the millisecond control loop. It existed to answer a slower, harder set of questions: how well are we operating, how do we make it better, and how do we stay agile when the same line has to build many different things? It turned machine reality into operations: scheduling, dispatch, traceability, OEE, quality, genealogy, the eleven functions the MESA model lays out. For the work I know, the value was in coordinating and improving the operation above the real-time machine-control loop.

I think the next useful step is a loop that can compare an operating change before someone commits it, then observe what happened. Physical and agentic AI can help with that. They still depend on coherent plant data and on explicit authority over what may change.

Control runs the process; MES (Level 3) exists to run the operation, and every layer is a different technology, joined by standardized seams.

The flexibility requirement becomes concrete on a mixed-model line. Manufacturing has moved hard from single-product lines toward mixed-model production (many variants intermixed on one line, lot size one) and from build-to-stock toward build-to-order and mass customization, where a unit isn’t made until someone orders that exact configuration. Picture a paint line running a mix of car models and colors in sequence, or an assembly line where consecutive units are each a different build, delivered just-in-sequence. That’s the environment MES has to run in now, and it’s a fundamentally different problem from a line that makes one thing all day.

And the people who got the most out of it were the plant managers and shift supervisors running the floor day to day, and the process and continuous-improvement engineers behind them. Their whole job is to make the operation better: more yield, more throughput, less scrap, tighter quality, and the flexibility to absorb a changing product mix without the line falling over. MES gave them the data to see what was happening.

In those programs, the reporting system could show the problem but did not provide a safe place to rehearse the fix. Testing a change often meant a physical line trial, with downtime and scrap at stake. The cost of that experiment limited how many alternatives we could try.

Two assumptions that became the ceiling

Two constraints in the MES work I know help explain why that next step is difficult.

The first assumption: model everything explicitly, up front. Entities, routes and exceptions had to be defined and connected across systems. Standards such as OPC UA and B2MML helped define the handshakes, but integration and shared meaning still required work.

I worked with a FactoryTalk ProductionCentre deployment whose schema ran well past a thousand relational tables. Mixed-model, build-to-order production added variants, options and routes that had to be represented per unit.

Reporting added another layer. Operators, quality, maintenance, supervisors and plant managers needed different views. Through the 2010s we built more than a hundred dashboards, then SAP BusinessObjects Universes to feed them: hand-built semantic layers defining dimensions and measures. At one customer we added dedicated BI engineers to the MES team to keep the reporting alive.

Manufacturing-intelligence products tried to unify those views. Systems such as FactoryTalk VantagePoint and Siemens XHQ brought operational sources together, but teams still had to define and maintain their shared meaning.

The second assumption: show the data, and a human decides. Improvement was report-and-decide by design. The MES surfaced the number; a person read it and judged what to do. Which means the human was the throughput limit on improvement: you could only get better as fast as people could read reports, meet about them, and act. The BI engineers weren’t a bug; they were what it took to keep feeding a fundamentally human decision loop.

MES sat where two kinds of fragmentation met, and the industry answered each by adding more layers.

Physical AI and agentic AI can loosen both assumptions, but only if they are working from shared operational context. That does not mean replacing every plant system with one model. It means linking the spatial model, asset identities, live state, orders, and history well enough that a simulation or an agent is not guessing which version of the plant is real. Decisions can then move through software where the risk allows it, with people still holding the gates that matter.

Walk the floor

I can see the change most clearly in the modules I know best. Physical AI and agentic AI are not two separate initiatives there. They often meet in the same operating loop, using the same linked context for different jobs.

Five places where the operating pattern could change. The system boundaries will still depend on the use case.

Material movement and the warehouse. Today the MES tracks moves, reconciles locations, and keeps WIP honest in its tables. A more autonomous version adds AMRs that perceive and navigate, with software re-routing the fleet against live demand rather than a fixed plan. Synthetic data can reduce how much footage has to be collected by hand, and edge systems such as Jetson Thor can keep perception and planning near the vehicle. MES does not become the robot controller. It remains one source of operational truth while the fleet manager, map, orders, and live plant state are tied together around it.

Scheduling and JIS/JIT sequencing. Today MRP and heuristics produce a plan, and when reality diverges, a planner often re-sequences it. That is hardest on a mixed-model line where the order decides whether the right parts arrive just in sequence and whether paint or tooling changes stay efficient. An agent could propose a new sequence from live orders, machine state, and labor availability, then test it against a digital twin before a planner commits it. OpenUSD can hold the composed spatial scene for that simulation in Omniverse; MES and ERP still own the production orders and genealogy that make the scenario meaningful. A useful comparison also has to arrive in time: the decision window determines whether the original solver is fast enough or a surrogate is worth testing.

Recipe and process design. Today recipes are authored and then validated on real equipment under change control. Simulation offers a cheaper place to explore some parameter changes before a line trial, with an optimizer or agent proposing candidates against the twin. The real process still decides whether the model was faithful enough. I would use the twin to arrive at the controlled trial with fewer bad options.

Quality inspection. Today, on many lines, quality still combines sampling plans, SPC charts, and defects that are flagged after the process has already moved on. In-line vision AI can inspect more of the work, while an agent can assemble the evidence for root-cause analysis or propose an upstream adjustment. The authority to change the process is a separate design decision. One example is an SOP assistant for Foxconn’s Bianca-board assembly: NVIDIA reports that DeepHow used Metropolis video search and summarization with Cosmos models, and that the system helped improve first-pass yield by 3%. NVIDIA is the source for that result, so I treat it as a vendor-reported deployment figure. It is still more useful than a generic accuracy claim because it ties the system to an operating measure.

Maintenance and asset health. Today many plants mix time-based maintenance with reactive work. Condition data such as vibration, temperature, acoustics, and current can help estimate risk before a failure, while an agent can gather the history, check parts, draft a work order, and propose a downtime window. I would still keep diagnosis approval and work authorization explicit. An automatically written work order still needs an approved intervention behind it. An older U.S. Department of Energy operations guide cites industry averages of 25–30% lower maintenance cost and 70–75% fewer breakdowns following the introduction of a predictive-maintenance program. I would not apply those broad historical figures directly to a particular plant. Separately, a 2017 Deloitte article reports 5–10% lower maintenance costs and 10–20% more equipment uptime and availability. The useful shift is from logging the event afterward to seeing enough evidence to act earlier.

These five cover only part of MES. The MESA model counts eleven functional areas: detailed scheduling, resource allocation and status, dispatching production units, document control, data collection and acquisition, labor management, quality management, process management, maintenance management, product tracking and genealogy, and performance analysis. I picked the five where the change is easiest to feel. Across them, the direction is from report-and-decide toward systems that can perceive, simulate, and sometimes act from linked operational context.

What ties all five together

None of those five works if every system means something different by the same asset, order, or location. What is needed is shared operational context, not one giant replacement database. The spatial model describes the plant, line, cell, geometry, and physical relationships. MES and ERP remain authoritative for orders, genealogy, and business state. Historians and asset services keep the time series, identity, and live condition data they are built to manage. A semantic and identity layer links those representations so a simulation, a robot, a vision system, and an operations agent can refer to the same thing without pretending all of their data belongs in one file.

OpenUSD is a strong foundation for the spatial part. It began at Pixar as a way to compose large 3D scenes from many authored layers, and that same design is useful when CAD, layout, simulation, and robotics each need a view of the same physical environment. Omniverse can run simulations against that composed scene. It does not remove the work of mapping plant identities and semantics, and it should not be asked to replace transaction systems or historians. Its value is giving those systems a shared spatial frame they did not have before.

The spatial model, identity links, and operational systems form the context together. No one layer owns all of it.

That’s why I keep Physical AI and agentic AI in the same conversation. Physical AI perceives, simulates, and acts in the physical setting; agentic AI reasons over the evidence and coordinates work. They become useful together when the asset identities, spatial relationships, and operating state line up well enough that both are referring to the same plant.

Where I’d temper this

I don’t think the whole pyramid collapses at once, and it would be dishonest to pretend otherwise.

The safety-critical control edge is the hardest part to converge. Deterministic controller loops, safety interlocks, and AI perception workloads have different timing and assurance requirements. Putting a GPU at the edge means vision, condition monitoring, or planning can run close to the line instead of waiting on a distant data center. It does not mean moving a certified interlock into a probabilistic policy. The interesting architecture is the boundary between them: AI can propose or guide an action, while deterministic control and explicit safety functions keep authority over the machine where the risk demands it.

Most plants still do not have this linked context. The reason we needed a hundred dashboards and a hand-built Universe in the first place is that the data was never coherent: different sources, identifiers, and meanings. Point an agent at that mess and it may produce a confident answer from mismatched records; run a twin on bad state and it will give a precise answer to the wrong plant. Building the mappings, ownership, and update paths is still the work. Physical AI does not supply that foundation, and agentic AI does not magically infer it. Both depend on it.

So, is it the next level?

Yes, I think it is, but not because MES gets an AI feature or a chatbot. The change is that more of the operation can be perceived and simulated before a person commits the next move, and some low-risk actions can be coordinated automatically. MES does not disappear. It remains part of the operational record while a spatial twin, live plant services, and AI systems make that record more useful for improvement. The future is still a stack of systems. The difference is whether they share enough context to work as one operating loop.

I take that proposal further in Rethinking MES: A Shared Architecture for Physical AI, working through the shared foundation, a batch decision and an engine-station exception.

Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA.