Transcript
Len Vermillion: Before we get to the five questions, who should be asking them?
Chris Little: Primarily, these are for managers or superintendents, who are the decision-makers responsible for capturing current and future needs in a specification to hand to their system integrator or in-house developer. They understand the problems and are familiar with standard terminology, but they don’t necessarily understand the specifics of how concepts such as hot backup server failover are supposed to work.
I also think this is relevant to integrators and consultants, who sometimes take for granted that their current approach to redundancy provides adequate resilience for their end users and adequate ROI for them.
Len Vermillion: For less technical readers, can you describe hot and cold backup?
Chris Little: For cold backup, when a primary server fails, someone must go to that location, pull a backup machine out of a closet, power it up, and hope it still connects to the field devices. During this time, operators are blind to what's happening, and in most cases, process data is lost.
Hot backup means that, if a server fails or its network connection is lost, there are one or more backups that can take over in sequence without delay or human intervention. These days, new systems should only be hot backup.
Len Vermillion: Let’s get to the questions you need to ask when upgrading your SCADA. Question number one, how many redundant servers will there be?
Chris Little: Unless you're a big system, the answer is probably one. If the primary fails, there's one backup. The problem is that extreme events, like hurricanes, which can bring down one server, can easily bring down two. Unlike other SCADA products, VTScada software supports any number of distributed servers. These can be configured in seconds without any fragile custom scripting.
Len Vermillion: Question two, where are the servers located?
Chris Little: Let’s say you have two servers. Are they both under the same desk in the same office? Resilience is about eliminating single sources of failure. If you have 10 redundant servers in the same basement, you still have one source of failure in the event of a flood. To minimize risk, the best practice is to place servers in geographically isolated locations. VTScada makes it simple to configure distributed servers across your organization’s LAN or WAN.
This problem can also occur with virtual machines. If all your virtual backup servers are hosted on the same physical machine, then you have one point of failure. Many users have redundant servers at several sites with one or more backups in the cloud.
Len Vermillion: Question three, how does your system’s historian failover?
Chris Little: A reasonable person might think that the historical database would failover with the server. The problem is that many SCADA products use third-party databases that must be purchased, installed and backed up separately. Most support one backup historian that can't be hosted at another location. VTScada’s Enterprise Historian is built right into every license, so it automatically fails over with the server by default.
VTScada supports automatic bidirectional server synchronization, which means all servers have an up-to-the-second backup of your process history, as well as the alarm/event history and configuration change log. Every redundant server is a backup of the entire application. If the network fails, they can each log local data, and automatically update one another when communications are restored.
Len Vermillion: What about PLCs or networks?
Chris Little: When it comes to redundancy, we often think of servers, but many critical applications require backups for their communications network. VTScada’s built-in Driver Multiplexer not only allows you to do that without any custom code, but also let’s you easily add redundant PLCs to your system, which is becoming more and more of a requirement.
Len Vermillion: Finally, are my thin client servers redundant?
Chris Little: For many operators, thin clients are their primary SCADA interface, letting them manage systems from anywhere using phones, tablets or laptops. The spec will not explicitly describe how the system is designed to handle thin client redundancy. Our thin clients are optional, native components that can be enabled on any VTScada server license. These can also be shared across all the redundant servers in an application, allowing any redundant server to be a seamless backup thin client server. No coding required.
Also, since most SCADA software requires third-party server products, they require failover to be configured separately. VTScada’s Internet server is built-in.
Len Vermillion: We covered a lot of ground. Anything else to add?
Chris Little: On many SCADA specifications, redundancy is a single checkbox. It does or doesn't support redundancy. The real answer is always more complicated. These questions will help you quickly understand what's being proposed, and if that's going to offer you the resilience you need.
Len Vermillion: Where can people learn more?
Chris Little: We go into more detail on our website, VTScada.com/redundancy. Plus, we have a free industrial version you can try.
