What's Really In Your OPC UA Server OPC UA Servers are much more sophisticated than Servers of other technologies.

John Rinaldi, Chief Strategist, Business Development Manager and CEO Real Time Automation (RTA)

OPC UA is, like its factory floor cousins, composed of a client and a server. The client device requests information. The server device provides it. But, as we’ll see in this article, what the UA server does is much more sophisticated than what an EtherNet/IP, Modbus TCP or Profinet IO server does. An OPC UA server models data, information, processes and systems as objects and presents those objects to clients in ways that are useful to vastly different types of client applications.  For more information  http://www.rtaautomation.com/technologies/opcua/

If you’ve ever worked with Modbus TCP you know that a Modbus Server device is going to be nearly identical to every other Modbus TCP Server. Because it’s a Modbus TCP Server, you could be pretty certain that it exposes most of its data as Modbus registers. And since there are just three function codes that operate on Modbus registers you could be pretty certain you’d know what function codes it supports. Other than the number of data items (registers) in its internal data tables, everything else in it is going to be pretty similar to every other Modbus TCP Server. Similar security (or lack of it), operations, error checking, physical layer and more. You won’t find a lot of variability.

All Servers, and we’re talking industrial Server devices here, provide the physical interface to the real world. Servers measure physical properties, indicate status, initiate physical actions and do all sorts of physical measurement and activations in the real world under the direction of a remote Client device. Servers are where the physical world meets the digital world.

OPC UA Servers are fundamentally just like all other Servers in that they are also endpoint devices. OPC UA Servers measure and digitize Inputs and transform Outputs to their analog equivalents. But that is where the similarity ends. OPC UA Servers are much more sophisticated than Servers of other technologies.

Figure 1 - OPC UA Server Overview

You can think about OPC UA Server device like you might think of automobiles; they all have a specific function, but there is a wide range of capabilities and services among them. Dump trucks, buses and your Buick are all automobiles, but the range of capabilities and services is vastly different.

Profiles

The specific capabilities of an OPC UA Server are described by the Profile it supports. A profile indicates to other devices (electronically) and to people (human readable form) what specific features of the OPC UA specification are supported. Engineers can determine from the Profile if this device is suitable for an application. A Client device can interrogate the Server and determine if it is compatible with the Client and its application and if it should initiate the connection process with the device.

Server Profiles support a wide range of functionality and provide the scalability found in OPC UA. The least functional Profile is the Nano-embedded Server Profile. The Nano Device Server Profile contains the minimum set of functionality needed by small, resource-constrained, embedded devices. The Standard OPC UA Server Profile contains the most comprehensive set of functionality but is usually only suitable for resource-rich devices like PC Servers.

Address Space

All Servers implement some sort of Address Space. The Address Space is how a Server device represents its functionality to Client devices. The Address Space is how the Inputs, Outputs and data in a device are represented. The Modbus Address Space consists of a series of 64K blocks. The EtherNet/IP and DeviceNet Address Space consists of Objects with Attributes that represent data points. And the ProfiNet IO and Profibus Address Space is represented as Slots with Modules and Channels.

The more sophisticated the Address Space, the better the device is at representing its data and functionality. Let’s imagine a two-channel Flow Controller with two temperature inputs and two Flow Sensors and look at its representation in a number of different protocols.

Modbus isn’t very functional in this flow controller. All you have is a series of registers and no way to provide meta-data regarding the units of the flow values and temperatures and no way to relate the temperature and flow for each channel together.

EtherNet/IP is more functional in that you can have a Flow Channel Object with attributes for the temperature and flow values. Instance #1 of that Object can provide the temperatures and flow for the first channel, while Instance #2 would provide the second channel. Meta-data can be provided in other attributes if the flow device vendor chooses to add the additional attributes.

ProfiNet IO is nearly the same as EtherNet/IP except that a module might be used to represent each of the two channels. Additional points could be used to provide meta-data.

In the more functional OPC UA Address Space, the OPC UA Server represents the data hierarchically in a way that makes more logical sense to a user and lends itself to a visual representation like Figure 2. With OPC UA, you get a much more complete view of hierarchical processes than you do with traditional technologies like Modbus TCP, ProfiNet IO, EtherNet/IP and BACnet.

Figure 2 - OPC UA Address Space

Services

Like other kinds of Servicers, OPC UA Clients issues message requests to a Server and the Server responds with response messages. Message Requests can be directed to the Address Space of the Server or to the Server’s OPC UA communication stack.

Requests issued to the Address Space can be as simple as reading an Attribute of a Node like the value of the temperature on Channel #2 in Figure 2. Or requests can be more sophisticated. A Client can request to Browse the Address Space, add or delete Nodes, subscribe to notifications, request historical data, diagnostics, or much more. The specific services supported by a Server are identified by the Profile it supports.

[an error occurred while processing this directive] An OPC UA Server implements a much more sophisticated set of services than Servers of other technologies. It announces its availability to interested Client devices, it provide a list of its capabilities and functionality to interested Clients, it provides notifications of different kinds of events, it executes small pieces of logic called Methods, it provides Address Space information in bulk to Clients (Query Service), it provides Browsing services so that a Client can walk through its Address Space, and it can allow Clients to modify the node structure of its Address Space. It can do a lot! And most of that function can’t be found in other automation technologies.

Requests can also be directed to the communication stack. These requests can be requests to identify the type and level of security available, what transports the Server supports, to create new connections or sessions, and do other connection management.

OPC UA Server Architecture

The architecture of a Server (Figure 3) can take many forms, but the same components are present no matter how it is architected. Let’s take a look at each of the individual components.

The most basic part is the OPC UA stack itself. This is where the heavy lifting of moving messages happens. Incoming messages from Client devices are received from the TCP/IP layer and passed to the OPC UA communications stack. This is where the Client is authenticated, access to the Servers resources are authorized, and where the incoming message is decoded to identify the service requested by the Client. For outgoing messages, this is where the responses are encoded and transmitted to the Client.

Figure 3 - Server Software Architecture

A service request like “read attribute” is processed in the section of the Server called “service sets.” Processing of the request generates a response message, which is passed through the communications part of the stack as described above. That happens for all service requests. The Client request is processed, a response created and then it is encoded, securitized and transported to the Client.

The user application is the part of the architecture that implements the Information Model and the OPC UA address space. This is where the application synchronizes the real world data to the OPC UA Address Space. Sensor or other data collected from the real world is stored as objects in the OPC UA Address Space. Output data in the Address Space is written to the real world outputs. And in more sophisticated applications, this data is organized to conform to a specific Information Model provided by a trade association or user group of some sort.

Lastly, the final part of an OPC UA Server is the Server end user application. If the device is a motor controller or some other sort of device, this is where the real work of the application happens.

The architecture detailed here is not the architecture that you may find in some of the widely available OPC UA toolkits in the marketplace. Some of these products differentiate the stack processing from any sort of service processing. The service sets, information model, Address Space and the rest are not part of the toolkit. If you plan to purchase a toolkit, make sure that you understand exactly what is included and what is not included.

The Server Object

Most networking technologies provide some sort of mechanism for a networked device to discover the identification information of a device. EtherNet/IP has an Identity Object and other technologies provide similar functionality.

In OPC UA, the Server Object provides that functionality. The Server Object, the black box on the following diagram, fits into the Address Space model as an Object in the Objects Folder under the Root Object. The Root Object is the top level object in an OPC UA Address Space.

Figure 4 - Server Object in the OPC UA Address Space

In Figure 4, you can see that the Server Object is typed by the ObjectType ServerType (all type definitions are lightly shaded boxes). The ObjectType ServerType defines a number of variables to include in the Object. These include:

• Server Array – The Server Array is essentially a set of pointers to remote OPC UA Servers that are referenced in the Address Space.
• Namespace Array – The Namespace Array is a table of URIs for the various namespaces used by nodes in the Address Space. Index 0 in the array is the OPC Foundation namespace. Index 1 is the local OPC UA Server, while index 2 and above reference other organizations that are responsible for the definition of Nodes used in the Address Space.
  
• Server Status - Operational status of the Server, including build information like manufacturer, product codes and software version.
• Service level – A quality of service level from 0 to 255 (best) that Clients can use to judge the relative reliability of Servers in a redundant Server network.
  
• Auditing – A Boolean indicating if the Server is generating auditing events.

The ObjectType ServerType requires the Server Object to support a number of component objects including:

ServerCapabilities
This object describes the capabilities supported by the OPC UA Server. The SeverCapabilities object contains the list of profiles supported by the Server, the list of signed software certificates from certification testing, the local IDs used for supporting multiple languages, and any number of other operational kinds of data variables.

ServerDiagnostics
This object contains items like session count, view count, session timeout, subscription counts and lots more counters that assist in troubleshooting Server operation.

VendorServerInfo
The VendorServerInfo Object exists to allow vendors to extend Server information by adding additional proprietary information to the Server Object. Vendors can subtype the Object Type and create their own type—“VendorServerInfo.MettlerScaleInfo,” for example—where they can store additional useful information that is particular to their Server implementation and application.

ServerRedundancy
The ServerRedundancy Object describes the redundancy capabilities provided by the Server. This Object is required even if the Server does not provide any redundancy support.

The Nine Most Important THings You Need to Know About OPC UA Servers

[an error occurred while processing this directive] Servers are complicated devices with capabilities and operating characteristics that are unlike traditional Servers in Building and Industrial Automation applications. Here’s a summary of what you really need to know about OPC UA Servers:

1. The specific capabilities of an OPC UA Server are described by the Profile it supports. The Nano Profile is the least functional, smallest profile, while the Standard Profile contains its full, complete capabilities. Every part of the Server’s architecture is a function of the Server Profile selected by the Server device vendor. The Profile identifies the transport: web services, HTTPS, OPC UA Binary TCP, or something else. The Profile identifies what the type and level of security that is used and the specific services that are supported.
   
2. All Servers support a Discovery Service which Clients use to discover OPC UA Servers that are available in a system. It communicates the transports, security and other communications characteristics supported by that specific Server. A network may also contain a special Server, called a Discovery Server that aggregates the information supplied by all the Servers on a network.
3. Once a connection is made, a Client that is not familiar with the Server’s operating characteristics reads the Server Profile to understand what certified functionality is incorporated in the Server, what encodings it uses, its support for subscriptions and notifications, what other services are supported, and much more.
4. Servers are only required to support a single transport. Any one of several transports can be supported by a Server. Clients, on the other hand, must support multiple transports.
5. A Server can support either XML or Binary encodings, or both. The vendor building the Server makes that decision at design time.
6. The Server Object, which is not required for the low-end Nano Profile, provides the vendor specific information about the Server.
7. A Server represents data to Client devices through its Address Space. An Address Space is almost always built at design time, but there is no reason why it can’t be modified during Server operation. An Address Space consists of Nodes defined by attributes that reference other Nodes.
8. Servers provide the type definitions for Objects, Variables and Data Types that are not predefined by the OPC UA Foundation. Some type definitions may not be typed locally if they are defined in another Server or by some other organization. In these cases, instead of the actual type definition, there is a reference to where the type definition can be found.
9. The Publish Subscribe functionality of OPC UA is supported in several different ways. Check with your Client and Server vendor to ensure compatibility.¹

OPC UA Server devices are end point devices that are more capable than Servers of other industrial technologies. UA Servers are designed to function in a wide variety of applications from low end sensor / actuator devices to sophisticated instruments and factory floor automation devices. The functionality of a Server is described by the Profile it supports. The least capable Servers use the Nano Profile while the most capable Servers use the Standard Profile.

For more information on OPC UA visit http://www.rtaautomation.com/technologies/opcua/.

______________

¹At the time of this writing, 2015, the OPC Foundation supports a working group that is redefining the operation of the Publish/Subscribe feature of OPC UA.

About the Author

The Industrial Ethernet Book focuses on explaining Industrial Ethernet concepts in a straightforward, clear fashion. The OPC UA: The Basics is an overview of this important technology. John’s latest book is on Modbus: the Most Pervasive Automation Protocol of the last 50 years of automation. You can get more of John’s opinions on automation, health, life, and sometimes, even love by subscribing to the RTA newsletter. Learn more by visiting http://www.rtaautomation.com/company/about-our-founder/ or connect with him on LinkedIn: https://www.linkedin.com/in/johnsrinaldi or via email; http://www.rtaautomation.com/contact-us/