How the fault-tolerant server status application works

Using the WMI technology, specific status points are collected from the ftServer. Those items are enumerated into a hierarchy (tree) structure. The hierarchy is then evaluated for critical missing components. If such a component is missing, then a place holder is created in the hierarchy and a missing state is assigned. The status of every component is scanned. The status of a bad component is traversed up the hierarchy to the root. The end result is an overall integrity of the system at the root of the hierarchy view.

Two pieces of data are communicated to the DVFTS_Status DeltaV module via an OPC write. They are the Boolean overall integrity and a number representing the system time. The system time is used as a watchdog timer in the module. If an update has not been received in 200 seconds, then the Change of State alarm is tripped.

The Refresh button will clear the entire hierarchy and rebuild it. If you are not sure that the hierarchy is reading correctly, it is recommended that the Refresh button be clicked.

The DVFTSStatus application uses two .ini files. One stores the basic settings of the form and the other stores the specific settings of that ftServer by name. The basic settings include the Server, Rev, Model, Write to DeltaV, Auto Update, and Module Name. The server-specific information includes the items unchecked and therefore excluded from the overall integrity compilation. The server specific information is saved to disk as you check or uncheck items in the hierarchy. The form specific items are saved when the Save Settings button is clicked.

The query for the status in the ftServer causes a system process spike each scan interval. This spike is in a normal priority process that defers to the high and real-time priorities of the DeltaV system. Therefore the status queries do not interfere with the operation of DeltaV on the ftServer.