Part 3: Address Space Model
| Document number | OPC 10000-3 |
|---|---|
| IEC designation | IEC 62541-3 |
| Colloquially | Part 3 |
| Group | Core |
Part 3 defines the meta-model: the eight NodeClasses, the attributes every node carries, typed references, the reference-type hierarchy, and the modelling rules that govern how types are instantiated. Everything any information model can express is expressible only because Part 3 said it was. Read it before you model anything.
Nodes, NodeClasses and attributes
There are exactly eight NodeClasses: Object, Variable, Method, ObjectType, VariableType, ReferenceType, DataType and View. Every node carries the mandatory attributes NodeId, NodeClass, BrowseName and DisplayName, plus attributes specific to its class - Value, DataType, ValueRank, ArrayDimensions and AccessLevel on a Variable, Executable on a Method, IsAbstract on a type. The set of attribute identifiers is fixed by the standard, which is what lets a generic client read any node it has never seen before.
References make a graph, not a tree
References are typed and directed, and a node can be the target of many of them. The hierarchy runs References, then HierarchicalReferences with Organizes, HasComponent, HasProperty, HasSubtype, HasEventSource and HasNotifier beneath it, and NonHierarchicalReferences with HasTypeDefinition, HasModellingRule and HasEncoding. Browsers present a tree because a tree is easy to draw, but the underlying structure has multiple parents and cycles, and any client that assumes one parent per node will eventually produce a wrong path.
Types, instances and modelling rules
An ObjectType or VariableType declares components, properties and methods as instance declarations. A modelling rule on each declaration says what happens when the type is instantiated: Mandatory means the instance must have it, Optional means it may, and the placeholder rules allow an unbounded set of similarly typed children. Interfaces, conventionally named with a leading I, let a type assert a capability without single inheritance, and the machinery-oriented models lean on them heavily.
NodeIds and permissions
A NodeId is a namespace index plus an identifier, and the identifier can be numeric, string, GUID or opaque. ExpandedNodeId adds the namespace URI and a server index for cross-server references. Part 3 also defines the RolePermissions, UserRolePermissions and AccessRestrictions attributes that carry per-node authorisation, and the well-known TrustedApplication role that some stacks assign automatically to a peer that authenticated with a trusted application certificate.
What it defines
| Concept | What it is |
|---|---|
| The eight NodeClasses | Object, Variable, Method, ObjectType, VariableType, ReferenceType, DataType, View. Nothing else exists, and a client can branch its whole rendering logic on this attribute. |
| Mandatory attributes | NodeId, NodeClass, BrowseName and DisplayName on every node. BrowseName is the machine-readable identity with a namespace index; DisplayName is localised and for humans only. |
| HierarchicalReferences | Organizes, HasComponent, HasProperty, HasSubtype, HasEventSource, HasNotifier. These are what a browse tree walks; the choice between Organizes and HasComponent carries real semantics. |
| HasTypeDefinition | The non-hierarchical reference from an instance to its type. Follow it to know what an Object actually is, rather than guessing from its BrowseName. |
| Modelling rules | Mandatory, Optional, MandatoryPlaceholder and OptionalPlaceholder. They are what makes a companion specification testable, and what makes optional nodes the bane of generic clients. |
| Interfaces | Abstract types applied with HasInterface, named with a leading I. They let one instance advertise several capabilities without a single-inheritance chain. |
| NodeId identifier types | Numeric, String, GUID and Opaque. Numeric ids in namespace 0 are stable forever; vendor string ids are usually stable; anything else should be resolved by browse path. |
| Well-known entry points | Numeric identifiers in namespace 0: 84 is the Root folder, 85 Objects, 86 Types, 87 Views. Every browse of an unknown server starts at one of these. |
| RolePermissions and AccessRestrictions | Per-node authorisation attributes. AccessRestrictions can require signing or encryption for a node, which is why a readable tag can fail on an unencrypted channel. |
| ValueRank and ArrayDimensions | Declare whether a Variable is a scalar, a one-dimensional array or a matrix, and how large. A client that ignores them writes a scalar into an array node and gets BadTypeMismatch. |
Do you need to read it?
Anyone building an information model, and anyone writing a client that has to work against a server it has not seen. Modellers need the modelling rules and the interface mechanism. Client developers need the reference hierarchy, because the difference between a working browse and a broken one is almost always a wrong assumption about references.
Traps that trace back to this part
- The address space is a graph. Nodes can have several parents, references can form cycles, and a depth-first browse without a visited set can run forever on a well-formed server. Track visited NodeIds and cap depth.
- Inverse browsing is not guaranteed to be useful. Some servers will not resolve a node's parents, so a tool that tries to reconstruct a path back to the Root folder from a bare NodeId shows the node existing with no known location. Store the browse path you used, not just the NodeId.
- Never hardcode a namespace index into a NodeId. The index is an index into that server's NamespaceArray at that moment; adding a device or reconfiguring a model renumbers it, and ns=3 silently starts pointing at a different model. Resolve the namespace URI at connect time.
- BrowseName and DisplayName are not interchangeable. BrowseName is the identity a companion specification defines and the one a browse path matches on; DisplayName is localised text a vendor may translate. Matching on DisplayName produces integrations that break when someone changes the server locale.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.