PANIC ALARM SYSTEM¶
The PANIC is software for building an alarm management system. It is developed mainly by ALBA synchrotron, however, several laboratories proposed some extensions or alternative solutions.
References¶
At this moment source code is kept on the GitHub: https://github.com/tango-controls/PANIC, however, it will be migrated to the GitLab tango-controls organization, soon.
Documentation: https://tango-controls.readthedocs.io/en/latest/tools-and-extensions/alarm/panic.html?highlight=PANIC
Papers: There are several publications referencing PANIC available on JACoW
Forum: There is a dedicated forum thread on Tango Controls: https://www.tango-controls.org/community/forum/c/general/development/panic-the-alba-alarm-system/?page=1
Architecture¶
Below is a short introduction to PyAlarm system architecture. Detail information is available in the online documentation.
A typical deployment of the PANIC system contains (in addition to Tango Controls):
PyAlarm device servers
PANIC GUI
SNAP archiving
There can be multiple PyAlarm devices provided by multiple PyAlarm servers. A PyAlarm device keeps alarms configuration in its properties. Each PyAlarm device serves a set of alarms (alarms are assigned to a PyAlarm device).
A PyAlarm device is subscribing or polling tango attributes which appear in its alarms formulas (part of alarm configuration). Alarm formulas are periodically evaluated. If the evaluation result is True alarm is triggered (the formula is detecting an abnormal condition, according to IEC-62682). An abnormal condition is defined when the alarm formula evaluation results in True.
PyAlarm devices play the Alarm Log role in the Alarm System.
If configured so, a PyAlarm stores alarm state changes as entries in a SNAP database. The entry also contains values of tango attributes involved in the formula evaluation.
SNAP database is the Alarm historian role in the Alarm system.
PANIC GUI is gathering and managing information from all PyAlarm devices. It provides the HMI role according to the IEC norm.
There could be additional components in the system, including Annunciators (mail system, SMS system, …) which are Alarm system’s External systems.
Alarm states¶
The PANIC follows IEC62682 standard for alarm states.
Each alarm individaully can be in one of the following states:
Normal (
NORM
) - the condition for the alarm is not active (formula evaluation has returned False),Uncacknolwdged (
UNACKED
) - the alarm condition has become active (there is an alarm sitution than needs an operator reaction),Acknowledged (
ACKED
) - the alarm (the condition) is still active but an operator has acknowledged it (react, start solving the alarm),Return to Normal (
RTNUN
) - alarm condition recoverd (is not active) but the alarm has not been automaticaly reset or acked by any operator,Shelved (
SHLVD
) - temporary disabled by an operator to focus on more important alarms,Suppressed by design (
DSUPR
) - notification disabled by the system, for example during startup to avoid alarms flooding in startup transient states,Out of sevice (
OOSRV
) - the alarm is defined in the system, but cannot be evaluated at this moment (i.e. a component which evaluates the alarm is switched off).
Working with alarms¶
Typical (end recommended) operation of an alarm is as follows:
The alarm systems detects an alarm condition and trigger the alarm (the alarm changes its state from
NORM
toUNACKED
),An operator notices the alarm (via a GUI or via other means of annunciation),
If the operator is going to solve the alarm situatiun, he acknowledges the alarm (the alarm state becomes
ACKED
,so another operators knows that someone is dealing with the issue),The operator solves the alarm cause (the alarm state changes to
RTNUN
),The operator or the system itself resets the alarm (the alarm state changes back to
NORM
).