Handover alarm generation

We follow the approach to generate alarms by supervising a device's properties (e.g. power bit). The acquired data is compared to reference values (e.g. on/off) and combined with other data (e.g. beam line state) to generate alarms (e.g. magnet is powered off in production beamline).

Tiers

To stay out of development and maintenance cycles of other control system modules and to utilize resources we propose to run separate alarm generation processes (aka sources) on frontends. In some cases rare frontend resources may also suggest to deploy a source server side. Alarm sources use standard means to acquire data from frontend softwares (i.e. DeviceAccess and FESA subscriptions) and communicate with the alarm system core via control system messaging.

Source configurations, i.e. which device/property values lead to which alarms under which conditions, are distributed by the core during runtime.

Pros:

• Enable fully dynamic alarm system configuration that is competely independent of other control system modules and their development/deployment/maintenance cycles.
• Utilize resources. SCUs will be powerful and can easliy handle the load.
• Keep out of devel and maintenance cycles of other software. For example do not depend on release cycles of FESA.
• Easily take into account current facility in future system. Supervise DeviceAccess devices. An integration of alarm generation into FESA cannot do this job.
• Be prepared for future restrictions. E.g. restricted availablity of machine context on frontends can easliy be addressed by moving sources to the server side.

Cons:

• A source is not a simple software product anymore and should run very stable.
• Distributed source processes on all frontend computer may generate some maintenance overhead in terms of
  • ensuring uptime of the processes and
  • ensuring correct behaviour of individual source processes, e.g. not monitor devices on other frontends.

Source architecture

A source process's core task is to relate acquired values from devices and machine state and de-/activate alarms depending one the result. Thus a source process has three internal tiers:

• data acquisition
• alarm generation
• communication with the alarm system core.

To enable the source to generate an alarm a for the alarm system it must be configured by

• a data source description, i.e. devices and properties to monitor and
• an alarm generation rule, e.g. a threshold for a temperature value.

Data acquisition

Data acquisition should be realized in a way that makes the generation independent of the data source (e.g. DeviceAccess, FESA or machine state). The generation should work on an abstraction of data values that will have to be generated out of the actual acquired device data.

Moreover a data item should be acquired only once even if it is needed for the evaluation of several alarm conditions.

Pros:

• Can be extended to cover other data sources

Cons:

• Expensive to develop for few people. Alternative would be to also send a flag from which source to acquire data and store this flag in the server side configuration DB. The abstraction would be less complex to implement.

Alarm generation

Alarm generation evaluates rules on acquired data. Example is a simple threshold comparison: if the acquired value is too large an alarm is raised. Rules can be more complex. To raise an alarm for an offline magnet in a production beamline two values have to be acquired, compared against bitmasks and combined, i.e. not_isSet(MAGNET:POWERBIT)_and_isSet(BEAMLINE:PRODUCTIONBIT). In this case data from several sources would be required for the evaluation.

To generalize this a boolean expression tree should be evaluated based on the boolean outcome of basic rules evaluations (e.g. threshold, bitmask) on acquired data. If the expression evaluated to true or false the alarm is raised or lowered respectively.

It is clear that this mechanism should be event driven, e.g. rules should only be evaluated if e.g. a threshold is exceeded. The threshold in turn should only be evaluated if the underlying data item changed, i.e. onChange subscriptions should be used where available.

Pros:

• Covers all required logic to generate alarms.
• Saves resources, reevaluates only if necessary.

Cons:

• None

Common alarm generation rules

According to Peter all former/current alarm conditions in UFC/DeviceAccess are of low complexity. A 'complex' example is the kicker oil temperature. The frontend software must read several sensors from the hardware. The corresponding status bit is set if one of it exceeds a (hardcoded) threshold.

The temperatures are not exposed through the device's properties. An internal timer ensures that the alarm is updated regularly.

A more complex scenario includes the inability to read an actual temperature from the sensor but only some value that has to be transformed into a temperature using a (variable) calibration curve. It is not the task of the alarm system to do this transformation. The device would have to expose all temperatures.

As a consequence the proposed approach should cover all upcoming alarming conditions.

Communication with the alarm system core

The interface receives configuration from a server side service and delegates its parts to the responsible source tiers. It is also responsible to send alarm state changes to the core. This is realized by monitoring the set of managed alarms for state changes.

Pros:

• None

Cons:

• None