The OPC UA (Open Platform Communications Unified Architecture) address space is the structured, hierarchical data model that an OPC UA server exposes to clients. It is a virtual namespace containing every object, variable, method, and data type that the server makes available — organised as an interconnected graph of nodes. When a client connects to an OPC UA server, it navigates, browses, reads, and subscribes to items within this address space. It is the foundational mechanism through which OPC UA delivers its information modelling capability, going far beyond the flat tag lists of older industrial protocols.
Why the Address Space Matters
Traditional industrial communication protocols, including OPC Classic (OPC DA, HDA, A&E), represent data as simple named tags or item identifiers. There is no built-in relationship between items, no structured type system, and no self-describing context. A client must already know what tags exist and what they mean.
The OPC UA address space changes this entirely. It lets a server describe not just values, but what those values mean, how they relate to each other, what type of equipment they belong to, and what methods can be invoked on them. A client that has never connected to a server before can browse its address space and discover its full structure automatically — without prior knowledge or custom configuration.
This self-describing quality is a key reason OPC UA has become the backbone of Industry 4.0 and IIoT (Industrial Internet of Things) integration.
Nodes: The Building Blocks
Every item in the OPC UA address space is a node. Nodes are classified by their NodeClass, which defines what kind of entity they represent. The most common node classes are:
- Object — represents a physical or logical entity, such as a pump, motor, or production line.
- Variable — holds a data value, such as a temperature reading or speed setpoint.
- Method — defines a callable function on an object (for example, Start or Stop).
- ObjectType / VariableType — define type templates that instances can be created from.
- DataType — describes the structure of a value (integer, float, string, custom structure, and so on).
- ReferenceType — describes how nodes relate to each other.
- View — a defined subset of the address space, allowing clients to see a filtered perspective.
Each node carries a set of standard attributes. For a Variable node, the most important attributes are:
| Attribute | Description |
|---|---|
| NodeId | Unique identifier for the node within the server |
| BrowseName | Human-readable name used when navigating the hierarchy |
| DisplayName | Localised name shown to end users |
| Value | The current data value |
| DataType | The data type of the Value attribute |
| AccessLevel | Whether the value is readable, writable, or both |
| Timestamp | Source and server timestamps attached to the value |
References: How Nodes Connect
Nodes do not simply sit in a tree — they are connected by references. A reference is a typed, directed link between two nodes. References define parent-child relationships (HierarchicalReferences), type-to-instance relationships, and more. This graph structure is what makes the address space more expressive than a simple folder hierarchy.
The most commonly used reference type is HasComponent, which links an Object to its child Variables and Methods. Another frequently used type is Organizes, which structures nodes into browsable folders.
Because references are typed and traversable in both directions, a client can ask not just “what is under this object?” but also “what type does this node derive from?” and “which other nodes reference this one?”
Namespaces: Separating Standard from Vendor-Specific Content
Every node in the OPC UA address space belongs to a namespace, identified by a Namespace Index. Namespace 0 is always reserved for the OPC UA specification itself — it contains the built-in types, base object types, and standard reference types defined by the OPC Foundation. Namespaces 1 and above are used for server-specific or vendor-specific content.
This separation ensures that standard OPC UA types are always consistently defined, while device vendors and application developers can add their own nodes and types without conflict.
A NodeId consists of two components: a Namespace Index and an identifier (numeric, string, GUID, or byte string). For example, the standard OPC UA Server node always has NodeId i=2253 in Namespace 0.
The Standard Nodes Every Server Exposes
An OPC UA server is required to expose a minimum set of well-known nodes, defined in Part 5 of the OPC UA specification. These include:
- Server node (
i=2253) — the root entry point; every client starts here. - ServerCapabilities — describes what the server supports.
- ServerStatus — current state, start time, and build information.
- NamespaceArray — lists all namespaces registered in the server.
- ServerArray — lists server URIs for multi-server configurations.
These standard nodes allow any compliant client to connect to any compliant server and immediately understand its capabilities — before reading a single process value.
Browsing the Address Space in Practice
When a client connects to an OPC UA server, it typically starts at the Objects folder (i=85), which is the conventional root for process data. From there, it follows hierarchical references downward through objects and folders until it reaches Variable nodes containing actual process values.
In tools such as OPC Expert, this browsing happens automatically. The application presents the server’s address space as an expandable tree, letting engineers navigate from server root to individual tags without manual configuration. This is the same mechanism used programmatically by SCADA systems, historians, and analytics platforms when they connect to OPC UA sources.
Address Space and Security
Access to nodes in the address space can be controlled independently of transport-level security. An OPC UA server can grant or deny read, write, and browse permissions on individual nodes or branches of the hierarchy, based on the authenticated identity of the connected client. This means a client might be authorised to read process values but not browse the full address space structure, or might be allowed to read but not write to setpoints.
This node-level access control is an important security layer that sits on top of encryption and certificate-based authentication. For a detailed look at how OPC UA security layers work together, see the OPC Expert guide to locking down OPC UA security.
Address Space vs. OPC Classic Tag Lists
| OPC Classic (DA) | OPC UA Address Space | |
|---|---|---|
| Structure | Flat or shallow tag list | Typed, hierarchical graph of nodes |
| Self-describing | No | Yes — clients discover structure at runtime |
| Relationships between items | None | Expressed via typed references |
| Type system | None | Full object-oriented type hierarchy |
| Methods | Not supported | Supported as Method nodes |
| Access control | Connection-level only | Per-node, per-operation |
| Platform | Windows only | Platform-independent |
Summary
The OPC UA address space is the mechanism that makes OPC UA semantically rich rather than just a data pipe. By structuring industrial data as a typed, self-describing graph of interconnected nodes — rather than a list of tag names — it enables any compliant client to discover, understand, and interact with a server’s data without prior knowledge of its contents. This is fundamental to OPC UA’s role in modern industrial integration, and it underpins everything from simple SCADA connectivity to complex digital twin and IIoT deployments.
For more on OPC UA’s broader capabilities, see What Are the Advantages of OPC UA and Is OPC UA a Protocol. Training on OPC UA information modelling is also available through OPCTI (OPC Training Institute).