System level redundancy is an important aspect of any healthy SCADA system, especially if thin clients are being utilized. System level redundancy is simply an extension of a Thick Client application, combined with some Script (e.g. VBScript in a Background Script) along with the Scheduler. To implement System-level redundancy (of IWS Servers), you will need two or more IWS Servers with identical applications. IWS also supports database redundancy and web thin client redundancy. To illustrate how this works, consider the following:
We have two IWS Servers (Server 1 and Server 2), each with the same application. These are common elements between the two Servers applications:
• Server 1 knows the IP address for Server 2
• Server 2 knows the IP address for Server 1
• Server 1 and Server 2 have a Scheduler function to create a “heartbeat” that will be enabled if the Server is the Primary
• Server 1 has a TCP/IP Client Worksheet to check the heartbeat of Server 2. This will be triggered periodically if Server 1 is the Hot Standby.
• Server 2 has a TCP/IP Client Worksheet to check the heartbeat of Server 1. This will be triggered periodically if Server 2 is the Hot Standby.
• Server 1 has a TCP/IP Client Worksheet to read the application tags of Server 2. This will be enabled if Server 1 is the Hot Standby
• Server 2 has a TCP/IP Client Worksheet to read the application tags of Server 1. This will be enabled if Server 2 is the Hot Standby
• Both Server 1 and Server 2 have Communication Worksheet(s) to read from the PLCs, but only the Primary will have the Communication Worksheets enabled.
To implement System-level redundancy, the following logic sequence must take place
• The first Server to power-up checks to see if another Server is running, If not, it will asserts itself as the Primary. If there is a Master already running (with a heartbeat), the Server asserts itself as the Hot Standby
• The Hot Standby periodically checks the heartbeat of the Primary. If it goes away, the Hot Standby asserts itself as the Master.
Using this scenario, each Server is running the same application but one Server (the Primary) is getting the data from “real world” devices while the other Server (the Hot Standby) is getting data from the Tags Database of the Primary. The redundancy switch-over time is a function of the heartbeat rate and the frequency of the Hot Standby Server checking the heartbeat of the Master. Each Thick Client will appear as though it is operationally controlling (monitoring) the machine or process, while in reality only one Server is communicating with the real-world devices.