BEAST_Plans

= Plans for the Best Ever Alarm System Toolkit =

PageOutline

This page lists plans for the [wiki:BEAST], functionality that is currently not available but under discussion by the developers.

== Dialer, Phone System == Alarms in designated subsections of the alarm tree should, after a delay, trigger a phone dialer and send a voice message.

The system could offer options like

• "Press 1 to repeat this message"
• "Press 2 to acknowledge this alarm"
• "Press 3 to talk to a control room operator"

Could be based on Asterisk PBX.

• What to support?
• Java or network API to the basic Asterisk PBX functionality?
• How to trigger system for alarms in subsection of alarm config, with delay? This issue is related to handling multiple setups

== Better Support for Multiple Setups == === Scenario === Support multiple setups, for example at the SNS

• Main Control Room
• Conventional Facilities Control Room
• Cryo Control Room

At ITER, there are several "Plant Systems" and the desire to have an integrating overall view. They maybe at least 160 Plant Systems, but they would be grouped into about 15 alarm setups.

=== Goal === Each Control Room or Plant System has its own setup (Alarm configuration, Alarm Server, Annunciator, CSS GUIs). Most of the time they simply run in parallel without interaction. But the "main" control room is somewhat special, and there are times when alarms from some of the "sub" control rooms should show up in the main control room because the secondary control room is not manned all the time. Usually this will be connected to a delay: Only notify the main control room of a sub-system alarm if that alarm remains acknowledged for some time.

==== How to configure? ==== In for example the “Cryo” setup, selected Areas can be configured to "propagate" after some time delay to the "main" display if they are not acknowledged in time. Each individual alarm PV is propagated, but the configuration is done on Areas or Systems, not on individual PVs, because this allows better organization of which alarms should be propagated.

The “Main” setup can be configured to either show or ignore propagated alarms.

==== How should the "sub" alarms show up? ==== The propagated alarms show up similar to normal alarms in an alarm table.

Technically, it might at least in the first implementation be easier to display them in a designated alarm table for only propagated alarms, not in the normal alarm table GUI.

Operators can otherwise treat propagated alarms like all alarms: Access guidance, acknowledge them. There is some kind of indication that shows the originating sub-setup, and the CSS alarm GUI can switch to use the secondary configuration, view/ack alarms in there, then switch back to the main configuration.

==== Phone Dialer ==== In addition, a phone dialer should be supported, triggered by un-acknowledged alarms.

=== Implementation Ideas === ==== Identify a Setup ==== A setup is basically identified by the

• RDB URL
• JMS URL
• Name of RDB configuration root element ("CUB")
• JMS topics ("CUB_SERVER", "CUB_CLIENT", "CUB_TALK")

Just one text identifier ("CUB") is actually configurable, it is used as the configuration root element and to construct the JMS topic names.

All setups that collaborate must use the same RDB and JMS. That way, the CSS Alarm GUI can offer a list of identifiers and allow users to switch between them. The CSS preferences will define the default_ identifier (e.g. "CUB").

==== Alarm Server knows Hierarchy, Sends Full PV Path to 'GLOBAL' topic ==== The Alarm Server knows the Root/Area/System/PV hierarchy (partially implemented). It sends updates with the full path to a PV.

For alarm PVs that are configured to propagate, the alarm server sends updates not only to its own ..._SERVER topic, but also to a GLOBAL_SERVER topic.

This GLOBAL topic can trigger a dialer or the new alarm GUI that watches ‘secondary’ alarm setups.

The alarm server persists the fact that an alarm has been propagated in new PV table fields. The GUI uses these to initialize, then monitors the GLOBAL_SERVER topic for updates. It sends acknowledgements to the GLOBAL_CLIENT topic.

The GUI fetches the description, path etc. of received updates from the RDB when updates arrive, it does not read the whole alarm database.

== Alarm Message Viewer == Right now there's a generic message history viewer. It allows to filter on messages of type 'ALARM', one can also filter on the 'NAME' which for alarm messages would be the PV name. But it is still a generic tool that also shows CSS log messages, EDM 'write' messages etc.

Should it be linked closer to the alarm system? How?

• Show only alarm messages?
• .. of the currently selected alarm setup?