Re: [Pvmanager-devel] alarm

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

  I have read all the messages from Bob, Ralph, Andrew, and Benjamin.

I think I can safely say:   THERE IS NO CONSENSUS

There is no consensus on either severity or on status/message.

Andrew and Benjamin discussed how to share constant strings. Mainly on 
the server. Since this is primarily a pvAccess rather than a pvData or 
javaIOC issue I will leave this discussion for Matej. But again, as 
Ralph reminded me, Matej does have a scheme to "cache" immutable strings 
on the server.

Thus the following only discusses the definition of alarm.

I think we agree on the following:

<structure structureName = "alarm">
<?type? name = "severity" ?details? />
<-- either -->
<scalar name = "message" scalarType = "string" />
<!-- or -->
<?type? name = "status" ?details? />
</structure>

But what is ?type? and ?details?

For each, selecting one of the following four alternatives should 
satisfy must of what has appeared in the discussion.

1) <scalar name = "xxx" scalarType = "int" />

This is basically what V3 does. In this case an interface (for V3 
alarm.h) is provided that allow the int value to be treated like an 
enum, i.e. a fixed set of strings are defined.

2) <scalar name = "xxx" scalarType = "string" />

A string value is passed.

3) <structure name = "xxx" extends = "enumerated" />

An enumerated structure is passed where an enumerated structure is 
defined as:

<structure structureName = "enumerated" >
<scalar name = "index" scalarType = "int" />
<array name = "choices" scalarType = "string" />
</structure>

This an array of string choices is provided and a index selects one of 
the choices.

4) <structure name = "xxx" extends = "multiChoice" />

A multiChoice array is passed where a multiChoice structure is defined as:

<structure structureName = "multiChoice">
<array name = "bitMask" scalarType = "byte" />
<array name = "choices" scalarType = "string" />
</structure>

An interface is provided that makes it easy to access a multiChoice array.

This allows a set of the string choices to be specified. If the array of 
choices is declared immutable then it is a fixed set of strings.


I claim that selecting one of four choices could implement everything 
that was said in the discussion.


Now lets consider severity and status/message separately.

First severity:

1) <scalar name = "severity" scalarType = "int" />

Again this is what V3 uses. If this is chosen than an interface will be 
provided that allows the int to be interpreted as an enum.

Consider uses:

Synoptic display widgets:  Can directly use the int for color coding. 
Use the interface to get associated string value.
Archiver:   Use the interface to get associated string value.

This has the advantage of very low overhead. String values are 
automatically shared via the interface.

2) <scalar name = "severity" scalarType = "string" />

Advantage is that archiver and other clients do not do have to know 
about a separate interface for getting the string value. To do things 
like color coding an interface could be provided.

Since, without a helper interface, it does not satisfy even common uses 
it offers no real advantage over 1) and requires passing strings.

3) <structure structureName = "alarmSeverity" extends = "enumerated" >
<array name = "choices"  immutable = "true" >
            [none,minor,major,invalid]</array>
</structure>

OR
<structure structureName = "alarmSeverity" extends = "enumerated" >
<array name = "choices"  immutable = "true" >
            [none,minor,major,invalid,unknown]</array>
</structure>

Note that Ralph is advocating the extra choice "unknown". Andrew makes 
the case that it is not needed.

and in alarm definition
<structure name = "alarmSeverity" extends = "alarmSeverity" />

This allows a single choice. Since the choices are immutable the choice 
strings can be shared.


But why is this better than 1) with an associated interface to allow the 
int value to be treated as an enum?

4) <structure structureName = "alarmSeverity" extends = "multiChoice" >
<array name = "choices"  immutable = "true" >
            [none,minor,major,invalid]</array>
</structure>

OR
<structure structureName = "alarmSeverity" extends = "multiChoice" >
<array name = "choices"  immutable = "true" >
            [none,minor,major,invalid,unknown]</array>
</structure>

and in alarm definition
<structure name = "alarmSeverity" extends = "alarmSeverity" />


Andrew is advocating that this be chosen or that somehow multiple alarms 
can be reported together rather than just maximize severity.

But this certainly makes things more complicated for user code for both 
color coding and string values.

Also with regards to multiple alarms from a single record. This sounds 
like it is to be used for diagnostic purposes. For on-line diagnosis, 
with the swtshell the entire record can be displayed, which will show 
every alarm field. Thus if a record goes into alarm and you want to find 
out more just display the record.


Now for the hard part:  status (or message)

1) <scalar name = "status" scalarType = "int" />

Again this is what V3 uses. If this is chosen than an interface will be 
provided that allows the int to be interpreted as an enum. Like V3 it 
means a fixed set of status values. Since no one is advocating this it 
will not be discussed further.

2) <scalar name = "message" scalarType = "string" />

This is what I am advocating. Andrew also gave some arguments for it. It 
allows meaningful  messages to be generated.

Bob and Ralph think this is not the correct solution.
Bob uses examples like:

 From the PLC
Open circuit detect
Over range
Perhaps out of software range
violates interlock limit

 From the driver
No communication
No connection for this tag (point)
Loop time limit violated

But How are these messages obtained?

Consider the PLC. The device support somehow sends a command to and gets 
a response from the PLC. There is some serial or network protocol used 
for the communication. Any decent protocol allows the PLC to send error 
and/or warning messages. The device support usually does nothing with 
the messages except use them to raise alarms. If the device support can 
just issue an alarm message then it can set a string like:

     PLCSector1Rack3 warning Perhaps out of software range.

Note that the device support does NOT know about "Perhaps out of 
software range." until the PLC sends it.

Ralph makes the argument:

>
> I agree there will be devices that need complex and maybe run-time
> changing sets of error strings, but I would think these will be few.
>
> Is there a way to treat these special devices special, and still have
> the efficient implementation for the 98% regular devices with a fixed
> set of status strings?
For such devices create a  multiChoice structure as a field separate 
from the alarm field.
Why complicate what 98% of device support must do.

Note that an archiver could be configured to monitor this field as well 
as the value and alarm.

3) <structure structureName = "alarmStatus" extends = "enumerated" >
     ....

This again just allows a single choice from a set of choice strings. If 
they are immutable than pvAccess could share them. It is like V3 except 
that each record could have a different set of choices.

4) <structure name = "alarmStatus" extends = "multiChoice" />

This could be done so that the choices are different for each record or 
chosen from some small set of different choices.

This is what Bob and I think Ralph are advocating. If for each record 
instance the set of choices are immutable than it will satisfy 
pvManager, i.e. the method:

List<String> getPossibleAlarms();

But this really puts a real burden on support code like device support. 
The support must know during initialization all possible status 
messages. From the PLC example above this is not really possible.


Thus I still advocate:

<structure structureName = "alarm">
<scalar name = "severity" scalarType = "int" />
<scalar name = "message" scalarType = "string" />
</structure>


And an interface that allows severity to be treated as an enum.

Marty