[widar-wg] Alerts - CM - configuration failure

[Sonja Vrcic]

Bill,
There is a proposal to add Config ID to Alert ID. When reporting 
configuration failure for configID=ABCD.1234567.4 for the WIDAR board 
b101-t-7, Alert ID would look (more-or-less) like this:
mccc-cm-config-failed-b101-t-7-ABCD.1234567.431


Note: Alert 'config-failed' will be cleared next time when the board is 
successfully configured. Successful configuration may have a different 
Config ID. (If clear alert is going to specify config ID, it would be 
more useful to identify the successful configuration).

Perhaps, clear alert should not specify config ID (or specify an empty 
string). The same may apply for the failure that occurred while 
de-configuring (transmitting the default configuration).

Raise alert for config ID=ABCD.1234567.4
mccc-cm-config-failed-b101-t-7-ABCD.1234567.4

Clear alert
mccc-cm-config-failed-b101-t-7

Raise alert for default configuration
mccc-cm-config-failed-b101-t-7

But, this would require alarm processing s/w to parse Alert IDs.

Sonja





Bill Sahr wrote:
> Pls see below.
>
> Sonja Vrcic wrote:
>    
>> Michael,
>> thanks for the quick response, please see my comments below.
>> Sonja
>>
>>
>> Michael Rupen wrote:
>>      
>    
>> My understanding is that operator can see only one alert of the same
>> type on the screen. If that is true, and CM implements a) operator would
>> see only the last generated alert (config ID). Therefore b) seems to be
>> a better solution.
>>
>> Config ID could be added to the alert message as a parameter. Since
>> alert can have multiple parameters, CM could add two or more config IDs
>> to the same alert.
>> But, is it possible to display one or more config IDs on the operator
>> screen.
>> And, if specified as parameter(s), would config ID(s) be added to the
>> archive.
>>
>>      
> If specified as a parameter, I don't think config IDs would be archived.
> To be archived, I think one would have to specify the config ID as an
> attribute of the "archive" element, perhaps as "mon".
>
> There is another option not yet discussed - there is a variant form of
> monitor data being used for the vlba that describes the monitor point
> data table as:
>
>    
>> hostname varchar(20) not null,
>> devicename varchar(20) not null,
>> monpointname varchar(30) not null,
>> timestamp double precision not null,
>> status int2 not null,
>> monpointvalue double precision not null,
>> monpointstr  varchar(20),
>> dtype  int2  not null
>>      
> monpointstr&  dtype are the variant fields.  If these fields were included
> as attributes in the archive element&  in the alertdata table in the
> database, then config ID could be set as the value of monpointstr.
> Of course, adding these fields to the archive element would mean modifying
> the xAlerts schema.
>
> Bill
>
>    

-- 
Sonja Vrcic
Software Engineer
Astronomy Technology Research Group - Penticton
National Research Council Of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
Sonja.Vrcic at nrc-cnrc.gc.ca
(250)497-2309 or (250)497-2300 ext.309
http://www.nrc-cnrc.gc.ca/eng/ibp/hia.html