OPC UA and AI:

Industrial interoperability is more than data exchange

For many years, industrial interoperability was primarily approached as a communication problem.
PLCs, SCADA systems, MES, ERP systems and industrial applications had to exchange information despite using different protocols, formats and technologies.
That problem still exists, but solving it is no longer enough.
Transporting a value such as:
72.4
tells us almost nothing.
Calling it:
Temperature
provides more information, but it is still ambiguous.
To actually use this information, we need its context.
What does it measure? Which piece of equipment does it belong to? What is its engineering unit? What type of equipment produced it? Which production process does that equipment belong to? How is this information related to other elements of the system?
This is the difference between transporting data and sharing its meaning.

An LLM can interpret data. It should not have to guess its meaning.

The capabilities of current Large Language Models are impressive. Given a variable name, documentation, a database schema or a few examples, a model can often propose a plausible interpretation.

It can also rapidly generate:

• mappings between data structures;
• APIs;
• JSON transformations;
• integration code;
• SQL queries;
• connectors between applications.

Some traditional integration work will therefore become significantly less expensive.
But there is a fundamental difference between inferring meaning and having an explicit definition of that meaning.
An AI system may reasonably infer that Temp_01 represents a temperature.
From that name alone, however, it cannot guarantee that this is the outlet temperature of a particular furnace, expressed in degrees Celsius, associated with a specific production unit and measured during a specific phase of the process.
In an industrial system, that distinction matters.
Probabilistic interpretation is extremely useful for exploration, search, assistance and recommendation. It does not replace explicit industrial knowledge when a system needs to understand — and potentially act upon — a real production environment.

OPC UA is more than a communication protocol

Reducing OPC UA to a communication protocol misses precisely this point.
OPC UA provides a meta-model for representing objects, variables, methods, types and the relationships between them.
An industrial asset therefore does not have to be exposed as a simple collection of tags.
It can be represented as an object of a defined type, with structure, properties, behaviours and relationships to other objects.
Information Models take this further by describing the structure and semantics associated with specific industrial domains.
Companion Specifications formalize this knowledge for machines, equipment and a growing number of industrial sectors.
The objective is no longer merely for another system to read a value.
It can also understand what that value represents within an industrial model.
Multiple Information Models rather than one universal model
It would nevertheless be unrealistic to assume that industry will eventually converge on one universal model.
A machine has its model.
A machine builder has its terminology.
A manufacturing process has its concepts.
A MES, ERP or maintenance system also has its own representation of industrial reality.
These models are not going to disappear.
Nor should they necessarily disappear.
One of the fundamental strengths of OPC UA is that multiple Information Models can coexist because they share the same OPC UA meta-model.
Interoperability therefore does not necessarily mean transforming every system until it conforms to a single representation.
It can instead mean allowing different models to coexist, to be understood and to collaborate.
This principle lies at the heart of OOUAMiddleware.

From the Information Model to the Runtime Model

An Information Model, however, is not sufficient if it remains only a description of the system.
Over more than twenty years of development and industrial deployments, OpenOpcUa has progressively evolved around another question:
How can industrial models become active components of the system itself?
This evolution led to OOUAMiddleware and its Runtime Model.
The Runtime Model loads, instantiates and operates industrial models within an execution environment.
Types, instances, relationships, services and behaviours are no longer merely described.
They exist within the platform runtime.
Models can then be connected to equipment, applications, databases and enterprise systems.
Workflows can orchestrate their behaviour.
Traceability can be built around the model.
Historization services can be associated with the relevant information.
Applications can operate on the same representation of the industrial system.
The model no longer merely describes the system. It participates in its execution.

When an ERP can participate directly in industrial execution

Consider a concrete example.
In a conventional architecture, a production order originating from an ERP system typically passes through several layers before reaching the production environment.
With a model-driven execution platform, the ERP does not need to know the PLCs or even the detailed structure of the machines.
It works with business concepts.
An OOUAMiddleware workflow can receive the production order, coordinate its execution across the relevant components of the industrial system, collect the information required for traceability, and return the resulting information to enterprise systems.
The ERP can therefore participate in the execution process without becoming an OT system and without directly interacting with the PLCs.
This separation is important.
Interoperability is no longer simply:
System A can communicate with System B.
It becomes:
Systems A and B can participate in the same process while preserving their respective responsibilities and models.

And now, artificial intelligence

AI agents introduce a new participant into this architecture.
An industrial AI agent may need to answer questions such as:

• Which equipment produced this part?
• Under what conditions was it manufactured?
• Which production order was active?
• Which measurements belong to this operation?
• Which pieces of equipment are of the same type?
• Which methods can be invoked on this equipment?
• What is the relationship between this alarm, this machine and this process step?

A database may contain the required values.
A Data Lake may contain even more data.
But neither inherently guarantees that the industrial relationships and meaning are explicitly available.
A structured industrial model changes the problem fundamentally.
AI no longer has to systematically reconstruct context from column names, documentation, local conventions and implicit knowledge.
It can operate on an explicit representation of the industrial system.

From industrial data to industrial knowledge

This may be where the most important transition is taking place.
For the past twenty years, industry has invested heavily in accessing data.
We connected machines.
We built historians.
We created Data Lakes.
We deployed IIoT architectures.
AI is now shifting the problem.
Having more data is no longer enough.
Digital systems need to understand what that data represents and how it relates to the real industrial world.
We are progressively moving from a problem of industrial data availability to one of machine-usable industrial knowledge.
OPC UA has a significant advantage in this transition: its architecture was designed from the beginning around a structured Information Model.
This direction is becoming increasingly visible as OPC UA Information Models and Companion Specifications are explored as structured semantic resources for AI-based systems, including retrieval, engineering assistance and agent-based architectures.
This does not reduce the value of Information Models.
It increases it.

OOUAMiddleware as an execution layer between industry and AI

This is also how we see OOUAMiddleware evolving.
OOUAMiddleware is not intended to become yet another AI platform.
Its role is different.
It provides AI systems with something they should not have to invent:
the structure of the industrial system;
the models of equipment and applications;
their relationships;
their context;
their services;
their behaviours;
the workflows governing their cooperation.
AI can then contribute what it does particularly well: search, interpret, correlate, assist, generate and — where architecture, governance and safety rules allow — act.
This leads to an architecture in which:
Information Models describe the industrial world.
OOUAMiddleware turns them into Runtime Models and orchestrates their execution.
AI tools and agents use this knowledge to understand and interact with the industrial system.
This combination is considerably more robust than asking AI to continuously reconstruct the meaning of an industrial environment from raw data.

AI does not make OPC UA obsolete

Artificial intelligence will profoundly change industrial integration.
It will automate some mappings, facilitate connector development, accelerate data analysis and make previously difficult systems easier to exploit.
But it does not remove the need for semantic interoperability.
It reinforces it.
The more capable machines become of reasoning about and acting upon industrial systems, the more they need an explicit, deterministic and verifiable representation of what they are manipulating.
An LLM can interpret the industrial world.
An Information Model can describe it.
A Runtime Model can make it executable.
OOUAMiddleware sits at the intersection of these three capabilities.
OpenOpcUa was created to implement OPC UA.
OOUAMiddleware now pursues a broader ambition: to make industrial models a shared execution and knowledge infrastructure for equipment, applications and the new generation of intelligent agents.