Why It’s Time to Unbundle OPC UA for Industrial AI

Every so often I have to eat my words in public, and today it’s OPC UA’s turn on the menu. For a long stretch, I was the guy grumbling that the thing was bloated — layer upon layer, a specification you practically needed a doctorate to implement. Turns out my complaint was half a truth wrapped around a bad conclusion.

The part I got right was the surface. The part I whiffed on was the why.

Why OPC UA Was Over-Engineered by Necessity

When OPC UA was taking shape twenty-odd years ago, the automation world had almost nothing to lean on. Industrial Ethernet was still finding its footing, EtherNet/IP and PROFINET were early-stage, and the lightweight messaging we take for granted now — MQTT, Sparkplug, plain old REST for machines — either didn’t exist or wasn’t on anyone’s radar.

If you wanted two devices to genuinely understand each other, you had to invent the whole chain yourself: security, transport, encoding and the model. OPC UA did exactly that. What looked like over-engineering was really just building the road while driving on it.

Fast forward to now and the ground has shifted underneath all of it. Shuttling bytes between machines is a solved, commoditized problem. It is the equivalent of dial tone. Nobody frets about whether the phone line will work.

The action has moved up the stack to meaning: how information is described, structured, and understood. Matthew Parris, Director for Quality Test Systems for Industry 4.0 at GE Appliances, has been hammering this point, and he nails it:

“The value of the information is only realized after a consumer can receive and interpret it.”

Transport is table stakes. Interpretation is the prize.

Why the OPC UA Information Model Matters for AI

Matthew’s reframing is what finally rearranged my thinking. The crown jewel of OPC UA was never its client-server plumbing or its pub/sub engine. It’s the type system, which provides a genuinely world-class way to model industrial information and the relationships between things.

The Clean Energy Smart Manufacturing Innovation Institute (CESMII) already treats it that way, anchoring its Smart Manufacturing Profiles on that type system. And the timing could not be sharper: as AI agents push into plant operations, they can’t do much of anything without well-structured, semantically rich data underneath them. Feed them ambiguity and you get expensive guesswork.

So, the model is what we’re after. Being dragged through an entire OPC UA implementation to get it is friction nobody needs.

Cutting Through the Node Set Bloat

Parris’s Blueprint paper shows how real that friction is. The type system is handed out as one enormous file, Opc.Ua.NodeSet2.xml, north of 83,000 lines of XML, once too large for GitHub to even display. Yet OPC UA’s own architecture already draws clean lines between the modeling building blocks, the core models and the access machinery. An experimental filter proved the point, shrinking the file to roughly 7 percent of its bulk while keeping the modeling essentials intact.

The Prescription: Take a Hacksaw to the Stack

My prescription hasn’t changed, only sharpened: take a hacksaw to the stack. Cut the type system loose, package it as a standalone artifact and let integrators bolt on whatever transport suits them. Brand it, ship it and get out of the community’s way.

I’ve been wrong before. This time, I’ll bet I’m not.