What can you tell me about pump alarms?
Notes about Pump Alarms
Conceptually, pump alarms tell the customer �there may be something wrong with your pump�. Specifically, there are 5 possible causes the criteria) for a pump alarm transition (note that there is no simple way to create violations under criteria #1 or #5):
- The pump violates the performance criteria, based upon weeks of performance data and dynamically changing thresholds.
- The pump runs continuously for longer than 2 hours.
- The pump goes 16 consecutive cycles without turning on. (24 cycles if 3-pump station).
- The pump has gone 8 cycles where every time it ran, some other pump also ran.
- The calculated inflow for each of the last 8 cycles during which the pump ran exceeded 20 TWVs (total well volumes).
Within the RTU, there are several differences between channel and pump alarms:
- There are no trip delays. Alarms occur as soon as any of the 5 criteria above are violated.
- There are no RTN or self-suspended states.
- Violations of criteria #1 are prevented until there are 250 cycles for each pump in the history buffer. There is currently no way for the web site to know for sure when this inhibition is in effect.
- All criteria violations are prevented whenever the pump sensitivity is DISABLED. So, things work like a regular channel�s status only. However, note that status only is not available for individual pumps and the DISABLED option applies to all pumps.
- Any Pump ALARM locks-in for 24 hours. This is different from self-suspension in that no other transitions can occur. But, the lock-in is cleared by any event that clears suspension:disarm/rearm, Reset All Self-suspension Command, Disable Scheduled Reports, Set LLT to 24 Hours Command (DEMO Mode), Re-enabling Scheduled Reports, etc�
- If a violation is present when the lock-in time expires, no new report is generated and another 24-hour lock-in period begins.
- Reports are generated only when the pump transits to or from the ALARM state.
- Re-arming and cycling power will reset the alarm and clear the reason. At least one full pump cycle is required in order to re-trip the prior alarm. The exception is reason #2, where cycling power clears the continuity timer and so requires the full time to re-trip, and re-arming does not clear the continuity timer and so will re-trip immediately (if pump still on).
At the web site, there are several distinctions about how the pump states are processed:
- The ON/OFF state of the pump at time of report is encoded with the alarm state. This bit informs customer displays, but plays no role in alarm status and notification.
- Transitions to NORMAL state never initiate notifications.
- Rule e) above implies that an alarm may persist for weeks, based on just a single report. In that case there is one and only one notification cycle. This is intentional, and serves to avoid obnoxious calls when a pump is down for repairs.
For the customer, pump alarms are also rather different from other channels:
- It may take many weeks for the performance-based criteria (#1) to become operational.
- It may take many hours for a problem to be detected.
- There may be pump problems that our algorithms cannot detect.
- Must not rely on re-notification for violations that persist for long periods of time.
- Must not expect RTN notifications when pump returns to normal performance.
- Must not rely on web site displays to immediately know that the pump has returned to normal. In fact, it may take up to 24 hours for the web site to know that.
- However, the Reset all Self-suspension Command could be used to get a more immediate update of the alarm/normal status.
- Therefore, a visit to the pump site is probably necessary whe