Microsoft, Google, and Wal-Mart are some of Dan Horon’s 300 global clients using his special computer software, which can pinpoint a fire or other emergency situation in a facility. Unlike a traditional fire alarm system, however, Horon’s software, RescueLogic, uses an Ethernet connection that converts messages from a control panel into data that can be viewed on computers connected to the network.
Horon isn’t alone in embracing the idea of using Ethernet or other computer networks in conjunction with fire alarm systems, a notion that has gotten the attention of NFPA 72®, National Fire Alarm and Signaling Code, technical committee members. “Computer networks are becoming part of the standard infrastructure [for a variety of occupancies], and the codes don’t provide a clear path to connect alarm systems to these networks,” says Horon, president of Minnesota-based Cadgraphics, Inc., which produces the RescueLogic software. He is also a member of NFPA’s Protected Premises Fire Alarm and Signaling Systems (SIG-PRO) Technical Committee. “There are no [code] specifications for what the software should do.”
That’s not to say committee members haven’t attempted to develop provisions in NFPA 72 pertaining to these networks. During the last few code revision cycles, members have remained at odds over the reliability of these networks to do what is expected during an emergency, which is to provide appropriate alarm signals and notification of problems that may include open circuits, ground faults, or shorts.
To resolve these concerns, the Correlating Committee on Signaling Systems for the Protection of Life and Property established a task group last year to develop code language for the 2016 edition of NFPA 72 that addresses the use of Ethernet, local area networks, and wide area networks in fire alarm systems, fire emergency voice and alarm communications systems, and mass notification systems. The SIG-PRO Committee reviewed those proposals at its latest meeting, held in September.
“We had a number of meetings where people had to get comfortable with the technology,” says Wayne Moore, vice president with Hughes Associates, a fire protection and life safety consulting firm, and NFPA Journal columnist (see his overview of using computer networks for fire alarm signals in the September/October “Buzzwords” column). Moore also chaired the Use of Networks in Fire Alarm and Emergency Communication Systems Task Group. “Once they were comfortable, we said, ‘How can we allow it in the code?’ ”
||Hughes Associates vice president Wayne D. Moore talks about concerns with Ethernet enabled alarm systems and steps to address those concerns in NFPA's upcoming mass notification codes.
Something old, something new
Conventional fire alarm systems typically rely on initiating device circuits that use dedicated copper wiring to connect a control panel to a series of devices, such as smoke detectors and pull stations. The wiring adheres to specific code requirements for installation and for the reporting of fault conditions as “trouble signals.” An initiating device circuit provides a non-specific alarm signal to the control panel if any one of the connected devices operate. Signaling line circuits are newer to the alarm industry and, unlike initiating device circuits, assign “addresses” to devices on the circuit, thereby providing more information about the location of an incident and status of a device.
No matter what kind of circuit is being used, all are required to be monitored for integrity according to the requirements in NFPA 72. “If we have an open circuit, or ground fault, it is annunciated at the alarm panel and tells users something is wrong,” says Merton Bunker, chair of the SIG-PRO Technical Committee. “That’s been one of the tenets of the code for nearly 40 years.”
Regardless of their thoughts on how reliable an alarm system would perform via computer networks, committee members interviewed for this story acknowledged the potential benefits of that model for alarm communication. Instead of installing copper wiring throughout a building or campus to connect traditional alarm systems, networks use little more than an alarm panel, a computer server, and hardware or software to transmit data. “Ethernet has a lot more capability of reporting potential problems than fire alarm designers ever considered,” says Horon, adding that his software transmits information about an incident and relevant floor plans to computers. “To a lot of end users, it seems like a real disadvantage to not have more information than what an LCD screen of an alarm panel gives them.”
When advocates for Ethernet technology stated their case for network inclusion in the code, committee members from the alarm industry remained skeptical as to whether these networks would produce proper alarm annunciations and signal transmissions. Extensive discussions on this issue occurred during previous NFPA code cycles and continued during the 2013 code cycle, as some committee members wanted additional clarity on the issue before allowing network performance and installation requirements in the code. “The committee is cautious and wants to make sure fire and life safety systems are very reliable and robust,” says Bunker. “We have to make sure the technology we’re using is going to meet some minimum safety levels. That’s why this process has taken at least two code cycles.”
Another concern was the reliability of an alarm system if a network goes down or is undergoing maintenance. Information technology professionals, says Moore, allow network downtime for repairs and upgrades, so safeguards need to be in place to make sure the alarm system remains operational during those periods. A separate point of contention focused on existing provisions in NFPA 72 that address performance requirements of circuits during a ground fault. Some committee members wanted networks to adhere to these code requirements, while network advocates argued that these requirements aren’t necessary.
Addressing these concerns head-on was the goal of the Use of Networks in Fire Alarm and Emergency Communication Systems Task Group, which was formed in October 2012 and included representatives from the alarm industry, Underwriters Laboratories, FM Global, and other areas.
Regarding the issue of network performance during downtime and maintenance, Moore says the task group looked at various failure modes and “developed language that would give us some operational integrity and acceptable end-to-end verification communication. The whole network had to provide a new level of reliability.”
Additional safeguards were included in a code proposal that creates a new class of circuit, Class N, which will be dedicated to networks. This new distinction would join the list of specific requirements for other types of alarm circuits and signaling pathways found in Chapter 12 of NFPA 72. For instance, a loss of communication between two endpoints on a Class N circuit will be annunciated as trouble, and a ground or short on one pathway would not impact any other pathway.
Upon reviewing current code requirements for reporting a single ground fault and relating them to a network’s operation, the task group decided not to include requirements for monitoring these faults. “Common fire alarm wiring connects many sensors through two parallel wires,” says Horon, a task group member. “A ground [fault] at one end could short the entire communication line if a ground occurs at any point along the other wire. With that potential, you want to report that first ground as a potential problem.” However, there is no need to report ground faults using Ethernet, adds Horon, since the cable prevents these events from impacting communications. Circuitry at both ends of an Ethernet cable prevents shorts or grounds from impacting the connected equipment.
During its latest meeting in September, the SIG-PRO Committee reviewed and approved the task group’s proposals, which will make its way into the First Draft of the 2016 edition of NFPA 72. The First Draft Report posting date is March 7, 2014.
“If the Class N circuit is retained through the remainder of the code development process, it will allow for newer technologies and better communication between equipment, which is where the industry is headed,” says Bunker. “We as a committee need to embrace new technologies and networks … and allow them to be used, because they can provide performance enhancements we currently don’t enjoy.”
Fred Durso, Jr. is staff writer for NFPA Journal.