Why OPC UA Information Models Matter More in the Age of Industrial AI Agents
How existing OPC UA information models can support AI-driven exploration, industrial traceability and evidence-based answers through the Model Context Protocol.
Introduction
The emergence of industrial AI agents raises a familiar engineering question: how can software interpret industrial data without relying on application-specific knowledge of every equipment, variable and process?
For years, industrial integration has focused heavily on connectivity and data acquisition. OPC UA addressed a broader requirement by introducing a standardized information modeling framework capable of representing equipment, types, properties and relationships.
These capabilities become particularly relevant when AI agents are introduced.
An agent can retrieve a temperature value through an API or a communication protocol. But identifying the equipment concerned, distinguishing a measurement from a setpoint, or establishing the relationship between a production operation and its consumed materials requires additional information.
Much of this context can already be represented in OPC UA information models.
The OPC UA meta-model provides a common framework in which different domain-specific models can coexist, retain their own semantics and be explored through standardized mechanisms.
With the Model Context Protocol (MCP), these existing models can also become accessible to AI agents through dedicated exploration and data-access tools.
At 4CE Industry, we implemented an MCP interface within OOUAMiddleware to investigate this approach. Our demonstration uses a synthetic stator manufacturing model to examine how an agent can navigate OPC UA relationships, retrieve production information and identify incomplete material traceability.
The experiment illustrates both the potential of existing OPC UA information models and the limits of conclusions drawn from incomplete industrial data.
1. Industrial Data Requires an Information Model
Many industrial systems still expose measurements as named tags. A name and value do not, by themselves, establish the associated equipment, production operation or engineering meaning.
For example:
TT_101 = 180.0
The value is ambiguous without a declared unit, source and role in the process.
It could represent a measured temperature, a setpoint, an alarm threshold or a calculated result. Its relationship to a specific machine or production operation may only be known to the application developer.
OPC UA provides mechanisms to represent this context explicitly.
An OPC UA AddressSpace contains Nodes organized through typed References. Objects, Variables, Methods, ObjectTypes, VariableTypes, DataTypes and ReferenceTypes provide the elements needed to describe an industrial system.
An equipment instance can therefore expose its properties and components while maintaining relationships to other equipment, operations and materials.
An agent can navigate these structures to discover the equipment and relationships relevant to a question, subject to the model and data actually exposed by the server.
2. The OPC UA Meta-Model and Model Coexistence
An important property of OPC UA is the distinction between its meta-model and the domain-specific information models built upon it.
The OPC UA meta-model defines the common mechanisms used to represent Nodes, types, attributes and References.
Domain-specific models define the meaning of the equipment, operations and information represented using those mechanisms.
This distinction allows multiple OPC UA information models to coexist within the same AddressSpace.
A manufacturing model, an energy model and an application-specific model do not need to be merged into a single universal business model.
They can retain their own namespaces, type definitions and domain semantics while using the same OPC UA modeling framework.
OPC UA Companion Specifications extend this approach by defining standardized information models for particular industries and equipment categories.
An agent can use standard OPC UA mechanisms to inspect the types and references associated with an instance and retrieve information relevant to a particular task. The domain-specific meaning remains defined by the corresponding information model.
However, sharing the OPC UA meta-model does not automatically establish semantic equivalence between different domain models.
The relationships and meanings required by the application must still be explicitly represented or otherwise established.
3. Making OPC UA Models Accessible Through MCP
MCP defines a mechanism through which applications and AI agents can discover and invoke tools exposed by an external system.
In an industrial context, these tools can provide controlled access to information that already exists within an OPC UA environment.
Figure 1 shows the logical access path used in the demonstration.
OOUAMiddleware maintains the configured OPC UA AddressSpace and provides access to the associated runtime services.
Its VpiMcpSrv extension exposes MCP tools through which an agent can inspect the model and retrieve available information.
The implementation currently provides twelve tools covering several operations:
| Capability | MCP tools |
| Node identification and navigation | get_node, browse |
| Type and instance inspection | get_type, find_instances_of_type, get_type_model, get_object_model |
| Value access | read_value, read_values |
| Historical data | read_history_raw |
| Context exploration and verification | get_operation_context, validate_context |
| Value writing | write_values |
The twelve tools provide model navigation, type and instance inspection, value reads, raw historical reads, contextual checks and value writing. The traceability demonstration uses read-only operations.
The agent does not generate the manufacturing model. NodeSets, instances, references and data sources are configured in the OOUAMiddleware project before the agent accesses them.
4. Demonstration: Material Traceability in Stator Manufacturing
To evaluate the approach, we constructed a synthetic manufacturing information model representing stator production.
The model contains stator instances, press-fit operations and copper materials.
It also includes relationships describing which materials were consumed during manufacturing.
The demonstration uses dedicated types, including:
- StatorType
- PressFitOperationType
- CopperTorretType
A custom HasConsumedMaterial ReferenceType establishes the relationship between a stator and the material consumed.
Production operations contain additional information, including measured insertion temperature, engineering unit and operation completion date.
The demonstration includes six stator instances, S001 through S006, with intentionally different levels of traceability completeness.
Figure 2 — Example OPC UA Information Model for Manufacturing Traceability
Starting with a business question
The user asks:
“Which stators are linked to copper batch DEMO-CU-A? Identify the relationships supporting the answer.”
The user does not provide NodeIds or specify which variables must be read.
The agent must identify the relevant objects and follow the modeled material relationships. A related test case adds a numeric condition: copper reference R2568-B and an insertion temperature strictly greater than 175 °C.
The documented test dataset supports the following expected classifications (subject to confirmation against the currently loaded model). These are test-case expectations, not a captured MCP execution trace:
Documented test-case classifications
| Stator | Classification | Evidence / limitation |
| S001 | Included | R2568-B; 180 °C (>175 °C) |
| S002 | Excluded | 175 °C; strict threshold not met |
| S003 | Excluded | Different copper reference |
| S004 | Included | R2568-B; 176 °C (>175 °C) |
| S005 | Excluded | Insertion temperature below threshold |
| S006 | Indeterminate | 188 °C; material link missing |
The classifications demonstrate why missing relationships must not be treated as negative matches. The original material-batch question and the temperature-filtered test are separate queries; the table belongs to the latter.
Handling incomplete traceability
S006 deliberately has production information but no material-consumption relationship. Its recorded temperature exceeds the threshold, but the copper reference cannot be established from the available model.
For S006, the supported statement is that the required relationship was not found within the explored scope. It is not valid to conclude that S006 used no copper or a different batch.