Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Wed, 5 Mar 2014 16:53:41 -0500

Hi:

Just like the alarm filters, I think this would be a good example for logic that is best put on the IOCs.
The same PVs that are used as alarm triggers should also be usable for operator interfaces.
If it shows as an alarm on the operator screen, and its used as an alarm trigger, it would generate the alarm.
Of course there are many cases where you want to suppress the alarm:
Device is not supposed to be on because machine is in a mode where the device should be off, so what would normally be an alarm is now the expected state, …

Putting that logic for when to enable or disable an alarm onto the IOC has several advantages:
The alarm state that you see on an operator screen always matches the alarm state displayed by the alarm system.
The logic for enabling/disabling the alarm can be as complicated as it needs to be: calc records, subroutine records, sequences, …
The person who implements the IOC logic for handling the device is probably most knowledgable about how to create a good alarm trigger implementation, so it's "in one hand".

Mind you, this is a BIG issue to solve.
Creating a good alarm trigger rarely just means: Set BI.ZSV or AI.HIHI and AI.HHSV.
You need to consider:
Should the alarm threshold (HIHI) change based on machine mode?
Is there a way to de-bounce the reading to avoid "ringing" of the alarm?
Are there a machine modes where the alarm should be disabled?
Could another PV, as a consequence of this alarm, also go into alarm at the same time? Can we somehow turn this into just one alarm, instead of sending multiple alarms to the operator, all for the same underlying reason? 
..

Ideally, each alarm starts out with a discussion between the subsystem expert who understands the system, the IOC person who implements the logic, an operator who needs to understand the alarm and the required actions. Then you add the IOC logic to properly turn the "raw inputs" into a good alarm trigger PV.

Thanks,
Kay

On Mar 4, 2014, at 10:39 PM, [email protected] wrote:
> We are currently using BEAST. There is the ability to put alarm system in Maintenance mode. But it puts the whole entire system in Maintenance mode. We would like to be able to put an Area or a System in maintenance mode. 
> 
> I’m wondering if there is any plan to implement such feature. Or would anyone else find this feature useful?
> 
> We have started investigating this implementation. Essentially the ENABLED_IND database field should be move to ALARM_TREE table from PV table, and isEnable() should be a base class method. 
> 
> Thanks,
> 
> Xinyu WU
> ASKAP Computing                       
> Australia Telescope National Facility 
> CSIRO Astronomy and Space Science
> phone: +61 2 9372 4727
> postal: PO Box 76 Epping, NSW. 1710
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System