Redundancy can mean a lot of things, as discussed in our Demystifying Redundancy Blog post. In this blog post we want to focus more specifically on one of the use cases in that blog post: managing redundant OPC servers. Just having two OPC servers talking to your PLC’s does not make them redundant. Most OPC Servers don’t have built-in methods of knowing there is another redundant OPC server instance out there.
Some HMI/SCADA systems support redundancy but sometimes it involves scripting and other custom written code. So, in many cases, you need supplemental software to manage and optimize the connections to your two OPC servers. Your OPC client then talks to the redundancy management software as if it is the actual OPC server.
This blog post covers some of the considerations and watch outs when choosing how to manage your OPC server redundancy. After that we will also discuss how the Cogent DataHub can help manage your redundancy to provide high availability for your OPC server communications.
Understand your Redundancy Requirements
So imagine you have a pair of OPC servers you need to manage redundantly. Let’s look at some of the first things you need to decide to get started. One thing you need to do is choose which server will be the primary and which will be the secondary failover server. Next, you’ll need to determine what triggers and criteria you will monitor to determine that a primary system is not available such that failover to the secondary server occurs.
Some common triggers might be when the quality of a tag goes to Bad or not Good or if the connection to the OPC server goes to Not Connected, either of which could indicate an issue with the network, the server machine itself or, in the case of the tag, an issue with the device itself. Sometimes a changing value in the downstream device is also used and a halt to the updates to that value for x period of time can signify loss of communications.
For situations where you have redundant OPC servers and each OPC server has a separate path to the control device, some OPC servers have built-in tags that indicate that communications to a downstream device have been lost. If the OPC server doesn’t have a failover path to the backup network path, your architecture might want a failover to a backup OPC Server that is on the backup network path. There are many other options, and the right choice is a function of your overall system operation and requirements.
Picking the right criteria and triggers is a careful balance. If you pick conditions that are too sensitive, you could get false positives and generate unnecessary failovers. If they aren’t sensitive enough, you could cause unnecessary downtime.
Another consideration is how will you know when the primary system returns to normal? Do you want to connect back to the primary or allow the secondary to continue as long as it is still working? Knowing these requirements will be important when evaluating OPC redundancy management software.
Now that you have some guidelines for considering your own specific requirements, we can look at how the Cogent DataHub handles management of redundant data sources.
DataHub for OPC Server Redundancy
The Cogent DataHub supports the ability to manage the connection between two redundant OPC servers. It does this by first establishing a connection to both the primary and secondary OPC servers. This is commonly referred to as hot redundancy. Hot redundancy means the DataHub will maintain an active connection to both OPC servers at all times and, when a failure of the primary takes place, DataHub will serve up the data from the secondary connection to the OPC client instantaneously.
Hot redundancy has the fastest failover time possible since the secondary OPC server is already connected and actively communicating with the same equipment. This means the DataHub does not have to take the time to create a connection, request all the tags and get updated values for everything. The result is a failover time in milliseconds to minimize data loss when failovers occur.
The one downside to hot redundancy is that both OPC servers are concurrently polling the field devices which could cause unneeded stress on the control network and hardware.
The DataHub can also support warm or cold redundancy. Warm and cold redundancy do not put the same load on the control devices but do take longer to fail over, creating a longer bump time , since the DataHub has to create the connection to the OPC Server and add the tag references and mark them active.. In a warm redundancy scenario the connection to the OPC server is made and ready, but the item references are added and made active at failover time. In cold redundancy the connection to the OPC server must also be made at failover time.
Which method is best ultimately depends on how much the time it takes to failover is worth to your business. If the business cost of downtime and the maximum time for a process bump during failover is short then, it may justify the extra load on the network and PLCs to have both communicating at the same time via hot redundancy.
Minimizing the process “bump” time in failover has a cost and in this case it’s added communications traffic – if several seconds of downtime for your process is unacceptable, hot redundancy may be a better option. It’s certainly a consideration that should be given proper consideration when planning a redundancy architecture for your system. Please contact us to discuss your requirements and we can recommend if hot, warm or cold redundancy is best for your application.
Taking these ideas a step further, the DataHub redundancy functionality is not limited to OPC servers. The DataHub can make any two identical data sets redundant. A data set is a collection of tags that you need access to in your client application. These data sets can include any data source that DataHub supports like OPC DA, OPC UA, OPC A&E, Modbus, Tunneling, ODBC, DDE and custom applications using the DataHub API. For example, you could have one connection be via OPC DA and the backup be via OPC UA or Modbus. As long as the exact same tag names show up in the data set, then things will work well.
The reason it is important to have the same data set in both the primary and backup data source is that if tags exist in one and not the other you will see a Bad or Not Connected quality for those tags when using the data source that doesn’t have the full data set. The DataHub keeps a copy of the data from both the primary and the secondary connection and places the active connection into an output group that your client connects to. When a failover occurs the output group will be instantly populated with the tags and values from the secondary connection so your clients barely notice there was a lapse.
The DataHub redundancy functionality provides both status and control of which connection is active through a set of user defined system data points. With these tags, you can know which connection is active and force a failover by writing to the “preferred source number” point. These points are part of the DataHub tag list and, because of that, your HMI can connect to and read or write to these tags. You could even go so far as to use these tags in conjunction with the Email/SMS feature of the DataHub to send an alert to someone when a failover occurs, ensuring you’re on top of any issues that might occur and another step towards minimizing costly downtime. You could also use the data logging capability in DataHub to keep a record of all failovers and failbacks in a database or other data store.
I hope this blog has given you the information you need to get started in the process of choosing how to manage your redundant OPC servers. If you are a current Cogent DataHub user, I hope we have given you some additional insights into how the DataHub can facilitate redundancy with your own OPC servers.
Aside from just redundancy, the DataHub offers a wide range of functionality for accomplishing an extremely diverse set of challenges many users, like you, may experience on different integration projects. Functionality including bridging data between different sources, sending email or SMS text reports or notifications, acting as a gateway solution between different types of OPC and other data sources and more.