If you’ve ever tried to read data from an OPC UA server, you’ve already interacted with the address space — even if you didn’t realize it. The address space is the core of what makes OPC UA different from simpler protocols. It’s not just a flat list of tags. It’s a structured, self-describing map of everything a server has to offer.
This guide explains how the OPC UA address space works, what information modeling means in practice, and how to use these concepts when building or integrating OPC UA systems.
Table of Contents
What Is the Address Space?
The address space is the collection of all information that an OPC UA server makes available to its clients. It’s defined in IEC 62541 Part 3 (Address Space Model) and Part 5 (Information Model).
Think of the address space like a building directory. When you walk into a large office building, the directory tells you what companies are on each floor, what departments they have, and how to reach them. You don’t need a separate guide for each company — the directory gives you the structure.
An OPC UA address space works the same way. A client can connect to any OPC UA server and browse its address space to discover what data is available, how it’s organized, and what it means. No prior knowledge of the server required. No separate tag lists or configuration files to hunt down.
Everything Is a Node
The address space is built from nodes. Every piece of information in the address space — whether it’s a temperature value, a motor object, a method you can call, or a data type definition — is represented as a node.
Each node has two things: attributes that describe it, and references that connect it to other nodes.
Attributes
Attributes are the built-in properties of a node. They’re defined by the OPC UA standard and cannot be extended by users or vendors. Every node has a set of mandatory attributes that depend on its node class.
The most important base attributes that all nodes share are:
| Attribute | Description |
|---|---|
| NodeId | Unique identifier for the node in the server |
| NodeClass | What kind of node it is (Object, Variable, Method, etc.) |
| BrowseName | A human-readable name used when browsing |
| DisplayName | The name shown to users in client applications |
| Description | Optional text explaining what the node represents |
The NodeId is how clients address a specific node. It consists of a namespace index (which namespace the node belongs to) and an identifier (which can be a number, string, GUID, or opaque byte string). Namespace index 0 is always the base OPC UA model. Index 1 is for server-specific instances. Custom information models typically start at index 2.
References
References are named relationships between nodes. They define how nodes relate to each other and give the address space its structure. Unlike attributes, references don’t hold data values — they’re pointers that say “this node is connected to that node in this way.”
For example, a reference might say: “Motor_01 HasComponent SpeedVariable” or “SpeedVariable HasTypeDefinition AnalogItemType.”
References can be hierarchical (creating tree-like structures that clients can browse) or non-hierarchical (creating cross-links between nodes anywhere in the address space). This means the address space isn’t limited to a single tree — it can represent complex, interconnected networks of information.
The Eight Node Classes
IEC 62541 Part 3 defines eight node classes. Each represents a different kind of element in the address space. No other node classes can be created — these eight cover everything.
Instance node classes
Object — represents a real or abstract thing in the system. A motor, a tank, a production line, a software component. Objects contain variables, methods, and references to other objects. They’re the main building blocks of the address space.
Variable — holds a data value. Variables are the nodes you actually read and write. They come in two flavors: data variables (representing actual values like temperature or speed) and properties (describing characteristics of other nodes, like engineering units or alarm limits).
Method — represents a callable function. Clients can invoke methods to trigger actions on the server. For example, starting a motor, running a calibration routine, or resetting a counter. Methods have defined input and output arguments.
View — a subset of the address space. Views let a server present simplified versions of its data for specific use cases. For example, a “maintenance view” might show only the nodes relevant to maintenance tasks, hiding everything else.
Type node classes
ObjectType — defines the blueprint for objects. Just like a class in object-oriented programming defines what instances look like, an ObjectType defines what variables, methods, and child objects an object of that type will have. Types can be subclassed (a MotorType might inherit from DeviceType).
VariableType — defines the blueprint for variables. Specifies the default data type, value range, and structure that variables of this type will have.
ReferenceType — defines the meaning of a reference. “HasComponent,” “HasProperty,” “Organizes,” and “HasTypeDefinition” are all reference types. They tell clients what kind of relationship exists between two nodes.
DataType — defines the structure of data values. Simple types like Boolean, Int32, and String are built-in. But OPC UA also supports complex structured data types — and these are defined as DataType nodes in the address space.
The Object Model: How It All Fits Together
The IEC 62541 standard describes the Object Model as the primary way servers represent real-world things to clients. An object is defined in terms of its variables (data you can read and write), its methods (functions you can call), and its references to other objects.
Here’s a practical example. Imagine a temperature transmitter on a factory floor. In OPC UA, the server might represent it like this:
The TemperatureTransmitter_01 is an Object. It has a Temperature data variable (current reading: 42.5 °C), an EngineeringUnits property (°C), a HighAlarmLimit property (80.0), a LowAlarmLimit property (10.0), a Status variable (Good), and a Calibrate() method that a technician can call remotely.
All of this is accessible through a single OPC UA connection. The client doesn’t need a separate tag list. It browses the address space, finds the transmitter object, and discovers all of its components — including what they mean.
This is fundamentally different from protocols like Modbus, where register 40001 is just a number with no context. In OPC UA, data carries its meaning with it.
Type Definitions and Inheritance
One of the most powerful features of OPC UA information modeling is the type system. Every object in the address space is based on a type definition, and types support inheritance.
How types work
An ObjectType is like a class in programming. It defines the structure that all instances of that type will share. For example, a MotorType might define that every motor has a Speed variable, a RunningState variable, a Start() method, and a Stop() method.
When you create a Motor_01 object based on MotorType, it automatically gets all of those components. The server exposes the type definition, and clients can look at the type to understand what any motor on the system will contain — even if they’ve never seen that specific motor before.
Subtyping
Types can inherit from other types. A VariableSpeedMotorType might extend MotorType by adding a FrequencySetpoint variable and a SpeedRamp property. It inherits everything from MotorType and adds its own components on top.
This inheritance hierarchy is exposed in the address space. Clients can browse it to understand the relationship between types. And because it follows the same rules as object-oriented programming, developers find it familiar.
Why this matters
Type definitions mean that machines from different vendors can describe themselves in standard ways. If Vendor A and Vendor B both build motors that conform to the same MotorType definition, any OPC UA client can interact with both of them identically — without vendor-specific configuration.
This is exactly what OPC UA companion specifications do. Industry groups define standard types for their equipment (packaging machines, CNC controllers, robots, injection molding machines), and any vendor that implements those types becomes automatically interoperable.
Namespaces: Keeping Models Organized
As the address space grows with types from different sources — the base OPC UA model, vendor-specific models, companion specifications — things could get messy. Namespaces prevent that.
Every node belongs to a namespace, identified by a URI. The OPC UA base model uses namespace 0 (http://opcfoundation.org/UA/). A companion specification for robotics would use its own namespace URI. A specific vendor would use yet another.
Inside a server, namespaces are mapped to numeric indexes for efficiency. The server tells clients which index corresponds to which namespace URI. This means a client can always identify where a node came from and which specification defines it.
Namespaces also prevent naming conflicts. Two different models can both define a “Status” variable without collision, because they live in different namespaces.
Browsing vs. Direct Access
Clients interact with the address space in two ways.
Browsing means walking through the address space step by step, following references from node to node. A client starts at a well-known entry point (like the Objects folder or the Server object), browses its children, picks one, browses its children, and so on. This is how clients discover what a server offers without prior knowledge.
Direct access means reading or writing a node by its NodeId. If a client already knows that the temperature value is at NodeId ns=2;s=Tank01.Temperature, it can read it directly without browsing. This is faster and is the normal mode during ongoing operations.
Most real applications use browsing during setup and configuration, then switch to direct access for runtime operations.
Information Models and Companion Specifications
The base OPC UA information model (defined in IEC 62541 Part 5) provides a standard set of types and objects that every server can use: the Server object (which exposes server diagnostics and capabilities), base data types (Boolean, Int32, Float, String, DateTime, etc.), base event types for alarms and status changes, and organizational nodes (Objects folder, Types folder, Views folder).
But the real power comes from companion specifications — standardized information models built on top of the base model for specific industries or device types.
Over 60 companion specifications exist today, covering areas like machine vision (OPC UA for Machine Vision), robotics (OPC UA for Robotics), packaging (PackML with OPC UA), CNC machining (OPC UA for CNC Systems), injection molding (EUROMAP 77/83), weighing technology, commercial kitchen equipment, and many more.
When a vendor implements a companion specification, their device describes itself in the same standard way as every other vendor’s device in that category. This makes integration plug-and-play instead of a custom engineering project for each vendor.
Practical Tips for Working with the Address Space
Use a browser tool first
Before writing any code, connect to your OPC UA server with a free browser tool like UaExpert. Walk through the address space manually. Look at the types, the references, the attributes. Understanding the server’s structure visually will save you hours of debugging later.
Don’t hardcode NodeIds
NodeIds can change between server versions or configurations. Instead of hardcoding them, use browsing or TranslateBrowsePathsToNodeIds to resolve paths at runtime. This makes your client resilient to server updates.
Leverage type definitions
When your client encounters an unfamiliar object, check its HasTypeDefinition reference. The type definition tells you exactly what variables, methods, and properties to expect. Code against types, not individual instances, for more robust integrations.
Use companion specifications when available
If there’s a companion specification for your industry or device type, use it. Don’t reinvent the data model. Standard models save development time and ensure interoperability with other systems that support the same specification.
Keep your custom models clean
If you need to create custom information models, follow OPC UA best practices: define clear types with meaningful names, use proper namespaces, document your model, and avoid putting everything in a flat list of variables. The address space’s power comes from its structure — use it.
Conclusion
The OPC UA address space and information model are what set this standard apart from every other industrial protocol. Instead of flat tag lists with no context, OPC UA gives you a structured, typed, self-describing data model that clients can browse and understand at runtime.
Nodes, attributes, references, types, namespaces, and companion specifications all work together to create a system where machines describe themselves, data carries its meaning, and integration between different vendors becomes straightforward.
Understanding these concepts is essential for anyone building OPC UA applications, designing information models, or integrating industrial systems. The address space isn’t just a feature of OPC UA — it’s the reason OPC UA exists.