Experimental Physics and
Industrial Control System

Elder Matias <[email protected]> · Thu, 6 Mar 2014 18:46:24 +0000

You should have every alarm in the system that you want the operator to do something with and some guidance to the operator on what they are expected to do about the alarm.  If because of the operating mode it is not something that is relevant the you should supress it.

What I have found in the past, if when the guidance to the operator is to look at an EDM screen it usually means you don't know what should be happening and you need to put some more thought into what the correct action should be and what the alarm means.

I am a strong believer in the concept of "If its not actionable by the operator, then it does not belong in the alarm handler."

A good comparison would be the following two sets of guidance:
   "One of two hundred temperatures is high, look at EDM screen xxxx"
vrs.
  "Absorber ABS1021-01 on straight xx water temperature is high.  Target 20 C, warning at 40 C and machine trip at 60 C.   Request maintenance to blow line and verify adequate flow to absorber".

Elder

Elder Matias, BSc,
CEO  T: 250.386.9398 x203 | [email protected]
MIGHTY OAKS  Business ~ IT ~ Community  27 Burnside Road West Victoria | TF: 866.386.9398 | www.mightyoaks.com

---------------
Date: Thu, 06 Mar 2014 08:49:47 -0800
From: Rolf Keitel <[email protected]>
To: tech_talk <[email protected]>
Subject: Re: CSS BEAST alarm hierarchy
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

I have some problems with these approaches (although I may be missing something, I haven't looked at beast for a while):

With Kay's approach I see the danger of introducing an obfuscation layer in the IOCs which separates the alarm logs from the alarm sources.
Operator screens will not show transient alarm conditions.
Igor's solution introduces another layer of complexity which we don't need on our machines.

I would like to have an alarm solution which involves only the alarm handler and the IOCs. I would like to have the option to define with each alarm group a PV which can be used to disable that group. This PV could be under operator control (for disabling alarms for section
maintenance) or controlled by IOC logic of arbitrary complexity.

- rolf -

On 3/6/2014 6:39 AM, Kasemir, Kay wrote:
> Hi:
>
> Conceptually, I think that is exactly the right approach.
>
> It's usually wrong to simply add 100 raw "temperature" PVs as alarms. It's better to have an operator display that shows these alarms, with summary PVs for sections of the machine, options to disable them, and those summary PVs are then used as alarm triggers.
>
> For the displays, we already have good tools: EDM, BOY, ? editors where you can create displays that suit the purpose.
>
> For the logic, we have CALC records, which have limitations for their number of input links, length of the formula, and also nothing in there that is specific to alarms.
> So often you end up with one "formula" that has to be split into several calc records.
> Or you put the SEVR of other records into the INPx fields because you really want to summarize based on the raw alarm states, not the raw values.
>
> Do you have a web link, paper, ? on your intermediate layer?
> Maybe it would also be worthwhile to create a new "alarm calc" record that has many inputs plus formulas that are aware of not just an INPuts value but its alarm severity?
>
> Thanks,
> Kay
>
>
> On Mar 6, 2014, at 9:26 AM, Igor Kriznar <[email protected]> wrote:
>> Hi,
>>
>> at ANKA we have implemented filtering, which filters alarms regarding
>> the operation mode. When machine is in shutdown or maintenance, most
>> of alarms are suppressed, before they reach CSS BEAST.
>>
>> All our alarms are feed into our intermediate alarm server, which
>> decided if they should go further to BEAST or be suppressed or be
>> somehow otherwise processed. For example have summary alarm PV, which
>> sums alarms from whole subtree.
>> Our intermediate alarm server is based on JCA and looks like bunch of
>> plain PV channels which are used by BEAST. No changes were made to
>> BEAST, everything is in configuration.
>>
>> Enable feature of BEAST I see more like permanent switch, if you want
>> to disable misbehaving alarm source.
>>
>> Hope this helps,
>>
>> Igor
>>
>>
>> On 05.03.2014 04:39, [email protected] wrote:
>>> Hi
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>

--
+-------------------------------------------------------+
| Rolf Keitel, Ph.D.                Tel: (604) 222-7453 |
| TRIUMF                                                |
| Vancouver, B.C., Canada                               |
+-------------------------------------------------------+

________________________________

This e-mail is intended only for the person to whom it is addressed (the "addressee") and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use that a person other than the addressee makes of this communication is prohibited and any reliance or decisions made based on it, are the responsibility of such person. We accept no responsibility for any loss or damages suffered by any person other than the addressee as a result of decisions made or actions taken based on this communication or otherwise. If you received this in error, please contact the sender and destroy all copies of this e-mail.

Ce courrier est strictement reservé a l'usage de la personne a qui il est adressé (le destinataire). Il peut contenir de l'information privilégiée et confidentielle. L'examen, la réexpédition et la diffusion de ce message par une personne autre que son destinataire est interdite. Nous refusons toute responsabilité a l'égard des pertes ou des dommages subis par une personne autre que le destinataire par suite de decisions ou de mesures fondées sur le contenu de cette communication ou autrement. Si vous avez recu ce courrier par erreur, veuillez communiquer avec son expéditeur et en détruire toutes les copies.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System