Re: [Pvmanager-devel] alarm

[Andrew J. <an...@ap...>]

On Tuesday 31 August 2010 06:48:00 Dalesio, Leo wrote:
> Pushing through any string to an operator has one problem -
> they are not managed and have no readily understood meaning.

In what way does presenting the operator with one of a limited set of alarm 
messages (as was originally described) make understanding an alarm any easier 
than a more specific error message written by the programmer who knows the 
most about the problem, i.e. from the original code that found it?

I don't believe any of the V3 EPICS display managers have used the alarm 
*status* of a channel in any way other than to display it in the PV Info 
dialog.  ALH does display and log the alarm status, but talking to Randy Flood 
our chief operator just now he says the only time the operators use the alarm 
status from ALH is when looking back at the log, and that a string description 
of the error might be just as helpful or even more so since it could contain 
more clues to the problem.

> In a use case ----
> A PV from a PLC - what do I want to know about it........
...
> There is not some endless set of conditions that have to be handled. A
> limited set per device support per record type is very achievable. My
> expectation is that there will be a large common set that will be used
> everywhere. Some handful will be needed to support devices.

The set may be limited, but in my experience as a driver writer it's usually a 
different set for every device, and there is often additional information that 
I want to include and log which could help with fixing the problem — for a 
communications failure I would want to include the text of the message 
received that I can't parse, for a limit violation the actual value that was 
out of range, for a disconnected link which of INPA-INPK it was, etc.

What could you do with the alarm classification information (which is how I 
think about what you're talking about) that you can't do with a string 
message?  I think that's the important question here; if it's just for logging 
then recording the full error string is better.

> A connection does not send across any unlimited set of unforeseen
> conditions.

But in some cases you can't know what those conditions might be in advance, 
especially if they're being reported to you by a manufacturer's poorly 
documented software (and by now you're probably using a later version than the 
original programmer had so it reports errors he didn't know about).  In those 
cases the driver writer might have to lump the errors from that library into a 
single classification, which is now almost useless.

> The error logging system, which was never formalized nor implemented, could
> be a new topic. There is need for it. Again though - some endless number of
> messages at least needs some standard information to make them useful.

I guess I'm saying that I see no real-time need for something like the V3 
alarm status, and a V4 alarm system would be much better if it incorporates 
the error logger rather than keeping the two separate.  A client like a 
display manager is usually only interested in the alarm severity, and it 
should not have to fetch the error strings if it doesn't want them.  The alarm 
manager however should be able to correlate alarms with error messages.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte