Re: [Pvmanager-devel] alarm

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

  On 01.09.2010 13:14, Marty Kraimer wrote:
> On 09/01/2010 10:39 AM, 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.
>>
>> Proposal 2
>> send strings
>> - argument - any device  may send any random string
>> - counter argument - any random strings should be handled as an error 
>> log, not as an alarm system. Alarms are well defined conditions that 
>> have been designed into the system that we may want to react to. Any 
>> error string (it would be helpful to have a use case here), is not a 
>> known condition that we can configure any reasonable response to. 
>> Putting in this mechanism will take care of some small case that we 
>> have not identified at the cost of giving useful structure that can 
>> be handled in a well defined way at the client side. We could send 
>> self describing alarms too - and that would handle anything that may 
>> occur - but it does not make for well behaved client development
>
> Let me make an argument for why the message should be part of the 
> alarm rather than going to the error logger:
>
> Lets say the message is
> PLCSector1Rack3Slot2 error Off Line
>
> If instead the status is something like READ_ALARM and the message 
> goes to the error log file then consider:

We are talking about a string enum here, not a classical enum.
The device support for the PLC knows all possible messages beforehand 
and adds them to the status string enum.
As the record name will adhere to a naming convention, it will contain 
the PLC and the signal information.

With the string enum choice being "error Off Line", a client that shows 
"<record name> <status string>" will show:

PLCSector1Rack3Slot2 error Off Line

which is exactly what you want.


Andrew's argument is that he is expecting devices, where the set of 
possible status strings is not limited or not known beforehand.
If such a device would send a string like "value 12.76545 exceeds the 
limit of 10.0", it could not be expressed as a status string enum choice.

I would expect the device support in such cases to parse the message and 
map the status to one of the known set, while Andrew wants to send the 
string over the wire and push parsing the message to the client.

Ralph