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.

PANIC system architecture

Fig. 1 PANIC system architecture

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).

PyAlarm

Fig. 2 PyAlarm internals

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.

Alarms evaluation cycle

Fig. 3 Alarms evaluation cycle

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.

Information flow in the PANIC system

Fig. 4 Information flow in the PANIC system

Alarm states

The PANIC follows IEC62682 standard for alarm states.

Alarms states

Fig. 5 Alarms 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

Opeating an alarm

Fig. 6 Operation with an alarm

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 to UNACKED),

  • 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).