Research Division EED/Controls Software<P> Design Note 91.1<P> Epicure Alarm Monitoring Process

Research Division EED/Controls Software

Design Note 91.1

Epicure Alarm Monitoring Process

David M. Kline

Contents

Abstract

The Alarm Monitor Process (AMP) is responsible for monitoring the reading, setting or status device properties that are requested by client applications. Clients that wish to perform device monitoring do so by using the provided da_ Epicure services within an application and specifying the analog boundaries for the setting or reading properties, or a binary bit pattern for the status property. AMP will setup the appropriate data acquisition at a periodic rate as specified by the client. When data acquisition returns, AMP validates the data by comparing it to the specified limits or the bit pattern of the associated property. If the analog value is outside of the limits , or the binary bit pattern does not compare, an alarm report is generated and sent to the ARD process indicating that the device is in alarm. The analog and binary alarm report is further qualified by AMP specifying which direction the value was outside of the limits, or by indicating which bit has gone into alarm. The device will continue to be considered in alarm by AMP until the read values either fall within the analog limits or compares with the binary value, at which point AMP will sent another message to ARD indicating either the analog value or bit(s) are normal for that particular device and property.

When a client requests that devices be monitored, AMP receives and places them into a data acquisition list in dynamic memory organized as a two dimensional linked list ordered by FTD. The requests are placed also in a non-volatile database (AMP database) implemented as an RMS indexed file. Primarily, the AMP database is used by AMP upon initialization to setup data acquisition for devices which were requested by clients. This file can be remotely accessed in order for other applications to read device monitoring information which reduces AMPs processing requirements. However, clients may query a device alarm state by a request read.

When a data acquisition list is received, AMP scans the internally for the FTD list and processes it device by device determining whether the device is in alarm or not. In the event a data acquisition error occurred on that device, a report is sent to ARD and the monitored device is skipped until a successful data acquisition status has returned.

AMP performs other maintenance operations which periodically monitor device consistency and the presence of the DAS process. The device consistency monitor executes at a predetermined interval and verifies that the devices in the AMP database are known to the local database server process . If the device is not found, it is deleted from the appropriate data acquisition FTD list, AMP database, and the event is logged to a file. The DAS process monitor also executes at a predetermined interval and verifies that the DAS process is still present. The monitor function uses the VMS system system sys$getjpi() to lookup the process. If the process is not present, AMP executes the da_run_down() service, logs the condition, and terminates gracefully.

Communication between clients and AMP is established by the use of a mailbox through the DAS process. When clients send alarm requests, DAS routes them to the mailbox. AMP reads the mailbox and processes the requests, then returns status to DAS which is routed back to the requestor. A communication path with ARD is necessary in order to send alarm reports when devices go in and out of alarm. Communication between ARD and AMP is implemented similarly using a mailbox. However AMP uses the alm_rpt_ Epicure services to establish this communication. When AMP initializes, it calls the alm_rpt_connect() service and passes an address of the PlayBackDevice() function. When ARD initializes, it uses the Epicure services to execute the PlayBackDevice() function at AST level on behalf of AMP. The purpose of the function is to scan the AMP database for devices that are in alarm and send the appropriate alarm report, thereby bringing ARD up to date as to which devices went into alarm while it was down. Furthermore, the communication mailbox that the alm_rpt_connect() service connects to is created by ARD. If the mailbox is not present, AMP will terminate with a fatal status. Therefore, the ARD must be brought up before AMP when the alarm system is initialized.

At present, AMP is responsible for monitoring all types of devices using the Epicure da_ services. In the future, AMP will use the Epicure services for only synthetic devices. Most of the device monitoring will be placed down on the frontend or at the CAMAC level. AMP will corrdinate the setup, download, and upload operations for these devices. By seperating this functionality, the data acquisition load is distributed between AMP and DAS.

Startup

The AMP is started by one logging into the EOPERATOR account and selecting the appropriate option, "RESTART AMP". This executes the startup command procedure which activates the image and sets the process limits. The limits which are of concern are the AST_LIMIT, PAGE_FILE, MAX_WORKING_SET, BUFFER_LIMIT, IO_BUFFER, ERROR, and OUTPUT swtiches and are described below:

AST_LIMIT
- Specifies the maximum number of asynchronous system traps that can be outstanding. The
BUFFER_LIMIT
-
ERROR
-
MAX_WORKING_SET
-
IO_BUFFER
-
OUTPUT
-
PAGE_FILE
-

AMP
AMP_MONITORING
AMP_DB_FNC

error logging

Future Implementation

Distribution:

Normal

Security, Privacy, Legal

rwest@fsus04.fnal.gov