It is possible to configure two Alarm Servers in a project. That is, a primary Alarm Server and a standby Alarm Server. With two Alarm Servers, you have improved (mirrored) redundancy on your system.
When both Alarm Servers are in operation, alarms are processed on both servers in parallel, and are logged by the primary Alarm Server. If the Primary Alarm Server becomes inoperative, the Standby Alarm Server starts to log alarms to devices.
When one alarm server task is shutdown the redundant alarm server task continues to process the alarm states. When the alarm server task is restarted, it tries to establish a connection to an alternate Alarm Server. If it can connect, it transfers the dynamic alarm data from the running Alarm Server to the other Alarm Server (this data includes summary data and the current alarm states). If a connection to an alternate Alarm Server cannot be established, the Alarm Server opens the save file (defined with the [Alarm]SavePrimary parameter) and restores the data from the file. If two save files exist, one from the primary Alarm Server and one from the standby Alarm Server, CitectSCADA uses the save file with the later date, or in other words, the newest save file. If no save file is configured, the Alarm Server cannot obtain the initial status (state) of the alarms and no summary information will be available. If this is the case, the Alarm Server starts processing the alarms, and then acknowledges the new alarms.
While both Alarm Servers are active, they will both read data from the I/O Server and process the alarms. The on/off status of each alarm is not passed between the two servers. When operators perform functions on alarms (for example, acknowledge, disable, enable, add comments, etc.), this information is passed between the two Alarm Servers (if an operator acknowledges an alarm on one server, that server tells the other server to acknowledge the same alarm).
Under normal operation, it is recommended to design your system to have an uninterrupted link between the alarm server tasks. This allows each server task to be able to communicate operational state changes (such as alarm acknowledgment) to the redundant peer. For alarm server task communication, network design that includes redundancy at the network layer helps the alarm server tasks continue operation even during a single network disconnection.
Alarm redundancy is designed to allow the user to resolve the arbitration of an alarm list that is different between redundant alarm server tasks. If a mismatch occurs, the user is able to select which alarm server task is incomplete and restart that server process. During the restart, the state of the alarm server task will match the online peer.
See Also