Re: [Pvmanager-devel] alarm

[Ralph L. <Ral...@be...>]

  On 31.08.2010 13:28, Andrew Johnson wrote:
> On Tuesday 31 August 2010 11:29:57 Ralph Lange wrote:
>> One more point for UNDEFINED: the Gateway.
>> If an IOC goes away, all direct clients would lose connection and thus
>> change the severity to UNDEFINED.
>> A client behind a Gateway does not lose the connection, but the Gateway
>> would simply forward the UNDEFINED severity, and thus act transparently.
> It is a mistake to confuse the meta-data about the state of the connection
> with the alarm severity from the device.  If a record is allowed to put itself
> in UNDEFINED severity (because its serial connection to the PLC is dead say)

I think UNDEFINED was just meant for CA connections.

Note that the pvManager classes (that all this originates from) are 
meant to be the *client* interface. So the additional severity merged 
the connection status for ease of use. I don't  think UNDEFINED was ever 
meant to be used on the server.
(Again: existing real world applications like the alarm handler are 
adding this severity level, so we might see this as a hint that it is a) 
needed,  and b) a resonable approach for a simplified handling of the 
connection status.)

>   a
> client connected through a Gateway would have no way to distinguish between
> the IOC being down and the PLC's serial cable having been cut.
>
> I think the Gateway needs a way to pass on its 'disconnected' status to the
> client (but without triggering another search), which should cause the
> connection callback to be run just as if the client were not using a Gateway
> at all.  I don't think you can use the alarm severity of the channel for
> reporting the connection status since the client may not even be monitoring
> channel alarms.

True. And - as stated above - if UNDEFINED is not used on the server, 
there's even no way to use it.

So behavior (direct and Gateway) would be: if the immediate CA 
connection (client or through Gateway) breaks down, the channel is 
disconnected (connection callbacks being called). For V3 there is no way 
to stop the client from searching for a disconnected channel, and I 
don't know if this would make sense.
If a lower connection (serial link to PLC or CA link between IOCs) is 
down, the record is INVALID with "link error" (or hopefully something 
more specific in V4).

>> "Maximize severity" is a well-established and widely used concept in
>> EPICS 3.
>> Moving that to the client will not work. In that case every client would
>> have to know that a certain calc record is combining redundant signals
>> and another one is a controller - that would replicate that information
>> and allow for greatly inconsistent views of the system.
>> How will a generic application (panel/alarm color mode) show a value
>> that has (NO_ALARM&  MINOR&  MAJOR&  INVALID)?
> A generic application that can only display one severity (or a V3 one through
> a Gateway) would use the maximum severity bit reported, in your case INVALID
> (NO_ALARM is not a bit, it's defined as the value zero, meaning the complete
> absence of any set bits).  However a more capable application might show that
> the record is currently reporting MINOR, MAJOR and INVALID alarms.

Nah...
In that case you would have a bitset that shows the severities, and 
another bitset that shows the set of status messages, but no clue which 
status caused which severity.
If you really want to implement something that complex, do it correctly: 
every status should has a severity enum connected to it. The more 
capable client can then create the severity set of the record by ORing 
the severities of the active status set.

And have the record's severity still be one enum value (defaulting to 
the highest severity of the active status set).

~Ralph