Re: alarm

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

On Monday 30 August 2010 10:37:31 Dalesio, Leo wrote:
> The idea was not to support a different list of alarm status per record.
> It is clear that there is some limited set of these status lists.
> The question is - by installation, device types, etc...?
>
> There could be a standard set for all records - as we attempted before.
> There could be a standard set for device support.

Insisting that there be a standard set makes it impossible to pass along error 
information from 3rd-party libraries (e.g. a manufacturer's library/DLL that 
implements their network protocol or talks directly to their hardware) over 
which you have no control.  I really think this design is heading in the wrong 
direction.

> The problem with a string, is that it does not handled the case - multiple
> alarm conditions are true at the same time. Bob

I disagree.  As long as the API that is called to register alarm messages 
joins the strings it receives with a \n (or if you don't like using new-line, 
you could make the status an array of strings) it's possible to combine an 
unlimited number of alarm conditions, and each string can include more 
information about the alarm condition than using a fixed string can.  The 
string(s) would get cleared at the beginning of record processing just like in 
V3 we reset NSEV and NSTA and recalculate the highest severity every time the 
record processes.

Looking at Marty's set of alarm severities (None, Minor, Major, Invalid, 
Undefined), I wonder whether they should be stored in a bitset rather than an 
enum (None becomes a synonym for zero, and the others get specific bits).  The 
relative priorities of Major, Invalid and Undefined might be different for 
some devices, but with an enum they're fixed.

If you use a bitset for the alarm severity and a string (or an array of 
strings) for the alarm status you have a lot more flexibility, and you can 
also diagnose multiple alarm conditions at once.  This needs more network 
bandwidth, but the API is much easier to understand and develop for -- 
programmer time is more expensive than bandwidth in the long term.

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