OPC DA stands for Open Platform Communication Data Access, a standard interface to access the process data. They are mainly used in industrial applications.
Table of Contents
Introduction to OPC DA?
The OPC system provides a standard mechanism to communicate with several database sources, both the devices on the industry floor and the control room database.
OPC Data Access is based on the Component Object Model / Distributed Component Object Model (COM/DCOM). This Microsoft standard is being extensively used due to data access requirements in automation, where data is read by the interface or written for the controller.
The OPC Foundation defines the behavior of real-time data transfer between the data source and data sinks, such as programmable logic controller and human-machine interface (PLC and HMI), without knowing each other’s native terminologies.
Before introducing OPC DA, vendors of products such as PLCs or HMIs required a special “custom driver” connecting with the device that transfers information between the product and a third party.
Many problems are associated with custom driver-based communication; some of these are mentioned here, including restricted technologies that limit the user to a specific vendor, high cost, difficult to maintain or configure, and challenging to keep up to date.
On the other hand, OPC DA made connecting any real-time data source easier without using a custom driver for the data source/data sink pair.
This makes it possible for the data reader and writer to communicate without knowing the internal data structure or source native protocol.
History of OPC DA
OPC Foundation introduced the OPC Classic Specifications, and the first OPC was the Client/Server architecture of OPC DA.
The OPC Foundation responsible for defining OPC specification standards is a nonprofit, independent organization.
It was established in 1996 with the involvement of five companies. Currently, hundreds of members worldwide use this technology and mainly focus on promoting OPC specifications.
Over the years, the specifications ware updated:
1996 – Version 1.0 – First specification.
1997 – Version DA 1.0a – Data Access (DA) name adopted.
1998 – Version DA 2.0 – DA 2.05a – Clarifications and modifications in the specification.
2003 – Version DA 3.0 -Further additions and alterations.
Some vendors create new OPC products with backward compatibility in mind, but it is not mandatory.
Since then, the OPC family has expanded; let’s review the different types of OPCs.
Other Types of OPC
OPC UA – The latest OPC is Unified Architectures (OPC UA), which provides the facility of the same functionality, provides independent platforms, and has the capability of optionally complex data analysis.
OPC HDA – OPC Historical Data Access (OPC HAD) is used for historical data transfer.
OPC AE – OPC Alarm and Events
OPC DA Architecture
OPC DA Local Architecture
In this architecture, all the components are installed on one local server.
This simple architecture will make your life much more easier since you will not have to deal with DCOM security configuration.
It’s also an excellent architecture for the testing environment; it enables you to test the connection to the field device (PLC in our case) without the connection between servers.
OPC DA Distributed Architecture
The purpose of OPC is to get data from the field devices (PLC in our case) and communicate it between servers and computers. The distributed architecture enables precisely that.
There is no limit to the number of OPC servers you can use in your control system. The reasons to add more OPC Servers:
- Location – For example, in a multi-site system, you can install an OPC server on every site. The OPC client (for example, an MES system) will communicate with all of them simultaneously.
- Load balance between OPC servers – In some applications, there is an enormous amount of data coming from the field device, or the requirement specifies a minimal scan rate (less than 1 second). In this case, you can balance the load by adding another OPC Server.
- Logical order – Let’s take, for example, a factory with five different machines that produce different products and processes; it is sometimes beneficial to distribute the system to the machine level and install one OPC server for each machine.
- Redundancy – To achieve a high availability system, add another OPC server in parallel and configure the two OPC servers to work in hot standby redundancy. In some cases, there is a need for another component called ‘witness’; this component will always check the two servers and activate a transition in case of a failure in the primary server.
OPC Server
OPC server is an executable service that can be installed on any local PC, which provides a connection between a controller and the OPC DA client (for example, SCADA).
COM / DCOM provides access to the OPC server, which is running on another computer, with the facility to access the source of data by more than one client simultaneously.
The OPC server uses the variables (termed as Items or Tags in OPC) available on the controller.
The server provides the information to the OPC DA client about the attributes associated with OPC DA Item/Tag:
- Value
- Quality of the value
- Timestamp
Apart from installation and initial drivers configuration, Tags and Groups are the main interaction of the system owner with the OPC DA. The OPC will scan the list of tags with the PLCs database addresses. This tag list has to be updated and maintained if future changes in the system occur.
Sometimes it’s possible (Depending on the OPC driver) to refer directly to the PLC database without the Tag list. It’s called Aliasing, and in this case, the OPC DA client will determine the PLC addresses and the required scan rate.
The use of Cache memory provides fast access to the values. Another possibility of non-cached access to the controller items.
If the OPC DA is an off-the-shelf software (Not a .Net implementation), then its installation and configuration are straightforward.
OPC connectivity to sources
Impotent role of the OPC is to communicate with different source communication devices; to do so, it uses Drivers.
A driver is a software component that enables an OPC server to meet the connectivity requirements of a specific device, system, or other data source. The driver handles all proprietary communications to the data source.
The drivers are the implementation of an industrial communication protocol like EthernetIP, ModbusTCP, Profinet, and hundreds of different drivers available today.
The data sources can be:
- PLCs
- VFDs
- Smart Instrumentation
- DCS
- Third-party applications
- And many more
OPC Client
In the end, our goal is to bring the data safely to the desired application that acts as the OPC DA client
Different OPC DA clients are given as follows:
- SCADA – Most use cases of OPC DA clients are the implementation of communication with a central SCADA system.
- MES – Like SCADA systems, Mes systems also need data from the plant floor and usually do it via OPC.
- 3rd part applications
Disadvantages of OPC DA
The OPC DA has a lot of problems; a few of them are:
- DCOM Problems – In many cases, the security of the DCOM component prevents us from initiating communication between computers (In the Local architecture, we can avoid it altogether); in those cases, we have to disable most of the security features and give high privileges, and so it defects the overall system security.
- Backward Compatibility of DA Client and OPC DA Server – Since there are several revisions to the OPC DA specifications, Not all products support backward compatibility to early revisions.
- Platform Dependence – The vast majority of the OPC DA products available in the market are Microsoft Windows software, usually with no support for Linux or iOS.
Real-life example with OPC DA
Let’s look at a real-life example with the following control system:
- Modicon Quantum PLC with built-in ModbusTCP supported.
- FactoryTalk View SE SCADA system with built-in EthernetIP supported.
We want the FTView to show data from the Modcon PLC, and since there is no protocol match, we need a different solution.
Kepware OPC Server, KepServer, can be used with ModbusTCP driver, and the SCADA, in this case, is the OPC client (FTView SE supports built-in OPC client capabilities).
Conclusions
OPC DA is widely used even though it isn’t the newest and most efficient data communication specification out there. This is mainly because of older devices that only support the OPC DA.
In the future, we will see fewer applications that use the capabilities of the OPC DA and more applications that will support OPC UA.
Therefore, we encourage you to learn OPC UA more in-depth.
FAQ
OPC DA cannot be used to transfer historical data, it is specially designed to transfer current values.
