RE: Understanding alarms, alarm server and notification usage in other facilities

["Blomley, Edmund \(IBPT\) via Tech-talk" <tech-talk at aps.anl.gov>]

Hey Érico,

During the 2026 Spring collaboration meeting I presented a follow-up. You can find the slides here: https://indico.in2p3.fr/event/37441/contributions/171969/
We basically developed a module which reduces the effort for more "dynamic alarms" down to defining additional info fields for the EPICS records itself. You can have a look at the current status of the module: https://github.com/KIT-IBPT/conditional-field-adjuster
It is currently in preview, but I hope we will be able to add some configuration options and release a proper version soon.

This module of course will not (and is not designed to) tackle all the concerns you raised, and modifications still require changes to IOC-related files.

As for notifications via E-Mail/SMS/etc.: We currently use a Python SoftIOC-based approach where independent e-mail alarms can be configured for individual PVs (including throttling options). We can therefore set up e-mail notifications for individual PVs to individual people/e-mail lists. But I wouldn't say that I am particular happy with this system as it adds parallel "alarm infrastructure" (and then there is the more general issue of the whole process and workflow of how to react to e-mail notifications). But adding additional "protocols" such as messengers, MS teams, Matrix, etc. would be relatively easy.
For the future I would probably migrate these notifications to instead create Olog entries and add e-mail notifications to certain types of Olog logbooks. AutOlog ( also presented during the collaboration meeting https://indico.in2p3.fr/event/37441/contributions/172027/ ) might make that easier to do.

But the idea of both approaches is the same: use another software layer and configurations (Python in this case) to generate individual notifications. You can probably also use the Phoebus alarm server in a similar fashion.
Therefore I would also be curious how other facilities approach these issues.

What we will probably end up with are:

- "more flexible" alarms on the EPICS PV layers using the module above
--- some of these "alarms" would rather be classified as notifications and some will not end up in the alarm server
--- some alarms will trigger Olog entries or additional notifications
- some other "states" will also trigger notifications/logbook entries (which might not propagate to the alarm server: developer or engineering info, measurement related info etc.)

But I am always interested in exploring other solutions or discuss the topic of alarms and notifications in more detail.

Cheers
eddy

Attachment: smime.p7s
Description: S/MIME cryptographic signature