An OPC UA NodeId can tell a client exactly which node to read. It does not necessarily tell an engineer which pump, line, or measurement that node represents in the plant.
Reliable OPC UA NodeId mapping keeps source identity separate from the names people use. The source identifier, browse path, equipment identity, and user-facing label should remain connected, but they should not be treated as the same field.
NodeId, BrowseName, and DisplayName have different jobs
A NodeId unambiguously identifies a node in an OPC UA server’s address space. It combines a namespace reference, identifier type, and identifier. The identifier can be numeric, a string, a GUID, or opaque data.
A BrowseName is a nonlocalized name used to browse the address space and construct browse paths. It includes a namespace and a string, but it is not unique across the entire server. Different nodes can have the same BrowseName.
A DisplayName is a localized label intended for users. The same node can return different DisplayName text for different session locales. Display names may also be repeated. They are useful in an interface, not as the sole identity for an integration.
| Field | Primary purpose | Mapping caution |
|---|---|---|
| NodeId | Address a specific source node | Keep its namespace meaning, not just the numeric index |
| BrowseName | Build and navigate browse paths | It is not globally unique in the server |
| DisplayName | Show a readable, localized label | It may change, repeat, or vary by locale |
| Asset ID | Identify physical equipment in the business model | Define it independently from source naming |
Store the namespace URI along with the index
A NodeId written as ns=4;s=Pump01.DischargePressure uses 4 as an index into that server session’s NamespaceArray. The index is compact for transport, but the OPC UA specification allows it to change in a later session. The namespace URI is the stable meaning behind the index.
For a maintainable mapping, retain the server or endpoint identity, namespace URI, identifier type, and identifier. Resolve the current namespace index when connecting. A stored ns=4 string without its URI can point to the wrong namespace after the server’s table changes.
OPC UA requires a server to persist the identifier type, identifier, and namespace URI for a node. Operational changes still need reconciliation. A vendor import, server replacement, or delete-and-recreate operation may expose a different node even if its label looks unchanged. Treat configuration changes as mapping changes to validate, not as proof that every identifier will survive.
Give equipment its own stable identity
Do not make a raw NodeId the equipment name. Use an internal asset key that belongs to the plant’s naming system, such as a controlled equipment number. Map each source point to that asset and to a defined attribute.
For one pump in a group of similar pumps, the mapping might look like this:
| Asset key | Asset name | Attribute | OPC UA source |
|---|---|---|---|
P-101 | Feed Pump 101 | Discharge pressure | Namespace URI + Pump01.DischargePressure |
| Bearing temperature | Namespace URI + Pump01.BearingTemp | ||
| Running status | Namespace URI + Pump01.Running |
Pumps P-102 and P-103 can use the same attribute template while binding to their own source nodes. The template standardizes names, data types, and engineering units. The mapping supplies the source identity for each equipment instance.
This is safer than inferring the plant hierarchy from a tag string alone. A string such as Pump01.Temp does not prove the plant, area, equipment type, or meaning of Temp. Those relationships need controlled metadata or an approved mapping rule.
Keep source, semantic, and display fields separate
A practical mapping record should retain:
- Source identity: endpoint, namespace URI, identifier type, and identifier.
- Browse context: browse path, BrowseName, and source description.
- Asset identity: site, area, equipment key, and equipment class.
- Measurement definition: attribute name, engineering unit, and data type.
- Display metadata: operator-facing name and optional localized labels.
This separation lets a DisplayName change without breaking the source binding. It also lets a source node move to a new equipment binding through a controlled change rather than a silent rename.
Plan for mapping changes
Before a server or controller change, export the current point inventory and mapping. After the change, compare namespace URIs, NodeIds, browse paths, data types, and engineering units. Classify points as unchanged, moved, replaced, added, or removed.
Do not remap automatically on name similarity alone. Two pumps can expose identical BrowseNames under different parent objects. Require an equipment key, approved path rule, or reviewed exception for ambiguous matches.
At scale, version the mapping and keep an owner for each exception. Test a representative set of equipment classes before bulk rollout. Validation should confirm that every required attribute resolves to one expected source, units match the asset definition, duplicate bindings are intentional, and retired nodes are not still collecting under old names.
If a mapping change leaves an OPC UA connection active but no data reaches the historian, follow this OPC UA troubleshooting workflow to check node selection and data writes.
Mapping OPC UA data into TDengine IDMP
TDengine’s OPC UA ingestion mapping can write each point_id to TDengine TSDB and retain source metadata such as BrowseName, DisplayName, Description, and Path as tags. The path and readable names help with later modeling, but they do not replace a plant-approved asset key.
TDengine IDMP models physical or logical assets as elements in a hierarchy. Attributes can reference measurements stored in TDengine TSDB, and templates can standardize repeated equipment. The documented Import from OPC workflow applies when OPC-structured data is already stored in TDengine TSDB. It uses a selected path tag, data column, optional quality column, and path level to build the model.
That workflow does not prove that every source hierarchy is a correct business hierarchy. Review the imported structure, choose the right parent level, and reconcile source paths with equipment keys before users depend on it. For sites that need a governed asset hierarchy and reusable equipment templates, industrial data modeling in TDengine IDMP can provide the context above raw time-series tables.
