Re: [Pvmanager-devel] alarm

[Dalesio, L. <da...@bn...>]

The idea of the metadata is that it provides all of the data needed to treat the thing being sent in a uniform and complete way.

Do we want to archive alarm status? I would think that a useful alarm status is near as important as the alarm severity.

In an alarm manager - this is more true. The status is as much a part of the alarm as the alarm severity.

In other instances, like display or multi-channel arrays, I can't make a compelling argument.
So how do you get the alarm severity without the alarm status.

I would say that severity is a critical component and value. 

Along your line of argument -
value, time stamp, alarm severity - is what I want most of the time.
if I also want alarm status - then asking for the alarm status information seems like an improvement over V3.


--
>From that perspective it seems that alarm severity either belongs to base characteristics and alarm characteristics or base characteristics only. Base characteristics include time stamp, alarm severity. Alarm characteristics include alarm statuses only.



----------------------------
The second part of the argument is stringEnum - or message.
The only benefit message has over strinENum is that it can be an arbitrary string.
For me, that is a logMsg utility - not an alarm system.
----------------------------


-----Original Message-----
From: Marty Kraimer [mailto:mrk...@co...]
Sent: Tue 9/7/2010 6:57 AM
To: pvm...@li...; epi...@li...
Subject: Re: [Pvmanager-devel] alarm
 
  On 09/03/2010 06:59 AM, Dalesio, Leo wrote:
>
> I am attaching a couple of slides that attempt to describe what is 
> being proposed (and I thought we had agreed to) at the meeting we had 
> at BNL.
> It changes the alarm status to a bitset. Multiple alarm statuses are 
> true at the same time - which reflects real life.
>

I agree that being able to expose device status info to CA clients is a 
desirable goal. Where I have a problem is making it a required component 
of alarm.

This is a generic issue: Should of set of components be presented as a 
single object or as a set of objects. For a client this means presented 
as a single interface or as a set of interfaces.

The following are three example of where this issue has been the basis 
of heated arguments.

1) The javaIOC allows each field to have optional support. For example 
the scan field has scan support. An input field can have any of a large 
set of supports attached. In fact an input field could have 
linearConvert support attached and have a subfield named input that can 
again have any of a large set  of different supports to get a raw value. 
A valueAlarm field can have valueAlarm support attached. And so on an so 
on. The issue is how to construct a database record. One way is the V3 
way, which means that a set of basic record types, with each type having 
a fixed set of fields. Thus record types ai, ao, bi, bo, mbbi, etc. 
Another way is to construct a record based on what it does. As an 
example a record template can be created based on: 1) the specific 
device, 2) the communication bus, 3) valueLimits if they make sense, etc.

2) pvManager data, i.e. value, timeStamp, alarm, and display. How should 
this be presented to the client? One way is a fixed set of interfaces 
like DoubleTimeStampAlarmDisplay or as a set of interfaces like 
Double,TimeStamp,Alarm,Display.

3) Alarm. This is the issues currently being addressed. Assume there are 
three components severity, message, and deviceStatus. I know this is has 
not been agreed upon as the three components but it is details. The 
issue is how is the presented to a client: As a single interface named 
alarm that has all three components or as multiple interfaces. Thus this 
is really 2) appearing at a different level.

I am going to start another thread giving arguments why I think a set of 
objects is much better than a single object. The thread will concentrate 
on 2) but the same arguments can be made about 1).