OPC UA Server Object

There’s a lot of interest around the globe for OPC UA. One of the drivers is that OPC UA is an extension of the original OPC which I have been calling OPC Classic. I named it after Classic Coke. Though OPC UA isn’t the same throwback after a terrible experiment that Classic Coke was.

The more I learn about OPC UA the more I marvel at its complexity and simplicity. It is both very powerful and at the highest level, very easy to understand. The power comes in the Type System, Object Model, multiple transport layers and ability to wrap other protocols.

For the past several days I have been studying the Server Object. Like everything else in OPC UA there are layers and layers of complexity to it.

The Server Object is, like almost all OPC UA Objects, an instance of a Type Definition. In its case, its Type Definition is the ServerType which is itself, a subtype of the BaseObjectType. All the type definitions for OPC UA are neatly grouped under the root node. From the Root Node in every Server you can follow the reference to the Types Object. From there you can follow the reference to the ObjectTypes Object. And from there to the BaseObjectType which is the parent of the ServerType. A Client can follow references from the Root Node through the Types Object to find the definition of any Object in an OPC UA Server.

The Server object, which is required as part of the Core Server Facet, neatly organizes a lot of information about the Server and makes it easily available to Clients who want to know the capabilities of the Server, its current operational status and any diagnostic information that the Server can provide. Since all Profiles are based on the Core Server Facet, a Client can count on being able to find this information by reading the Attributes and properties of the Server Object. A Client can find the Server Object from the Root Node of the Server by following the reference to the Objects Object and then to the Server Object.

In the Server Object you will find a number of different kinds of references:
ORGANIZES – An Organizes reference serves no purpose other than to establish a relationship from one of the source Objects to the nodes it organizes. The Root Node, for example, uses Organizes references to relate the base View, Objects and Types Objects to it. The View Node Organizes all references to the currently existing Views in a system. The Server is the destination node for a Organizes reference from the Objects Object.

COMPONENT – A component reference implies a “stronger” relationship between the Source Object and the Destination Object. A Component reference through a hasComponent reference implies that the destination Object is part of the Source Object. The Server Object, for example, has hasComponent references to the ServerCapabilities Object, VendorServerInfo Object and Namespaces Object. Whenever the destination is complex, meaning it is more than just a simple variable, UA requires that a hasComponet reference.

PROPERTY – A Property reference is simply some additional data that identifies what the node represents. A property could be the last configuration update, the number of run hours or the number of jobs processed. The key factor in the data being referenced with a hasProperty reference instead of a hasComponent reference is that the data being referenced must be simple. Simple variables are always connected to an Object with just a hasProperty reference. The Server Object has properties like the ServerArray (list of Remote Servers referenced in this Server) and the NamespaceArrary (list of Namespaces referenced by Objects in this Server).

The Server Object provides a wealth of data to a Client. It is one of the under-discussed and exceptional features included in OPC UA.