Deployment and configuration

This section provides hints on deployment and PyAlarm devices configuration for SOLEIL.

PyAlarm dependencies

To start the PyAlarm the following python packages have to be installed:

  • MySQL-python ( this package is provided with rpm sudo yum install MySQL-python),

The rest of the packages may be installed with pip tool:

  • numpy

  • pytango

  • fandango

  • PyTangoArchiving

  • taurus

  • panic

, when installed with pip, it will install all required dependencies as well.

Note

CentOS 7 needs the EPEL repository to install the pip tool (sudo yum install python-pip).

On some systems (i.e. CentOS 7), it may be required to upgrade the default pip to the most recent version before installing the packages above:

sudo pip install --upgrade pip
sudo pip install --upgrade setuptools

PANIC GUI dependencies

The GUI requires few additional (in respect to PyAlarm) packages:

sudo yum install python-pyqt4
sudo yum install python-guiqwt

Number of devices/device servers

At SOLEIL, tango devices and device servers are grouped in subsystem-dedicate VMs.

It is then recommended to make PyAlarm device server available on all (virtual) machines either by providing python packages via shared NFS or local installation on the machines.

Then on all subsystem VM, there should be at least two PyAlarm devices.

It is suggested that a dedicate PyAlarm server instance provides each device (one device per server), a threading model of Python is not a real multi-thread.

The device server instance and devices naming conventions should take into account the purpose of the devices it serves (i. e. PyAlarm/rf_slow, for providing alarm/rf/slow_alarms device, which serves a slow alarms).

Timing configuration

As it was discussed during the training, it is recommended to have at least two PyAlarm devices per subsystem.

One will handle standard alarms (slow); the other will serve fast alarms.

Alarms evaluation cycle

Fig. 16 Alarms evaluation cycle

Standard PyAlarm timing configuration

Most of the alarms will not require fast evaluations (are not based on short signals). For such alarms, the evaluation property may be set to 10 seconds or even more. The recommended settings are the following:

  • EvalTimeout: 300, this will allow for slower devices,

  • AlarmThreshold: 3, this will suppress transient communication problems,

  • PollingPeriod: 10,

  • Reminder: 3600,

  • AutoReset: 3600, this may be adjusted according to control room practices. Having alarm auto-reset after one hour is a safe option if there is always an operator who looks from time to time on the alarm list dashboard, so none of the “mysteriously-self-healed” alarms is missed. If it is not the case, the AutoReset time shall be increased to make sure that none of the alarms will be missed without being noticed.

Fast PyAlarm timing configuration

PyAlarm devices providing alarms based on quickly changing values (some RF alarms) may need more often formulas evaluation to detect shorter/transient events.

  • EvalTimeout: 10,

  • AlarmThreshold: 1,

  • PollingPeriod: 0.1,

  • Reminder: 3600,

  • AutoReset: 3600,

Startup

The alarms evaluation should start when all subsystems are already running. It is then recommended to start PyAlarm instances at Run Level 5.

Then, use the following property settings:

  • Enabled: 300,

  • StartupDelay: 120,

This way, the alarms will not be evaluated for two minutes preventing alarms from transient states. Then for 5 minutes, there will not be any notifications about alarms, except view on the PANIC GUI. Those settings will prevent notifications’ flood for operators during startup. Usually, during the startup operators are in the control room, and they have access to the Panic GUI to see activated alarms.

Exceptions handling configuration

At the beginning, it is recommended to set the exception related properties as follows:

  • RethrowState: True,

  • RethrowAttribute: True,

  • IgnoreExceptions: True,

This will make sure that alarm will be triggered if there are issues with reading of any involved attribute.

UseTaurs

It is recommended to set the UseTaurus property to True for all PyAlarm devices. This will enable events for retrieving attributes values, so the formula’s evaluation will not be slowed down by attributes reading.

Naming conventions

It is recommended to have a defined naming convention for:

  • PyAlarm device servers instances

  • PyAlarm device instances

  • Alarms

The proposed instance name is: PyAlarm/{subs}{#}, where

  • {subs} is an abbreviation of a subsystem to which the server is related (rf, vac, …),

  • {#} is one digit sequence number.

The suggested device naming schema is alarm/{subs}/{standard/fast}{#}, where:

  • {subs} is an abbreviation of a subsystem to which the device relates (rf, vac, …),

  • {standard/fast} is one of standard or fast to denote the device timing configuration,

  • {#} is one digit sequence Number.

Alarms’ names may follow the following convention: {SYS}_{SUBS}_{OBJECTORVALUE}_{ISSUE}, i.w.: SR_VAC_PRESSURE_DROP, I_RF_CAVITYTEMERATUR_OVERFLOW, I_RF_MODULATOR_FAILURE, BL01_VAC_FRONTEND_CLOSED