OPC Experts Interviews: The Technology Behind OPC UA

Summary

The OPC Experts Interviews is a series taking a deep dive into open platform communications, OPC/OPC UA and related technology. In this interview with Uwe Steinkrauss, CEO of Unified Automation, you will learn how the science of OPC UA is applied across the industrial automation sector.
  

Uwe, please introduce yourself to our readers: Tell us a bit about yourself, your company, Unified Automation and your involvement to date with OPC and the OPC Foundation.

Steinkrauss: I am the CEO of Unified Automation and we are based in Nuremberg, Germany. We do Software Development Kits and Toolkits in all programming languages. Our customers use these Libraries to integrate OPC UA into their devices. We have implemented OPC UA tools and solutions since its inception in 2006, when OPC UA first started. We are involved in the Technical Working Groups, Prototyping, and Test and Certification activities of the OPC Foundation. We help drive the OPC UA standard forward by continuously contributing and supporting marketing events, roadshows, fairs, and tradeshows of the OPC Foundation.

Technologically speaking, how is OPC UA different, relative to other standards?

Steinkrauss: OPC UA is the first industrial-grade communication standard that combines data modeling with a secure transport. One is nothing without the other, but this combination is the key to success.

Tell us about the concept of modelling, what it is, and for what purpose it is intended. 

Steinkrauss: We need modeling to describe "things". To be more precise here, we need to describe the meaning of the data and we need to deliver the so-called "metadata" out-of-the-box. This is the precondition for Plug & Play or Plug & Produce. We need self-describing things and self-describing data. OPC UA offers an object-oriented description model that enables you to describe any kind of data. By describing it's meaning, OPC UA turns raw data into useful information. The metadata is conveniently included and can be read just like the data itself.

       The OPC Experts Interviews is a series of discussions taking a deep dive into open platform communications and related technology. International experts discuss OPC and OPC UA, protocol binding, security, the new Field Level Communications group, projects and experiences, and more. Automation.com is the exclusive publisher of these interviews, which are conducted by OPC Foundation personnel. Check back frequently to read the latest interviews.

What is so special about secure transport; don’t other secure protocols exist as well?

So, does every company produce their own model of their machines and equipment? What if users of different machine brands want to interact with these machines; do they need to understand all the different models?

Steinkrauss: Each device or machine vendor could create their own model, but the real benefit of modeling data is achieved when creating standardized models. The so-called companion specifications describe such models for an entire group of machines/devices or a branch/use-case. Besides generic access, which will always work, applications can be "specialized" within the data model. Therefore, they can do special things with this data, because they "understand" the data. This is an important requirement for flexible and "smart" networking.

The OPC UA standard provides two communication mechanisms: Client-Server and Publish-Subscribe, also known as Pub-Sub. Why not concentrate on just one?

Steinkrauss: OPC UA has two communications mechanisms because both are needed to meet all the requirements of industrial automation applications. Each one has advantages for certain use cases. Such use cases expand even beyond industrial automation.

OK, so when does one use Client-Server; and why? What is the advantage of using Client-Server?

Steinkrauss: Client-Server communications use a Request-Response paradigm.  The Requestor (the Client) gets only what it asked for. Client-Server uses Peer-to-Peer connections based on TCP/IP. OPC UA defines an abstract service API which implements a Service Oriented Architecture (SOA).
The resulting advantage is reduced bandwidth, since only that which was requested is transferred; and only when it has changed.
Secondly, there is robust transmission. Client-Server communications run within the context of a session and have configurable timeouts for each and every service call. Additionally, there is a keep-alive mechanism which monitors both the Client and the Server, confirming each is active on the network. The Client-Server messages have sequence numbers, response confirmation, plus acknowledgement within the next request. Furthermore, Client-Server subscriptions have data queues and retransmission on Layer 7. Simply said: nothing gets lost, even if the physical connection was interrupted. Once the session is re-established, all the data and events that occurred during the outage are presented.

The same question applies then for Pub-Sub; when do we use it, and to what advantage?

Steinkrauss: The Publish-Subscribe model is a different way to access data. Simply said: if only the last value is the exciting one, you should consider Pub-Sub.
Pub-Sub uses UDP-Multicast to address communication in one-to-many scenarios. The Publisher repeatedly sends out the DataSet across the network, upon which many subscribers are listening. The advantage to this is that publishers can reach many receivers with minimal CPU and memory resources (a low-cost device) on the sender's side. Secondly, with Pub-Sub, networks can realize very fast transmission speeds within the local subnet. But, be aware, there will be no backup, queue, re-transmission, or flow control, whatsoever. Therefore, a stable, Layer 2 network infrastructure is needed; hence, quality of service (QoS) plays an important role with Pub-Sub.

Tell us about Time Sensitive Networking (TSN) and how it plays into deciding which communication mechanism to choose.

Steinkrauss: TSN provides the aforementioned stable, Layer 2 network infrastructure, including a high level QoS. OPC UA and Pub-Sub can utilize many different transports but let’s focus, for this example, on using TSN. In contrast to the best-effort principle, as seen in a regular package-oriented network, deterministic data transmission is possible over TSN. Now, OPC UA can serve use-cases where "timeliness" is important, such as motion control and functional safety applications.

Now that we have received a base understanding of both communication mechanisms, does one have to choose either Client-Server or Pub-Sub?

Steinkrauss: No, ideally you don't have to choose. Both variants are available in parallel in most OPC UA capable devices. When considering a TSN or 5G infrastructure, one can use OPC UA at the lowest field level inside a machine. But even without TSN, anyone can use Pub-Sub in a machine or production line.
On a controller, at the HMI/SCADA level, or even in the MES/ERP at the factory level, users would probably prefer Client-Server communications, in keeping with the no-loss-of-data principal. Similar preferences likely apply when using OPC UA for configuration and engineering purposes.
Within IT or cloud applications, users could employ either or both. For a constant stream of pure telemetry data, Pub-Sub may be sufficient; however, for command and control, users would opt for service-oriented Client-Server. The majority of OPC UA enabled devices come with both options. The use-case dictates which is best for the job.

In the IT world, and especially in cloud applications, communication protocols like AMQP or MQTT exist. Do I continue using them instead of OPC UA or how does OPC UA deal with them?

So, have I correctly understood that, next to built-in security – which we talk about in another article  – scalability and re-use are two key elements of OPC UA?

Steinkrauss: OPC UA has ONE information model which contains data plus metadata, (preferably standardized in companion specification). This model can be accessed via TWO mechanisms (Client-Server and Publish-Subscribe). The access mechanisms use THREE (up to 5) transport protocols (which are selected according to the use case).
The continuity of OPC UA modeling, from the smallest sensor up to IT and Cloud applications, is one key element. The second key element is the re-use of established protocols, according to each use case.
OPC UA is based on Ethernet (encoded binary or JSON) and is transported natively with either UA-TCP and UDP, or MQTT, or WebSockets; all of which are well established open standards.
- Article adapted from an interview conducted by Peter Seeberg