EPICURE Design Note 85.0
EPICURE ALARMS SPECIFICATION
T. Watts, F. Nagy, D. Baddorf, E. Dambik, A. Thomas, D. Johnson
This is the initial specification describing an overview of the
Epicure Alarm Reporting System (EARS).
This specification will be followed by design notes detailing
the four major components of the alarm system: Monitor, Dispatcher, Display,
and Control.
Terminology
- Alarm Report is a notification that an alarm has occurred.
An alarm report is emitted for any state change that is being
monitored. This report is created by the monitoring task(s) and is made
available to any type of display task.
- Event is a specialized report that has a single state.
An event is usually used to report informational messages.
- Alarm Block is a structure containing the information to be used
for controlling alarm monitoring.
- Monitoring is the act of comparing the readbacks from devices
with the limits and nominals established in the alarm block for that device.
A change in state of a device readback will
result in an alarm report.
- State Change is the act of a device going from ``good to bad''or
``bad to good''.
- Monitor Program is a program that decides if a device is within
its established limits or nominals, or if a device readback has changed state.
- Display Program is a program that determines whether or not a device
should be posted or removed from a display using the relevant information in
the alarm report for each device.
- Control Program is the program that allows a user to establish the
monitoring information in device alarm blocks.
- Clearing Alarms is a process by which the monitor task(s) can be
requested to emit a going good alarm report for a particular device or set
of devices. The receipt of the going good message should in turn
cause the corresponding alarm messages to be
cleared by all alarm display programs, as a direct result of their receipt of
the forced going good alarm report. The
monitor task(s) will continue to monitor the device(s) just cleared,
and shortly follow with a
going bad alarm report should the device(s) still be in an alarm state.
Requirements for EPICURE ALARM MONITORING:
- A single set of global limits will be supported for each alarmable device.
The programs that monitor devices will use this set of limits to determine if an
alarm report should be issued. Limit information will be stored in non-volatile
memory.
- Devices will be monitored for detection of alarm conditions, based on the FTD
available in both the Analog and Digital alarm blocks. The maximum FTD rate that will be
permitted is .5 hz, (once every 2 seconds). Although devices can also be monitored at
select clock event/offset combinations, it will be necessary to restrict the monitoring of
devices on some clock events.
- The monitor programs will provide information in each alarm report indicating if
the device has just gone bad or just gone good.
- The alarm system will support the monitoring of synthetic devices. This is expected
to be handled by a special monitoring program which will generate a standard alarm report.
The limits are established by setting a standard alarm block which is made available to this
application.
- A special application could be written to allow devices to be monitored
locally with different local limits.
- Alarm messages will be allowed to be packetized and returned to the monitor program
at a 1 hz rate.
- It is the burden of the monitor program to tear apart consolidated digital alarms into individual alarm reports.
This will be done in order to allow the possibility of posting an alarm message for multiple digital status
bits which have been returned as a single status readback. This means that a display attribute must be setup
for each digital alarm bit that one may wish to post on the alarm display.
Each of these status bits will be capable of being bypassed independently.
- The monitor program should be designed so it is possible to push the task
of monitoring alarms down to the lowest level.
- The monitor program(s) must support alarm clear requests.
Requirements for EPICURE ALARM DISPLAY:
- Alarm reports will be available globally. This includes the capability of making alarm
reports available to experimenter nodes.
- Camac and Cryo reports will be consolidated and reported in a single consistent manner.
- Display of alarms on VT220 and VT3xx terminals, and Vax workstations will be supported.
- An alarm message is translated into a device name using the DI/PI pair stored in the alarm report.
- Event reports, informational alarm reports that a condition has occurred, will be supported by the
alarm display facility. Event reports do not have going good and going bad states. Therefore, event messages
will have a lifetime associated with them. When the life of an event expires, it will automatically be removed from
the display screen.
- Alarms will be displayed categorically. Each device belongs to a single alarm category.
This category is stored in the Central Database and considered to be static. A static relation will
be provided to catalog these alarm categories. The database editor will allow a user to redefine the
category to which a device alarm belongs, but it is expected that these category changes will be infrequent.
- Alarms will be assigned one of 16 priority levels. Devices with the highest priority will be displayed
as the first items in display windows. This assures that the most important alarms won't be missed.
The database editor will allow a user to define the priority of a device. While it is possible to change the
priority of a device, this action should be infrequent, and the priority is thus considered static.
- New alarms will be announced using both audio and video. Messaging windows will use
breakthrough writes to alert terminal and workstation users of new alarm postings.
- Each interactive application that supports alarm display, should have the capability of of issuing clear commands.
When a clear is issued, all message sources will respond by clearing the item(s) or grouping(s) targeted by the request.
Any alarm message that can be posted, must also be able to be cleared.
- Alarm report filters will be available on a per display basis.
- All Alarm messages will be capable of being logged to a file. Logging is selected using one of the
flag bits provided in the DISPLAY attribute. Logging of alarms will be accomplished by a special
non-interactive application running on DISNEY.
- Alarm information will be available to user application programs on the VAX. Alarm display programs
should use color to highlight problems if it ever becomes available.
- Fixed locations will contain permanent alarm displays of a small number of critical
predetermined devices. These displays are referred to as comfort displays.
- Hooks could be implemented to allow a designated user-written application to run in
response to a specific alarm.
- The override device field is a DI,PI of some other device whose alarm state can be used by a
display program as a filter.
The override device field of the database DISPLAY attribute will be used to determine whether or not
a particular alarm message should be posted on the display. If the device and property specified by the
OVERRIDE is already posted,
then this alarm will not be posted unless the OVERRIDE DI,PI clears and the device previously filtered
from display is still in alarm.
An OVERRIDE device field is made available in the DISPLAY attribute of the alarm property.
The OVERRIDE device field would be specified when the display attribute is
being defined in the database. While it can be changed, this should be an infrequent action.
- The display program expects an alarm report for each alarm condition that is to be posted or removed.
Requirements for EPICURE ALARM CONTROL
The control program will allow users to define the devices that should be scanned, the scan rate, and the
conditions to be used in determining if a device is in alarm. This program will be invoked whenever a user
wants to view the alarm conditions presently selected, or change these conditions.
- Selection of a single ftd for the analog alarm block (max .5 hz rate)
- Selection of a single ftd for the digital alarm block (max .5 hz rate)
- Selection of a tries needed counter (max tries = 15). This counter acts as a noise filter by
requiring a device to stay in a bad state over multiple read samples before an alarm report will be emitted.
- Selection of high and low values, or nominal and tolerance (for the purpose of display and input)
in analog alarm blocks.
Both raw and scaled units will be supported.
- Selection of the nominal values and masks for digital alarm blocks
- Setting of the bypass bit(s) which decides if this device is to be scanned or bypassed
- Display of the corresponding analog and digital alarm text messages
- Display of event message text
- Display of alarm logging on/off
- Provides a mechanism to create lists and lists of lists.
These lists will be used to allow a user to manipulate alarm control such
as bypass as a group.
- Provides a summary of lists by title and status.
- Provides a means by which to rename, create, or delete a list
- Provides a means by which to bypass all devices on a list
- Provides a means by which to view, build and edit list contents
- Provides a means by which to issue clears to devices or lists
- Retrieves alarm blocks from the monitor task using standard da_ services and
sets monitor conditions using standard ds_ services.
Keywords: RDCS, EPICURE, controls, alarms, watch
Distribution:
Normal
Security, Privacy, Legal
rwest@fsus04.fnal.gov