An OPC UA (Unified Architecture) namespace is a unique address space that organizes and identifies nodes — such as variables, objects, and methods — within an OPC UA server. Every node in an OPC UA server is assigned a NodeID that includes a namespace index, which maps to a namespace URI (Uniform Resource Identifier). This combination ensures that nodes from different vendors, devices, or applications can coexist on the same server without naming conflicts. In short, namespaces are OPC UA’s mechanism for preventing collisions and maintaining globally unique identification across heterogeneous industrial systems.

Why Namespaces Exist in OPC UA

OPC UA servers can expose data from many sources simultaneously — a PLC (Programmable Logic Controller), an HMI (Human-Machine Interface), a historian, and custom application logic might all share the same server. Without a structured way to separate these data sources, node names would inevitably clash.

Namespaces solve this by assigning each data source or application domain its own URI-based namespace. A node’s full address is therefore the combination of its namespace index and its local identifier, making it globally unambiguous.

To understand why this matters, it helps to understand how OPC communication works at a protocol level — OPC UA is far more than a data transport layer; it defines a complete information model where context and identity matter as much as the values themselves.

Example namespace assignments:

  • Namespace 0 is always reserved by the OPC Foundation for the OPC UA base information model.
  • Namespace 1 is typically reserved for server-specific or vendor-specific information.
  • Namespaces 2 and above are used for custom models, companion specifications, or application data.

How Namespace Indexes Work

When a client connects to an OPC UA server, it requests the NamespaceArray — an ordered list of namespace URIs. The position of each URI in that array is its namespace index. Because the index is session-specific and can differ between servers (or even between connections to the same server), robust OPC UA clients always resolve namespace indexes dynamically by reading the NamespaceArray, rather than hardcoding index values.

Index Namespace URI Meaning
0 http://opcfoundation.org/UA/ URI identifier — not a web address OPC UA base model — defined and maintained by the OPC Foundation (always index 0)
1 Server-defined Server-local or vendor namespace
2+ Custom URI Application, device, or companion spec namespace

NodeIDs and Namespaces: How They Fit Together

A NodeID in OPC UA has two components:

  1. Namespace Index (ns): An integer pointing to an entry in the NamespaceArray.
  2. Identifier: A numeric, string, GUID, or byte-string value that uniquely names the node within that namespace.

Written in OPC UA notation, a NodeID looks like this:

ns=2;s=Pump1.Speed

This means: namespace index 2, string identifier Pump1.Speed. If namespace index 2 maps to urn:mycompany:plc:model, then the full, portable identity of the node is urn:mycompany:plc:model + Pump1.Speed — unique across any OPC UA ecosystem.

Companion Specifications and Custom Namespaces

OPC UA companion specifications — such as those for robotics (OPC UA for Robotics), machine tools (umati), or batch processing — each define their own namespace URI. When a device implements one of these specifications, it registers that companion spec’s namespace on its server. This allows generic clients to discover and interpret the device’s information model without prior knowledge of the vendor.

For custom industrial applications, organizations can define proprietary namespace URIs to represent their own data models, ensuring their nodes are identifiable and portable across systems.

Practical Implications for OPC UA Clients and Integrators

When building or configuring OPC UA client applications, understanding namespaces is essential for reliable node addressing. This is especially true when connecting to servers that expose data from both OPC Classic and OPC UA sources simultaneously — a common scenario in plants running mixed legacy and modern infrastructure.

  • Always read the NamespaceArray at connection time. Never assume a namespace index is fixed.
  • Use namespace URIs as the stable, portable identifier when storing or sharing node references across systems.
  • Be aware of index shifts when a server is updated or reconfigured — the URI remains stable, but its index position may change.

Tools that support proper OPC UA server browsing will expose the full NamespaceArray and let integrators inspect NodeIDs in context — essential for building configurations that remain valid even when server internals change. For a broader look at how OPC clients and servers interact, see how OPC client-server communication works.

Summary: Key Points About OPC UA Namespaces

  • A namespace is a URI-based address space that scopes node identifiers within an OPC UA server.
  • Namespace index 0 is always the OPC Foundation base model; all other indexes are server- or application-defined.
  • NodeIDs combine a namespace index and an identifier to create globally unique node addresses.
  • Clients must read the NamespaceArray dynamically — namespace indexes are not guaranteed to be stable.
  • Companion specifications use namespaces to enable interoperability between devices and vendors.