Alarm Filter Rules

Overview of Central Alarm Filtering

What is Central Alarm Filtering?

Central Alarm Filtering, or Central Filtering, is an internal Verisae engine that processes raw unfiltered alarms received directly from a site controller or through a head-end controller and turns them into suitable alarms that we can then use to trigger reactive flagged conditions.

What does it do?

Central Filtering collects raw, unfiltered alarms and sits on them until a specified count or delay is met. It then passes the filtered alarms into the Verisae application to our Site Equipment Alarms table. Once there, the flagged condition engine takes over and performs its standard process. In its next phase, this functionality will have the ability to group together similar alarms from separate controllers and produce one all-encompassing alarm, thus reducing noise in the alarm receiver and recording better alarms, as well as the ability to process site offline alarms.

Alarm Filter Rules are set up to help reduce the alarm volume so that clients only see the alarms that require human attention. Alarm Filter Rules can be set up for any standard Alarm Type that is defined in the system for clients. There are four alarm criteria that can be used in the Alarm Filter Rules:

Alarm open for a specified duration

Alarm counts in a period of time

Specified duration or counts in a period

Notification not received for a specified duration

The Alarm Filter Rules are also configurable to the alarm strategies of Return to Normal (RTN) and Repeat Until Resolved (RUR). The RTN strategy involves an alarm “occur” and “clear” being sent. The RUR strategy does not include a sent “clear” for the alarm; instead we have created a way to determine a clear of the alarm using a definable alarm clear period: if no alarm is received in this period, the clear is inferred.

The implementation of a Site Offline Alarm Filter Rule is also highly configurable, as we have multiple methods to receive or generate a Site Offline Alarm. Users can choose from the following methods:

Alarm counts in a period of time

Notification not received for a specified duration

Generate Site Offline Alarm based on non-receive of any notification/alarm from the site

Return to top

Frequently asked questions

How does it compare to our current alarm process?

Currently, the Verisae system only receives filtered alarms after ActiveFM, the filtering engine from RDM, processes raw alarms and performs its own triage. The alarms we receive from ActiveFM are net new alarms that pass directly into our Site Equipment Alarms table, then on to our flagged condition engine. Our Central Filtering engine takes the place of ActiveFM and allows us to do all of the filtering and triaging in-house.

How is it different than flagged conditions?

Central Filtering is a precursor to flagged conditions. Flagged conditions are caused by filtered alarms that meet the requirements for specific alarm types already defined in our system. The flagged conditions are reported to users and also have the ability to generate work orders. Central Filtering would, as described above, allow us to take in raw alarms and pass filtered, net new alarms out to our Site Equipment Alarms table, which then sends the alarms through the flagged conditions engine.

Why is it important?

Central Filtering is important as it reduces alarm noise and prevents users from being overwhelmed with an immense volume of alarms. This overflow of notifications impairs their ability to find and deal with the important alarms and undermines the whole purpose of the alarm system. Our filtering solution funnels down this huge intake of raw alarms and passes on only alarms that meet established requirements and justify human intervention.

Return to top

Process diagram

Central alarm filtering process within vx Observe:

Intro to vx Observe > Central Alarm Filtering > CAF abstract diagram v2.png