Posts

Case Study: Minera San Cristobal, Bolivia – 2

/by
Using DataHub software to integrate video cameras and expert systems

Minera San Cristobal, owned by Apex Silver and Sumitomo Corporation, is one of the largest silver-zinc-lead mining projects in the world. The mine, located in the Potosi district of southwestern Bolivia is expected to produce approximately 450 million ounces of silver, 8 billion pounds of zinc, and 3 billion pounds of lead.

As described in a companion article, the engineers at the San Cristobal mill used DataHub® software to connect their DeltaV Professional Plus SCADA system to an SQL Server database in the corporate offices. After witnessing the success of that project, the engineers decided to connect their two SGS expert systems to DeltaV in a similar way.

“We saw how well DataHub software transported OPC data across the network,” said Sr. Mario Mendizabal, Production Engineer at Minera San Cristobal, “so we thought it could help us connect to our Grinding and Flotation Expert Systems.”

In the San Cristobal mill the ore extracted from the mine is crushed, ground, and refined through flotation process to yield concentrates of silver, zinc, and lead, which are then shipped abroad for final smelting. These processes are monitored and controlled using the DeltaV system.

Although the DeltaV system allows an operator to input setpoints and other values directly into the system, Sr. Mendizabal and his team wanted to apply an SGS Advanced Systems application to optimize two critical parts of the mineral refining process: grinding and flotation. Each expert system runs on a separate sever. To add to the challenge, the Flotation Expert System also requires real-time data input from two banks of 25 video cameras. These cameras monitor the size, speed, and other qualities of the bubbles as they lift the valuable mineral particles to the surface, where they can be skimmed off as foam. There is one bank of cameras for the zinc flotation circuit, and another for lead. Each of these five systems-DeltaV, the Grinding Expert System, the Flotation Expert System, and the two camera systems-needed to be connected in real time.

Fortunately, each system had an OPC server. What was needed was a way to bridge the OPC servers, aggregate their data streams, and tunnel/mirror the data across the network for the other systems. Based on his previous success using DataHub software, Sr. Mendizabal chose to apply it to this task. He already had a DataHub instance connected to the DeltaV system. So he just installed a DataHub instance on each of the SGS servers, and each of the camera system servers. Then he connected those four DataHub instances to the main DataHub instance running on the DeltaV server.

“It didn’t take long at all to get the system configured,” said Sr. Mendizabal. “Since it is tunnel/mirroring across the network, we avoided DCOM settings and networking issues entirely. The connection is completely secure, and rock-solid.”

When the expert systems are switched on, the plant data flows from DeltaV to the Grinding Expert System and the Flotation Expert System. These systems continuously and intelligently adjust the values of the setpoints, and send them back in real-time to DeltaV, which passes them along to the relevant process. To make its calculations, the Flotation Expert System also takes into account the real-time data that is streaming in from the two Video Camera Systems.

“It is very important to know that when the expert system is controlling the plant we are trusting our production to DataHub software,” said Sr. Mendizabal. “We are very pleased with its performance, and highly recommend it for this kind of mission-critical work.”

Case Study: ABB, Colombia

/by
Electrical substation upgrade: connecting ABB MicroSCADA suite to Oracle using DataHub

A key task for ABB in Colombia is upgrading electrical substations. The ABB development team is always looking for new tools for their substation automation systems to make operation easier, and to provide as much information as possible for the system operators.

One of the latest developments was the addition of a database to their Substation Automation System. The Substation Automation equipment used by ABB is designed according the 61850 standard. The idea of adding a database was to allow the operator to access valuable information stored over long periods of time (2-4 years).

“As with most SCADA systems, the trends graphics and the historical data are stored temporarily,” said one member of the development team. “Your typical substation equipment is designed to have no moving parts. It uses a small, solid state disk to store data, which is not big enough to store information for long periods of time.”

abb-colombia-system

The ABB substation automation system uses ABB’s MicroSCADA suite. One of the functions of that software is to provide a gateway between the IEC 61850 data protocol and OPC. Using the information available in OPC, the development team chose the DataHub® from Cogent (a subsidiary of Skkynet) to interface between MicroSCADA and Oracle, storing process information in a network disk.

“We found the DataHub to be a powerful, user-friendly software package that allows us to bridge between our OPC server and Oracle,” said a member of the development team. “The support of the Cogent team was great. The DataHub is a very good complement to the IEC 61850 technology. We can save data in the Oracle database, and also monitor live data in the DataHub data browser. The first prototype is now in a testing period, and is running well.”

Case Study: Citect (Schneider Electric), USA

/by
Citect optimizes OPC-based system using the DataHub

A major battery manufacturing plant in the United States was recently faced with an interesting data integration challenge. Management needed access to data coming from a large number of different processes. Over 220 OPC-enabled field devices across the plant had to be connected to a single Citect MES system. The many OPC servers used for these connections are unique in that their data set is very dynamic. From one minute to the next any of the 220 devices may be present or absent in the data set.

citect-logo “Our challenge was to provide data from our dynamically changing OPC servers to a Citect system that is designed to work with a fixed data set,” said the company project leader. They decided to bring in a team from Citect to come up with a solution.

Citect, of Schneider Electric, is well known in the industrial process control world for their line of automation and control software solutions, particularly their MES systems. Dan Reynolds, the team leader for Citect, had heard about the DataHub® through his support department, and thought it might work. They configured the DataHub for OPC tunneling, to communicate across the network without the hassles of DCOM. And, thanks to the DataHub’s unique approach to OPC tunnelling, Dan found that it also solved the problem of providing a fixed data set.

citect-battery-manufacturing-system

“The DataHub mirrors data across the tunnel,” said Dan, “so the Citect system sees a constant data set. When a device goes offline, the tag remains in the DataHub. Just the quality changes from ‘Good’ to ‘Not Connected’.” Confident in their approach, the Citect team moved the testing from their location to the battery plant. But they soon found themselves faced with another challenge.

The production system is designed so that a field device can add or remove OPC items at any time. So, not only the OPC servers, but individual tags can suddenly appear or disappear from the system. When a new tag comes online, the server updates its tag count, but doesn’t say that a new value is available, because the OPC specification doesn’t require a server to say when a new point is created. This looked like a show-stopper for the configuration team. They knew that there is no OPC product on the market that can deal with that kind of behavior. Continually rereading the data set was not possible, because new points may be added during the read. So Dan got in touch with Cogent (a subsidiary of Skkynet), and working together they came up with a plan.

The solution was two-fold. First, the device behavior was modified to compact the tag add/delete cycle to a limited time. Then Cogent wrote a DataHub script that monitors a few OPC server tags, and when these tags change, a time-delayed function in the script re-reads the server’s data set. The scripted time delay allows for all the new points to be added before the data set is reread, and the DataHub thus discovers all of the new data as soon as it all becomes available.

“We are pleased with the performance of the DataHub for this application,” said Dan Reynolds. “There is no way we could have done this project with any other OPC tunneling product, or combination of products.”

“The Skkynet software has become an integral part of our MES solution,” said the project leader. “Without the DataHub, we would not be getting reliable data. If we hadn’t had it, our MES integration project would probably have come to a halt.”

Tunnelling OPC DA – Know Your Options

/by

Since OPC was introduced over fifteen years ago, it has seen a steady rise in popularity within the process control industry. Using OPC, automation professionals can now select from a wide range of client applications to connect to their PLCs and hardware devices. The freedom to choose the most suitable OPC client application for the job has created an interest in drawing data from more places in the plant. Industry-wide, we are seeing a growing need to connect OPC clients on one computer to OPC servers on other, networked computers. As OPC has grown, so has the need to network it.

The most widely-used OPC protocol for real-time data access is OPC DA.  However, anyone who has attempted to network OPC DA knows that it is challenging, at best. The networking protocol for OPC DA is DCOM, which was not designed for real-time data transfer. DCOM is difficult to configure, responds poorly to network breaks, and has serious security flaws. Using DCOM between different LANs, such as connecting between manufacturing and corporate LANs, is sometimes impossible to configure. Using OPC DA over DCOM also requires more network traffic than some networks can handle because of bandwidth limitations, or due to the high traffic already on the system. To overcome these limitations, there are various tunnelling solutions on the market. This article will look at how tunneling OPC DA solves the issues associated with DCOM, and show you what to look for in a tunnelling product.

Eliminating DCOM

The goal of tunnelling OPC DA is to eliminate DCOM, which is commonly done by replacing the DCOM networking protocol with TCP. Instead of connecting the OPC client to a networked OPC server, the client program connects to a local tunnelling application, which acts as a local OPC server. The tunnelling application accepts requests from the OPC client and converts them to TCP messages, which are then sent across the network to a companion tunnelling application on the OPC server computer. There the request is converted back to OPC DA and is sent to the OPC server application for processing. Any response from the server is sent back across the tunnel to the OPC client application in the same manner.

OPC Tunnelling

This is how most tunnellers for OPC DA work, in principle. A closer look will show us that although all of them eliminate DCOM, there are some fundamentally different approaches to tunnelling architecture that lead to distinctly different results in practice. As you review tunnelling solutions, here are four things to look out for:

  1. Does the tunnelling product extend OPC transactions across the network, or does it keep all OPC transactions local?
  2. What happens to the OPC client and server during a network break?
  3. How does the tunnel support multiple client-server connections?
  4. Does the tunnelling product provide security, including data encryption, user authentication, and authorization?

1. Extended or Local OPC Transactions?

There are two basic types of tunnelling products on the market today, each with a different approach to the problem. The first approach extends the OPC transaction across the network link, while the second approach keeps all OPC transactions local to the sending or receiving computer.

OPC Tunnelling Comparison

Extending the OPC transaction across the network means that a typical OPC client request is passed across the network to the OPC server, and the server’s response is then passed all the way back to the client. Unfortunately, this approach preserves the synchronous nature of DCOM over the link, with all of its negative effects. It exposes every OPC client-server transaction to network issues like timeouts, delays, and blocking behavior. Link monitoring can reduce these effects, but it doesn’t eliminate them, as we shall see below.

On the other hand, the local OPC transaction approach limits the client and server OPC transactions to their respective local machines. For example, when the tunnelling program receives an OPC client request, it responds immediately to the OPC client with data from a locally cached copy. At the other end, the same thing happens. The tunnelling program’s job is then to maintain the two copies of the data (client side and server side) in constant synchronization. This can be done very efficiently without interfering with the function of the client and server. The result is that the data crosses the network as little as possible, and both OPC server and OPC client are protected from all network irregularities.

2. Handling Network Issues

There is a huge variety of network speeds and capabilities, ranging from robust LANs, to WANs running over T1 lines on multi-node internets, and on down to low-throughput satellite connections. The best tunnelling products give the best possible performance over any given kind of network.

To protect against network irregularities and breaks, any good tunnelling application will offer some kind of link monitoring. Typically this done with a “heartbeat” message, where the two tunnel programs send messages to one another on a timed interval, for example every few seconds. If a reply isn’t received back within a user-specified time, the tunnelling application assumes that the network is down. The OPC client and server may then be informed that the network is broken.

In practice this sounds simple. The problem arises when you have to specify the timeout used to identify a network disconnection. If you set the timeout too long, the client may block for a long time waiting for a reply, only to discover that the network is down. On the other hand, setting the timeout too short will give you false indications of a network failure if for some reason the connection latency exceeds your expectations. The slower the network, the greater the timeout must be.

However, this balancing act is only necessary if the tunnelling product uses the extended OPC approach. A product that offers local OPC transactions still provides link monitoring, but the OPC client and server are decoupled from the network failure detection. Consequently, the timeout can be set appropriately for the network characteristics—from a few hundred milliseconds for highly robust networks to many seconds, even minutes for extremely slow networks—without the risk of blocking the OPC client or server.

How the tunnelling product informs your OPC client of the network break also varies according to the tunnel product design. Products that extend the OPC transactions generally do one of two things:

  1. Synthesize an OPC server shutdown. The OPC client receives a shutdown message that appears to be coming from the server. Unaware of the network failure, the client instead operates under the assumption that the OPC server itself has stopped functioning.
  2. Tell the client nothing, and generate a COM failure the next time the client initiates a transaction. This has two drawbacks. First the client must be able to deal with COM failures, the most likely event to crash a client. Worse yet, since OPC clients often operate in a “wait” state without initiating transactions, the client may think the last data values are valid and up-to-date, never realizing that there is any problem.

Products that provide local OPC transactions offer a third option:

  1. Maintain the COM connection throughout the network failure, and alter the quality of the data items to “Not Connected” or something similar. This approach keeps the OPC connection open in a simple and robust way, and the client doesn’t have to handle COM disconnects.

3. Support for Multiple Connections

Every tunnelling connection has an associated cost in network load. Tunnelling products that extend OPC transactions across the network may allow many clients to connect through the same tunnel, but each client sends and receives data independently. For each connected client the network bandwidth usage increases. Tunnelling products that satisfy OPC transactions locally can handle any number of clients and servers on either end of the tunnel, and the data flows across the network only once. Consequently, adding clients to the system will not add load to the network. In a resource-constrained system, this can be a crucial factor in the success of the control application.

If you are considering multiple tunnelling connections, be sure to test for cross-coupling between clients. Does a time-intensive request from a slow client block other requests from being handled? Some tunnelling applications serialize access to the OPC server when multiple clients are connected, handling the requests one by one. This may simplify the tunnel vendor’s code, but it can produce unacceptable application behavior. If one client makes a time-consuming request via the tunnel, then other clients must line up and wait until that request completes before their own requests will be serviced. All clients block for the duration of the longest request by any client, reducing system performance and increasing latency dramatically.

On the other hand, if the tunnel satisfies OPC requests locally, this situation simply does not happen. The OPC transactions do not cross the network, so they are not subject to network effects nor to serialization across the tunnel.

4. What About Security?

Whenever you get involved in networking plant data, security is a key concern. In fact, security is a primary reason for choosing tunnelling over DCOM. DCOM was never intended for use over a wide area network, so its security model is primarily designed to be easily configured only on a centrally administered LAN. Even making DCOM security work between two different segments of the same LAN can be extremely difficult. One approach to DCOM security is to firewall the whole system, so that nothing gets in or out, then relax the security settings on the computers inside the firewall. This is perhaps the best solution on a trusted network, but it is not always an option. Sometimes you have to transmit data out through the firewall to send your data across a WAN or even the Internet. In those cases, you are going to want a secure connection. Relaxed DCOM settings are simply not acceptable.

Most experts agree that there are three aspects to network security:

  • Data encryption is necessary to prevent anyone who is sniffing around on the network from reading your raw data.
  • User authentication validates each connecting user, based on their user name and password, or some other shared secret such as a private/public key pair.
  • Authorization establishes permissions for each of those authenticated users, and gives access to the appropriate functionality.

There are several options open to tunneling vendors to provide these three types of security. Some choose to develop their own security solution from the ground up. Others use standard products or protocols that many users are familiar with. These include:

SSL (Secure Socket Layer) – Provides data encryption only, but is very convenient for the user. Typically, you just check a box in the product to activate SSL data encryption. The tunneling product must provide user authentication and authorization separately.

VPN (Virtual Private Network) – Provides both encryption and authentication. VPN does not come as part of the product, per se, but instead is implemented by the operating system. The tunneling product then runs over the VPN, but still needs to handle authorization itself.

SSH (Secure Shell) Tunneling – Provides encryption and authentication to a TCP connection. This protocol is more widely used in UNIX and Linux applications, but can be effective in MS-Windows. SSH Tunnelling can be thought of as a kind of point-to-point VPN.

As none of these standard protocols covers all the three areas, you should ensure that the tunnelling product you chose fills in the missing pieces. For example, don’t overlook authorization. The last thing you need is for some enterprising young apprentice or intern to inadvertently link in to your live, production system and start tweaking data items.

How Can You Know? Test!

The concept of tunnelling OPC DA is still new to many of us. Vendors of tunnelling products for OPC DA spend a good deal of time and energy just getting the basic point across: eliminate the hassles of DCOM by using TCP across the network. Less attention has been put on the products themselves, and their design. As we have seen, though, these details can mean all the difference between a robust, secure connection, or something significantly less.

How can you know what you are getting? Gather as much information as you can from the vendor, and then test the system. Download and install a few likely products. (Most offer a time-limited demo.) As much as possible, replicate your intended production system. Put a heavy load on it. Pull out a network cable and see what happens. Connect multiple clients, if that’s what you plan to do. Configure the security. Also consider other factors such as ease of use, OPC compliance, and how the software works with other OPC-related tasks you need to do.

If you are fed up with DCOM, tunnelling OPC DA provides a very good alternative. It is a handy option that any engineer or system integrator should be aware of. At the very least, you should certainly find it an improvement over configuring DCOM. And with the proper tools and approach, you can also make it as robust and secure as your network will possibly allow.

Download White Paper (PDF)

Redundancy for OPC

/by

Early one morning, Mel Farnsworth was sitting in the control booth at the Hardy Automotive Parts assembly line, drinking his final cup of coffee before the end of the shift. Watching the line meter graph in his HMI console, he noticed that the yield and efficiency trends for the Line 3 had dropped to zero. So he looked down through the control-room window, but Line 3 seemed to be rolling right along. What was the problem?

The line was running smoothly, but Mel wasn’t getting the data he needed. Somewhere between the PLCs and his HMI display there was a data disconnect. Maybe it was a fieldbus problem, or a bad network connection. Perhaps it was caused by his OPC server, or possibly even his HMI system itself. Whatever the reason, since Mel’s data connection was a single chain, one break in the chain means that he didn’t get his data. To minimize this kind of risk and ensure the highest possible availability, mission-critical systems often use redundancy.

What is Redundancy?

Redundancy in a process control system means that some or all of the system is duplicated, or redundant. The goal is to eliminate, as much as possible, any single point of failure. When a piece of equipment or a communication link goes down, a similar or identical component is ready to take over. There are three types of redundant systems, categorized by how quickly a replacement (or standby) can be brought online. These are cold standby, warm standby, and hot standby.

Cold standby implies that there will be a significant time delay in getting the replacement system up and running. The hardware and software are available, but may have to be booted up and loaded with the appropriate data. Picture the olden days of steam locomotives. The cold standby was the extra engine in the roundhouse that had to be fired up and brought into service.   Cold standby is not usually used for control systems unless the data changes very infrequently.

Warm standby has a faster response time, because the backup (redundant) system is always running, and regularly updated with a recent copy of the data set. When a failure occurs on the primary system, the redundant system can disconnect from the failed system and connect instead to the backup system. This allows the system to recover fairly quickly (within seconds, usually), and continue the work. Some data will be lost during this disconnect/reconnect cycle, but warm standby can be an acceptable solution where some data loss can be tolerated.

Hot standby means that both the primary and secondary data systems run simultaneously, and both are providing identical data streams to the downstream client. The underlying physical system is the same, but the two data systems use separate hardware to ensure that there is no single point of failure. When the primary system fails, the switchover to the secondary system is intended to be completely seamless, or “bumpless”, with no data loss. Hot standby is the best choice for systems that cannot tolerate the data loss of a cold or warm standby system.

A Typical Redundant OPC System

What does redundancy look like in an OPC-based system? A typical scenario would have two OPC servers connected either to a single device or PLC, or possibly duplicate devices or PLCs. Those two OPC servers would then connect to some kind of OPC redundancy management software which, in turn, offers a single connection to the OPC client, such as an HMI. The redundancy manager is responsible for switching to the secondary OPC server when any problem arises with the data coming from the primary OPC server. This scenario creates a redundant data stream from the physical system all the way to the HMI.

The most common use of redundancy for OPC is with OPC DA or UA, but it is possible to configure redundant OPC A&E systems as well. The principles are the same.  Sometimes, on large systems, it is necessary to configure multiple redundant pairs. Redundancy can also be configured over a network, using DCOM or OPC tunneling. For a networked configuration, the redundancy manager would normally reside on the OPC client machine, to minimize the number of potential points of failure.

Although cold or warm standby may be useful under some circumstances, typically an engineer or system integrator implementing a redundant OPC system is looking for hot standby. This is the most useful kind of redundancy in a process control system, and at the same time the most difficult to achieve. Let’s look a little more closely at that all-important task of the OPC redundancy manager in a hot-standby system—making the switch.

Making the Switch

Put simply, a hot-standby redundancy manager receives data from two identical inputs, and sends a single output to the OPC client. It is the redundancy manager’s job to determine at all times which of the two data streams is the best, and switch from one to the other as soon as possible whenever the status changes. The switch can be triggered by a number of different kinds of events:

  • Single point value change – to or from a certain value, achieving a threshold, etc.
  • Single point quality change – for example, from “Good” to any other OPC quality.
  • Multiple item monitoring – if the quality or value of any point in a group goes bad.
  • Rate of change monitoring – if points change value more slowly than expected.
  • Network breaks and timeouts – checked with some kind of heartbeat mechanism.

Once the switch has occurred, the system or the redundancy manager itself might have the ability to send an alarm or email message, or even launch some kind of diagnostic or investigative program. It might also be able to log diagnostic information about the state of the primary OPC server or network connection. And in a system that distinguishes between primary and secondary inputs, there will often be a means to favor the primary input, and switch back to it when possible, sometimes referred to as a fallback.

Practical Considerations

The idea of redundancy for OPC is not difficult to grasp, but implementing it takes some thought. An initial decision on cold, warm or hot standby will impact all aspects of the implementation. The choice of proper hardware and software is critical for a well-functioning system. Robust system architecture is also important, especially if the connection is across a network. In addition to selecting OPC servers and planning the network infrastructure (if necessary), an important decision will be the software used to manage the redundancy. Good redundancy management software should be easy to use, with no programming necessary. The technology should be up to date, capable of running on the latest version of Windows. There should be an absolute minimum chance of data loss during a switchover, even over a network.

The Timer Pitfall

In practice it is not possible to achieve a completely seamless switchover in all cases, even with a hot standby system. For example, if a network failure occurs on the primary connection, a certain amount of time will pass before a redundancy manager can detect that failure. Data transmitted during this period will fail to arrive, but the redundancy manager will not be able to distinguish between a failure and a normal pause in data flow.

Many redundancy managers implement timers to periodically check the network connection status to try to minimize this delay, but a switchover mechanism based on periodic timers will always suffer from data loss. Systems with multiple timing parameters will often result in additive delays, where the fastest possible switchover for the system is the sum of these timing delays. In addition, the use of timers to detect network failure can result in a configuration problem where the system integrator must trade off switchover latency against false-positive network failure detection. This effectively becomes a trade off between system stability and responsiveness.

Using timers to periodically check data values or qualities, or poll the OPC servers, is also problematic because timers introduce unnecessary latency into the system. Whereas a network failure must be detected based on timing, a data value or quality change can be detected immediately as the event occurs. Generally it is usually best to avoid systems based on time-based value change detection, and use event-based object monitoring instead.

Object and Link Monitoring

A good redundancy manager should be able to support both object monitoring and link monitoring. Object monitoring means the ability to monitor individual points, and make a switchover based on an event. For example, if a designated watchdog tag changes in a significant way, such as turning negative or going over a specified threshold, it can trigger a switch to the secondary OPC server. Or maybe you’d like to monitor a group of points, and if the quality of any of them goes to “Bad” or “Unconnected”, you can switch.

Link monitoring is especially useful for networked connections. Your system will need a way to detect a network break very quickly, to prevent data loss. For hot standby on high-speed systems with fast data update rates, timeout detection with a sub-second response rate is essential. In any event, the system should be able to detect a timeout for a failed network connection, as well as a failure to receive data. This distinction is important. It may take seconds or even minutes to detect a communication failure, but a redundancy manager should be able to detect a stoppage of data flow in an amount of time very close to the true data rate from the physical system. The redundancy manager should be able to switch from one source to the other based solely on an observation that data has not arrived from the primary connection, but has arrived from the backup system.

Some systems use COM timeouts for link monitoring. This may be acceptable for circumstances where relatively long data outages are tolerable, but we do not recommend relying on COM timeouts for hot or warm standby.

Smart Switchover

The behavior of the redundancy system during a switchover can be significant. For example, suppose the primary and secondary connections have both failed for some reason. A typical redundancy manager will begin a cycle of attempting to attach to one and then the other OPC server until one of them responds. The redundancy manager will flip-flop between the two indefinitely, injecting sleep periods between each flip-flop to reduce system resource load. This sleep period is itself a source of latency. A smarter switchover model is to maintain a source health status that allows the redundancy manager to only switch over when a source status changes. This allows the redundancy manager to effectively idle, or perform simultaneous reconnection attempts, until a source status changes, then immediately respond without introducing extra latency. Smarter switching logic can result in substantially reduced system load and switchover times.

Forced Switching vs Preferred Source

It is useful to be able to select one data source over another, even if the currently attached source is healthy. A naïve redundancy manager will “force” the user to switch, even if the backup system is not available. This will again result in a flip-flop behavior as the redundancy manager attempts to switch to the unavailable backup source. A much better approach is for the redundancy manager to understand the concept of a preferred source that can be changed at runtime. If the preferred source is available, the redundancy manager will switch to it. If the user wants to switch from one source to another, he simply changes the preferred source. If that source is available, the switch will be made. If it is not, the redundancy manager will make the switch only when it becomes available. This eliminates the flip-flop behavior while at the same time eliminating the data loss associated with the minimum of two switch cycles that the naïve redundancy manager will impose.

Accessing Raw Data

A good hot redundancy system will give the client application access not just to the redundant data, but also to the raw data from both sources. This gives the client application the option of presenting diagnostic information about the system on the “far side” of the redundancy manager. Most redundancy managers hide this information so that a client application would have to make and manage multiple connections to access the raw data, if it is possible at all.

Other options and features

In addition to the above capabilities, a good redundancy manager may offer additional features for your convenience. It might provide the option to refresh the entire data set at switchover. Maybe it will send out emails or even launch additional programs at each switchover. This can be useful for notifying key personnel of the system status. It may log diagnostics to provide valuable information about the reasons for making the switch. Some redundancy managers can connect to multiple servers, and create multiple redundant connections. Others can let you work with subsets of the data. Another desirable feature is the ability to assign the primary and secondary data sources, and to trigger a fallback from the secondary to the primary data source once the problem that caused the switchover has been resolved.

As control systems continue to grow in complexity, and as we rely more and more on them, Mel Farnsworth’s situation will become more common, and more costly. If data connectivity is crucial to the success of the company, it would be wise to consider the possibility of installing a redundant system, and to take into account the above considerations when implementing redundancy for OPC.

Advanced Tunnelling for OPC with Cogent DataHub

/by

OPC has become a leading standard for industrial process control and automation systems.  Among several OPC standards, the one most widely used throughout the world is OPC DA, or OPC Data Access. Many hardware manufacturers offer an OPC DA interface to their equipment, and OPC DA servers are also offered by third-party suppliers.  Likewise, most HMI vendors build OPC DA client capabilities into their software.  Thus data from most factory floor devices and equipment can connect to most HMIs and other OPC DA clients.  This universal connectivity has greatly enhanced the flexibility and efficiency of industrial automation systems.

But OPC DA has a major drawback—it does not network well.  OPC DA is based on the COM protocol, which uses DCOM (Distributed COM) for networking.  DCOM was not designed for real-time industrial applications. It is neither as robust nor secure as industrial systems require, and it is very difficult to configure. To overcome these limitations, Cogent offers a “tunnelling” solution, as an alternative to DCOM, to transfer OPC data over a network.  Let’s take a closer look at how tunnelling solves the issues associated with DCOM, and how the Cogent DataHub from Cogent Real-Time Systems provides a secure, reliable, and easy-to-use tunnelling solution with many advanced features.

Making Configuration Easy and Secure

The first problem you will encounter with DCOM is that it is difficult to configure.  It can take a DCOM expert hours, and sometimes days, to get everything working properly.  It is difficult to find good documentation on DCOM because configuration is not a simple, step-by-step process.  Even if you are successful, the next Windows Update or additional new setting may break your working system.  Although it is not recommended practise, many companies “solve” the problem by simply bypassing DCOM security settings altogether.  But this kind of granting broad access permissions is becoming less and less viable in today’s security-conscious world, and most companies cannot risk lowering their guard to allow DCOM to function.

Tunnelling with the Cogent DataHub eliminates DCOM completely, along with all of its configuration and security issues.  The Cogent DataHub uses the industry standard TCP/IP protocol to network data between an OPC server on one computer and an OPC client on another computer, thus avoiding all of the major problems associated with using the DCOM protocol.

The Cogent DataHub offers this tunnelling feature by effectively ‘mirroring’ data from one Cogent DataHub running on the OPC server computer, to another Cogent DataHub running on the OPC client computer, as shown in the image above.  This method results in very fast data transfer between Cogent DataHub nodes.

Better Network Communication

When a DCOM connection is broken, there are very long timeout delays before either side is notified of the problem, due to DCOM having hard coded timeout periods which can’t be adjusted by the user.  In a production system, these long delays without warning can be a very real problem.  Some OPC clients and OPC client tools have internal timeouts to overcome this one problem but this approach does not deal with the other issues discussed in this paper.

The Cogent DataHub has a user-configurable heartbeat and timeout feature which allows it to react immediately when a network break occurs.  As soon as this happens, the Cogent DataHub begins to monitor the network connection and when the link is re-established, the local Cogent DataHub automatically reconnects to the remote Cogent DataHub and refreshes the data set with the latest values.  Systems with slow polling rates over long distance lines can also benefit from the user-configurable timeout, because DCOM timeouts might have been too short for these systems.

Whenever there is a network break, it is important to protect the client systems that depend on data being delivered.  Because each end of the tunnelling connection is an independent Cogent DataHub, the client programs are protected from network failures and can continue to run in isolation using the last known data values.  This is much better than having the client applications lose all access to data when the tunnelling connection goes down.

The Cogent DataHub uses an asynchronous messaging system that further protects client applications from network delays.  In most tunnelling solutions, the synchronous nature of DCOM is preserved over the TCP link.  This means that a when a client accesses data through the tunnel, it must block waiting for a response.  If a network error occurs, the client will continue to block until a network timeout occurs.  The Cogent DataHub removes this limitation by releasing the client immediately and then delivering the data over the network.  If a network error occurs, the data will be delivered once the network connection is re-established.

Cogent DataHub Other tunnelling products
The Cogent DataHub keeps all OPC transactions local to the computer, thus fully protecting the client programs from any network irregularities. Other products expose OPC transactions to network irregularities, making client programs subject to timeouts, delays, and blocking behavior. Link monitoring can reduce these effects, while the Cogent DataHub eliminates them.
The Cogent DataHub mirrors data across the network, so that both sides maintain a complete set of all the data. This shields the clients from network breaks as it lets them continue to work with the last known values from the server. When the connection is re-established, both sides synchronize the data set. Other products pass data across the network on a point by point basis and maintain no knowledge of the current state of the points in the system. A network break leaves the client applications stuck with no data to work with.
A single tunnel can be shared by multiple client applications. This significantly reduces network bandwidth and means the customer can reduce licensing costs as all clients (or servers) on the same computer share a single tunnel connection. Other tunnelling products require a separate network connection for each client-server connection. This increases the load on the system, the load on the network and increases licensing costs.

These features make it much easier for client applications to behave in a robust manner when communications are lost, saving time and reducing frustration.  Without these features, client applications can become slow to respond or completely unresponsive during connection losses or when trying to make synchronous calls.

Securing the System

Recently, DCOM networking has been shown to have serious security flaws that make it vulnerable to hackers and viruses. This is particularly worrying to companies who network data across Internet connections or other links outside the company.

To properly secure your communication channel, the Cogent DataHub offers secure SSL connections over the TCP/IP network.  SSL Tunnelling is fully encrypted, which means the data is completely safe for transmission over open network links outside the company firewalls.  In addition, the Cogent DataHub provides access control and user authentication through the use of optional password protection.  This ensures that only authorized users can establish tunnelling connections.  It is a significant advantage having these features built into the Cogent DataHub, since other methods of data encryption can require complicated operating system configuration and the use of more expensive server PCs, which are not required for use with the Cogent DataHub.

Advanced Tunnelling for OPC

While there are a few other products on the market that offer tunnelling capabilities to replace DCOM, the Cogent DataHub is unique in that it is the only product to combine tunnelling with a wide range of advanced and complimentary features to provide even more added benefits.

Significant reduction in network bandwidth

The Cogent DataHub reduces the amount of data being transmitted across the network in a two ways:

  1. Rather than using a polling cycle to transmit the data, the Cogent DataHub only sends a message when a new data value is received.  This significantly improves performance and reduces bandwidth requirements.
  2. The Cogent DataHub can aggregate both client and server connections.  This means that the Cogent DataHub can collect data from multiple OPC servers and send it across the network using a single connection.  On the client side, any number of OPC clients can attach to the Cogent DataHub and they all receive the latest data as soon as it arrives.  This eliminates the need for each OPC client to connect to each OPC server using multiple connections over the network.
Non-Blocking

While it may seem simple enough to replace DCOM with TCP/IP for networking OPC data, the Cogent DataHub also replaces the inherent blocking behaviour experienced in DCOM communication.  Client programs connecting to the Cogent DataHub are never blocked from sending new information.  Some vendors of tunnelling solutions for OPC still face this blocking problem, even though they are using TCP/IP.

Supports slow network and Internet links

Because the Cogent DataHub reduces the amount of data that needs to be transmitted over the network, it can be used over a slow network link.  Any interruptions are dealt with by the Cogent DataHub while the OPC client programs are effectively shielded from any disturbance caused by the slow connection.

Access to data on network computers running Linux

Another unique feature of the Cogent DataHub is its ability to mirror data between Cogent DataHubs running on other operating systems, such as Linux and QNX.  This means you can have your own custom Linux programs act as OPC servers, providing real-time data to OPC client applications running on networked Windows computers.  The reverse is also true.  You can have your Linux program access data from OPC servers running on networked Windows computers.

Load balancing between computers

The Cogent DataHub also offers the unique ability to balance the load on the OPC server computers.  You may have a system where multiple OPC clients are connecting to the OPC server at the same time, causing the server computer to experience high CPU loads and slower performance.  The solution to this is to mirror data from the Cogent DataHub on the OPC server computer to an Cogent DataHub on another computer and then have some of your OPC clients connect to this second ‘mirrored’ computer.  This reduces the load on the original OPC server computer and provides faster response to all OPC client computers.

Advanced Tunnelling for OPC Example – TEVA Pharmaceuticals (Hungary)

TEVA Pharmaceuticals in Hungary recently used the Cogent DataHub to combine tunnelling and aggregation to network OPC data over the network and through the company firewall.

Laszlo Simon is the Engineering Manager for the TEVA API plant in Debrecen, Hungary. He had a project that sounded simple enough. He needed to connect new control applications through several OPC stations to an existing SCADA network. The plant was already running large YOKOGAWA DCS and GE PLC control systems, connected to a number of distributed SCADA workstations. However, Mr. Simon did face a couple of interesting challenges in this project:

  • The OPC servers and SCADA systems were on different computers, separated by a company firewall. This makes it extremely difficult to connect OPC over a network, because of the complexities of configuring DCOM and Windows security permissions.
  • Each SCADA system needed to access data from all of the new OPC server stations. This meant Mr. Simon needed a way to aggregate data from all the OPC stations into a single common data set on each SCADA computer.

After searching the web, Mr. Simon downloaded and installed the Cogent DataHub. Very quickly he had connected the Cogent DataHub to his OPC servers and determined that he was reading live process data from the new control systems. He was also able to easily set up the tunnelling link between the OPC server stations and the SCADA workstations, by simply installing another Cogent DataHub on the SCADA computer and configuring it to connect to the OPC server stations.

“I wanted to reduce and simplify the communication over the network because of our firewall. It was very easy with the Cogent DataHub.” said Mr. Simon after the system was up and running. Currently about 7,000 points are being transferred across the network, in real-time, using the Cogent DataHub. “In the future, the additional integration of the existing or new OPC servers will be with the Cogent DataHub.”