Configure the monitorCriticalAlarms JSON file
- Last UpdatedApr 24, 2025
- 3 minute read
Note: For information on overriding default configuration settings, refer to Modify configuration settings.
The monitorCriticalAlarms process monitors new alarms and determines whether critical conditions exist. In the event of a critical condition, the process publishes a Publish/Subscribe (PubSub) criticalAlarm message. Configure the JSON file associated with this process to:
-
Identify the status point that controls the device that generates an audible alarm in the event of a critical alarm (refer to Configure a status point to control the audible device).
-
Configure a delay for a recurring OPEN command.
This prevents the application from sending multiple OPEN commands to the status point controlling the audible alarm.
-
Configure retries for the AlarmFilterString Business Logic Tier (BLT)
The monitorCriticalAlarms process monitors a list of critical analog, status, and multistate points with active critical alarms for state changes. To monitor the list, the process calls the AlarmFilterString BLT. If the BLT call fails repeatedly, the process deems the list unreliable and clears it. Configuring a periodic retry call to the BLT prevents the list from staying in a bad or corrupted state that may result from such things as failures, database locks, or timeouts.
-
Configure the frequency at which the monitorCriticalAlarms process verifies the list of critical analog, status, and multistate points with active critical alarms.
To configure the monitorCriticalAlarms JSON file
-
In the %DNADataRoot%\RealTime\config\Settings directory, either create or open the RealTime_monitorCriticalAlarms.json file.
-
Change the value of "criticalAlarmHornPointName" to the name of the status record created as per Configure a status point to control the audible device.
{
"RealTime": {
"criticalAlarmHornPointName": "CRITICAL_ALARM_HORN",
"openCommandDelay": 60,
"bltRetries": 2,
"alarmIntegrityFrequency": 20,
"criticalPopupDelay": 0,
"enableAllCriticalAlarms": false,
"HornCommandDataset": null
}
}
Note: The default value is CRITICAL_ALARM_HORN.
-
In the following line, change the value to the time in seconds the monitorCriticalAlarms process waits before sending another OPEN command after the initial command:
"openCommandDelay": 60
Note: The default value is 60.
-
In the following line, change the value to the number of retry calls to the AlarmFilterString BLT:
"bltRetries": 2
Note: The default value is 2.
-
In the following line, change the value to the frequency at which the monitorCriticalAlarms process regenerates the internal list of critical alarms when no critical alarms currently exist:
"alarmIntegrityFrequency": 20
Notes: The monitorCriticalAlarms process checks the list every cycle if at least one critical alarm exists.
The default value is 20. -
In the following line, change the amount of time in seconds that the monitorCriticalAlarms process will wait before triggering the Critical Condition Summary window:
"criticalPopupDelay": 0
-
In the following line, change the conditions that the monitorCriticalAlarms process uses to determine if a critical condition exists:
"enableAllCriticalAlarms": false
Setting the value to TRUE will enable any alarm with a critical severity to trigger a critical condition. Setting the value to FALSE will only enable alarms that have a critical severity for a point that is also configured as critical to trigger a critical condition.
-
In the following line, enter the dataset name that was configured on the Alarm Horn status point:
"HornCommandDataset": null
If this value is set, only the system that owns the dataset will command the Alarm Horn when a critical condition is detected. If the value is left blank, all systems can trigger the Alarm Horn when a critical condition is detected.
Note: This key setting replaces the -d startup option for the monitorCriticalAlarms process.
-
Save the file.
-
Restart the RealTime service.