i3X Integration in OOUAMiddleware
Expose OPC UA information models…
One industrial model. Multiple interoperability interfaces.
One Industrial Model, OPC UA and i3X Interfaces
OOUAMiddleware now integrates i3X (Industrial Information Interoperability eXchange), developed by CESMII, through VpiI3XSrv, a dedicated Virtual Protocol Interface (VPI).
The integration enables applications using i3X to discover and consume industrial information managed by OOUAMiddleware while preserving the OPC UA information model as the semantic foundation of the system.
What VpiI3XSrv Provides
VpiI3XSrv extends OOUAMiddleware with an i3X interface while preserving the existing OPC UA information model as the semantic foundation. The current implementation covers the main mechanisms required for applications to discover industrial information, access runtime values and consume historical data through i3X.
Model Discovery
VpiI3XSrv exposes the structure of the industrial model through the i3X discovery API. Applications can discover namespaces, types, objects, elements and relationships, allowing them to navigate the model rather than working with an isolated collection of data points.
The exposed structure originates from the information model managed by OOUAMiddleware, so the same industrial semantics remain available independently of the access interface.
Current Data Access
Applications can read and write current industrial values through the i3X interface. Values are associated with their corresponding model elements and include the runtime information required to interpret their state.
This provides direct access to live industrial data while keeping acquisition and protocol-specific mechanisms behind the OOUAMiddleware abstraction layer.
Subscriptions
VpiI3XSrv implements the i3X mechanisms required to subscribe to value changes and synchronize updated values.
Instead of continuously polling individual data points, an application can create subscriptions and follow the evolution of selected industrial information. The implementation has been exercised with i3X Explorer on dynamically changing values.
Historical Data
Historical values managed by OOUAMiddleware can be retrieved through the i3X interface. The current implementation has been tested with data archived in PostgreSQL, including timestamps and OPC UA quality information.
This allows an i3X application to access historical industrial data without requiring direct knowledge of, or access to, the underlying persistence system.
Structured Data
The integration is not limited to scalar process values. VpiI3XSrv can expose structured industrial data derived from the OPC UA information model.
Tests with structures such as MaintenanceInfo demonstrate that complex information containing multiple typed fields can be delivered as structured JSON through i3X. This preserves significantly more industrial context than an interface limited to individual scalar tags.
Industrial Object and Relationship Discovery
VpiI3XSrv exposes more than individual industrial values. It makes the structure of the OOUAMiddleware information model discoverable through the i3X interface, including objects, elements and the relationships that connect them.
The example below shows VpiSet as discovered by i3X Explorer. The relationship view preserves its position within the industrial model: VpiSet is exposed as a child of I3XTest and is itself related to OpenOpcUaSystem.
This allows an i3X consumer to navigate industrial information in context instead of treating every value as an independent data point.
i3X Explorer discovering the VpiSet object and its relationships as exposed by OOUAMiddleware through VpiI3XSrv.
Current Values, History and Subscriptions
The Level example demonstrates how the same industrial element can be consumed through several i3X mechanisms. i3X Explorer displays its current value together with timestamp and quality information, retrieves its historical evolution and maintains an active subscription to subsequent value changes.
These capabilities are provided through VpiI3XSrv while acquisition and persistence remain managed by OOUAMiddleware.
Current value, historical data and active subscription for the Level industrial variable in i3X Explorer.
Structured Industrial Data Through i3X
Industrial information is not always reducible to scalar values. The MaintenanceInfo example demonstrates the exposure of a structured OPC UA value through i3X.
i3X Explorer receives the structure as a JSON object containing several related fields, including commissioning and maintenance dates and the current maintenance mode. The semantic structure of the information is therefore preserved instead of being flattened into unrelated individual tags.
Structured MaintenanceInfo data exposed by OOUAMiddleware through i3X as a JSON object.
Historical Data Integration
Historical data exposed through i3X is not stored or managed by VpiI3XSrv itself. Historical persistence remains a service of the OOUAMiddleware architecture and is accessed independently from the i3X interface.
In the current demonstration environment, PostgreSQL is used as the historical storage backend. OOUAMiddleware connects to PostgreSQL through a dedicated VFI (Virtual File Interface), which provides the persistence layer used to archive and retrieve industrial values.
The resulting data path is:
Industrial Asset → VPI → OOUAMiddleware Runtime → VFI → PostgreSQL
When an i3X application requests historical data, VpiI3XSrv does not access PostgreSQL directly. The request is processed through OOUAMiddleware’s historical services, which retrieve the corresponding data through the configured VFI:
i3X Consumer → VpiI3XSrv → OOUAMiddleware Historical Services → VFI → PostgreSQL
This separation is important. PostgreSQL is an implementation choice of the demonstration, not a dependency of the i3X integration. The persistence backend is abstracted by the VFI architecture. Another VFI and another storage technology can therefore be used without changing the i3X interface or the industrial information model.
PostgreSQL in the i3X Demonstrator
For the current i3X demonstrator, PostgreSQL provides a convenient persistent backend for validating the complete historical data path. Industrial values are acquired by OOUAMiddleware, archived through the PostgreSQL VFI and subsequently retrieved through the i3X historical data API.
The tests demonstrated that values previously archived in PostgreSQL could be retrieved from i3X Explorer with their associated timestamps and OPC UA quality information. In the principal validation test, ten historical points were retrieved with Good quality.
The demonstration therefore validates more than a direct i3X-to-database connection. It exercises the complete OOUAMiddleware architecture:
acquisition → model-driven runtime → historical service → VFI persistence → i3X exposure
This architecture keeps three responsibilities independent:
- VPI provides connectivity to industrial data sources.
- VFI provides abstraction of the persistence backend — PostgreSQL in this demonstrator.
- VpiI3XSrv exposes the resulting industrial information and historical services through i3X.
Consequently, changing the persistence technology does not require redesigning the i3X integration. As long as the corresponding VFI provides the historical services expected by OOUAMiddleware, VpiI3XSrv remains independent from the physical storage implementation.
PostgreSQL is the persistence backend used by the demonstrator. Historical storage remains abstracted through the OOUAMiddleware VFI architecture and is independent from the i3X interface.
OPC UA and i3X: Complementary Interfaces
OPC UA and i3X play different roles in the OOUAMiddleware architecture. They are not implemented as two competing representations of the industrial system. Instead, they provide complementary access mechanisms to the same model-driven runtime.
At the center of the architecture, the OPC UA Information Model remains the authoritative representation of industrial structure and context. It defines types, instances, relationships and semantics independently from the interface used by consuming applications.
OOUAMiddleware interprets and executes this model at runtime. Runtime values, historical services, subscriptions and other industrial services are therefore associated with the model itself rather than being implemented separately for each external interface.
OPC UA as the Industrial Interoperability Interface
OPC UA provides the standardized IEC 62541 interface to the OOUAMiddleware runtime. OPC UA clients can navigate the AddressSpace and use the services defined by the standard, including data access, subscriptions, methods, events and historical access.
This interface is designed for industrial interoperability between systems that understand the OPC UA service model and its semantic AddressSpace.
i3X as an Additional Data Access Interface
VpiI3XSrv exposes the same underlying industrial information through the i3X API.
An i3X consumer can discover objects and relationships, access current and structured values, subscribe to changes and retrieve historical information without requiring a separate industrial model to be maintained for i3X.
The i3X interface therefore extends the ways in which applications can consume information managed by OOUAMiddleware without replacing the OPC UA architecture underneath it.
One Model, Multiple Interfaces
The architectural separation can be summarized as:
Industrial Information Model
defines the structure, relationships and meaning of industrial information.
OOUAMiddleware Runtime
interprets the model and provides runtime, acquisition, persistence and industrial services.
OPC UA
provides standardized IEC 62541 industrial interoperability.
i3X through VpiI3XSrv
provides an additional API-oriented interface for discovering and consuming the same industrial information.
This separation means that adding i3X does not require duplicating the industrial model or moving semantic responsibility into the i3X interface.
Current i3X 1.0 Validation Status
The current validation matrix covers 20 i3X route/method combinations. At the present stage, 18 of these 20 combinations are considered functional at least partially, representing 90% functional route coverage within the scope of the matrix.
Functions Already Validated
- namespace, type, object, element and relationship discovery;
- current value reading and writing;
- structured data access;
- subscription creation and management;
- synchronization of subscribed values;
- historical data reading through the OOUAMiddleware persistence architecture.
Testing has been performed with i3X Explorer and with the OOUAMiddleware demonstrator, including structured values and historical data persisted through the PostgreSQL VFI.
Remaining Validation Work
Two route/method combinations are not currently counted as functional in the validation matrix: historical writing and SSE streaming. Additional cross-cutting requirements also remain to be completed or qualified, including aspects such as HTTPS, gzip support, date validation and some relationship/depth behaviors. These remaining items do not prevent the current demonstrator from exercising the principal discovery, current-data, subscription and historical-read scenarios, but they are part of the work required before making a broader i3X 1.0 compliance claim.
Functional Validation Is Not Formal Compliance
OpenOpcUa does not currently claim full i3X 1.0 compliance.
The official CESMII compliance test suite has not yet been executed against VpiI3XSrv. Formal compliance can therefore only be assessed after the remaining implementation gaps have been addressed and the implementation has been evaluated using the appropriate official validation process.
Current status: broad functional i3X 1.0 API coverage demonstrated — formal compliance validation still in progress.
| Validation area | Current status |
|---|---|
| Model discovery | Validated |
| Current value read/write | Validated |
| Structured data | Validated |
| Subscriptions & synchronization | Validated |
| Historical read | Validated |
| Historical write | Not yet validated |
| SSE streaming | Not yet validated |
| Official CESMII compliance suite | Not yet executed |
Extending the OpenOpcUa Interoperability Architecture
The integration of i3X extends the OpenOpcUa interoperability architecture without changing its fundamental model-driven principles.
OOUAMiddleware continues to use the OPC UA Information Model as the semantic foundation of the industrial system. Industrial objects, relationships, runtime values and historical information remain managed by the same runtime architecture, independently from the interfaces used to consume them.
VpiI3XSrv adds i3X as a new interoperability interface around this existing architecture. Applications can therefore access industrial information through i3X while OPC UA clients continue to use the standardized IEC 62541 services and AddressSpace.
This approach avoids creating parallel representations of the same industrial system. The model is defined once, executed by OOUAMiddleware and made available through the interfaces required by different consumers.
The same architectural principle already separates industrial connectivity through VPI, persistence through VFI, and runtime execution from the information model. i3X now becomes another example of this separation: a new interface can be introduced without redesigning the underlying industrial model.
One industrial model. Multiple interoperability interfaces
From OPC UA Interoperability to Multi-Interface Industrial Data Access
Industrial architectures increasingly need to serve different categories of consumers: traditional industrial applications, enterprise systems, analytics platforms, data infrastructures and emerging software ecosystems. Binding industrial semantics to each communication technology independently would recreate the integration complexity that information modeling is intended to eliminate. OpenOpcUa takes the opposite approach: preserve the industrial model and evolve the interfaces around it. The integration of i3X through VpiI3XSrv demonstrates this principle in practice.