Re: [foxboro] Change Process Button Status

  • From: "McQuaid, Paul" <paul.mcquaid@xxxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 10 Jun 2013 11:58:40 -0500

I had a similar discussion in a customer training course I was running 
recently, the solution agreed as best, by the class, was as Brad previously 
suggested point priority 1-3 alarms at the CAD on a workstation and the 
historian and point 4-5 alarms to a group with only the historian that way ONLY 
alarms appear at the CAD but all alarms (1-3) and events (4-5) appear in the 
Alarm history display, which can be open at the same time as, and called from, 
the CAD.

After all priority 4 -5 alarms will, by default that is, appear at the bottom 
of the CAD list and have to be scrolled down to see anyway assuming you have 
more than 10 (by default) priority 1-3 alarms active?

To my class it was a more than acceptable solution, although there are some 
assumptions there e.g. all alarms are sent to the historian which is assumed to 
be accessible by the Historian display, so I do realise this is not a "one size 
fits all" solution before anyone comes back :-)........

Best Regards

Paul McQuaid
Snr Technical Instructor
Invensys Systems (UK) Ltd

Mob:+44(0)7776 245320

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Neil Martin
Sent: 10 June 2013 15:56
To: foxboro@xxxxxxxxxxxxx
Cc: foxboro@xxxxxxxxxxxxx; foxboro-bounce@xxxxxxxxxxxxx
Subject: Re: [foxboro] Change Process Button Status

Many users want to be able to send all the priority 1-5 notification and alarm 
messages to the CAD so that there is a way for the operators to be able to see 
all of the messages that are routed to the workstation, but be able to 
configure which priority ranges cause the PROCESS button to blink red.  CADs 
can be set to filter and show only certain priorities (like 1-3 which we 
considered to be the actual alarms), but we have no way to control which 
priorities make the PROCESS button blink red.  Currently the PROCESS button 
will blink red anytime a new notification or alarm message is received.

Conroe & Dayton , TX. 
Conroe ph) 936-760-6205
Dayton ph)  936-257-4212
pager) 936-522-0052



"Wilson, Brad" <brad.wilson@xxxxxxxxxxxx> Sent by: foxboro-bounce@xxxxxxxxxxxxx
06/10/2013 09:30 AM
Please respond to
foxboro@xxxxxxxxxxxxx


To
"foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
cc

Subject
Re: [foxboro] Change Process Button Status






If you want to utilize priority 4-5 but not have them go to CAD, just send 
them to a group that doesn't include the workstation.
The group can still include historian or printer, but the Process button 
won't flash.

Brad Wilson
Invensys Operations Management

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Boulay, Russ
Sent: Friday, June 07, 2013 9:32 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Change Process Button Status

Well stated.....

As to the original question:
If a user chooses to send an alarm to workstation for CAD alarming....the 
Process key will always act the same no matter what the priority.
There is no coloring or priority of alarms associated with the Process 
button.

If a user wishes to have additional evaluation of alarms performed before 
delivery to the CAD....then they would implement Message Manager.....where 
alarms can be prioritized for delivery during alarm storms and even 
execute programs based on alarms....among other options

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Lowell, Timothy
Sent: Friday, June 07, 2013 6:14 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Change Process Button Status

It sounds like you are talking about "alarm management". Like "network 
security", you are opening up a huge and expensive can of worms.

Alarm management is an operations problem, not a control systems problem. 
Operations needs to lead it. As control systems engineers, we can guide 
them and show them what is possible and then actually implement the 
changes, but Operations has to be the owner of the process. They need to 
identify what alarms are actionable, and how much time they need to react 
to the alarm and how severe it is, which sets the priority. This requires 
many, many hours of combing through the Master Alarm Database and 
eliminating the unnecessary alarms and/or re-prioritizing the ones that 
are needed. That's one reason why it's expensive, since you normally have 
to pay those Operations guys overtime. Another reason for the expense is 
that you also need to analyze the alarms you are getting first, to know 
which are the ones causing the most problems so that your alarm 
rationalization process can go more quickly. For the alarm analysis, 
Invensys gives you no inherent tools, so you need to buy somethin
 g from PAS, TiPS, Matrikon, Limeware, etc. to do the analysis. A third 
reason for the expense is that the things you find in alarm analysis are 
often chronic instrument problems, which usually aren't cheap to fix.

Then, after you do the alarm analysis and rationalization, and implement 
the instrument fixes and system changes, you need to keep doing it, at 
least on a monthly basis, which means the expense is ongoing (more work 
orders, overtime, and software maintenance agreement fees).

To answer your original question, I know of no quick software fix to limit 
the Process button to one set of priorities.

Tim


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of ivancvieira@xxxxxxxxxxxxxxxx
Sent: Friday, June 07, 2013 7:43 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Change Process Button Status

Content-Transfer-Encoding: quoted-printable
Content-type: text/plain; charset=ISO-8859-1

You are right, Martin. I mean the big red 'Process' button. We have a lot 
of alarms level 3, 4 and 5 and the process button never turn green.

Kind Regards,

IVAN DA COSTA VIEIRA
Eng=BA de Equipamentos - Eletr=F4nica
PETROBRAS
Usina Termel=E9trica Euz=E9bio Rocha



De:              martin.theobald@xxxxxxxxx
Para:            foxboro@xxxxxxxxxxxxx
Data:            07/06/2013 09:25
Assunto:                 Re: [foxboro] Change Process Button Status
Enviado por:             foxboro-bounce@xxxxxxxxxxxxx



I might be wrong but I think Ivan means the big red 'Process' button in 
the top left of the FoxView window that is usually used to call up the 
current alarm display (CAD).
Regards,

Martin Theobald



From:   "Andika, Ferdi" <ferdi.andika@xxxxxxxxxxxx>
To:     "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>,
Date:   07/06/2013 04:08
Subject:        Re: [foxboro] Change Process Button Status
Sent by:        foxboro-bounce@xxxxxxxxxxxxx



Yes, you can. Choose bit state instead of discrete on dynamic update.
You can use .ALMSTA parameter in certain blocks (which have alarm in them 
like CIN, AIN, etc). Then specify the priority.

Regards,

Ferdi Andika
Project Application Engineer
PT Invensys Indonesia

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of ivancvieira@xxxxxxxxxxxxxxxx
Sent: Thursday, June 06, 2013 11:54 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Change Process Button Status


Dear list,

It's possible to change the Foxview Process Button status to only blink or 
turn red when a high priority alarm (like level 1 or 2) be active??

Kind Regards,

IVAN DA COSTA VIEIRA
Eng=BA de Equipamentos - Eletr=F4nica
PETROBRAS
Usina Termel=E9trica Euz=E9bio Rocha
"O emitente desta mensagem =E9 respons=E1vel por seu conte=FAdo e 
endere=E7= amento.
Cabe ao destinat=E1rio cuidar quanto ao tratamento adequado. Sem a devida 
autoriza=E7=E3o, a divulga=E7=E3o, a reprodu=E7=E3o, a distribui=E7=E3o ou 
= qualquer outra a=E7=E3o em desconformidade com as normas internas do 
Sistema Petrobras s= =E3o proibidas e pass=EDveis de san=E7=E3o 
disciplinar, c=EDvel e criminal."






 




 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please select the Legal Entities link at invensys.com.


You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
reception@xxxxxxxxxxxx. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: