Re: [Pvmanager-devel] alarm

[Benjamin F. <ben...@be...>]

On Mittwoch, 1. September 2010, Dalesio, Leo wrote:
> We are making an alarm system.
>
> What we have now:
> 1 alarm severity and the 1 alarm status that caused that severity.

And both have to be one of a *statically fixed* set of choices.

> What we want -
> something that gives more information than that.

I disagree. We need not more, merely more specific information.

A fixed set of choices for severity is good. When writing support for 
devices (whether at the device support level or, for more complex devices, 
at the database level) I never had any problem deciding which severity to 
assign to the several possible alarm states(*). In fact, I find the 
limitation to a small number of fixed choices actually helps, as it makes 
you think harder about what exactly the different alarm states mean for the 
user.

Things are quite different for alarm status. Fitting the alarm states of a 
device into the pre-defined set of choices always feels like forcing it 
into a straigh-jacket. It never feels like it fits right. Having more 
freedom here would be very valuable. The question is how much freedom we 
want. An arbitrary string value for the alarm status would be maximum 
freedom, but imposes no structure at all. Maybe we want to impose *some* 
structure. Ideally, I would want an enumeration type, but one I can define 
myself. I also want o define it at several different levels.

For instance, a driver or device support could define a set of choices for 
the alarm states of a certain ('atomic') device. However, such a device is 
often just a small part of some larger (logical) device, which one programs 
at the database level. In that case I want to be able to define my own set 
of choices for the alarm states of the complex device at the database 
level.

Cheers
Ben

(*) What is the plural of 'alarm status' (in English)?