Introduction
Last updated
Last updated
In recent years, the OPC Foundation (an interest group of well-known manufacturers for the definition of standard interfaces) has defined a large number of software interfaces to standardize the information flow from the process level to the management level. According to the different requirements within an industrial application, different OPC specifications have been developed in the past: Data Access (DA), Alarm & Events (A&E), Historical Data Access (HDA) and Data eXchange (DX). Access to process data is described in the DA specification, A&E describes an interface for event-based information, including acknowledgement, HDA describes functions for archived data and DX defines a lateral server to server communication.
Based on the experience with these classic OPC interfaces, the OPC Foundation defined a new platform, called OPC Unified Architecture (UA). The aim of this new standard is the generic description and uniform access to all information which is to be exchanged between systems or applications. This includes the functionality of all previous OPC interfaces. Furthermore, it is to generate the possibility of natively integrating the interface in the respective system, irrespective of which operating system the system is operated on and irrespective of the programming language in which the system was created.
Today, automation is used prominently in every major industry. While different industries often use different specialized devices, control systems, and applications, they all share a common, rapidly growing challenge - how to share data both amongst all these components and the rest of the enterprise.
Before looking at what OPC is and how it goes about solving one of automation’s biggest communications headaches, it is worth looking at what the problems were in the first place. Following is a list of factors that have traditionally caused the biggest data sharing issues, followed by a brief explanation of what impact OPC has hadon each issue:
Vendors often used proprietary protocols that allowed products from a particular product line to communicate among each other, but required custom drivers to communicate with other vendors’ products. To make matters worse, different product lines from the same vendor often did not communicate among each other, which necessitated the need for additional connectors.
OPC resolves this by making it unnecessary for the Data Sink to know anything about how the Data Source communicates or organizes its data.
Every end-to-end connection required a custom driver to facilitate communications between specific endpoints. For example, if an HMI needed to communicate with a PLC, it required a custom HMI driver written for the specific protocol used by the PLC. If this PLC data was to be historized, the historian required its own driver because the HMI’s custom driver could only be used to communicate with the HMI, not the historian. If a custom driver for the specific endpoints was not available, data communications were difficult and expensive to establish.
OPC eliminates the need for custom drivers between each new application and Data Source. In Figure 1, a single standard PLC driver could be shared by both the HMI and the Historian via an OPC connector with the added benefit that the OPC connector would only require a single connection to the PLC – reducing controller loading.
The use of custom drivers between every endpoint meant that even a small number of devices and applications quickly involved the use of many drivers. The same HMI running on multiple computers, all communicating with the same device, required multiple installations and configurations of the same driver on each computer. If the HMIs communicated with additional devices, each HMI required its own set of custom drivers for each of the devices. This created a version maintenance nightmare.
Using OPC greatly simplifies integration because once an OPC Connector for a particular Data Source is configured, all OPC-enabled applications can start sharing data with that Data Source with no concern for additional custom drivers.
Each driver establishes its own connection to the device or controller that it is designed to communicate with. Given the large number of custom drivers being used in a typical installation, the controller was often bombarded by many requests for the same information from every application that it needed to communicate with. In addition, many devices could only accept a limited number of simultaneous connections. If the number of drivers trying to connect to a device exceeded the number of connections it had, further workarounds were needed.
Traffic, and hence device loading, is greatly reduced by using OPC Connectors because a single Device-specific OPC connector requires only a single connection to the Data Source while simultaneously communicating with many applications.
As vendors release new products they eventually stop supporting older ones. When a new version of an HMI comes out, it may require its own set of device drivers that sometimes may no longer support communications with a device the previous version of the HMI supported.
OPC extends the useful life of legacy systems because once an OPC connector for a legacy system is configured, it allows any OPC-enabled application (most are) to communicate with the legacy system regardless of whether the application natively supports communication with the legacy system or not. Thus, OPC allows the newest applications to continue communicating with the oldest systems.
As the need for automation data grows throughout the enterprise, data-connectivity problems are compounded because applications from the corporate side were not designed to communicate with devices and controllers. This can potentially add extra load to the automation infrastructure and raise various automation security concerns.
OPC makes true enterprise-wide automation data sharing possible by allowing approved applications to share data with automation Data Sources without the need for installing custom drivers—all that’s required is an OPC connector.
