Re: [Pvmanager-devel] alarm

[Ralph L. <Ral...@be...>]

  On 30.08.2010 18:02, Andrew Johnson wrote:
> On Monday 30 August 2010 15:11:34 Ralph Lange wrote:
>> The UNDEFINED enum option was just added to allow clients to distinguish
>> between:
>> * a working connection to a PV/record that has a value and set its
>> severity to INVALID (for one of several reasons, which can be found out
>> reading the status)
>> * no working connection to a PV/record
>> The alarm handler (maybe other clients) already implement this
>> additional severity, so we added it as it is needed.
 >
> Which is more severe, the Undefined status of a broken PV-link to a secondary
> temperature sensor on an IOC that got turned off for maintenance, or the Major
> alarm from the primary sensor indicating that the equipment is overheating?  I
> agree that this is a made-up example and that we would usually expect the
> application developer to ensure that the broken link would not override the
> overheating status, but I'm showing that Undefined is not always more severe,
> so it shouldn't necessarily overshadow a Major alarm.  The application
> designer is the only person who knows which matters more.

Excellent example, but it proves a different point. ;-)

The thing that is really special in your example is the *relation* 
between the two PVs, i.e. them being two separate sensors for the same 
signal. This is a redundancy example, and the point you are proving is 
that "maximize severity" is an inadequate algorithm for combining 
redundant signals. Which is definitely true. Thinking longer about this, 
you will probably have to create a new record type for combining 
redundant signals, and have fields to configure the combination 
algorithms for values as well as alarms:
Given three redundant analog inputs for the same signal, should the 
value be a) the lowest, b) the highest, c) the average? Should the 
severity be a) the lowest, b) the highest, c) the severity of the 
majority of inputs? There are valid use cases for each of these options.

[Actually, redundancy as a concept is only poorly supported in EPICS, 
and we should probably change that in EPICS 4 - but that's a different 
discussion.]

The traditionally more common use case is a controller, with its inputs 
being unrelated. A controller needs to have special actions for 
severities of INVALID or higher (IVOA etc.), and any input being INVALID 
must immediately put the controller into INVALID and execute the special 
actions. "Maximize severity" or the new "maximize severity INVALID" are 
perfectly adequate algorithms for that. UNDEFINED (i.e. an input with no 
connection) has to be treated the same as INVALID for a controller, as 
both mean the input value is unusable, and the result of the control 
algorithm is the same.

One more point for UNDEFINED: the Gateway.
If an IOC goes away, all direct clients would lose connection and thus 
change the severity to UNDEFINED.
A client behind a Gateway does not lose the connection, but the Gateway 
would simply forward the UNDEFINED severity, and thus act transparently.

> My point of suggesting using a bitset was that maybe the client should be the
> one that looks at the different outstanding alarm severities and messages; it
> could still use the Maximize Severity algorithm, but it doesn't have to.  In
> V3 we use a 16 bit enum to send 2 bits of severity information, having thrown
> away all data about lower priority alarms which might also exist; if you use a
> bitset, you can still send a 16 bit quantity, but now you're sending 3 or 4
> bits of severity information and letting the client decide what to discard.

"Maximize severity" is a well-established and widely used concept in 
EPICS 3.
Moving that to the client will not work. In that case every client would 
have to know that a certain calc record is combining redundant signals 
and another one is a controller - that would replicate that information 
and allow for greatly inconsistent views of the system.
How will a generic application (panel/alarm color mode) show a value 
that has (NO_ALARM & MINOR & MAJOR & INVALID)?

I do see a record having more than one alarm status (hence the bitset), 
but I think it should still have one severity.

Adding more algorithm choices to the severity inheritance might be useful.

Ralph