OPC UA Base Information Model and Companion Specifications
In part two of this series, I introduced you to OPC UA Information Modeling as a framework that allows you to digitally describe physical objects and processes in a plant-floor. I also highlighted that, to make it possible for you to build such a digital description, OPC UA defines what is called a Node, which is its basic unit of information that is used to build every other type of information.
Meaning that, as an OPC UA application developer, you would need to use a Node to create your variables, methods and objects and then in the connect them to build a complete information structure of your machine,device or sensor.
Now, because you’ll be building this information structure, with the sole purpose of it being consumed by another machine or application, there has to be rules around how an information model is built and presented so that there is consistency in the interpretation of information by all machines and applications that are using OPC UA. So to put those rules in place, the OPC foundation went on to officially define what a node should be composed of and came up with what is called a BaseNodeClass, which is like a template that can be used to create other nodes.
The BaseNodeClass specifies the characteristics that are mandatory for all Nodes to have. And these characteristics are that:
Every Node must have an identity which is unique, it must have a display name which clients can use for displaying to the end user, it must specify what type of Node Class it belongs to, and it must have a name that clients refer to when browsing the OPC UA server address base.
Further, the Base Node Class also defines other characteristics that are optional, for example, the description of a Note.
Now from that template of a base node class, the foundation went on to derive eight special types of Base Node Classes that you can inherit from, to create objects that you can join together in many different ways to come up with the kind of information structure that you need to represent any physical entity.
These special classes of nodes include, for example:
A Variable NodeClass, for representing a value that can be read and written to. A Method NodeClass, for representing a method that can be called by a client, and an Object NodeClass, for representing real world objects that you find in a factory.
This collection of the Base Types is what constitutes an OPC UA Base Information model. And it is the foundation upon which you as an OPC UA application developer can build a custom information model for your machine and be guaranteed that it will be understood by any OPC UA client.
To actually create a custom OPC UA information model, you either use a text editor to create a standardized XML file, or you use some graphical tools to produce the XML file.
This is demonstrated in part four of this series, but you’ll be able to get a glimpse of an OPC UA information module XML file developed for the robotics industry later on in this article.
Now, there is a challenge presented by using custom OPC UA information models. But before we dive into that, let’s first talk about the built-in OPC UA information models. For basic functionality of an OPC UA server, the foundation decided to build in some information models by adapting Classic OPC specifications into OPC UA. These functionalities are built on top of the OPC UA Base Information model and they come standard with any OPC UA server.
The first built-in information model is OPC UA Data Access. This is a Classic OPC specification that was adapted into OPC UA and it is intended for continuous data acquisition from a PLC or any piece of industrial equipment. It provides capabilities such as read, write, browse, and subscribe.
Second, there is OPC UA Historical Access, which is also an OPC UA adaptation of a Classic OPC specification, that provides capabilities for processing and analyzing data collected from a machine.
Next there is OPC UA Alarms and Conditions (AC), which again is an OPC adaptation of a Classic OPC specification. It provides the capabilities to receive alarms, respond to alarms, and filter through alarms.
And lastly, there is an OPC UA Programs (Prog) information module, which provides capabilities to run a stored set of instructions, for example, to run and control a batch process.
So here you can actually build a custom information model on top of these built in information modules.
Now, speaking of custom information modules, in as much as an OPC UA client will be able to browse through your OPC UA server address space and dynamically discover and map out your custom information model, it can only do so after it connects to your server.
But yet, for true interoperability, a system has to be able to anticipate the information structure that it will encounter before even making a connection, because then, you are empowered to build machines and software applications that have got full knowledge of how they are expected to interact with each other. This is what inspired the OPC foundation to collaborate with various industry verticals, to specify a standardized information model per industry vertical. Otherwise known as Companion Specifications.
For example, if device and software vendors in the Pharmaceutical industry agree on the same information model specification, then it becomes possible to build plug-and-play systems within that industry.
Companion Specifications are built on top of the OPC UA base and built-in information models. And currently, they range from industrial communication protocol modeling, where protocols such as Profibus and BACnet are being mapped to OPC UA, to vertical specifications collaborations, such as in Oil & Gas, Energy and Factory Automation.
Now, individual organizations are able to define and document their information models because the OPC foundation standardized how information modules are defined and packaged. Which is, using an XML file format that can be imported into an OPC UA application source code.
Now, as promised, let’s take a brief look at one such companion specification. The OPC UA Companion Specification for Robotics, which was created by a joint Working Group of the OPC Foundation and VDMA, the largest network of European companies offering robotics and robotic component.
In their own words, VDMA defines an OPC UA Information Model for the representation of a complete motion device system as an interface for higher level control and evaluation systems. The main use cases for OPC robotics Part 1 are: Condition Monitoring, Asset Management, Preventive Maintenance, and the vertical integration into higher level production IT systems.
Now let’s take a look at the actual information model.
Below is the OPC UA Robotics Information Model in the form of a NodeSet2 XML document.
You can see in the image above, that at the top of the document we have things like the declaration of the Namespace URIs.
Now, moving further down the document, we can see from the image below that we have an Axes node, which inherits from the Object NodeClass. It has a NodeID, a BrowseName, a DisplayName, a Description, and it has a list of Reference Nodes that specify how it is linked to other Nodes. The first Reference specifies that it has a component and it specifies the NodeID of the component in this information model.
And if we check the NodeID, we can see that this component is actually an AxesIdentifier, which is also an Object Node. And the AxesIdentifier also has a component specified by this NodeID. And this NodeID points to a Node called ParameterSet, which also has a component specified by an ID. And this component is a Variable Node, which holds the ActualPosition variable of a double data type. And this ActualPosition variable node also has a component which is a Variable node that holds the engineering units and it goes on and on.
So you can see how an information structure is being built using different types of nodes and using references to connect them.
That brings us to the end of this article, thanks for reading.
