Disabled Alarm Expiration Date

[jacquelinegarrahan]

I propose adding the ability to associate disabled alarms with an expiration date, past which the alarm leaf/node will be automatically enabled.

Would this feature be useful to other users?

[georgweiss]

While potentially useful this might pose a usability issue when alarms users assumed were disabled at some point in time become active again. Users might not be aware of the expiration date unless there is a way to clearly indicate it.

[shroffk]

While we can figure out the representation for temporarily disabled alarms... I think the disable alarm with a timeout is generally a good feature which would encourage good practices

[shroffk]

Currently disables alarms are simply grey, we can include a time representations
XF:28ID{PS:123}-Temp (8h)

[georgweiss]

That's fine, but my concern is the case where the Phoebus client starts signalling alarms that automatically become enabled at a point in time when users have forgotten about it.

[shroffk]

Phoebus client starts signalling alarms that automatically become enabled at a point in time when users have forgotten about it.

I actually see this as a feature not a concern :)
Disabling alarms should not be a way to forget them...the "surprise" might be useful to encourage users to properly handle the alarm configuration.
If it is noisy then filter or add threshold or use something else
If it not important then remove it
Basically, disabling alarms should not be a permanent solution... so a surprise is well justified to those who use disable in this fashion (I hope I am not being mean to the poor users)

[shroffk]

Oh, I just saw Kay's response... sorry for repeating

[kasemir]

users have forgotten about it

The alarm configuration is not static. One big motivation for the alarm system was that adding/disabling/updating alarms is not something that is limited to one system expert. Instead, operators in the control room can disable an alarm, or update the alarm guidance when for example a telephone number in there no longer applies.
While it's now technically easy to add/update/disable/remove an alarm, doing that in a useful way still requires some thought, often the collaboration of a system expert, control system engineer and operator. And the result requires monitoring, for example a monthly analysis of most frequent alarms, a review of disabled alarms, exactly to avoid that a disabled alarm is forgotten and never fixed.

Having support for "shelving" of alarms, i.e. disable with a deadline, can be useful and was mentioned in the book that influenced the design of the alarm system, https://www.amazon.com/Alarm-Management-Handbook-Bill-Hollifield/dp/0977896927 . But it's again just one more tool. An operator simply disabling an alarm with 7 day deadline won't magically make that alarm function again. Need to coordinate with system expert and/or controls engineer to determine when the alarm will very likely be usable again, and certainly better to fix & renable instead of disabling with timeout, hoping for magic, and then being surprised that reality still applies.

[jacquelinegarrahan]

I just pulled out my copy... (Ernest had me read this at the outset of starting the SLAC project)

The handbook also mentions some other interesting requirements for shelving:

• Daily notifications of all suppressed alarms
• Priority based control (eg. requiring supervisor approval for shelving high alarms and enforcing maximum duration)
• Automatic disabling of logging by chattering alarms while shelved

The first seems like it might be overkill, but I could imagine cases where the second and third might have some utility. I suppose it would require per-alarm shelving specific configurations.

[kasemir]

As for implementation, the configuration currently contains enabled: true to enable, which is also the default, and enabled: false to disable. I would extend that to allow a date/time, like enabled: 2021-12-24 00:00:00 will enable the alarm from that date/time on. That is allow date/time in addition to plain true (default) and false.
In the GUI, it could also show that re-enable date.
When disabling an alarm trigger PV in the GUI, it might be possible to disable an alarm
a) As now, simply disable
b) Disable until some date/time
c) Disable for some relative time like "12 hours" or "7 days"
But those requests from the GUI would then turn into plain true/false or a date/time deadline.
The GUI should not show an updating "Disabled for 2 hours, 14 minutes, 10 seconds" but just show the (optional) date/time deadline to minimize periodic GUI updates.

[jacquelinegarrahan]

Re your point above on forgotten alarms: relative times might be intentionally limited to dissuade user's from ignoring to the point of forgetting.