OPC UA Address Space Explained
One of the strengths of OPC UA is its semantic address space model. An information model defines the nodes and their structure provided in the server’s address space. Similar to object-oriented programming, an information model defines types which can be extended and instantiated. In addition, these types can be semantically enriched by using specific reference types to other nodes.
The OPC Foundation defines a base Information Model in the official OPC UA specification Part 5 (can be downloaded here for free after registration). It defines necessary base object types, reference types, variable nodes and more as defined in the OPC UA address space and further explained in this post.
The Basics
An OPC UA information model is a collection of nodes and their references. Additionally, the information model itself defines the node id within that information model. The OPC UA address space defined the following basic node types:
- VariableType Node
- Variable Node
- Object Node
- ObjectType Node
- Method Node
- Reference Node
- ReferenceType Node
- DataType Node
- View Node
More detailed information on these different node types can be found in the official OPC UA Specification Part 3: Address Space Model, can be downloaded here for free after registration
Every node is identified by a unique node id inside this specific node set. The node set is identified by a unique Namespace URI. A node id is only complete if the id itself and the namespace uri are indicated.
Namespace URI and Namespace Index
Every information model must have its own unique identification URI. For the base OPC UA specification, this URI is http://opcfoundation.org/UA/.
Additional companion specifications or custom specifications define their own namespace URI, e.g., http://opcfoundation.org/UA/DI/ for the DI specification.
Inside an OPC UA server, the namespace is identified by a namespace index. Index 0 is always the base nodeset, and index 1 is for any instances of nodes which do not belong to a specific nodeset.
Depending on usecase, a server can load additional nodesets into its address space. These nodesets normally start at index 2.
After connecting, a client should always query the namespace array of the server to see which namespaces are loaded into the server, and to be able to match the namespace URI to a namespace index.
It is not guaranteed that a server keeps the same namespace index after restarting it. Therefore it is crucial to query the namespace array after every new connection by a client.
Node ID
A node id uniquely identifies a node inside its node set. This node id and namespace index combination is only valid for this specific server instance. As explained in previous section, the namespace index may change during different server instances.
Therefore the node id always exists of two parts, the namespace index, and the id part. The id can be one of the following types:
- Numeric
- String
- GUID
- Byte String
Most commonly used is the numeric node id and the string node id. Every information model defines the node id for all the nodes which are defined inside that model.
Variables: Properties vs. DataVariables
A variable is used to represent a value in the OPC UA address space model. OPC UA Part 3 defines two types of Variables: Properties and Data Variables.
Properties
Properties are characteristics of Objects, DataVariables and other Nodes defined by the Server.
One major difference to DataVariables is, that Properties do not allow to have child-properties. In general a Property should not have any child nodes and should be a leaf node.
Also, a Property BrowseName shall be unique in the context of a Node to uniquely identify it.
DataVariables
A DataVariable represents the content of an Object. For a file this could be the binary string, while a property is used to provide modification times.
Compared to Properties, DataVariables may also have child DataVariables to form a more complex structure.
Companion Specifications
The base information model can be extended through companion specifications. A companion specification basically extends the core types with custom object types or defines new variable types.
Some example companion specifications are for example:
- OPC UA for Devices (DI)
- OPC UA for Robotics (ROB)
- OPC UA for PLCopen
A full list of officially released specifications can be obtained here.
An OPC UA Server can implement any combination of given companion specifications to provide the corresponding hardware data. The loaded companion specifications are listed inside the server’s namespace array variable.
Additionally to the officially released companion specifications, anyone can create his own companion specification which extends the basic OPC UA node set with custom types and definitions.
A tutorial on how to create your own Information Model can be found in this post:
This post was migrated from https://opcua.rocks/
