OPC Bridging Transfers Data Between Industrial Automation Systems
OPC Bridging Transfers Data Between Industrial Automation Systems
OPC Bridging Transfers Data Between Industrial Automation Systems
Introduction
Integrators frequently use OPC technology to connect one Industrial Automation
system (PLC, DCS, SCADA, HVAC, etc) with another so data can be shared between
the two systems. Because OPC technology is based on the 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,
generically called an “OPC Bridge,” to facilitate this sort of communication. This
whitepaper discusses the concept of the OPC Bridge, the solution architecture,
required software components, and various features to help Integrators
differentiate between different OPC Bridge products.
OPC Overview
OPC is an industrial communication standard that enables manufacturers to use
data to optimize production, make operation decisions quickly and generate
reports. OPC enables plants to automate the transfer of data from a control system
(PLC, DCS, analyzer, etc) to an industrial software application (HMI, Historian,
Production system, Management system, etc). 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. In essence, OPC is the Modbus of
the new century. It is not a replacement for low-level
communication standards such as 4-20mA, Hart,
Profibus, or Foundation Fieldbus. Rather,
organizations use OPC in high-level communication.
Connectivity Challenge
Successful automation of industrial systems often needs to connect various
disparate systems, or islands of automation, together. The following are some
common examples of system interconnectivity:
In the past, plants would achieve this system connectivity using hardwire (4-20mA)
connections. But these were often extremely expensive, especially if the plant
needed to transfer large quantities of data. Vendors then came up with less
expensive options such as serial interfaces or various proprietary networks.
However, the proprietary nature of these solutions kept installation/maintenance
costs high and often was unable to connect all systems. Fortunately, the
emergence of OPC provides a significant improvement to these solutions.
Since 1996, OPC has become the de facto standard for Integrators to connect
industrial automation systems. OPC Servers are available for every major control
system vendor 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.
OPC is based on Client/Server architecture. Therefore,
an OPC Client application (HMI, Historian, Production
system, Management system, etc) makes requests to
exchange data with an OPC Server. The OPC Server
responds to these requests. But, note that an OPC
Server can only respond to requests; the OPC Server
cannot make requests. In other words, OPC Servers can Image 2: The only way for two
OPC Servers to communicate is
only do what they are told. So, two OPC Servers cannot to have an OPC Client application
provide a bridge between the
exchange data with each other directly because each
two servers, thus becoming an
waits for a request from the other, and since OPC Servers “OPC Bridge.”
don’t make requests, no data transfer will take place.
This is true for any Client/Server based system architecture in general and OPC
specifically.
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 connects two or more OPC Servers together. The OPC
Bridge requests data from one OPC Server, and writes the data to another OPC
server. All OPC Bridge products follow this concept. Integrators must take three
steps to setup the data transfer:
a) Setup the OPC Bridge to connect to the OPC servers. The OPC Servers to
which the bridge connects are preset by the Integrator.
b) Setup the OPC Bridge to read data from one OPC Server, and write it to
another OPC Server. The Integrator preselects the specific data to transfer.
c) Setup the OPC Bridge to automatically execute the above configuration.
After the initial setup, 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 hard-wire interface between the two
systems.
Most OPC Bridge applications can execute in all of the modes listed above,
however, when selecting an OPC Bridge, I recommend that you choose a
product that can run as a Windows Service.
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 comments from various OPC vendors.
Multithreaded operation
It is important for an OPC Bridge to continue operations even when an acceptable
fault in the system occurs. Consider an OPC Bridge that transfers values from two
data sources (i.e. two OPC Servers) to a single destination (i.e. a third OPC Server).
If one of the two data sources (i.e. one of the OPC Servers) 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.
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 suppose the OPC Bridge then 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. This is because the OPC Server sends values
to the OPC Bridge when the values change, and the Setpoint does not change, so
the OPC Server does not send an update.
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
· Etc.
Calculations
Integrators often use OPC Bridges to perform calculations and transformations on
incoming data. For example, an OPC Bridge could take a 4-20mA reading from a
PLC, and transform it to a voltage that is between 0 to 240 volts.
Additional References
The OPC Training Institute has various other
whitepapers to help you troubleshoot and learn more
about OPC. These are available on the OPCTI
website at www.opcti.com. If these are of interest,
you can also consider attending one of OPCTI’s many
hands-on OPC courses where you get the opportunity
to benefit from experts’ context, learn new concepts,
and immediately apply them in live connectivity
scenarios and troubleshooting activities. The OPC Training Institute's website is
full of helpful whitepapers and
additional resources to help you solve
OPC & DCOM: 5 Things You Need to Know common OPC configuration problems
This whitepaper discusses the five steps to a simple and learn more about OPC.