OPC bridging transfers data between industrial automation systems

Integrators frequently use OPC technology to connect one industrial automation or process control system with another so that data can be shared between the two systems. Because OPC technology is based on a client-server architecture, the challenge is that two OPC servers cannot communicate with each other directly. A variety of vendors provide an intermediate software solution for connecting disparate OPC client-server systems, generically called an ‘OPC bridge’.

OPC is an industrial communication standard that enables manufacturers to use data to optimise production, make operation decisions quickly and generate reports. OPC enables plants to automate the transfer of data from a control system (PLC, DCS, analyser, etc) to an industrial software application (HMI, historian, production system or other management system). OPC is typically found in Level 3 networks and higher. Thus, OPC transfers process control data between the Control (Level 2) network and the Operations/Manufacturing (Level 3) network. It also exchanges data between the Operations/Manufacturing network and the Business (Level 4) network.

Figure 1: OPC communication enables applications to interoperate and simplifies system architecture.

Connectivity challenge

The successful automation of industrial systems often requires the connection of various disparate systems, or islands of automation, together. The following are some common examples of system interconnectivity:

• Sending data from a PLC to a DCS
• Connecting disparate PLCs together on a single network
• DCS ‘console replacement’
• Connecting an emergency shutdown system (ESD) with a DCS
• Sending data from one plant area or unit to another for feedforward or feedback control
• Bringing heating, ventilation and air conditioning (HVAC) data into an energy management system (EMS)
• Augmenting an existing SCADA system with a new data source

Since 1996, OPC has become the de facto standard for integrators to connect industrial automation systems. OPC servers are available from major control system vendors and the list of available OPC software continues to increase on a monthly basis. With OPC providing the communication backbone, connectivity is easier to establish, provided that integrators keep a few key OPC architectural concepts in mind.

Bridging concepts It is not possible for two OPC servers to communicate with each other ‘out of the box’ unless the vendor added non-OPC server capabilities to the OPC server software. Because OPC is based on a client-server architecture, an OPC server can only respond to requests from an OPC Client; the OPC server cannot make requests. In other words, OPC servers can only do what they are told. So two OPC servers cannot exchange data with each other directly because each waits for a request from the other, and therefore no data transfer will take place. The only way for two OPC servers to communicate is to have an OPC Client application provide a bridge between the two servers, thus becoming an OPC bridge. The OPC bridge requests data from one OPC server, and writes the data to another OPC server. All OPC bridge products follow this concept.

Figure 2: The only way for two OPC servers to communicate is to have an OPC Client application provide a bridge between the two servers.

Integrators must take three steps to set up the data transfer:

1. Set up the OPC bridge to connect to the OPC servers.
2. Set up the OPC bridge to read data from one OPC server and write it to another OPC server.
3. Set up the OPC bridge to automatically execute the above configuration.

After the initial set-up, most OPC bridge applications are set to execute automatically with little to no human intervention. This enables data to transfer on a regular basis, just as if there were a hardwired interface between the two systems.

Connecting to OPC servers

The first step to setting up an OPC bridge is connecting to the OPC servers. OPC bridge products typically provide integrators with the following ways to connect to OPC servers:

• Graphical user interface (GUI) — enabling integrators to graphically browse the local PC and other PCs on the network.
• Manual configuration — enabling integrators to get quick access to known OPC resources.

Figure 3: Cogent OPC DataHub enables integrators to connect to local and remote OPC servers. This OPC bridge software provides a mixture of a GUI and manual configuration to help both beginners and advanced users.

Most OPC bridge applications provide both methods and allow integrators to select the most efficient way to establish the OPC server connection. While a GUI is certainly easier for beginners to understand, the manual configuration method is preferred by experienced users.
Establishing the first connection to OPC servers is usually the most difficult step when using OPC, especially if the OPC server resides on a remote PC.

Mapping OPC items

After making the initial connection to the OPC servers, integrators must select the source and destination of each data item. OPC bridge applications typically enable integrators to accomplish this as follows:

A graphical interface enables integrators to graphically select each source item and the destination of the data.

Figure 4: Kepware LinkMaster provides a drag-and-drop GUI that enables integrators to quickly map data from its source to destination. Integrators can also make use of an import file for mass configuration.

Data-importing capabilities enable integrators to create a configuration file using an application such as Microsoft Excel and import the file into the bridge for mass configuration.

It may seem the graphical configuration method is an efficient way to configure the OPC bridge, but consider that most data transfers move hundreds and even thousands of items from one OPC server to another. Setting up each data item individually is both time consuming and error prone. Therefore, if you must move a lot of data, it is recommended that you select an OPC bridge that enables you to create standard configuration files, such as a CSV file, with a tool such as Microsoft Excel.

OPC bridge execution

Once the integrator sets up the OPC bridge, they must automate its execution. This automation comes in a few different flavours (listed in increasing desirability):

• Standard Windows application with explicit start-up: The OPC bridge starts only when someone explicitly selects it. This start-up mode may be convenient for testing purposes, but not for production because this method requires manual intervention to initiate the operation of the OPC bridge.
• Standard Windows application with automatic start-up: The OPC bridge starts when a specific user logs on to Windows. While this method does not require manual intervention, it does require a specific logon account.
• Windows service: A Windows service is a specialised application that is set up to execute with the ‘System’ identity. In other words, it executes as the operating system itself. This is the most desirable method to run the OPC bridge. This application can automatically start as soon as Windows boots up and does not require a specific user to log on to the PC. The OPC bridge is then able to immediately begin transmitting data with minimum interruption. Execution as a Windows service is desirable even if the project requires specific user accounts (with a user name and password combination) to connect to remote PCs.

Figure 5: Cyberlogic Crosslink executes as a Windows service. Crosslink’s configuration enables users to bypass DCOMCNFG to set the Server’s execution either as system or a specific user account.

Most OPC bridge applications can execute in all of the modes listed above; however, when selecting an OPC bridge, it is recommended that you choose a product that can run as a Windows service.

Key OPC bridge considerations

Performance

The performance of OPC bridge applications varies from vendor to vendor. However, most can easily outperform even the fastest automation networks. Connections to a DCS typically provide data in the range of about 100-500 points per second. Even connections to a PLC rarely exceed 2000 points per second. However, OPC can transfer data at over 10,000 points per second.

While an OPC bridge can technically transfer data at over 10,000 points per second, its performance is usually limited by its connection to its various data sources. To put the performance of the OPC bridge in the right perspective, I recommend you find out the speed of data from the original data source. This will help you to make more sense out of the specifications and claims of various OPC vendors.

Multithreaded operation

It is important that an OPC bridge continues to operate even when an acceptable fault in the system occurs. Consider an OPC bridge that transfers values from two data sources (two OPC servers) to a single destination (a third OPC server). If one of the two data sources stops operating or is delayed, it may still be necessary for the OPC bridge to continue transferring information from the good data source to the destination.

The ability to wait for one operation to complete while the other continues requires a multithreaded design for the OPC bridge. Unfortunately, most Windows applications are single threaded; in other words, they only do one task at a time.

When selecting an OPC bridge, ask your vendor whether or not their OPC bridge uses a multithreaded design when connecting to OPC servers. This will enable your system to withstand faults without compromising the entire health and performance of the system.

Cache reads upon reconnection

OPC Client applications (such as an OPC bridge) receive data updates from OPC servers whenever the OPC server detects a change in the data source. OPC servers transmit data that changes at various rates: some readings, like pressures and flows, change at high rates (many times per second), while other readings, such as setpoints, change at a very low rate (once per week, or never).

For example, the setpoint for room temperature is (typically) set once and left alone. Suppose that an OPC bridge disconnects from an OPC server that has the room temperature setpoint and later reconnects. In this case, the setpoint does not change, so the OPC server will not report a change in value. If the OPC bridge does not read the value and quality of the setpoint when it reconnects to the OPC server, the OPC bridge will never report the true value and quality of the temperature setpoint.

When an OPC bridge reconnects to an OPC server, it should immediately perform an operation called a ‘cache read’ from the OPC server. This will ensure that the OPC server will quickly pass all its available values. This transfer will take place quickly because a cache read tells the OPC server that the OPC bridge requires values that are already in the memory of the OPC server. A cache read explicitly tells the OPC server that the OPC Client or Bridge only requires values that are already in the server’s memory address space. This will ensure that no data ever displays incorrectly.

Bad quality data

OPC uses a ‘quality’ identifier to inform users of the validity of the data in each OPC item (point or reading). For example, suppose an OPC item contains the value of a flow reading. The value of the flow reading could be questionable if any of the following occur:

• There is no reading at all
• The reading is out of range
• The PLC disconnects from the flowmeter
• The OPC server disconnects from the PLC

Thus, in addition to providing a value for the flow itself, OPC also provides an associated quality to describe the validity of the data, or a description of the reason the data is questionable. This helps users troubleshoot the system.

The OPC bridge may also be required to pass this value along. In this case, the OPC bridge may be required to write the data as well as the quality of the data. So, in addition to the standard OPC server quality values, the OPC bridge must also inform the OPC server at the destination of additional troubleshooting information such as:

• The OPC bridge itself is disconnected from the source OPC server
• The OPC bridge is unable to transmit data
• The OPC bridge received a bad calculation
• The OPC bridge is overloaded

It is recommended that integrators select an OPC bridge that enables them to select how the OPC bridge passes OPC quality information. The OPC bridge should also pass along additional OPC quality values in case the OPC bridge itself has a problem with the data.

Calculations

Integrators often use OPC bridges to perform calculations and transformations on incoming data. For example, an OPC bridge could take a 4-20 mA reading from a PLC and transform it to a voltage that is between 0 and 240 V.

If an OPC bridge that enables you to perform calculations on incoming data is used, then, in the case of an error, the OPC bridge should notify the destination OPC server of the problem, typically using the OPC quality identifier.

Available OPC bridge products

Table 1 shows a list of popular OPC bridge software products.

Table 1: Popular OPC bridge products.

Company	Product name	Website
CAS	DataPorter	www.cas.eu
Cogent	OPC DataHub	www.cogent.ca
Cyberlogic	OPC Crosslink	www.cyberlogic.com
Emerson	OPC Mirror	www.emerson.com
Honeywell	OPC Integrator	www.honeywell.com
Iconics	DataWorX32	www.iconics.com
Kepware	LinkMaster	www.kepware.com
Northern Dynamic	OPC Gateway	www.nordyn.com
Open Automation Software	OPC Route.NET	www.opcsystems.net
SAE Automation	OpcDbGateway	www.saeautom.sk

OPC Training Institute
www.optci.com