Industrial IT&C > Company > News

The Key to Migrating to OPC for Ethernet Data Acquisition and SCADA

20 July, 2009

Imagine you're implementing a solution to collect data from thousands of alarm points in a factory using TCP/IP over an Ethernet network. Besides making sure all your data acquisition devices are compatible with one another, it's important to integrate everything into a user-friendly monitoring and control system. Sounds tough, doesn't it?

Although traditional OPC has been around for years to provide interoperability between Ethernet data acquisition devices and SCADA systems, there are several limiting factors that deter many system integrators. Thankfully, Active OPC Servers, with their "push" architecture, have made OPC technology a more viable and optimal solution for Ethernet data acquisition and SCADA applications.

What is OPC?
Industrial device manufacturers are always looking for a way to integrate their own communication interface with monitoring and control devices and major software applications, such as SCADA (Supervisory Control and Data Acquisition) and HMI (Human Machine Interface) systems. While SCADA and HMI developers are also busy upgrading, modifying, and testing the compatibility and quality of their solutions for newly released products, industrial device makers are worried about which format/protocol(s) to support. As a result, integration, compatibility, and development present a major headache for both device manufactures and software developers.

In 1996, the OPC Foundation introduced a series of standards and specifications known as OPC (OLE for Process Control) to solve this problem and facilitate interoperability in industrial automation.

Fig. 1: With or without OPC

OPC is a series of standards and specifications developed by Microsoft and worldwide automation suppliers, such as Rockwell, Siemens AG, and Intellution. The core of OPC is Microsoft's OLE COM (component object model) and DCOM (distributed component object model) technologies, which provide a common method for data exchange between programs, or use a "Network Neighborhood" to browse a folder remotely on the network. The OPC Server package can be installed where the OPC Client is located, or anywhere on the local network. This COM/DCOM framework has defined a standard set of objects, interfaces, and methods to facilitate interoperability in process control and manufacturing automation. By integrating OPC standardization into both software (SCADA) and hardware (device package), industrial devices can now communicate with the central monitoring software. For SCADA/HMI developers, this means OPC Client can now be built in as a standard driver to communicate with network devices, making it easier to support meters, process controllers, alarms, and I/O devices. For device manufacturers, providing an OPC Server solution along with their products allows for interoperability with SCADA, which account for over 80% of data acquisition applications.

An OPC Server is essentially the middleware that connects a field device to the SCADA/HMI. It basically consists of two layers. The upper layer, or the OPC layer, is the common OPC interface running various OPC specifications—such as OPC Data Acquisition (DA), OPC Alarms and Events (A&E), OPC Historical Data Access (OPC HDA), and OPC XML—to connect to the application software that has an OPC Client built in. As for the lower device communication layer, device manufacturers or third-party OPC Server package providers need to offer a communication interface (usually known as a device driver) in order to connect to a field device.

Although there are many benefits of using OPC, data acquisition and SCADA integrators are hesitant to adopt OPC for several reasons, including:

1. Difficulties with OPC Server configuration
2. Perceived lack of additional benefits

Difficulties of OPC Server Configuration

1. The High Learning Curve

To activate an OPC Server, the first thing a user must do is to connect to the field device. This process includes setting the channels, interfaces, protocols, devices, addresses, data formats, etc. These configurations represent the actual connections to the field device and the specific OPC Server fieldbus protocols. This is because for device manufacturers, OPC Server simply acts as a software protocol converter to translate the fieldbus protocols to OPC protocols. So if system integrators ask for an OPC connection, they not only need to learn how to use OPC protocols, but also learn the fieldbus protocols for each field device. In the end, it can take a great deal of time to set up the entire connection, even for a well trained engineer.

2. High Cost of an OPC Server Package

A per-seat license fee is usually required to use a SCADA system so users are charged according to a scale of points (also called channels or tags). The license confers the right to use the built-in driver (interface) to connect to field devices. OPC Server package providers and third party OPC manufacturers are also subject to per-seat licensing fees so end users end up paying twice to implement OPC connections in their SCADA systems. Due to these hefty fees, many users are deterred from implementing an OPC Server package in the first place.

Perceived Lack of Additional Benefits
As previously described, connecting devices to an OPC Server is essentially just configuring fieldbus protocols. So why do we need middleware like OPC? If you're looking for easy integration, why not just use the fieldbus protocols to connect devices directly and bypass OPC altogether? What benefits does OPC bring besides interoperability? SCADA system integrators are primarily concerned with reducing response time, improving flexibility to connect the remote devices, and reducing bandwidth and CPU usage to keep heavy-duty applications running. Can an OPC Server deliver all these benefits? If the answer to these questions is "No," then a system integrator is unlikely to deploy an OPC solution.

Push-based Active OPC Server
In addition to the standardized OPC Client/Server architecture, a new push-based OPC Server technology is now available for Ethernet-based data acquisition and SCADA applications.

Fig. 4: Push-based Active OPC Server and Pull-based traditional OPC Server

1. Push for Tag Installation

An Active OPC Server can generate tags and necessary information for target devices automatically without requiring system integrators to specify IP addresses, I/O channels, and data formats one by one, or edit and import configuration text files. In this push-based architecture, a single click "pushes" the installation profile from the device itself to the OPC Server so that the user does not need to spend time searching the devices on the network, or checking the user manual for detailed address definitions. It takes users an average of 2.5 minutes to create tags using a traditional OPC Server, and 60% of that time is wasted on looking up details in user manuals. By using Active OPC Server's push technology, users can generate all the tags they need in seconds—no questions asked.



2. Push for Device Connection

In Ethernet and TCP/IP networks, fixed IP addresses are always required for remote field devices so that the OPC Server can connect to a target IP address, creating problems for both IP management and Internet connectivity. For example, mobile devices are generally assigned dynamic IP addresses because they are constantly moving, such as in hospital or factory floor applications. However, dynamic IP addresses make it incredibly difficult for an OPC Server to connect to the devices and locate a device on the Internet. Obtaining fixed addresses for your devices would be ideal but cost-prohibitive.

Active OPC Server reverses this situation, acting as a Web server to provide access to remote devices regardless of their IP addresses. This push-based algorithm allows the field devices to be anywhere on the network, even if its IP address constantly changes, making the OPC to field device connection Internet/WAN and firewall friendly. Traditional OPC Servers, especially those used for data acquisition applications, lack this capability.

3. Push for Status Updates

Most Ethernet fieldbus protocols, Modbus/TCP, and similar proprietary protocols designate "master" and "slave" devices in their setups. As the terminology suggests, slaves respond to queries from the master. The increasing number of the devices and channels has contributed to higher CPU loading, more bandwidth being occupied, and longer response times when polling the entire loop cycle of the devices. Using push technology for tag status updates can go a long way in solving this problem. Instead of polling and waiting for timeout or responses from a traditional OPC Server, Active OPC Server simply waits for remote devices to send updates when an exception (such as change of status, or when a pre-defined threshold, limit, or schedule is reached) occurs. As a result, Active OPC Server reduces response time and CPU usage through push-based, event-driven, and periodic data updates.

Performance tests have revealed that using Active OPC Server and this "Push" architecture results in an I/O response time that is 7 times faster than other OPC Server packages (using a testing environment with 2,560 I/O channels). In a different test of network bandwidth usage, Active OPC Server and the field device caused an apparent 80% reduction in network traffic. The end result is that I/O access is more precise, and the cost of communicating with remote I/O devices is substantially lower, especially when the remote site has limited bandwidth (e.g., satellite, microwave, and cellular communication). At the same time, the CPU usage of the SCADA/HMI system is also reduced by 35% so that less maintenance effort and lower level hardware devices can be implemented.

Active OPC Server is the Key
Thanks to Active OPC Server's push-based architecture that requires no learning for configuration, system integrators no longer need to worry about CPU loading and bandwidth issues. Real-time event-driven updates also mean you don't have to wait for polling results anymore, offering greater flexibility in managing IP addresses for LAN/WAN access. And the best part is, it's free.