A Lesson in Campus Fire-Alarm System Design
There are many considerations prior to the layout and design of a campus fire-alarm system. The most important is finding out what the owner expects to accomplish with the system. Is the intent to have total monitoring and control of the site facilities? Or is it to have a central command center for monitoring the campus systems? Are there other systems to incorporate into this campus network infrastructure? The answers to these questions will help determine the direction of the system design. In general, there are three basic types.
A proprietary campus system gives the owner full monitoring capabilities and control of the entire campus. In this configuration, there is a single source manufacturer for the fire-alarm equipment for all campus buildings. The fire-alarm system in each building becomes a "node" or "network address" in the site fire-alarm system network. The site fire-alarm head-end panel for this application is typically a computer workstation that includes color graphics display software.
A non-proprietary campus system is similar in that it allows the owner some basic system control functions and full monitoring of the various building fire-alarm systems on the campus. In this configuration, one fire-alarm system manufacturer's workstations are typically utilized as the site system head-end user interface with a combination of fire-alarm system panels from various manufacturers installed throughout the campus. The buildings that have the same fire alarm manufacturer's panels as the head-end work-station support full system control and monitoring from the head-end panel. The buildings that have non-compatible fire-alarm panels support monitoring from the head-end panel through a variety of interfaces. These interfaces can be a mixture of relay contacts, RS-232 software drivers, gateways or contact-ID-type communications.
The third type of campus structure utilized is an integrated system. This system is very similar to the non-proprietary system, but incorporates a third-party software and hardware system platform. This system platform typically is not a fire-alarm network system. The benefit of this system architecture is the ability to monitor and control other campus systems using the common network communications pathways between buildings. This allows the owner even greater control and more monitoring functions for site-wide fire-alarm systems, as well as other non-fire-alarm building systems around the campus.
Once the system type is selected, there are several factors to consider, campus age being one of them. Depending on the age of the campus, there are a variety of communications options available for interconnecting the building systems. The newer the campus or the more recent the communications upgrade for the campus, the more choices there are for connecting the building systems. These building fire-alarm systems can be interconnected via fiber-optic cabling, RS-485 communications cabling, serial communications via telephone lines, wireless communications, central station-type monitoring or even hardwire interconnections. There are distance limitations between buildings and total system distance limitations to consider for each of these communication types. The best solution for a particular campus site may be either a single form of communication throughout the system or a hybrid solution of the various communication formats.
Another important consideration for the type of campus fire-alarm system is the total size of the cam-pus and the number of system points. As an example, some of the larger college campuses may have 50 or more different buildings, which count as nodes in the system network. The network fire-alarm system may not have adequate address node capacity to accommodate the system, which could lead to utilizing a non-proprietary or integrated system installation. The other size consideration is the number of points on the system. While most fire-alarm systems publish system capacities of several hundred thousand points, the manageable capacity of these systems is typically far less. The systems transmit data back and forth over the network, so the more data transfer that occurs, the slower the system becomes. Again, a non-proprietary or integrated system installation may be called for based on the system point total. Most integrated system platforms allow filtering out of the more mundane system network traffic, while a proprietary fire-alarm system network typically does not allow similar filtering options.
The existing situation
The existing campus raceway infrastructure is another factor that can have a significant role in the decision as to how the system will communicate and what type of system is installed. In some of the older campus sites, there may be inadequate raceway infrastructure to support new or additional communication pathways. It may not be economically feasible to replace aging raceway or add new raceways, so existing communication cabling may have to be incorporated into the system design. Two campus projects, recently completed in the Rocky Mountain region, offer examples of how an existing campus raceway infrastructure can affect what type of system is installed. Both campuses consisted of 20-plus buildings each. Due to the continual upheaval and shifting of the soil, underground raceway with traditional cabling was not an option. The solution in each case was to interconnect the buildings via a wireless radio-frequency fire-alarm system network.
On the same note, existing fire-alarm systems can also help dictate the type of system and communication formats to be utilized. Typically, a campus facility is not built out all at one time. Campuses are typically constructed over a period of years or even decades with numerous upgrades and additions throughout the life of the campus. As such, the odds are fairly high that there will be numerous fire-alarm systems installed in the different buildings. Luckily, there are some design options available to address interconnecting these various fire-alarm systems. For example, for a campus using three different brands of fire-alarm systems installed in the various buildings, one solution could be three separate fire-alarm system networks with monitoring and control functions available at a common workstation user-interface point. While not the optimal solution for the owner, this design might be the most feasible. The other method for accomplishing a site-wide fire-alarm system in this scenario would be to select a third-party integrated platform that has the software drivers or gateways available to monitor the three different system types.
Along with the items listed above, the age of the existing installed systems can play a significant role in how fire-alarm systems interact. Systems that have been installed recently (less than five years old) are equipped with Ethernet-type local area network (LAN) interconnect capabilities. These systems are typically designed to communicate with other systems via the BACnet standard. Systems that were installed anywhere from five to 10 years ago typically have network capabilities that allow some communications between the panel RS-232 printer ports, gateways, etc., to the site-wide system head-end panel. Systems installed more than 10 years ago are typically non-networkable and would require relay interface or even a central station-type monitoring scenario, since the technology today did not exist in fire-alarm systems that far back.
Another deciding factor in choosing the system is the presence of non-fire-alarm systems installed throughout the campus. If there are card access and other security systems, various building automation systems or other critical systems installed throughout the campus, the integrated systems approach may be the best solution for the project. This approach allows the owner greater monitoring and control of the various fire-alarm and non-fire-alarm systems installed throughout the campus. This creates enhanced opportunities to fully utilize the various features of each system while possibly reducing operational costs. These integrated systems tend to be more costly than traditional proprietary or non-proprietary systems, but the benefits to the owner can certainly outweigh the additional costs.
The last major item to consider when designing campus fire-alarm systems is requirements of the local authority having jurisdiction. No matter what the owner desires or the engineer designs, the AHJ has the final say as to how the campus system architecture is implemented and how the system will function. Many AHJs are traditionalists who do not want central control of a site-wide campus system, and they may require the local buildings to be able to override any control or monitoring functions occurring from a central command center. The newer fire-alarm systems are equipped with passwords and command priorities to allow this local control, but in some cases that is not sufficient. The AHJ may demand specific compatibility requirements between the various systems or even disallow certain systems or control and monitoring functions to occur on the campus system. The designer needs to involve the AHJ throughout the design process to ensure that the campus system design will ultimately be approved.
As we've seen, there are multiple ways to structure a campus fire-alarm system depending on the factors involved. In closing, here are a few key points to keep in mind during the design process.
First and foremost is to perform a detailed site evaluation of the existing conditions of the installed systems, communication formats available and potential site issues. Second, determine the owner's expectations of the system. Third, develop various design options with associated costs so the owner can make educated business decisions. Finally, once the owner and designer agree on the specifics of the system, the AHJ should be brought in to discuss the system's operation and approve its concept and functionality prior to commencement of the design or implementation of construction. Bringing in the AHJ early in the process helps reduce redesign costs, aids in the review and approval process, and paves the way for a successful project.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering 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.