The Adaptable Nature of OPC UA Applications
Introduction
In the spring of 2015, a research group at Aachen University in Germany presented a paper titled “A RESTful Extension of OPC UA” (Grüner, 2015).
That paper addressed the ongoing discussion about the need and desire of stateless communication for industrial applications, with a specific focus on the use of OPC UA as a means to successfully address those requirements.
A popular architecture, Representational State Transfer (REST) allows distributed applications to interact between known endpoints, without the need for the participants to maintain a stateful communication channel. Instead, the requests and the responses are atomic and self-contained.
Technically, OPC UA cannot be considered stateless – given the need to define SecureChannels and Sessions as foundational transport.
Take a look at a simplified sequence diagram representing an OPC UA over TCP Read operation:
The Aachen team eventually proposed a REST implementation so that similar operations would be self-contained, in such a way that a client can issue a request without implementing a session ceremony:
Their proposal included a small modification to the OPC UA binary protocol to attain such behavior. That experiment (described in the paper) implied giving up things like the security implementation in favor of a faster performance and the compatibility of existing clients.
The goal was to allow users to implement more flexible architectures, with a similar decoupling model as the web services and the HTTP REST implementations that constitute the heart of many new developments like cloud deployments, service buses, etc.
Session-less Services
Fast-forward to 2017, the OPC UA working groups are about to release the 1.04 specification (at the time of this writing, the specification is in Release Candidate state). The core innovation of this release is the specification of the Pub-Sub architecture, which some of you might have heard and even seen demoed at conferences or in the GitHub reference implementations.
In a recent conversation with Randy Armstrong, of long OPC fame, I was introduced to some of the new concepts. Of all the things that Pub-Sub brings to the table, the one simple aspect I wanted to especially mention is the implementation of Session-less Services.
The idea is similar to the RESTful implementation: OPC UA Services such as Read, Write, or Call, can be invoked without carrying specific caller state information.
The comparison between the “traditional” versus the session-less methods is clear in this simplified diagram:
Some of the parameters that would normally be in the RequestHeader and the ResponseHeader, will now be included in the body of the message. An Authorization header is still going to guarantee a good level of security for the encoded messages.
A significant excerpt from the Part 4 specification (OPC Foundation, 2017):
“Session-less Services can be invoked via a Secure Channel by using the Access Token returned from the Authorization Service as the authenticationToken in the requestHeader passed with the Service Request. The Secure Channel shall have encryption enabled to prevent eavesdroppers from seeing the Access Token. If application authentication through the Secure Channel is sufficient, Servers may not require the Access Token. In this case, the authenticationToken shall be null.”
This is quite a big step compared to the Aachen experiment, which had the great merit of thinking “out-of-the-box” but still within the intentions of OPC UA.
The implication of this small enhancement is that now it opens the door to specific atomic behavior implementations where devices and systems need to exchange relevant and secure information (or invoke a method call!) across a largely distributed system, without the infrastructur requirements of stateful communications, but also when there is no need for more complex (and much more powerful) pub-sub implementations (like AMQP, which is supported by 1.04).
Conclusion
Clearly, all the efforts around a reliable and flexible implementation of Industrial Internet of Things (IIoT) and Industrie 4.0 have prompted the research of more different ways to exchange information among industrial systems.
And once again, the advantage of the OPC UA design is that – since its inception and for its very nature – it is a specification that can fit more than one scenario and does not constrain innovation but enables it.