Re: [foxboro] Alarm envrionments
- From: Kevin FitzGerrell <fitzgerrell@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 21 Jun 2005 14:50:49 +1200 (NZST)
Alan,
I've used a couple of approaches.
I do normally assign an alarm group for historian only.
Although alarm group is not connectable, alarm priority is, so alarm priority
can be reduced (or raised) for whole groups of alarms if desired.
CAD filters can be used to keep low priority alarms off the display during
periods of significant upset.
While you're right about sequence logic, setpars and omsetimp being more
difficult to trace than block connections, it's not that much different than
working with graphics which can affect blocks in much the same manner. I feel
the key is making it obvious on the operator graphics that special conditions
are in place -- ie, if alarms are redirected using a setpars script, one
function of the script should be to set a CIN that shows a warning on operator
displays that alarms are redirected.
I also use off-line HTML documentation that's auto-updated weekly to keep
track of cross references between control logic, historian, graphics, etc...
I'm starting to include scripts, INI15 links, and sequence logic (where full
object names are used) in that documentation.
Regards,
Kevin FitzGerrell
Senior Control Engineer
Kinleith Pulp & Paper
Carter Holt Harvey Ltd.
+64 27 460 9994
Quoting "Armour, Alan" <aarmour@xxxxxxxxxxxxx>:
> Kevin, you have just highlighted an issue I have with all alarm blocks.
> All the paramaters for Alarm Groups are non setable and non
> connectable.
> I want to be able to redirect some alarms away from the operator during
> abnormal situations (alarm storms). There are many alarms which the
> operator is not interested in at the time, but provide useful
> information in the post event analysis. Some can be just inhibited via
> INHALM if they are recorded in historian (PI)but many are not.The
> alternative is to set up a special alarm group with only alarm history
> in it. I have resisted techniques like setpars and sequence blocks
> because it is harder for people to see when they are activated.
> Regards,
> Alan Armour =20
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Kevin FitzGerrell
> Sent: Tuesday, 21 June 2005 11:39 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Alarm envrionments
>
>
> One other approach that hasn't been mentioned yet is to actually
> redirect the=20
> alarms -- using a setpars (fast) or omsetimp (slower) script, or a
> sequence=20
> block (very slow) to change the alarm groups of the blocks with
> alarms=20
> configured in Unit 1. If this approach is used, consider having the
> backup=20
> group direct alarms to both Unit 1 and Unit 2 -- this preserves CAD and
> AHD=20
> for Unit 1 when alarms are redirected, ie Group 4 -> Unit 1, Group 8 ->
> Units=20
> 1 & 2.
>
> Advantages:
> * Alarms are redirected from Unit 1 to Unit 2 even if the Unit 1
> workstation=20
> is down.
> * Alarms from Unit 1 do not affect Unit 2's CAD and AHD when not
> redirected.
> * Can be done from either Unit 1 or Unit 2 workstation.
>
> Disadvantages:
> * Transition period issues, ie - if an alarm is received on one
> workstation,=20
> but the return to normal is received on the other unit, gcio LED may
> not
> show=20
> appropriately on one workstation, and alarm may have to be cleared from
> one=20
> CAD, rather than just acknowledged.
> * Because alarm groups are settable, if an upload is done while alarms
> are re- directed, the alarm groups in the station work files will be
> changed.
> * Script or program needs to be updated when new alarms are configured
> in Unit=20
> 1.
>
> Regards,
>
> Kevin FitzGerrell
> Senior Control Engineer
> Kinleith Pulp & Paper
> Carter Holt Harvey Ltd.
> +64 27 460 9994
>
> Quoting stan <stanb@xxxxxxxxx>:
>
> > We have a single node that serves as the control system for 2
> "units".
>
> > At present we have the alarms for, say, unit 1, directed to on WP,
> and
>
> > the alarms for say, unit 2, directed to 2 other WP's.
> >=20
> > I'd like for the unit 2 operator to be able to "back up" the unit
> 1=20
> > operator on handling alarms, Unit1 has an audible alarm that the
> unit=20
> > 2 operator can
> > hear.
> >=20
> > I was poking around in the alarm manager screens, and I found
> under=20
> > Display
> > -> Operations, that I can bring up a new window, that has=20
> > -> "environments"
> > as
> > one of it's choices. Is there some way I can configure this so
> that=20
> > the WP's for unit2 can "switch environments" and see the unit1
> alarms?
> >=20
> >=20
> > --
> > U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite
> > Vietcong Terror=20
> > - New York Times 9/3/1967
> > =20
> > =20
> >
> ______________________________________________________________________
> > _
> > This mailing list is neither sponsored nor endorsed by Invensys=20
> > Process Systems (formerly The Foxboro Company). Use the info you=20
> > obtain here at your own risks. Read=20
> > http://www.thecassandraproject.org/disclaimer.html
> > =20
> > foxboro mailing list: //www.freelists.org/list/foxboro
> > to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> > to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> > =20
> > =20
>
> =20
> =20
> _______________________________________________________
> ________________
> 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
> =20
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
> DISCLAIMER
>
> The contents of this electronic message and any attachments are intended
> only
> for the addressee and may contain legally privileged, personal,
> sensitive or
> confidential information. If you are not the intended addressee, and
> have
> received this email, any transmission, distribution, downloading,
> printing or
> photocopying of the contents of this message or attachments is strictly
> prohibited. Any legal privilege or confidentiality attached to this
> message and
> attachments is not waived, lost or destroyed by reason of delivery to
> any
> person other than intended addressee. If you have received this message
> and
> are not the intended addressee you should notify the sender by return
> email and
> destroy all copies of the message and any attachments. Unless expressly
> attributed, the views expressed in this email do not necessarily
> represent the
> views of the company.
>
>
> ______________________________________________________________________
> _
> 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
>
>
_______________________________________________________________________
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:
