OPC Introduction
OPC (Open Platform Communications) is a standards-based approach for connecting data sources such as PLCs, controllers, I/O devices, or databases with graphics, trending, alarming, and other HMI client applications. It enhances the interface between client and server applications by providing a universally supported and well-documented mechanism to communicate data from a data source to any client application. Included are not only a detailed guide on how to pass the data, but also specific information on other attributes to supplement that data, such as range information, data type, quality flags, and date and time information.
OPC UA or Unified Architecture unites legacy OPC standards, such as OPC-AE (Alarms and Events), OPC-DA (Data Access), and OPC-HDA (Historical Data Access) into one specification. It is an International Electrotechnical Commission (IEC) standard with reference number IEC 62541. Learn more
GENESIS supports these protocols, with OPC UA as the common and modern standard, and OPC Classic as the legacy option for backwards compatibility.
The GENESIS Alarming application service, which has both client and server components, is an example of a real-time data display that focuses on the alarm and event type data specified by the OPC-AE standard. You can configure Alarming to display real-time alarm events in a viewer application that originates from an alarm server application that monitors alarm-based OPC-AE devices.
Client-Server Model
Being of a distributed nature, OPC UA works in both a client-server model and in a publish-subscribe model.
For client-server communication, the full range of the information model access is available via services. This follows the design paradigm of service-oriented architecture (SOA), with which a service provider receives requests, processes them, and sends the results back with the response.
These interactions can be done with different levels of security, reliability, and performance.
The publish-subscribe (Pub/Sub) model provides an alternative mechanism for data and event notification. While in client-server communication, each notification is sent to a single client with guaranteed delivery, the Pub/Sub has been optimized for many-to-many configurations. With Pub/Sub, OPC UA applications do not directly exchange requests and responses. Instead, publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, subscribers there may be. Similarly, the subscribers express interest in specific types of data and process messages that contain this data, without needing to know its origin.
Platform Independence
Given the wide array of available hardware platforms and operating systems, platform independence is essential. OPC UA functions on any of the following and more:
- Hardware platforms: traditional PC hardware, cloud-based servers, PLCs, or micro-controllers such as ARM
- Operating Systems: Microsoft Windows, Apple OSX, Android, any distribution of Linux, etc.
OPC UA provides the necessary infrastructure for interoperability across the enterprise, from machine-to-machine, machine-to-enterprise, and everything in between.
OPC UA Transport Protocols
The OPC UA transport protocols are currently described in the specifications as follows:
- OPC UA TCP: a custom binary protocol, usually used for performance-critical environments
- HTTP/SOAP: the standard envelope used on classic Web Services
- HTTPS: usually used for REST Services
All these transport/session protocols are used in conjunction with data encoding techniques, such as:
- OPC UA Binary format: Used in conjunction with the OPC UA TCP protocol.
- XML: Used in conjunction with HTTP/SOAP protocols to expose classic web services.
- JSON: Used in conjunction with HTTPS to provide a REST service.
OPC UA Variable Types
OPC UA supports a number of data types (variables) for various cases. Learn more
These variables are produced by one or more field devices, such as sensors and actuators, and consumed by the OPC UA server. The OPC UA server then notifies subscribed OPC UA clients of these variables. The OPC UA clients consume all data produced by sensors and actuators through the OPC UA server.
What's Next?