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.

=== 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 "lesser" 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 lesser alarm if the lesser alarm has not been acknowledged after some time.

==== How should the "lesser" alarms show up? ==== As an ordinary alarm in the "Main Control Room" alarm system, can be configured to annunciate, be delayed? Or as a separate “alarm from a secondary alarm server”?

When operators in the main setup see that there is an alarm from a secondary setup, they should have an easy way to access the secondary setup, for example: Switch the CSS alarm GUI to use the secondary configuration, view/ack alarms in there, then switch back to the main configuration.

==== How to configure? ==== In for example the “Cryo” setup, an “Area” or the whole alarm setup can be configured to trigger alarms in the “Main” setup. The “Main” setup can be configured to either show or ignore alarms from secondary setups. Is the delay configured on the main or secondary setup?

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

=== Implementation Ideas === ==== Identify a Setup ==== Right now a setup is basically identified by

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

This should change to just one text identifier (“CUB”), which is then used as the configuration root element and for the JMS topic names. All setups use the same RDB and JMS. Combined with the next item, all could use the same JMS topics.

That way, the CSS Alarm GUI could offer a list of identifiers (all root elements from the RDB) and allow users to switch between them.

==== Alarm Server knows Hierarchy, Sends Full PV Path ==== Right now each Alarm Server only knows the list of PVs in its setup.

This should change: The Alarm Server knows the Root/Area/System/PV hierarchy. It sends updates with the full path to a PV.

That way, GUIs can listen to updates from multiple alarm servers and decide based on the path if they want to react to an update. The server could determine if a PV belongs to an Area that requires updates to other setups.

==== Mirror Area/System State to PVs? ==== Each Area and System in the configuration gets an optional Mirror PV. If set, the Alarm Server sends updates for the alarm state to those PVs.

The PVs can be uses as ordinary trigger PVs in the “main” alarm setup, which would also handle the delays.

The dialer could also watch these PVs, and other tools like operator interfaces could then display alarm summaries (those mirror PVs) as well.

Seems the easiest approach, but how would the dialer get details like description of the alarm?

==== Mirror Area/System State to New JMS Topic? ==== Extend Alarm Server to send updates for the alarm state of (selected) Areas/Systems to a new JMS topic.

This topic can then be used to trigger a dialer or a new alarm GUI that watches ‘secondary’ alarm setups.

Since the alarm server sends the messages, it could include the description, path etc. so the dialer or a new alarm GUI for secondary alarms has all the information.

But also seems more work, and is the delay handled on the client side? Or on the server side?