Re: [Pvmanager-devel] alarm

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

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.

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.

> By definition severity ("degree of seriousness") has an importance
> ordering, which *must* be uniform throughout the system to allow a
> consistent view of the alarm situation across devices.
>
> Should devices have their own set of severity terms and definitions,
> device support must map the device's internal severity set to the EPICS
> severity set.

I agree, but an unconnected PV shouldn't always be mapped higher than Major.

> > Note that severity is used by many widgets to display mote than just a
> > string. For example  none is green, minor is yellow, major is red. What
> > happens if severity is a bit set and what if it's choices are also
> > extendable?
>
> Exactly.
> Also: What would "maximize severity" mean if any record can have the
> severities in different order?

I'm not saying that we should allow the severities to be re-ordered, I am 
objecting to adding Undefined as a severity that means not connected and 
putting it above Invalid.  Connection status needs to be filtered by the 
application to turn it into severity data.

Combining two severity bitsets just means ORing them together; it's /simpler/ 
than the maximize-severity algorithm.  Providing you define the bits properly 
you can also compare two severities using < or > to find which is more severe.

Combining the status messages would be a little harder, but I can think of 
several possibilities.


However my main objection was with the plan to force alarm status to be 
selected from a fixed set of strings.  That really limits what a driver writer 
can do if she has no way of knowing what error strings might come back from 
her network-connected device, or from the interface library that a device 
manufacturer gives her.

In Data Access Jeff allows a client and/or server to dynamically add new 
property names to their circuit at runtime; they get sent over the wire once 
when they are needed, along with an ID number that will refer to them in the 
future.  Adopting this model for alarm status messages would be much better 
than requiring that all alarm strings be known and passed up to the client at 
connection time (slow and unnecessary).  A driver writer looking for high 
performance could register all their static alarm strings and just give an ID 
when posting an alarm, but you can also be flexible for drivers that can't do 
that (you would allow the server to withdraw or overwrite an ID so it can be 
re-used for a different alarm string in that case).


Looking back, I see Marty discussing a "pvManager getPossibleAlarms method" as 
the reason for the static strings implementation; I'd want the author of that 
specification to explain why it's needed and so restrictive.

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