Reconstructing OPC UA Address Spaces from Time-Series Databases⋆
arXiv:2606.10663v1 [cs.DB] 9 Jun 2026
Lukas Lürzer[0009−0000−5953−1381] , Hannes Unger[0000−0003−3715−6845] , and Stefan Huber[0000−0002−8871−5814] Josef Ressel Centre for Intelligent and Secure Industrial Automation, Salzburg University of Applied Sciences, Austria {lukas.luerzer,hannes.unger,stefan.huber}@fh-salzburg.ac.at
Abstract. OPC UA has become the dominant open protocol in operational technology. Time-series databases routinely archive OPC UA telemetry but discard the semantic metadata (node hierarchy, engineering units, and type definitions) which gives sensor values their meaning. Recovering this information from a time-series database is non-trivial: namespace indices recorded at the source are session-local and unstable across restarts, and naive merging across multiple source servers results in identifier collisions. We present opcua-ts, an implemented architecture that persists this semantic information alongside its telemetry in a general-purpose time-series database under a lifecycle-stable join key, and that reconstructs the source address space as a live OPC UA endpoint. We characterize the conditions under which the reconstruction is sound across multi-source deployments and validate the approach with a NodeSet2 XML round-trip against the source server. Initial results from a boiler-simulator round-trip indicate that the approach is feasible. Keywords: OPC UA · Information Model · Time-Series Databases · Semantic Metadata · Address Space Reconstruction.
1
Introduction
OPC UA [3] has become the dominant protocol for machine-to-machine communication in operational technology (OT). Every compliant server exposes an address space: a typed, hierarchical graph of objects and variables with engineering units, data types, references, and browse paths. Additionally, the OPC Foundation maintains a growing family of standardized companion specifications (for robotics, machine tools, process control, energy, and other domains), so that compliant servers across vendors expose semantically interoperable type systems out of the box. In practice this information model is usually lost at the OT/IT boundary, because typical ingestion pipelines (Telegraf, MQTT bridges, ad-hoc adapters) ⋆
This is the authors’ accepted version of a paper accepted at AI4IP 2026 (workshop at DEXA 2026). The final authenticated version will appear in the Springer CCIS series; the version of record will be available via its DOI once published.
2
L. Lürzer et al.
marshal each value into a schema-light row keyed by node identifier, and the surrounding structural metadata has no natural home there. Downstream analytics, dashboards, and ML pipelines therefore operate on context-free numeric streams and reintroduce the missing semantics through hand-maintained mapping tables, which drift out of sync as the source address space evolves and the mapping is updated only when someone notices. Recovering the address space from such a time-series store is non-trivial. The binding between values and their semantic context is broken at ingestion, namespace indices recorded in the source server are session-local and unstable across server restarts, and naive merging across multiple source servers admits identifier collisions in both the namespace and the browse-name dimension. We therefore investigate the following research questions: – RQ1. Can the OPC UA information model be persisted alongside its telemetry in a general-purpose time-series database with a join key? – RQ2. Under what conditions can the original address space be reconstructed from such a store and served as a live OPC UA endpoint, including across multi-source deployments where namespace and browse-name collisions are unavoidable? – RQ3. How can the semantic fidelity of a reconstructed address space be validated against the original source? To answer these questions, we contribute (i) a join key derived from the namespace URI rather than the session-local namespace index, which makes it canonical (one form per node) and lifecycle-stable (unchanged across server restarts and crawl boundaries), and under which telemetry and semantic metadata can be co-located in a general-purpose time-series store; (ii) an aggregate reconstruction server that builds the persisted information model into a live OPC UA endpoint and manages namespace and browse-name collisions across multiple sources; and (iii) a validation procedure based on a NodeSet2 [3] round-trip against the source server.
2
Related Work
Historical access to OPC UA data is standardized through the Historical Access profiles defined in OPC UA Part 11 [2], and a number of commercial historians implement them. These products treat the address space as a runtime structure that is mirrored at configuration time, not as a first-class artifact persisted alongside the time series; an address space recovered from such a historian therefore reflects the configuration snapshot at mirror time rather than the lifecycle of the source server. Semantic-aware digital-twin platforms address the closely related problem of giving industrial values a queryable semantic context, but typically do so through proprietary graph or semantic stores attached to the time-series layer via integrations, rather than by co-locating the semantic and temporal layers under a shared key. To our knowledge, no open system persists OPC UA semantic
Reconstructing OPC UA Address Spaces from Time-Series Databases OPC UA server (machine A)
Semantic crawler
OPC UA server (machine B) ...
model
Time-series store values + model Telegraf
3
reload
Reconstruction OPC UA server
OPC UA clients
values
Fig. 1. Architecture proposal of opcua-ts: a semantic crawler and Telegraf persist the information model and live values under a shared join key; a reconstruction server serves the aggregate as a live OPC UA endpoint.
metadata in a general-purpose time-series database such that the source address space can be reconstructed programmatically.
3
System Architecture
Figure 1 shows the workflow. Two ingestion paths feed the store under a shared node_id tag: a semantic crawler persists per-node metadata, while Telegraf [1] polls live values. The design is source-agnostic: any compliant OPC UA server (PLC-embedded, gateway, simulator) can be used, and the reconstruction server reproduces its information model without requiring access to the original device. 3.1
Storage Model
opcua-ts co-locates two complementary stores in the same time-series database, joined by a shared key: a values store carrying live telemetry, written by Telegraf, and a metadata store carrying the semantic information model, written by the crawler. The two stores share a canonical join key node_id (its grammar appears in Listing 1.1). The key is derived from the namespace URI rather than the namespace index : indices are session-local and unstable across server restarts, whereas URIs are durable across the lifecycle of the source server. The metadata store carries, per node, the display name, browse path, datatype name, type-definition name, parent node_id, engineering unit, EURange, non-hierarchical references, and a monotonic crawl_version field that enables both last() snapshots and historical change detection without overwriting prior rows. Listing 1.1 shows the join-key grammar and a representative metadata record. 3.2
Crawler Pipeline
The crawler performs a depth-first traversal of the source server starting from the standard Objects (i=85) and Types (i=86) roots, recording for each node the hierarchical references used to reach it and the HasTypeDefinition target. A second pass enriches Variable nodes with EURange and EngineeringUnits via the HasProperty reference.
4
L. Lürzer et al.
Listing 1.1. Canonical node_id and a sample opcua_metadata row (selected fields). # Canonical node_id grammar <namespace_uri>|<id_type>|<identifier> # Example: http://myplant.com/boiler/UA/|i|1002 # Sample opcua_metadata row (selected fields): node_id : http://myplant.com/boiler/UA/|i|1002 display_name : Loop Temperature browse_path : /Objects/Boiler1/BoilerLoop1/LoopTemperature data_type : Double type_def : AnalogItemType eu_range : -50:200 engineering_unit : degree Celsius parent_node_id : http://myplant.com/boiler/UA/|i|1001 crawl_version : 42
3.3
Reconstruction Pipeline
The reconstruction server loads the latest metadata rows from the metadata store into a node-opcua [4] address space. It employs two collision-resolution mechanisms for multi-source deployments: when two source servers share a namespace URI, the aggregate registers each instance with a #source= fragment suffix so that namespace indices remain distinct; and a router places one container object per source endpoint under Objects, isolating browse-name collisions. Each Variable is wired to a value cache keyed on endpoint::node_id, populated by a background poll against the values store, so clients see the most recent value with its original SourceTimestamp.
4
Validation via NodeSet2 Round-Trip
We say a reconstructed address space is semantically faithful to its source if every browse, read, and type-resolution observation a standard OPC UA client may perform yields the same answer against the reconstruction as against the source, and if the per-namespace NodeSet2 XML serialization preserves BrowseName, NodeClass, DataType, TypeDefinition, browse-path position, engineering metadata, and non-hierarchical references node by node. We assess this by exporting both the source and the reconstructed server’s address spaces to NodeSet2 XML and comparing them attribute by attribute. NodeSet2 XML is the canonical OPC UA address-space serialization defined in the OPC UA specifications [3], and the node-opcua library provides both a loader (generateAddressSpace) and a per-namespace serializer (toNodeset2XML()). We rely on this serializer for both directions of the round-trip. Procedure. The round-trip proceeds in four steps. First, we export the source server’s namespace to NodeSet2 XML directly via toNodeset2XML(). Second, we
Reconstructing OPC UA Address Spaces from Time-Series Databases
5
run the crawler against the same source server, populating the metadata store with one row per node. Third, we instantiate a reconstruction from the latest crawl. Finally, we export the reconstruction’s namespace using the same serializer and compare the two NodeSet2 files attribute by attribute. Initial findings. We exercised the round-trip on a boiler-simulator address space with eleven functional nodes, including five AnalogItemType variables. The source serialized to 25.4 KB and the reconstruction to 19.9 KB. All functional nodes survive the round-trip together with their data types, type definitions, the EURange, EngineeringUnits, and InstrumentRange properties of the analog items, and the non-hierarchical GeneratesEvent reference. This indicates that the approach is feasible in principle. Known gaps. The 5.5 KB size delta between the two files is fully accounted for by two optional display hints, Definition and ValuePrecision. The metadata loader filters all PropertyType sub-nodes from the snapshot, because nodeopcua’s addAnalogDataItem() re-emits the EURange, EngineeringUnits, and InstrumentRange properties from the primary metadata fields, and re-loading the source’s own property nodes would collide. The two hints are dropped as collateral; widening the metadata query to preserve them is straightforward future work.
5
Discussion and Conclusion
Coupling the semantic and temporal layers in a single store lets analytics pipelines join telemetry with engineering units and browse paths without an external mapping table, allows the reconstruction server to expose a semantically-rich OPC UA endpoint to clients that cannot query the time-series store directly, and makes the appearance or disappearance of a node_id (via crawl_version) a queryable event. Limitations remain: the reconstruction is snapshot-based, and custom ObjectType / VariableType definitions reattach to built-in base types in the current implementation. OPC UA semantic metadata can therefore be persisted alongside its telemetry without sacrificing the ability to reconstruct the source address space. Future work covers type-hierarchy preservation and subscription-driven crawls. Acknowledgments. During the preparation of this work, the authors used AI tools for language editing and formatting assistance.
References 1. InfluxData: Telegraf OPC UA Input Plugin. https://github.com/influxdata/ telegraf/tree/master/plugins/inputs/opcua (2024) 2. OPC Foundation: OPC UA Specification, Part 11 (Historical Access). Specification Release 1.05, OPC Foundation (2023)
6
L. Lürzer et al.
3. OPC Foundation: OPC UA Specification, Parts 1 (Overview) and 6 (Mappings). Specification Release 1.05, OPC Foundation (2023) 4. Rossignol, E.: node-opcua — OPC UA stack for Node.js. https://github.com/ node-opcua/node-opcua (2024)