I have been around manufacturing IT long enough to see the same movie play out.
A site wants digital transformation. They buy a few tools. They connect some machines. They build some dashboards. Everyone celebrates for about six months.
Then the bill shows up. Not just money. Maintenance. Custom code. Vendor specific connectors. One off data models. New hires who inherit a spaghetti plate of integrations and quietly start rewriting it all from scratch.
So when I listened to the CESMII and I3X session at the ProveIt! Conference 2026, I paid attention.
Not because it was another platform pitch. It was the opposite.
The message was simple. We will not scale Industry 4.0 until we stop reinventing integration every single time.
And honestly. That is the right problem to obsess over.
The real problem. Not lack of tech. Too much fragmentation
Manufacturing productivity has not jumped the way many expected after 2010.
It is not because we lack technology. It is because we layered new technology on top of fragmented systems.
Here is the pattern I keep seeing.
- One vendor for HMI and KPIs.
- Another for quality.
- Another for contextualization and data movement.
- Another for analytics.
- Then a cloud platform to centralize everything.
Each system works. Sort of.
But each one has its own model. Its own API. Its own naming. Its own assumptions.
So every integration becomes custom. Every application becomes tightly coupled to one stack. Even when people use MQTT, the payloads are different. The naming is different. The meaning is different.
That is not smart manufacturing. That is expensive plumbing with better marketing.
CESMII. Profiles instead of opinions
CESMII’s angle is Smart Manufacturing Profiles.
In plain terms. Data needs contracts.
If I say OEE, Good Count, or Downtime Reason, it should not be a free for all. If one system publishes temperature in Fahrenheit, another in Celsius, and another already filtered. You do not have data. You have confusion at scale.
The session positioned OPC UA NodeSets as the modeling language for these profiles. I like that direction. It forces explicit definitions. It forces discipline. It creates reusable type definitions instead of one off JSON blobs.
This is where the Unified Namespace conversation gets serious.
A Unified Namespace without types is just a well organized junk drawer.
An MQTT topic tree is not a namespace if the structure and payloads are inconsistent. Without shared types and relationships, teams end up writing defensive code everywhere. “If the tag looks like this, do that.” That is a polite way of saying there is no contract.
Data is facts. Knowledge is the relationships between facts.
If those relationships are not modeled, they live in scripts and tribal memory. And that does not scale.
I3X. Tackling API chaos before it kills scale
Even if we agree on models and namespace rules, we hit the next wall.
Every vendor exposes a different API.
Different ways to browse. Different ways to query history. Different ways to subscribe. Different authentication patterns. Different quirks.
So application teams still build the same app three times for three different platforms.
That is API chaos. It quietly turns your enterprise architecture into a long term integration tax.
The I3X concept presented at ProveIt! 2026 is about defining a common interoperability API for industrial systems.
The goal is not to replace every proprietary interface. The goal is to standardize the common 80 percent.
The capabilities described were practical and boring. Which is good.
- Browse and explore namespaces
- Discover types and definitions
- Read live data
- Query historical data
- Subscribe to changes
If that sounds basic. Good. Basic is what scales.
A shared consumption layer above a Unified Namespace changes the economics of application portability. It reduces the penalty for adding new vendors. It lowers the cost of scaling from one site to ten.
The ProveIt! moment. Multi vendor interoperability in weeks
The live demo at the ProveIt! Conference 2026 was the part that mattered.
This was not a slide about future vision. It was multiple systems exposing data in a consistent way. A reference explorer style client was used to browse structure, pull live values, and query history through the same interface.
It felt less like a sales demo and more like an integration review.
A few details stood out.
- A reference explorer client validated consistent browsing and history access across vendors.
- A historian style component talked about scale numbers like 1 million tags and 200,000 writes per second. Whether every plant needs that is not the point. The point is that this is not positioned as a toy stack.
- Contextualized models were exposed through the same interoperability layer.
The key message was speed. Interoperability in weeks, not years.
That claim gets abused in this industry. But shared models plus a common API is exactly how you make that timeline plausible.
My honest opinion. Governance will decide if this works
Here is the uncomfortable part.
Most manufacturers do not have a technology problem.
They have a governance problem.
Standards only become real when someone enforces them. When a project is late. When a vendor pushes back. When a site says, “We are special.”
That means.
- Naming rules that do not get waived because of schedule pressure.
- Profiles that do not get bypassed because it is “just a pilot.”
- Vendor implementations that go deep, not just checkbox compliance.
- Procurement and architecture boards that demand data contracts.
If companies treat CESMII profiles and I3X as an operating model change, not a technical experiment, this could be significant.
If not, it becomes another strong conference demo that struggles in real plants.
I have seen both outcomes before. The difference is never the API specification. It is the discipline behind it.
Why this matters for plant connectivity at scale
When you are responsible for multi site architecture, your daily reality looks like this.
- Different automation stacks
- Different naming habits
- Different historian setups
- Different interpretations of “standard”
A common modeling approach plus a common interoperability API shifts the work up the stack.
Instead of rebuilding integration glue at every site, teams can build applications that travel. Less rework. Less custom mapping. Lower long term cost.
It also sets up the future conversations. Better analytics. Better AI. Better digital workflows.
Those do not run on raw tags. They run on consistent, trusted, well described data with clear contracts.
What I am watching next
A few things will determine whether this becomes real.
- Does vendor adoption go deep, or stay superficial?
- Do we get solid developer tooling that normal plant teams can use?
- Do end users demand compliance with profiles and APIs in governance and procurement?
If those things happen, the work CESMII (and I3X) showed at the ProveIt! Conference 2026 could become one of the more practical interoperability moves in recent years.
If not, it will still be a good demo.
And we will be back to writing custom integrations. Just with nicer slide decks.
This post reflects my personal opinions from sessions I attended at the ProveIt! Conference 2026.
I am not affiliated with the companies mentioned, and this content is not sponsored. Company names and trademarks belong to their respective owners.
Company referenced: cesmii.org
Leave a Comment