About Alarm Timing and Activation

We’ll start with meters and loggers: they typically collect data as it happens, however they may have a call-in schedule that will delay the activation of an alarm or notification.

For example, let’s say that every 15 minutes our data logger records into its internal memory the value sent to it by a level-measuring meter. So, we have the following two hours of data:

• 6:00 AM --- level 3.1 feet    
• 6:15 AM --- 3.0
• 6:30 AM --- 3.3
• 6:45 AM --- 4.1  
• 7:00 AM --- 4.1  
• 7:15 AM --- 3.8  
• 7:30 AM --- 3.6
• 7:45 AM --- 3.4
• 8:00 AM --- 3.0

This data logger is scheduled to call-in a string of data every two hours: at 6:00am it sent to FlowWorks the data it collected between 4am and 6am. Then at 8am it sent the above nine measurements with time and date stamps.

FlowWorks' alarm / notification function will analyze the data as it is stored into the database. If we have an alarm configured to notify us when level exceeds 4-feet, it will mention that such an event began at 6:45am. Now, we don't definitively know  if the event began at exactly 6:45am - it could have very well begun anytime between that data point and the previous point at 6:30am. What we do know for sure is that the level was in an “alarm condition" at 6:45am.

FlowWorks will list 6:45am as the “start of event”; however notification messages stating that there is an alarm condition will actually send just moments after 8:00am; the message will tell you that the alarm condition began at 6:45am. This delay is due to the reporting cycle - FlowWorks notifies you about the event as soon as it receives the data, processes it, and identifies the rule  in the alarm's trigger  as 'true' (level > 4).

As FlowWorks continues to examine and test the data received against the defined alarm rules, it will notice that the alarm  condition ended by 7:15am, and it will issue an end-of-event message.

If the call-in schedule remained at every two hours, but instead they occurred 7am, 9am, 11am, etc., at about 7am FlowWorks would issue a start-of-event alert; however it would be sometime after the next call-in at around 9 AM when you would be notified that the active alarm event ended at about 7:15am.

Now that you have a grasp on the basic timing concepts described above, we can now look at the next timing consideration: 'dwell'.

Dwell is designed to reduce 'false' alarms due to insignificant events, such as data spikes. Dwell stipulates a 'lag time' between when the data causes an alarm's trigger to evaluate as 'true', and when an alarm is actually activated. Users can specify a dwell period in the settings for any alarm or notification.

To explain dwell, let's take a humorous example: you’re in a community of rabid supporters of the local football team, which is playing out of town this weekend. Your meter is looking at the level in the sewer system. Half-time occurs and all of those fans who have been glued to the television break for their restrooms. The level in the sewer system sees a sudden spike, as a result. Do you need to dispatch crews? Probably not.

Dwell is a setting by which you can say, "I’m fine with levels exceeding my alarm trigger for short periods  of time (you define how long), but if it lasts longer than the number of minutes I have defined as the 'Dwell Time' then I'd like to be notified. Going back to the example, we may expect sewer levels to go back to normal after about 30 minutes. We can set dwell to 30 minutes so if within that time levels go back to normal, the alarm is not activated and all is "business as usual". However, if after 30 minutes the level still continues to exceed the alarm trigger's threshold, FlowWorks will activate the alarm and all configured alerts will be deployed.

FlowWorks will always look at the data as if it were continuous. However, the call-in schedule may cause a potential delay in when the alarm or notification is identified and an alert is generated. Plus, a trigger event with a dwell that would take the analysis into the next call-in cycle would need to wait for the receipt of the next packet of data to confirm the alarm and deploy an alert.

Let's visualize this: if we plot out the data so that we can see when the data logger recorded the data, when that data was communicated to FlowWorks, and how FlowWorks rebuilt the data stream, we can begin to see how reporting cycles and dwell combined can cause delays in alarms and notifications. The call-in frequency for this example is every 2 hours.

At 6:45am the data logger recorded a value for the measured level as 4.1-feet. At 7am, the same level is recorded. The logger then called-in to FlowWorks and submitted the level-data it recorded between 5am and 7am.

FlowWorks laid this data out in a time-string and noticed that the data for 6:45am exceeded the value set in an alarm rule. It was ready to send alerts, but the user also defined a 30-minute 'dwell', telling us that any 'spike' (where level goes above the alarm's proscribed threshold) of a duration less than 30 minutes should be ignored. At 7am, FlowWorks only had two values for the excessive level - one at 6:45am and the other at 7am. This is less than the required “continues for more than 30 minutes” dwell time. Thus, alerts were not deployed.

At 9am, FlowWorks received a call-in from this site with data spanning from 7am to 9am. When we lay this data out and add it to the time-string from the earlier call-in, we see that by 7:15am, the level dropped below the alarm trigger value. Thus, FlowWorks did not deploy any alerts.

Now, let's say the data looked like this:

As FlowWorks analyzed the data it received at 9am, it saw that the alarm's over-trigger values were first logged at 6:45am, and continued until 7:45am. This exceeded the dwell time defined in the alarm's rules. Hence, two alert messages were sent: an indication that an event began at 6:45am and continued past the dwell timer; and a second message that the event ended at 8am (the first data-value with a time-stamp that falls back below the trigger-value).

Note that FlowWorks learned that the alarm event (which was first noticed with the 7am data packet) continued past the dwell time at 9am (when the next packet of data arrived). Hence, alerts were sent to the proscribed recipients at about 9am. This has caused some confusion with our users in the past, who have asked why they did not receive an alert at 7:15am. In this case, at 7:15am FlowWorks had no data upon which to issue the alert. The system had to wait for both the expiration of the 30-minute dwell timer AND receipt of the next 2-hour data packet, before it could send an alert.

Without dwell, a “start of event” at 6:45am would have caused alert messages to be sent, as soon as the data packet was received. Thus, if response to a condition such as that described above is critical, we recommend that you do not set a dwell time. You may also want to invest in infrastructure that supports more frequent call-ins. Referring to the example above, if data packets were received on the hour, the alarm would have been issued at 8am instead of 9am. This is because FlowWorks would have seen the condition continuing at 8am. The “end of event” notice would have still been delayed until the 9am data packet was received, when FlowWorks could see that at 8:15am the level dropped to a value less than the trigger value, as defined in the alarm.

Thus, you can see that by increasing the frequency of call-in cycles, delays are naturally reduced as you move more toward “real-time” reporting. At the same time, this can significantly increase your maintenance schedule, for frequent call-ins may cause significant drain on battery units. It is indeed a trade-off: investment in battery packs and the labor of swapping these in and out vs. the delay in being made aware of an alarm condition.

When configuring an Alarm or Notification; or trying to troubleshoot why alerts were received at particular times (or not at all); it can help to plot out the data, as we have done above. This can help you visualize how a call-in schedule and dwell time can affect when you will actually be alerted to the condition for which you are configuring an Alarm or Notification.