-
Notifications
You must be signed in to change notification settings - Fork 0
BEAST_Plans
(XXX macro: "PageOutline")
This page lists plans for the [wiki:BEAST], functionality that is currently not available but under discussion by the developers.
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
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.
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.
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.
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.
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?