Interactive alarm editing proposal

[LordIdra]

Overview

Currently, the alarm configuration can be edited either by modifying the XML directly or using the tools in Phoebus (the move/duplicate/rename tools in the alarm tree, the configuration menu for alarms/components, and the 'Add PVs to alarm system' button).

At ISIS we are migrating our alarms from valarm to Phoebus. I am writing a conversion script to get us to a good starting point, but we expect a lot of manual tweaking will be needed potentially including frequent large changes like moving groups of alarms to different components. Having an interactive way to do this would be very helpful for us.

Possible improvements

The alarm tree could be improved as follows:

• Search bar
• Drag/drop
• Copy/cut/paste
• Allow component/alarm settings to be displayed on the right side of the PV tree screen rather than opening in a separate window
• Keybinds (ctrl-x, ctrl-c, ctr-v, delete)
• Change the 'Move PV' screen so that it does not create a new Kafka connection each time - currently we need to wait several seconds to move a PV due to this
• Remove the 'rename item' context menu button and instead add it to the configuration screen

Mirrored alarms

Another possible change which should probably not be implemented but still merits discussion is to allow alarms to appear in more than one component. The reasoning for this is that some alarms logically are split across components. For example, an alarm which is part of a cooling system spanning multiple components could appear in those components and also in a 'cooling system' component. This would not change anything in the alarm table. The obvious problems are that

• this might lead to situations where an alarm is unintentionally disabled. To continue the example, the cooling system is still running, but one of the components it covers is disabled. Since the disabled component contains the cooling system alarm, this leads to a cooling system alarm being disabled. This isn't necessarily obvious behaviour and operators might not be aware that they have just disabled an alarm which is part of another system.
• this introduces additional complexity and ambiguity in the UI - e.g. when an alarm is duplicated should the new alarm be mirrored to the old one so any configuration changes apply across both? A visual indicator would also be needed so it is possible to tell that an alarm appears in several locations. (And so on)
• unlike the other proposed improvements, this would most likely require non-trivial architectural changes to the alarm server

Still, this might be a good starting point for a 'mode switching' system which allows components of an accelerator to be easily disabled without having to maintain an untenable number of mode configurations for each config. For example, at ISIS there are some components which are usually only run for testing during startup. Putting aside the above issues for a moment, a component could be created which contains all of these alarms, and when they are no longer being used an operator could simple right click -> disable all on said component. Mirroring would allow these alarms to exist both under this 'startup testing' component and also under separate components which indicate their physical position in the machine.

Prototype

I have created a prototype which is essentially a more interactive version of the alarm tree to test some ideas. It is slightly rough around the edges and has some bugs but does update the alarm configuration live in Kafka. Here is a video of it so far:

2026-09-08.11-12-38.mp4

As this functionality is needed at ISIS anyway, I plan to implement at least some of the proposed improvements in due course but wanted to put this out there first to gather input. If something useful comes out of it we'd like to contribute.