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:
Proprietary Protocols:
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 amongst 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.
Custom Drivers:
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.
Complex Integration:
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.
Device and Controller Loading:
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.
Obsolescence of Legacy Infrastructure: 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.
Enterprise Wide Data Connectivity:
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.
Are there some Real-World Examples of OPC in Action? Yes. For some real-world examples of how OPC has been used to resolve various third- party data connectivity issues.
Advantages of OPC
The first and still most successful Classic OPC standard – OPC Data Access – was designed as interface to communication drivers, allowing a standardized read and write access to current data in automation devices.
The major use case was HMI and SCADA systems accessing data from different types of automation hardware and devices from different vendors using one defined software interface supplied by the hardware vendor.
Standards following later like OPC Alarm & Events and OPC Historical Data Access were also designed to access information provided by SCADA systems.
With the successful adoption of OPC in thousands of products, OPC is used today as standardized interface between automation systems in different levels of the automation pyramid.
It is even used in a lot of areas where it was not designed for, and there are many more areas where manufacturers want to use a standard like OPC but are not able to use it because of the COM dependency of OPC or because of the limitations for remote access using DCOM.
OPC XML-DA was the first approach of the OPC Foundation to maintain successful features of OPC but to use a vendor and platform neutral communication infrastructure.
There are several reasons why just creating Web Service versions of the successful OPC specification did not cover the requirements for a new OPC generation. One reason was the poor performance of XML Web Service compared with original COM version. Furthermore, using different XML Web Service stacks caused interoperability problems.
But besides the issue of platform independence, the OPC member companies brought forward the requirement to expose complex data and complex systems, removing the limitations of Classic OPC.
The OPC Unified Architecture was born out of the desire to create a true replacement for all existing COM-based specifications without losing any features or performance. Additionally it must cover all requirements for platform-independent system interfaces with rich and extensible modeling capabilities being able to describe also complex systems. The wide range of applications where OPC is used requires scalability from embedded systems across SCADA and DCS up to MES and ERP systems.
The most important requirements for OPC UA are
- Communication between distributed systems
- Reliability by
- Robustness and fault tolerance
- Redundancy
- Platform-independence
- Scalability
- High performance
- Internet and firewalls
- Security and access control
- Interoperability
- Reliability by
- Modeling Data
- Common model for all OPC data
- Object-oriented
- Extensible type system
- Meta information
- Complex data and methods
- Scalability from simple to complexmodels
- Abstract base model
- Base for other standard data models
The requirements can be grouped into the ones for the communication between distributed systems being able to exchange information and the requirements for modeling of data describing a system and the available information.
Classic OPC was designed as device driver interface. OPC is used as system interface today; therefore, the reliability for the communication between distributed systems is very important.
Since network communication is not reliable by definition, robustness and fault-tolerance are the important requirement, including redundancy for high availability. Platform-independence and scalability is necessary to be able to integrate OPC interfaces directly into the systems running on many different platforms.
To replace proprietary communication, an important requirement is always high-performance in intranet environments. But also internet communication through firewalls must be possible out of the box, which makes security and access control another important requirement. And first and foremost the interoperability between systems from different vendors is still the most important requirement.
Modeling of data was very limited in Classic OPC and needed to be enhanced by providing a common, object-oriented model for all OPC data. This model must include an extensible type system to be able to offer meta information and to describe also complex systems. The availability of methods provided and described by servers and callable by clients is a powerful feature needed to make OPC flexible and extensible.
Complex data is required to support the description and consistent transport of complex data structures. It was an important requirement to enhance the modeling capabilities, but it was equally important to support simple models with simple concepts. For this reason it is required to have a simple and abstract but extensible base model to be able to scale from simple to complex models.
In addition to the functional requirements for a new OPC generation, the initial group of over 40 representatives defining the requirements and use cases for OPC Unified Architecture was not only composed of OPC members.
Other standardization organizations like IEC and ISA interested in using OPC as transport mechanism for their information were involved in the early design process. In this group the OPC Foundation defines HOW to describe and transport data, and the collaborating organizations define WHAT data they want to describe and transport depending on their information model.
Another important design goal was to allow an easy migration to OPC Unified Architecture to protect the investment in the very successful Classic OPC standards and to build upon the large installed base of OPC.
Also Read: What is OPC ?