EPICS Acknowledge Latched Alarm

EPICS clients must examine four fields to fully determine the effective state of an alarm:

• SEVR: Am I alarming and if so, what priority (severity)
• STAT: Am I alarming and if so, what type (status)
• ACKS: Am I latched, and if so, which severity (highest severity unacknowledged alarm)
• ACKT: Do I latch (acknowledgements required)

An EPICS alarm acknowledgement message intended to clear a latched alarm requires specification of a severity to avoid accidentally clearing a latched alarm of major severity when intending to clear a minor severity alarm in the event of a race condition (scenario where alarm escalates concurrently during an attempt to acknowledge).

JAWS has a completely separate latch/acknowledgement system in order to support generic alarm sources other than EPICS. The epics2Kafka JAWS service monitors EPICS SEVR/STAT only and ignores ACKS/ACKT. Further JAWS makes no attempt to send EPICS specific acknowledgements. EPICS guarantees that SEVR/STAT always reflect the current alarm state. The ACKS/ACKT are global latch states that generally can be safely ignored with a few caveats. The original EPICS alarm handler even has the concept of local latch states that ignores ACKS/ACKT so there is already a precedent for ignoring these fields.

Beside the original EPICS alarm handler itself, the only other client we identified as potentially aware of EPICS native latching is EDM. With EDM, it doesn't appear we actually have any screens at JLab that are aware though and it doesn't appear that any EDM widget is latching aware by default. We simply theorize that EDM makes it relatively easy to configure a widget with a field specific EPICS PV specifier to explicitly monitor ACKS. There is nothing stopping any EPICS client from examining these latching fields so although we are not aware of any clients using them this is a potential issue to be aware of. It may make sense to set ACKT = OFF on all EPICS records to disable latching in EPICS.

EPICS native latching tracks latching at the IOC instead of on a central server so there are implications during a network failure. Specifically, during a network failure an alarm may quickly come and go and the central server would not be notified to latch, whereas it could be tracked on the IOC and discovered later. It seems unlikely in the general case that anyone would bother to check if any alarms latched during a network failure however and the benefits of the centralized approach outstrip this one consideration. After a network failure the CA protocol re-connect notifies clients of the current state of monitored records so although transient alarms could be missed, the current state is reported when the network is restored.