Frequent communication alarms can clutter your alarm banner, potentially masking critical events. If your immediate priority is to reduce this noise without necessarily diagnosing the root cause, a targeted suppression workaround can be implemented.
This technique involves creating a dedicated alarm severity level specifically for communication alarms, allowing you to selectively silence them while retaining the ability to escalate them when needed.
Important Considerations:
- This is a workaround, not a permanent solution. It is crucial to eventually investigate and resolve the underlying causes of frequent communication alarms.
Implementation Steps:
-
Create a Custom Severity:
- In your server configuration, create a new alarm severity level. For example, you might name it "Suppressed Comms Alarm." In our example we named it "Alert".
- In your server configuration, create a new alarm severity level. For example, you might name it "Suppressed Comms Alarm." In our example we named it "Alert".
- Assign Severity to Communication Alarms:
- Configure your outstation communication alarms to use this newly created "Alert" severity.
3. Configure Suppression:
- Within the severity settings, disable any audible notifications (sound).
- Optionally, configure user-specific alarm filters to hide alarms of this severity from standard alarm lists, minimizing visual clutter.
4. Create a New Change Priority Action:
- Create a new "Change Priority" action (Create New | Alarm Redirection | Change Priority Action) and set it to a severity level other than "Alert." This will be used to escalate the suppressed alarms.
5. Implement Alarm Redirection for Escalation:
-
- Configure an alarm redirection on the root group of your system (Edit properties | 'Redirection' tab).
- This redirection should escalate alarms of the "Suppressed Comms Alarm" severity to the severity configured in the "Change Priority" action after a defined delay. This ensures that persistent communication issues will eventually trigger a visible alarm.
Alarm List (Pre-Delay)
This screenshot demonstrates the alarm list before the delay period has elapsed. It shows the communication alarms present, potentially with the suppressed severity, and optionally hidden by user filters.
Alarm List (Post-Delay)
This screenshot shows the same alarm list after the delay period has passed. The alarm redirection has escalated the communication alarms to a visible and audible severity, making them noticeable.