Our current alarm system supports this and uses this apparently (though I'm not sure which one, maybe both). Delays help minimize nuisance alarms. An off-delay keeps an alarm active for a time past when the alarm would otherwise no longer be active (setpoint threshold no longer exceeded). An on-delay prevents an alarm from being active for a time even after it otherwise would have entered the active/alarming/annunciating state (setpoint threshold exceeded).
We've identified at least three implementation options to consider:
The alarm source could handle delays (an EPICS IOC for example)
The client (HMI/GUI) could handle delays
A Stream processing app could handle delays (the filter app could be extended to include timers - or a whole new stream processing app could be created)
We need to support one or both of:
Our current alarm system supports this and uses this apparently (though I'm not sure which one, maybe both). Delays help minimize nuisance alarms. An off-delay keeps an alarm active for a time past when the alarm would otherwise no longer be active (setpoint threshold no longer exceeded). An on-delay prevents an alarm from being active for a time even after it otherwise would have entered the active/alarming/annunciating state (setpoint threshold exceeded).