Risk analysis and mass notification

In the fire alarm community, there has been a lot of discussion about mass notification. The incorporation of mass notification systems (MNS) in buildings first got attention after the Dept. of Defense (DoD) began requiring the installation of such systems as a result of the attack on Khobar Towers in Saudi Arabia in 1996.

04/01/2010


               

               

              In the fire alarm community, there has been a lot of discussion about mass notification. The incorporation of mass notification systems (MNS) in buildings first got attention after the Dept. of Defense (DoD) began requiring the installation of such systems as a result of the attack on Khobar Towers in Saudi Arabia in 1996.

               

              Khobar Towers provided housing for the U.S. Air Force, Saudi Air Force, and other military. The explosion—detonated outside of this high-rise residential building—caused 20 fatalities and injured 372 people. The marines on security duty became aware of the impending event and did everything they could to try to warn occupants, but without equipment to facilitate notification, they were unable to warn all of the occupants before the explosion.

               

              As a result of the Khobar Towers attack, MNS was required through the DoD Unified Facilities Criteria (UFC) 4-010-01 “DoD Minimum Antiterrorism Standards for Buildings,” which became effective in 2002. Concurrently, UFC 4-021-01 “Design and O&M: MNSs” was developed. UFC 4-021-01 provided the design, installation, and maintenance requirements for MNS.

               

              Soon thereafter, the Air Force petitioned NFPA to start a standard development project to address the design and installation of MNS, with a goal of revising NFPA 72 to allow fire alarm systems to also perform mass notification functions. In response to that petition, NFPA expanded the scope of the Signaling Systems for the Protection of Life and Property Project to include mass notification.

               

              This scope expansion resulted in significant revisions to the 2007 edition of NFPA 72 focused on allowing fire alarm systems to also function as MNS. An annex to the 2007 edition of NFPA 72 provided guidance for the design and installation of MNS.

               

              The work of the committees did not stop there. The 2010 edition of NFPA 72 was revised, reorganized, and expanded. It now includes requirements for the design, installation, and maintenance of MNS in a new Chapter 24 titled, “Emergency Communication Systems.” This chapter includes all the requirements for emergency voice/alarm communication systems, firefighter communications, and mass notification. The name of the code has also been changed from the “National Fire Alarm Code” to the “National Fire Alarm and Signaling Code” to recognize this expansion of scope.

               

              As with other systems addressed by the code, NFPA 72 does not require an MNS to be installed. However, if one is provided, the code requires that the system be designed, installed, and maintained in accordance with the provisions of NFPA 72.

               

              Risk analysis

              Prior to the incorporation of mass notification requirements in the body of the code, NFPA 72 did not have any requirements for risk analysis. While the 2007 edition of NFPA 72 has guidelines for the design and installation of mass notification in Annex E, there are no requirements. The body of the 2007 edition was modified to change language that previously prevented a fire alarm system from either performing mass notification or being integrated with an MNS.

               

              When the new Technical Committee on Emergency Communications Systems was considering Annex E guidelines for the design of an MNS for incorporation into the code as requirements, the committee realized that many of the MNS design recommendations needed to consider the specifics of the project and the many variables that could apply. In order to write requirements for MNS in the body of the code, the committee determined that performance-based design approaches would need to be incorporated. Performance-based design includes risk analysis.

               

              A key requirement of the 2010 edition of NFPA 72 is that MNS be designed to address the nature and anticipated risks of the facility. The requirement for a risk analysis recognizes that design approaches for MNS have to be specific to each project and may need to vary significantly from facility to facility in order to meet safety goals. The committee also realized that prescriptive requirements could not address all situations.

               

              What is a risk analysis?

              NFPA 72 defines risk analysis as a process to characterize the likelihood, vulnerability, and magnitude of incidents associated with natural, technological, and manmade disasters and other emergencies that address scenarios of concern, their probability, and their potential consequences.

               

              While the code identifies things that should be considered in the risk analysis, it does not define the detail of analysis. The code does not intend that a risk analysis be a thesis. The depth of analysis needs to be discussed with the owner and other stakeholders as early as possible in the design process to facilitate the work.

               

              The design brief and risk analysis should be prepared and approved before the actual design of the system is procured to avoid either additional cost for design features that weren't anticipated before the risk analysis was prepared, or overpaying for a system that anticipated more features or devices than needed to meet the safety goals.

               

              Where is a risk analysis required?

              The design of an MNS requires that a design brief be prepared using recognized performance-based design practices. The design brief becomes the basis for the MNS design and a document that all of the design team members, owner, authority having jurisdiction, and other stakeholders can agree on. In the context of compliance with NFPA 72 2010 edition, the approved design brief sets features and performance of the MNS for a specific facility or application. Guidelines for the preparation of a design brief won't be discussed here, but the Society of Fire Protection Engineers (SFPE) publishes a guide to performance-based design that is widely recognized in the design and enforcement community.

               

              NFPA 72 specifically requires a risk analysis to be performed under the following conditions:

               

              • When signals other than fire signals need to take precedence

              • To inform the determination of survivability criteria for emergency communication system circuits when not specifically defined by the code

              • If an MNS is being provided.

              Signal priority can impact not only the activation of notification appliances and the activation of messages, but also activation of other building features that may be expected to operate in an emergency. These features might include exhaust and HVAC systems, containment, and compartmentation features (i.e., automatic door closure). For events other than fire, it may be appropriate and necessary for these systems to perform one way in a fire emergency and another way in the event of a different type of emergency. Depending on the situation, operation in fire mode in a nonfire condition may create confusion or a hazard to life. That is why the code recognizes the need to allow for other signals to take priority over fire alarm signals.

               

              In the case of systems that use trained personnel to direct emergency actions, if the signals to these trained personnel are not given the necessary and appropriate priority, it may prevent personnel from receiving a notification signal that requires their immediate action to direct occupants or emergency responders.

               

              Drivers of risk analysis

              The need for the MNS to be specific to the application is the main driver for the risk analysis. While there can be many different fire scenarios in a building, the actions required to address occupant safety can be defined prescriptively in the code. Performance-based design is applied when there is either a unique building design or unique hazard that requires a more in-depth analysis to achieve life safety or property goals.

               

              The challenge with an MNS is that every facility or campus has unique risks that need to be addressed by the system design. Nonfire events that should be considered include:

               

              • Security breach (presence of armed assailants, etc.)

              • Public disturbance (demonstration, riot, etc.)

              • Health (toxic chemical release)

              • Geological (earthquake, volcano, tsunami, etc.)

              • Meteorological (tornado, hurricane, flood, hail, etc.)

              • Utility outage

              • Medical emergency

              • Terrorism-related.

              The owner and operators of a facility need to be involved to assist in defining the potential risks. A number of questions should be asked to identify the risks and features that may need to be incorporated in a system design. Here are some examples:

               

              • What event(s) may occur that would need emergency action (i.e., is it fire, security, safety, health, environmental, geological, meteorological, utility service disruption, or another type of event)?

              • What is the urgency of the emergency event? How quickly will action need to be taken to avoid injury or property damage?

              • What is the expected severity of an event?

              • What is the probability of an event occurring?

              • What areas of the facility are subject to the risk?

              • What actions need to be taken by occupants and emergency responders for each event?

              • What is the validity of the emergency event, and has the emergency event been investigated and/or confirmed?

              • What general and special instructions should we send to which occupants?

              Risk analysis considerations

              Key factors that need to be considered in the risk analysis include:

               

              • The number of people that need to be notified for the various events

              • Characteristic of the occupancy (i.e., building construction, equipment, operations)

              • Management/staff capabilities

              • Extent of notification (there may be different first responders for different emergencies).

              Emergency response plan

              The risk analysis also provides the basis for the development of the emergency response plan. The MNS design should be coordinated with this plan. The risk analysis may also identify areas of improvement or modifications needed for the emergency response plan.

               

              The emergency response plan should include the following:

               

              • Emergency response team members and structure

              • Emergency response procedures for each expected type of event

              • Emergency response equipment

              • Notification/communication

              • Message content

              • Message recipients

              • Authority to send messages

              • Initiation procedure

              • Emergency response training and drills.

              A framework

              It was not the intent of the NFPA 72 Technical Committee on Emergency Communication Systems that every risk analysis be a thesis paper. Preparing a risk analysis for an MNS can be challenging. One of the first steps is to get the stakeholders on the same page in defining the purpose and goals for the MNS as well as the threats. The owner and ultimate user of the system need to take an active role in defining these factors. If they don't actively participate in this process, the designer could miss important factors that aren't obvious to an outside party or make design decisions that are not compatible with the facilities emergency management plan or operations.

               

              Different facilities will need different depths of risk analysis. The breadth and depth of analysis should be agreed upon with the owner at the beginning of the process and should be documented in the risk analysis. A basic outline for a risk analysis for the purpose of informing MNS design should include:

               

              • Project description

              • Goals and purpose of the MNS

              • Expected characteristics of the occupants

              • Expected characteristic of management and staff (availability, roles in emergencies, etc.)

              • Occupancy characteristics (threats and hazards present)

              • Anticipated events that could present a risk (internal and external)

              • Given the factors above, design features required for the system to be effective.



               



              No comments
              Consulting-Specifying Engineer's Product of the Year (POY) contest is the premier award for new products in the HVAC, fire, electrical, and...
              Consulting-Specifying Engineer magazine is dedicated to encouraging and recognizing the most talented young individuals...
              The MEP Giants program lists the top mechanical, electrical, plumbing, and fire protection engineering firms in the United States.
              2014 Product of the Year finalists: Vote now; Boiler systems; Indirect cooling; Integrating lighting, HVAC
              High-performance buildings; Building envelope and integration; Electrical, HVAC system integration; Smoke control systems; Using BAS for M&V
              Pressure piping systems: Designing with ASME; Lab ventilation; Lighting controls; Reduce energy use with VFDs
              Case Study Database

              Case Study Database

              Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

              These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

              Click here to visit the Case Study Database and upload your case study.

              Protecting standby generators for mission critical facilities; Selecting energy-efficient transformers; Integrating power monitoring systems; Mitigating harmonics in electrical systems
              Commissioning electrical systems in mission critical facilities; Anticipating the Smart Grid; Mitigating arc flash hazards in medium-voltage switchgear; Comparing generator sizing software
              Integrating BAS, electrical systems; Electrical system flexibility; Hospital electrical distribution; Electrical system grounding
              As brand protection manager for Eaton’s Electrical Sector, Tom Grace oversees counterfeit awareness...
              Amara Rozgus is chief editor and content manager of Consulting-Specifier Engineer magazine.
              IEEE power industry experts bring their combined experience in the electrical power industry...
              Michael Heinsdorf, P.E., LEED AP, CDT is an Engineering Specification Writer at ARCOM MasterSpec.