In past columns I've commented that, even though many of us are aware of the shortcomings of Modbus, we're all familiar with it because it's still the single, common-denominator protocol that almost all devices default to.
However, the OPC Foundation has been steadily improving its products, starting with the release of the OPC Unified Architecture (UA) in 2008, which is published as multiple parts of the IEC 62541 standard series as a platform-independent, service-oriented architecture.
More recently, the OPC Foundation released support for client-server communications. This set the groundwork for widely distributed systems limited only by the hardware itself.
Servers are the interface to the real world, allowing the measurement of physical properties, indication of status, and initiation of physical actions. The OPC UA Client device sends message packets to server devices, receives responses from its server devices, and then acts on that information.
Each OPC UA system may contain multiple clients and servers with each client interacting concurrently with one or more servers, and similarly each server communicating with one or more clients. OPC UA applications can combine server and client components to interact with other servers and clients. Sessions are used to manage the client/server communications relationships with the resulting session’s subscription data only going to the client creating the subscription.
This client-server subscription model requires resources in the server for each connected client to provide reliable delivery using buffering, acknowledgements and retransmissions. As a result, the hardware in the clients and servers constrains the number of connections and amount of data that can flow over the network, which is why most field devices don't have the processing power to support OPC UA communications.
Client-server communications also enable a service-oriented architecture (SOA). This is how a service provider receives requests, processes them and sends the results back with the response.
In 2016, OPC added publish/subscribe (pub/sub) functionality to the standards portfolio. With client-server communications, each notification is for a single client with guaranteed delivery. Pub/sub provides an alternative many-to-many mechanism for data and event notification.
OPC pub/sub works by having publishers send messages to a message-oriented middleware, without knowledge of what, if any, subscribers there may be. Subscribers express interest in specific types of data, and then process messages that contain this data, without needing to know where it originated.
OPC UA pub/sub provides the necessary infrastructure to achieve seamless interoperability for a host of new applications and devices under the umbrella of IIoT, IoT and Industry 4.0. OPC inclusion of pub/sub provides an infrastructure that effectively allows information integration from embedded devices to the cloud.
Cloud infrastructures use pub/sub protocols for native connectivity to the edge without using adapters, so now with OPC UA, applications can also provide data directly to the cloud. The cloud integration path uses the ISO/IEC AMQP 1.0 protocol with JSON data encoding, which readily allows handling of the information in modern stream and batch analytics systems.
All this communication requires security, and that's also been factored into OPC UA as well. The latest items added include support for time sensitive networks (TSN) for consistent message timing and OPC UA Safety.
Similar to most other safety (fieldbus) protocols, OPC UA Safety is based on the black channel principle, and currently addresses controller-to-controller communication using OPC UA clients/servers with a safety integrity level (SIL) up to 4.
OPC may not yet be able to meet the requirements of every control system application, but it's certainly making an effort through its collaborative efforts to become the “new glue" from low-level devices with suitable processing capability through to business systems.
About the author: Ian Verhappen
