OPC Experts Interviews: OPC UA Use Cases

Summary

Christopher Anhalt of Softing talks about markets, adoption drivers, competing standards, the horizontal and vertical integration of IT and OT, companion specification use cases, green-field and brown-field… and many other things relevant to use cases that have made OPC UA so successful.

Christopher, please introduce yourself to our readers. Tell us a bit about yourself, your company, Softing, and your involvement to date with OPC technology and the OPC Foundation.

Anhalt: Sure, let me begin with Softing the company. Softing has specialized in industrial communication and embedded technology for over 30 years. We are headquartered just outside of Munich, in the town of Haar, Germany. We have several business units, one of which is called Industrial Automation, which focuses on developing and marketing industrial automation solutions.

Regarding the OPC Foundation, Softing has been a member since the early days in the 90s. We have a close cooperation with the OPC Foundation and have been actively involved in several technical working groups. For the past three years, I’ve worked as the business development manager in the Industrial Automation business unit and I'm also the marketing representative for the OPC Foundation for this internal group.

Can you please give us an overview of the different markets in which OPC UA has been deployed successfully and comment on growth opportunities for the future?

Anhalt: Let me begin with vertical segments. The core vertical, where OPC is coming from, is industrial automation. This is the vertical where OPC UA has been deployed successfully, and where we expect growth in the near future and beyond. Of course, it is possible to use and to deploy OPC UA in other verticals, including building automation, transportation, and many other segments.

From the beginning, OPC technologies have had a global presence, enhanced by collaborations with both international and regional standards bodies. The very diverse membership of OPC Foundation adds to its global presence.

It is remarkable how deeply OPC technologies have been adopted, especially in recent years, and we expect that growth to continue, especially in the Asian region. I mean, we see growth globally, but it has been particularly strong in Asia, where we now count China, Japan, South Korea, and Thailand as key markets; each are contributing to the rapid growth of OPC UA.

Regarding technology use cases, I will speak about vertical integration. This is the integration between OT devices and IT software applications, which count for the clear majority of deployments, driving additional growth in the future.

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. Visit us frequently to read the latest interviews.

What have been the drivers for adoption of OPC UA in various market segments and will they change as OPC UA moves into new markets?

Anhalt: Well, to summarize, the primary driver is the need for interoperability between devices, PLCs, and machines; interoperability between devices and software; and, finally, interoperability between software components. Interoperability throughout industrial solutions has been, and continues to be, the founding principle of the OPC Foundation. Users face questions about how to integrate these different components (hardware and software) efficiently; how to move data efficiently or securely; how to keep solutions flexible so they can be changed to take advantage of new solutions in the future.

When we talk about new markets, we need to look at what we now call IoT or Industrie 4.0. It's fundamentally the same need–the need for interoperability–but, what differs is scale and time-to-market pressures. Scale, with respect to hardware and the growing number of devices. Innovation in IT is now happening with short development cycles and increasing time-to-market pressures. These new pressures will only further increase the adoption of OPC UA because it's designed to address exactly those needs.

What about other interoperability standards competing with OPC UA? Do they exist, on perhaps an architectural level or even on a protocol level?

Anhalt: Well, that's a good question. The short and simple answer is, no.

First, there is no competing standard on the architecture level. When one looks at the combination of technologies or features that OPC UA integrates – information models, namespaces, semantic information, multiprotocol support, and security – the mixture of these, and other elements of OPC UA, is unique and there is just no other standard that combines and integrates all that.

Secondly, when you mention protocol level, it's true that OPC UA will sometimes be compared, and is often miscategorized, as a protocol. That's not to say that there may be scenarios and use cases where our goal can be achieved easily by implementing a protocol. But that's not really interoperability. A protocol is a different thing than an interoperability standard. It's not a correct comparison to liken OPC UA to a protocol.

Can you comment on adoption of OPC UA as the interoperability standard within the automation industry versus adoption within IT? Has it not been the case since the introduction of IoT, that folks working in either world have had a hard time understanding each other? Has OPC UA been able to bring these two worlds together?

Anhalt: Well, another good question and it's certainly true that there is an adoption gap between IT and OT, including a cultural gap. I would also add that there is an administrative gap between OT and IT in some organizations. I certainly believe that OPC UA has helped to bring these two worlds together. For example, when we look at technology, there is a deep similarity between information models, which I’ve already mentioned, and object-oriented design, which is a well-known, established concept in IT. So, the information modeling, based on the OPC UA standard, is not foreign to people experienced in IT.

The same is true for security standards; OPC UA is using, or leveraging, what has been implemented successfully in the IT industry for many years. Elements like TLS encryption or X509 certificates, to give a couple of examples. Within OPC UA, there are technological elements that help bring these two worlds together.

Let’s observe what the big IT players are doing; those who have entered the IoT market. Companies like Microsoft with their Azure platform; SAP with their Go to Market strategy and associated reference architectures; they all include OPC UA.

There is a third element, which I’ve observed in several meetings recently. I see that there's increasing knowledge about OPC UA among the IT systems integrators. For example, historically, companies have engaged in enterprise IT system integration projects but, now, they are starting to expand their portfolios and move into the industrial IoT market. What I now realize is that they have knowledge about OPC UA and their position now is, “please give us an OT interface that supports OPC UA and we know how to integrate our solution using that interface.” So, the short answer is yes; OPC UA has been able to bring these worlds together.

Let’s stay with the integration of IT and OT for a bit. Can you please share an overview of typical IT/OT use cases with our readers?

Anhalt: Yes, although, may I point out that the term “use case” is sometimes used broadly and can mean many different things. Perhaps some readers would expect me to explain, in some detail, different applications like OEE [overall equipment effectiveness], predictive maintenance, quality assurance or typical industrial IoT applications that require IT/ OT integration. These are interesting topics, but I don't want to focus on them. Instead, I would prefer to briefly outline some ways that OPC UA can be used to handle the interoperability problem. You may prefer to categorize these as data integration use cases; therefore, I'll try to outline the benefits and the relevance of OPC UA regarding these particular use cases.

The first group of use cases could be summarized as “implementing a basic interface”. Perhaps your company is a machine vendor or maybe a PLC vendor and you want to add an interface to your device that can be used for integration. Here is where OPC UA can be used. The same is true at the basic interface-to-software application – HMI’s, SCADA, or perhaps an MES system–A vendor may be looking for an interface that can be used for integration. OPC UA is a perfect choice.

A second use case deals with “data aggregation.” You may want to add an OPC UA aggregation server to your solution. This means that an aggregation server is used to collect data from many different data sources, which could be OPC UA data sources or perhaps others. The aggregation server integrates those data into one OPC UA server. This application has quite a few benefits. It may make communication between OT and IT applications more efficient by reducing communication overhead and communication cost. It may make configuration simpler. Aggregation servers help users build better-performing and easier-to-maintain applications.

I call the third use case, “interface abstraction.” This is the most abstract use case; by that I mean that OPC UA can be used to shield away differences in OT in order to provide a unified interface to IT. Using an interface abstraction strategy could help segregate various machines or perhaps, if we think about corporate level exchanges, it could be used to isolate locations.

What further details can you share with us regarding the three sub-categories you’ve just identified? Let’s start with vertical communication between OT and IT.

Anhalt: There are many details I could talk about, so let me pick just two. The first one is the feature I mentioned earlier regarding multiprotocol support. Users have a choice between different protocols that are supported by OPC UA. These fall into two broad categories. One is called the Pub-Sub [publisher/subscriber] model and the other is called Client-Server. Each model has its pros and cons and it's helpful to be able to choose. For example, if you have a scenario where scalability is key–a lot of data points which need to be communicated every time data changes–it is best handled by a Pub-Sub protocol. Whereas, a use case where you want to read out a certain value only occasionally–perhaps based on interaction with a human-being during configuration–this type of scenario is where the Client-Server protocol comes in handy.

Another aspect, which I mentioned earlier, deals with security. We all agree, as soon as we start talking about cloud applications, security becomes a crucial element. By adopting proven standards and by making security configurable, OPC UA helps users set up secure OT and IT communications. For example, OPC UA makes it possible to implement roles and configure role-based access rights to OT data. Another example is preventing access to “secret” process data from a maintenance person, one who uses a certain application to access the system for maintenance purposes; this person may even be an external user. These are a few simple examples of something you can do with OPC UA; you configure security to model certain roles and give role-based access for IT applications to OT.

And how about horizontal communication between OT and IT… so, between devices?

Anhalt: Again, I’ll pick two examples. The first, relevant scenario describes communication between sensors and supervisory controllers. OPC UA Pub-Sub can be implemented on devices with limited resources. For example, there are basic OPC UA server implementations that support Pub-Sub requiring only 200 kilobytes of code, or even less. When implementations are that small, they certainly do not include full-blown security. I mean, a cryptographic algorithm certainly requires more resources than that. However, in reality, security may not be needed at that level – it is certainly relevant for IT/ OT integration – but since this particular application is within the OT domain, it may be acceptable to relax some of these strict security requirements.

The second use case I want to mention, only briefly, is PLC to PLC communication. Here, OPC UA can also help, in combination with deterministic IP communications, but I guess that's a broader topic that potentially deserves separate treatment.

And last, but not least, what about use cases of OPC UA within IT… so, within the upper layers of IoT solutions? 

Anhalt: I guess one might ask a clarifying question, like, “what do you really mean by upper layers?” IT certainly is expanding; and it's coming closer and closer to the machine. Let me begin to answer this question by addressing OT at the edge.

When referring to the extension of on-prem, central platforms, or cloud platforms, designers are using OPC UA between various software components running at the edge. This could include a component for edge analytics and a separate gateway component that translates data from a central PLC into OPC UA. Then, these two components talk between each other, in terms of OPC UA data models within the IT realm. That's what I mean by “edge."

Now, when we think about the other “upper layers” such as MES systems or applications for predictive maintenance, OPC UA can certainly be used there. Having semantic information available can be very interesting for analytics, especially since the application is using OPC UA in its standardized data format. This is extremely attractive for end users. Think about not having a proprietary data format that requires a lot of migration effort, especially if the user ever decides to move to another platform.

So, as a final question on the topic of use cases, is OPC UA only relevant for green-field plants and factories? What about integrating OPC UA into my existing, brown-field production line?