Re: [foxboro] Alarm envrionments

I'm assuming in my suggestion that:

1) There is more than one source for the remote alarm manager (redundancy)
2) That external horns or lamps would be used to annunciate the alarms.
3) That both systems are in the same control room.


Regards,
 
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
alex.johnson@xxxxxxxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Kevin FitzGerrell
Sent: Tuesday, June 21, 2005 3:13 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Alarm envrionments

Jim,

I also have serious reservations about using setpars, for the reasons 
you've listed.  However, in this example, not changing the station 
workfiles is an advantage, rather than a drawback.  While setpars 
certainly has the potential to be dangerous, that's because it is a 
powerful tool, rather than inherently bad.  In this particular example, 
I think it's more appropriate than iccdrvr.tsk.

Alex's suggestion of using a remote AM is an excellent one, however it 
has a few drawbacks:
1) The local horn won't be sounded for high priority alarms.
2) If the alarms are being sent to the alternate unit because of work 
being done in the main unit which may cause the WP there to be down 
(tape backups, ups maintenance, whatever...) the remote alarm manager 
will be down as well.

I believe what we are talking about here is exactly dynamic alarm 
handling.  You're correct in noting it should not be done without 
careful design and considerations, but really that describes most of the 
  project work associated with the DCS.

Regards,

Kevin FitzGerrell
Senior Control Engineer
Kinleith Pulp & Paper
Carter Holt Harvey Ltd.
+64 27 460 9994

Pan, Jim wrote:
> I have some conservations in redirecting alarms, especially using
"setpars".
> 
> I am not in favor of using "setpars" for making online changes (any
> changes), it's too dangerous. Because it bypasses ICC so it's very easy to
> change non-settable parameters in a global scale and very quickly it's
going
> out of control. I would prefer to use 'iccdrvr' task and 'iccapi'
commands.
> 
> Secondly, once the alarms have been redirected, they may not be historized
> properly. Alarm redirection should be done with careful design and
> considerations. It is usually done as part of the advanced alarm
management
> process, sometimes we call it 'dynamic alarm handling'.
> 
> I think Alex's suggestion of using the remote AM to view the alarms from
the
> other Unit would be the best approach for pre version 8 systems.
> 
> Jim Pan
> Lifetime Learning
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
> Behalf Of Kevin FitzGerrell
> Sent: Monday, June 20, 2005 8:39 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Alarm envrionments
> 
> One other approach that hasn't been mentioned yet is to actually redirect
> the 
> alarms -- using a setpars (fast) or omsetimp (slower) script, or a
sequence 
> block (very slow) to change the alarm groups of the blocks with alarms 
> configured in Unit 1.  If this approach is used, consider having the
backup 
> group direct alarms to both Unit 1 and Unit 2 -- this preserves CAD and
AHD 
> for Unit 1 when alarms are redirected, ie Group 4 -> Unit 1, Group 8 ->
> Units 
> 1 & 2.
> 
> Advantages:
> * Alarms are redirected from Unit 1 to Unit 2 even if the Unit 1
workstation
> 
> 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,
> 
> but the return to normal is received on the other unit, gcio LED may not
> show 
> appropriately on one workstation, and alarm may have to be cleared from
one 
> 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 
> 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. 
>>
>>I'd like for the unit 2 operator to be able to "back up" the unit 1
>>operator
>>on handling alarms, Unit1 has an audible alarm that the unit 2 operator
>>can
>>hear.
>>
>>I was poking around in the alarm manager screens, and I found under
>>Display
>>-> Operations, that I can bring up a new window, that has "environments"
>>as
>>one of it's choices. Is there some way I can configure this so that the
>>WP's for unit2 can "switch environments" and see the unit1 alarms?
>>
>>
>>-- 
>>U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite
>>Vietcong Terror 
>>- New York Times 9/3/1967
>> 
>> 
>>______________________________________________________________________
>>_
>>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: http://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:             http://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:             http://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:             http://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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: