OPC UA on the rise from Unified Architecture to Universal Application

Recent developments show the OPC Foundation is making rapid progress toward fulfilling its original vision of eliminating multiple gateways. Everywhere.

By Ian Verhappen

Control readers will be familiar with OPC and the current version of that communication protocol, Unified Architecture (UA). However, as we will see, OPC is doing what it can to become the Universal Application as an engine of the much discussed Industrial Internet of Things (IIoT). A few examples of how OPC UA is becoming ubiquitous include:

  • Integrated as a ‘kernel’ within the FDI standards recombining HART, Foundation fieldbus and Profibus PA protocols.
  • AutomationML, a neutral data format for storing and exchanging plant engineering information, which when connected with OPC, will enable transfer of engineering data to operating systems.
  • PLCOpen, working with IEC 61131 and associated languages for programming PLCs to extend hardware independence from the software code.
  • BACnet, bringing OPC to the building automation environment.

I also recently received a few press releases about OPC at this year’s Hannover Messe (Interkama) exhibition that are causing me to believe the folks at the OPC Foundation truly want it to become the Universal Application protocol. They announced a collaborative strategy with Object Management Group (OMG) on the Data Distribution Service (DDS) standard.

DDS is middleware (the software layer that lies between the operating system and applications) protocol and API standard for data-centric connectivity that integrates the components of a system together, providing low-latency data connectivity with high levels of reliability and a scalable architecture. The standard allows software developers to focus on their applications, rather than the mechanics of passing information between applications and systems. OPC will be the connection between applications, while DDS will provide platform independence at the physical layer—getting the packets where they need to be in a timely, secure manner regardless of the protocol.

The other announcement that caught my eye was that OPC now supports Publisher-Subscriber communication functionality. Until now, OPC has been based on client/server architecture. Updating the architecture to include publish/subscribe capability is targeting connection and information transfer from embedded devices to the cloud. Existing applications already using OPC UA client/server communications can add the publish/subscribe features with minimal effort. The technology demonstration at Hannover Messe has been configured to show both semantic and syntactic data interoperability.

Existing applications using OPC UA client/server communications can add publish/subscribe features with minimal effort.

The new publish/subscribe capability provides a uniform model for distributing data and events from OPC UA devices to interested observers (subscribers) inside the production environment, as well as in external IT and analytics cloud systems. The connection to the cloud uses the ISO/IEC AMQP 1.0 protocol with JSON data encoding to enable handling the information in stream and batch analytics systems.

I suspect that before this integration happens in very many facilities, the OPC Foundation and 42 organizations that worked on developing the standard will be asked to confirm that connecting my embedded device to a cloud-based analytics system meets all the cybersecurity requirements of IEC62443.

Though not part of the present implementation, I wonder if this new capability will someday enable the use of OPC Publisher/Subscriber for closed-loop control. After all, it is publisher/subscriber capability that allows Foundation fieldbus to “control in the field” by being sure nodes on the network receive the information they require in a timely fashion to allow calculation of the regulatory control algorithms. If OPC now can guarantee delivery of messages on a real-time, scheduled basis, the potential is one step closer to reality. Time will tell.

Want to get columns like this in your inbox?  Subscribe to our Enewsletters here!

Lastly, OPC UA is now available on the open-source repository of GitHub. Open sourcing OPC UA technology allows groups such as academia and research organizations, as well as many suppliers and end-users, to assess and make potential enhancements to the code. The OPC Foundation will continue to maintain the integrity of the OPC specifications by requiring reference implementations prior to releasing any OPC specifications or enhancements that might arise from this initiative.

OPC is keeping busy and truly striving to be a key player in the development of IIoT, and in the process hoping to become the Universal Application capable of gluing all the disparate systems together at the application layer regardless of the native protocol of the end devices communicating with each other. When you think about it, that was the vision for starting OPC in the first place—making it possible for any device to talk to another without needing multiple gateways.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • The description of DDS is a bit misleading. I suggest you take a look at this slide-deck http://bit.ly/dds-opcua in which the difference and similarities between OPC UA and DDS crisply explained. The presentation also helps understanding how DDS lays over the 7 layers ISO OSI model. I think that will help clarify why statements like "DDS will provide platform independence at the physical layer" are wildly incorrect. DDS sits on top the Layer 4, i.e. transport layer, and provides functionalities belonging to session, presentation and application layer. Additionally, DDS support for data modelling allow to capture both functional and non-functional properties of data. Anyway, I suggest you take a look at the slides. Cheers, Angelo Corsaro OMG DDS SIG Co-Chair

    Reply

  • Thank you for your comment and reference to the slide deck explaining the relationship mentioned above in greater detail Angelo. I made the common mistake many of us do in describing Layers 1-3 as the "physical layer" / Ethernet so your expansion referencing the OSI model certainly helps. Ian

    Reply

RSS feed for comments on this page | RSS feed for all comments