Re: [Pvmanager-devel] alarm

[Marty K. <mrk...@co...>]

  FOR pvmanager but not pvdata listeners

The discussion is about alarm severity and status. pvManager currently 
defines these as:
public enum AlarmSeverity {NONE,MINOR,MAJOR,INVALID,UNDEFINED{

public interface Alarm {
     AlarmSeverity getAlarmSeverity();
     Set<String> getAlarmStatus();  // get current enabled status values
     List<String> getPossibleAlarms(); // get all possible status values
}

The discussion is how can this be implemented efficently.

ALL,


On 08/30/2010 11:11 AM, Ralph Lange wrote:
>    Hi Marty,
>
> On 30.08.2010 09:13, Marty Kraimer wrote:
>>     I did not know if this message should go to the pvmanager mail list or
>> the pvdata mail list so I just picked pvdata.
> Please send to both lists in those cases, else people will be missing
> things.
> Deleting a double mail is a lot easier than reading one you didn't get.

OK starting with this reply.
>> My concern is the two methods:
>>
>> Set<String>   getAlarmStatus():
>> List<String>   getPossibleAlarms();
>>
>> I want to make the case that these should just be the single method:
>>
>> String getMessage();
>> [...]
> Please remember our discussions with Matej at the last meeting:
>
> Each status with its strings will be represented as an enum within
> pvAccess. So, in the worst case, the server sends the set of strings
> once per channel (at connection to a channel).
> Matej was also saying that if modules (device supports) define these
> string enums as immutable (and most of them will), they will be shared
> between channels, so that the server only sends the enum strings once
> per client (when the client connects to the first channel using that enum).
> In both cases, the updates will always be simple ints (bitsets).
>

Thanks for the reminder. I did forget. Sorry.
> I do not see any performance issue with this approach.
>
> Also, the bitset format for statuses was widely agreed-upon, and it
> certainly does *not* only apply to digital I/O. (Why should it? I really
> don't understand that point of your argumentation.)
> Complex devices may have a set of error conditions, combinations of
> which may be true at one moment. While the old (enum) approach was
> forcing EPICS to show just one error (e.g. "READ error", which tells you
> next to nothing), the bitset approach allows you to show a more
> realistic impression of your device's status.
>

OK I think I can start seeing an implementation. The trick is to get a 
set of immutable string choices but allow each support have a chance to 
add new choices.

Since Support has methods initialize and start what could be done is the 
following:

During initialize and during start any support module can add new 
choices. After a record instance has been started all alarm status 
fields will be set immutable. Since the pvAccess server will not allow 
client to connect to a record until after it is started then the 
pvAccess optimization can be used to limit the passing of strings.

Let me try again.

There is a need for a structure that defines a bitset structure in 
addition to the enumerated structure we have now in order to allow 
enabling of multiple statuses.
Let me come up with a proposed definition of a standard bitset structure 
and a proposed interface that support can call to set alarm severity 
choices and to raise alarms. Better to think about it overnight instead 
of making up something quickly.

In a separate message Andrew suggests that the severity also be a bitset 
instead of an enum.

Do we really want this?
Do we want the number of severity values to be extendable?

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? Sounds like some rules are required.

Marty

> Cheers,
> Ralph
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
>