Where older protocols expose data as a flat list of numbers, OPC UA exposes it as a connected graph you can walk. That graph is the address space, and the rules for how it is structured - what a node is, how nodes reference one another, and how types describe objects - make up the information model. This guide explains how the address space organizes objects, variables, and types into a browsable hierarchy, and why a self-describing model lets a cloud SCADA discover a facility's assets instead of hand-mapping every address.
OPC UA Address Space and Information Model in one line: The OPC UA address space is the full set of nodes a server exposes, connected to one another by typed references so that a client can browse it like a graph or tree. The information model is the framework of node classes - objects, variables, methods, and their type definitions - that gives that graph structure and meaning. Together they make OPC UA self-describing: a client can navigate from a facility down to its equipment and individual measurements, learning names, data types, and relationships from the server rather than from an external address map.
The building block of the address space is the node, and OPC UA defines several node classes for different purposes. Object nodes represent things - a pump, a well, a separator - and act as containers. Variable nodes hold actual values, such as a pressure reading or a run status, and are usually organized underneath the objects they belong to. There are also method nodes for callable actions, and type nodes that define reusable templates. Every node has attributes like a display name and a NodeId, so it is both addressable and labeled.
What turns a pile of nodes into a navigable structure is references. A reference is a typed, directed link from one node to another, and the reference type carries meaning. A HasComponent reference says one node is a component of another - a Pressure variable is a component of a Wellhead object - while HasProperty, HasTypeDefinition, and Organizes references express other relationships. Because references are typed, a client does not just see that two nodes are connected; it sees how they relate, which lets it reconstruct the plant's structure rather than a random web of links.
This graph model is the antithesis of a flat register list. In Modbus, register 40021 sits next to 40022 with no relationship implied and no hierarchy at all; structure exists only in the engineer's spreadsheet. In OPC UA, the pressure and temperature of the same wellhead are visibly children of that wellhead object, and the wellhead is visibly part of a pad, which is part of a field. The relationships are first-class data inside the server, so the shape of the plant is something a machine can read directly.
The information model gets much of its power from type definitions. Just as object-oriented programming has classes and instances, OPC UA has object types and object instances. An object type such as a Pump type declares that every pump has a run status, a speed, and a discharge pressure; each actual pump on the plant is then an instance of that type, linked to it by a HasTypeDefinition reference. A client that understands the Pump type immediately knows what to expect from any pump instance without inspecting each one individually.
This typing is what makes the model semantic rather than merely structural. Companion specifications build standardized information models for particular domains on top of base OPC UA, defining agreed types for common equipment so that a device from one vendor and a device from another expose the same shape. Even without a formal companion spec, a server's own types tell a client that these ten nodes are all pumps and share a common structure, which is far richer than ten unrelated groups of registers that happen to follow the same convention.
Being self-describing has a concrete payoff: a client can arrive at a server it has never seen and figure out what is there. By browsing from the top of the address space downward and reading type definitions, it can enumerate the objects, discover their variables, learn each variable's data type and units, and understand how everything is organized - all from the server itself. The model carries its own documentation, which is precisely what a flat register map cannot do.
Traditionally, bringing a new facility into a SCADA system means hand-building an address map: someone lists every register or point, its meaning, its units, and its scaling, and that list is transcribed into the SCADA configuration. It is slow, error-prone, and goes stale whenever the field changes. OPC UA's browsable, self-describing address space changes the nature of that work, because the structure and meaning already live in the server and can be read rather than retyped.
For a cloud SCADA such as Merobix, this means connecting to a facility's OPC UA server and browsing its address space to discover what assets exist - the wells, separators, tanks, and compressors - and what each one measures, complete with data types and units. Rather than starting from a blank map and filling in every address by hand, the platform can present the server's own hierarchy and let an engineer select the objects and variables to bring in as tags. The equipment structure the server publishes becomes the starting point for the SCADA's own asset model.
The benefit compounds over the life of a field. When a facility adds a well or a new skid, and its OPC UA server exposes the new objects and variables, a browse of the address space surfaces them for inclusion instead of requiring the map to be rebuilt from a fresh spreadsheet. Because the model is typed, a new pump that is an instance of an existing pump type is understood the moment it appears. This is the practical difference between a protocol that hands you a bag of numbers and one that hands you a labeled, structured picture of the plant that a cloud platform can walk on its own.
The address space is the concrete set of nodes and references a particular server exposes - the actual graph of objects and variables. The information model is the framework of rules and node classes, such as objects, variables, and type definitions, that gives any address space its structure and meaning. In short, the information model is the grammar and the address space is a sentence written in it.
A reference is typed and directed, so it does not merely connect two nodes - it states how they relate. A HasComponent reference says one node is a component of another, while HasTypeDefinition says a node is an instance of a type. Because the relationship is machine-readable, a client can reconstruct the plant's real structure rather than seeing an unlabeled web of links.
It removes most of the hand-transcription, not all judgment. A client can browse a server and learn what nodes exist, their types, and their units without an external map, which is a large saving. An engineer still chooses which nodes matter, how they map to the SCADA's own tags and units, and how they are alarmed, but they start from a discovered, labeled structure instead of a blank sheet.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.