[labnetwork] Question: use of gas alarm logic to prevent building evacuations on silane bottle changes...

[Hughes, John S]

Hello Ian,

At our facility we are able to disable the alarm "announcements" that would give audible and visual calls for evacuation of the building. The University's Public Safety group still receives all the actual alarm signals, but we let them know ahead of time that we are doing maintenance and that they should not respond (with the fire trucks, etc.) unless they receive confirmation from us that there actually is a problem. Then, of course, the work has to be very carefully monitored so that, in the case of real need, the alarms are immediately reactivated and an appropriate response is provided by Public Safety.

Public Safety is in direct contact with us whenever we do this, so we do not feel that response time will be appreciably slowed in case something unforeseen actually dose go wrong. Also, because there are literally dozens and dozens of various monitors and sensors, if any alarms are tripped other than the ones we let them know we expect to be affected, they would immediately proceed with their normal alarm response, whether or not they heard from us.

 -- John

-------------------------------------------------------------
John S. Hughes                         Office: (217) 333-4674
Associate Director                        FAX: (217) 244-6375
Laboratory Operations                     hughes at illinois.edu<mailto:hughes at illinois.edu>
Micro and Nanotechnology Laboratory
University of Illinois at Urbana-Champaign
3114 Micro and Nanotechnology Laboratory
208 North Wright Street
Urbana, Illinois  61801              http://mntl.illinois.edu
-------------------------------------------------------------

On May 5, 2011, at 7:44 PM, Ian Harvey wrote:

Dear Labnetwork,

Question:
How to prevent spurious gas/silane alarms (e.g., from cylinder change burps) from unnecessarily evacuating an entire building?

Background:
We recently had a very brief burst/decay of silane associated with the removal of the dust cap in preparation for installing a new silane cylinder. The burst was captured by our gas alarm as a single "spike" that exceeded the level-2 alarm threshold (10 PPM) for 3 seconds and decayed back to below level 1 (5 PPM) after 12 seconds (peak was 19 PPM).  However, the fire alarm was triggered, the entire engineering building was evacuated for 20 minutes, and six fire trucks showed up.

This cylinder was 13 months old, 1 month past its expiration date.  The cylinder was chained and strapped into position inside the gas cabinet when the dust cap was removed.  At present, we feel it is best to evacuate the building, since our old lab is in a B-class occupancy area.  However, in our new facility, our silane will be behind a 2 hr firewall in a special gas room, attached to the single-story fab wing and 50 yards from (but still attached to) the multi-story research tower.  We are looking for more robust system-level solutions limiting unnecessary evacuation of the research tower in our new facility.

Approaches: Aside from procedural approaches like "Don't use expired cylinders", and "Open dust caps very slowly", has anyone attempted to use alarm logic in their HPM system, such as: "<<If>> the alarm originates in the gas box <<and>> room air sensor is below threshold...  or variations on timing between sense and decay to stage the triggering of different alarm levels??

How do others handle this situation in your respective labs?

Thank you in advance for your inputs!

--Ian

********************************************
Ian R. Harvey, Ph.D.
Associate Director, Utah nanofab
College of Engineering / University of Utah

Research Associate Professor
Department of Mechanical Engineering
Adjunct Associate Professor
Department of Electrical & Computer Engineering
2232 MEB

mail to suite 2110 MEB, 50 S. Central Campus Drive
Salt Lake City, Utah   84112-9011
801/585-6162 (voicemail)
801/581-5676 (lab main number)
www.nanofab.utah.edu<http://www.nanofab.utah.edu/>

_______________________________________________
labnetwork mailing list
labnetwork at mtl.mit.edu<mailto:labnetwork at mtl.mit.edu>
https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mtl.mit.edu/pipermail/labnetwork/attachments/20110506/9f5431be/attachment.html>