Alarm States of Front-End Devices

Devices should display critical conditions by alarms. For each device type, it has to be defined what should be signaled by an alarm state. Compared to the usual FESA device status the Alarm states must not be monitored by a client but are pushed independently to an Alarm service which processes these Alarm States.

The Alarm State is of binary type: ACTIVE, INACTIVE. The name of an alarm must be unique in the whole system, it consists of 3 parts, source-type, source-name, resource-locator. For the Front-Ende devices it is "FESA", <Class-Instance-Name>, <Unique-Name-in-Class-e.g.-Property.Field.Name>

Alarm states should be defined with care:

• Alarm states should Display conditions which are of relevance for the Operation of the machines
• flooding the alarmdisplay with lots of deltailed alarms has to be avoided, concentrate on relevant alarms
• alarms should not oscillate, conditions which rapidly Change between ACTIVE and INACTIVE should not be displayed as alarm
• alarms should not be affected by actions/measurements due to multiplexed operation, i.e. in general alarms are created by error-conditions which are DC
• for analog-values a dead-band meachnism has to implemented

This page is a collection of possible states which may be signaled by the alarm system. The list is not yet a guideline for alarm definition. In general, creation of alarms should be restrictively dealed with.

Possible Alarm States

General Error Items in the Device Status Property

When a device is in a state where it is not usable in the accelerator environment, the cause should be indicated in the device's status, readable by the Status-property. Typical reasons are missing cooling water, missing powerline, overtemperature.

All the possible states should be combined to summerized information:

• interlock
• opReady
• modulesReady
• control (local/remote)

A modulesReady alarm could indicate loss of communication between a device and its FEC.

Attention: opReady may only generate alarm when it is caused by an error-condition but not when initiallizing the equipment.

For operational use, the status valu-item 'opReady' is the most important one: This summerizes whether the device is ready for usage in the accelrtor operation or not. All errors in the device, like missing cooling water, as well as an error in the control system interface (modulesReady-error) should result in an opReady=FALSE condition.

In the first step, all devices should implement an alarm to signal an opReady=FALSE condition:

opReadyAlarm

device is not operational ready

Inconsistent configuration / setup of device HW

E.g.: Bumper provides for selection between two power supplies by manually operated switches. Seperate switches are provided for positive and negative voltages. Setting both switches to different power supplies would not allow to operate the bumper. However, as with other error conditions, such an inconsisten setting should be indicated in the device's Status property and should result in an opReady=FALSE condition.

Nominal and Measured values inconsistent

An alarm could be raised if a measured output value is not within acceptable limits of the nominal value after a certain time period.

This is feasable for non-multiplexed data. For multiplexed data, situation is complex: A deviation may occur in a beam process which is not executed again for long time, while in all other beam processes the deviation may be OK, and the accelerator operates correctly. Should such an deviation be signaled by an alarm? When such an alarm condition will be cleared? A widely agreed strategy has to be developed bevor implementing alarms for nominal and measured values inconsistencies of multiplexed data.

Specific Examples

Gas Inlet

ModulesReady - communication with MKS controller failed repeatedly, will then be covered by opReady-alarm

Inconsistent output - measured gas flow not equal to nominal - gas source problem

Error Conditions covered by opReady Alarms

Services Unavialable

Services essential to the operation of the device are missing.

e.g.:

Cooling Water Unavailable

High Voltage Power Supply Unavailable

Cryring Device Examples

Some possible alarms for selected Cryring devices

Magnet PowerSupply

ModulesReady - power supply cannot be controlled

Cooling Water Unavailable - power supply cannot be operated

HV Power Supply Unavailable - power supply cannot be operated