When using the Enhanced Failover feature, you can use the SAC tab in the Mission Control application to view the status of the Scan, Alarm, and Control (SAC) program. The SAC program retrieves process information from an I/O driver or OPC server. Using the data it receives, SAC updates blocks in the database and processes alarms. SAC also writes set point values from the database to a control device. SAC runs independently of the I/O driver or OPC server.
When reviewing the SAC tab in Mission Control, the Status field indicates whether SAC is in one of the following modes:
- Run
- Standby
- Stopped
The following figure shows an example of SAC in Run mode on a primary SCADA Server. The Status field is set to Run, and is highlighted in the following figure. Another field that you may want to monitor is the Blocks Proc. field, which is also highlighted in the following figure. In an Active (running) SCADA, the Blocks Proc. field is continually increasing. If this number stops updating or the Status is stopped, there may be a problem with SAC.
IMPORTANT: Starting and stopping SAC in an Enhanced Failover environment is not recommended. Doing so may lead to an unexpected failover and role change.
Mission Control, with SAC Tab Selected
TIP: You can view more information about SAC in the Health screen of the SCADA Sync Monitor. For more information, refer to the Diagnostics with the SCADA Sync Monitor section.
NOTE: The fields in the Alarm Synchronization tab in Mission control are unavailable when Enhanced Failover is configured. Use the SCADA Sync Monitor to view information regarding the synchronization process instead.
More Information on Drivers and SAC
SAC, when running, receives a write request as a result of a user action or internally via another block. SAC processes the request and pushes the request to the driver. It is possible that at any given time you would have a number of pending writes in the driver queue. If the driver is optimized, the goal would be to have the writes get processed very quickly.
NOTE: Configuring the driver to perform tasks as “fast” as possible can be detrimental. Drivers should be optimized based on the actual throughput restrictions and PLC responsiveness.
The speed at which writes in the queue get processed depends primarily on the driver technology (Serial vs. Ethernet) and the driver configuration (whether or not the driver has been properly setup or optimized).
It is important to note that pending writes in the queue do not necessarily indicate issues. It is possible for a driver to have pending writes as long as the count does not continue to permanently grow. It is also possible for a driver to receive thousands of writes, have the queue count increase briefly, and then come back down, ideally close to 0.
The following two examples describe how driver queues and Enhanced Failover are independent of each other.
Example 1: Drivers and SAC
Consider this example: the driver is in the running state on both SCADAs. The driver is very busy and has an average 10 pending writes in the queue. When the “failover” happens, the current active node switches from Active to Standby. SAC will be “paused” at this time.
When the Active node becomes the Standby, the driver is still running. The writes will still be processed as fast as the driver can handle them. The driver remains independent of SAC. So while SAC is paused and no longer processing, the driver will continue to process anything in the write queue. If there are 10 pending writes the driver will write them to the device. If there are no communication errors to be reported, the writes will be successful.
One possible side effect is if you have a very quick driver, the writes will likely be done by the time the second Node is promoted to Active, but if you are using a driver connected over a serial line, then it is possible that the two drivers will attempt writes at the same time against the same IO on the PLC at least for the duration needed for the first driver to empty its write queue.
Example 2: Drivers and SAC
The driver is in the running state only on the Active SCADA (using script). When the “failover” occurs programmatically, one driver is stopped while the other driver is started.
When a driver is stopped either programmatically or manually, the write queue will get flushed. Therefore, if you had 10 pending writes, then stop the driver, you just lost 10 writes and the writes will never take place.
It is important to understand that this is not a driver issue. Understanding a driver's capability, testing, and optimizing the driver based on actual throughput restrictions and PLC responsiveness is the best way to ensure desired driver performance.
