Innovations in Comfort, Efficiency, and Safety Solutions.
What's Really In Your OPC UA Server
OPC UA Servers are much more sophisticated than Servers of other technologies.
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.
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.
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
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
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 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:
The ObjectType ServerType requires the Server Object to support a number of component objects including:
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.
This object contains items like session count, view count, session timeout, subscription counts and lots more counters that assist in troubleshooting Server operation.
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.
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
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:
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/.
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/
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]