OPC UA Information Model: Nodes, Objects, and the Address Space
Classic OPC exposed a list of tags. OPC UA exposes a structured, object-oriented information model — a graph of nodes representing objects, variables, methods, and types, connected by typed references, all browsable at runtime. This self-description is the biggest conceptual leap UA makes over DA, and the reason a UA client can connect to a server it has never seen and understand not just what the values are, but what the data means.
This guide covers the building blocks: nodes, the address space, objects vs variables, the type system, and companion specifications. For the practical side of walking the model, see browsing an OPC UA server.
Nodes: the Atomic Unit
Everything in a UA server is a node. A temperature reading is a node. The sensor object that contains it is a node. The data type "TemperatureSensor" is a node. Each node has a unique NodeId and a set of attributes — BrowseName, DisplayName, Value, and so on. There are several node classes; the ones you touch daily are:
- Object — a container that groups related nodes. Has no value of its own.
- Variable — holds a value. This is where the actual data lives.
- Method — a callable function on the server.
- ObjectType / DataType / ReferenceType — the type system that describes the others.
The Address Space
The collection of all nodes in a server is its address space. Nodes are linked by references — typed relationships like HasComponent, HasProperty, Organizes. The address space is therefore a graph, not a list, and a client explores it by browsing: start at a node, follow its references, discover its children. See browsing a server.
Motor object might have Speed and Current child variables plus a Start() method. The object gives structure; the variables hold the numbers you subscribe to.The Type System
UA is strongly typed. Every variable has a DataType (built-in like Int32, Double, String, or a custom structure). Every object is an instance of an ObjectType. Types themselves are nodes, so the type hierarchy is part of the same browsable address space. A client reading Motor.Speed knows the type is Double and the engineering units are RPM — without an external mapping document.
Standard Namespaces and Companion Specs
UA defines a base information model (the standard server object, standard types) in the UA namespace. On top of that, companion specifications add agreed domain models: OPC UA for Machinery, Robotics, Machine Vision, Plastics, Oil & Gas, and more. A vendor that implements "OPC UA for Machinery" exposes machine state, modes, and jobs using the standard object types the spec defines — so a client built against the companion spec works against any conformant machine, regardless of vendor.
Why This Matters
- Self-describing. No external register map or tag spreadsheet. The server tells the client what exists and what it means.
- Type-safe. You know a variable is a Double before you read it.
- Structured. Objects and references model real equipment hierarchy, not a flat list.
- Interoperable. Companion specs let multi-vendor equipment expose a common model.
Browsing the Model on macOS
MacTools OPC UA Explorer walks the address space natively: connect, browse objects and variables, inspect attributes and types, then subscribe to the variables you care about. The information model becomes visible and navigable without Windows tooling.
Browse the UA Address Space on macOS
MacTools OPC UA Explorer — walk objects, variables, and types in any UA server, subscribe to changes, read and write nodes. Native macOS app.
Get MacTools OPC UA ExplorerFrequently Asked Questions
What is the OPC UA information model?
The OPC UA information model is the structured, object-oriented representation of data inside an OPC UA server, exposed through its address space. Data is organized as nodes (objects, variables, methods) connected by typed references, with a type system that lets clients understand what each node is, not just its value. It replaces the flat tag list of classic OPC with a browsable, self-describing hierarchy.
What is a node in OPC UA?
A node is the atomic unit of an OPC UA address space. Every piece of information — a variable, an object, a method, a data type — is a node identified by a NodeId and described by attributes (BrowseName, DisplayName, Value, etc.). Nodes are linked by references, so the whole server content is a graph of nodes you traverse by browsing.
What is the difference between an object and a variable in OPC UA?
A Variable node holds a value (the actual data — a temperature reading, a setpoint). An Object node is a container that groups related variables, methods, and child objects, but has no value of its own. A Motor object, for example, might contain Speed and Current variables plus a Start method. Objects give structure; variables hold data.
What are OPC UA companion specifications?
Companion specifications are standardized information models built on top of base OPC UA by industry groups (e.g. OPC UA for Machinery, Robotics, Machine Vision, Plastics, Oil & Gas). They define agreed object types and structures so that equipment from different vendors exposes the same data the same way, making clients interoperable without vendor-specific mapping.
Related: Continuous Monitoring
Voltrus SCADA browses and subscribes to OPC UA address spaces in production — dashboards, alarms, historian. From $249 lifetime.