From Interface to Integrate
Fire-alarm and security systems each serve well-understood roles in the buildings we occupy, and each system stands sentry in its own way against a host of threats to life and property. Because these systems perform different functions, they normally operate independently and utilize their own dedicated head-end equipment, wiring and initiating/indicating devices.
Fire-alarm and security systems each serve well-understood roles in the buildings we occupy, and each system stands sentry in its own way against a host of threats to life and property.
Because these systems perform different functions, they normally operate independently and utilize their own dedicated head-end equipment, wiring and initiating/indicating devices. Traditionally, there has been a need to interface these systems in some fashion to ensure that the normal and proper functioning of one system does not conflict with the mission of the other. Additionally, such interface has been enacted because certain capabilities of one system might be utilized to enhance the effectiveness of the other. Over the years, the extent to which these systems have interfaced has continued to grow more intelligent, and more complex.
The term interface can be defined as a point at which independent systems or diverse groups interact. Fifteen years ago—when zoned, hard-wired fire-alarm systems were prevalent—interfacing was primarily limited to one or two fire-alarm outputs connected to the access-control system for door-unlocking in facilities with electronically locked doors. The fire-alarm system needed to be able to signal to automatically unlock the electrically operated door locks to ensure unimpeded egress during alarm situations.
This basic interface between fire-alarm and security systems has traditionally been accomplished, in its simplest form, by connecting an output contact in the fire-alarm control panel (FACP) in series with a door-lock relay contact in the access-control panel (ACP). A fire alarm initiation at the FACP results in opening the FACP output contact, thereby dropping power to the door lock and causing it to release. This is also known as a “fail-safe” configuration, as any loss of power to the FACP or the door lock would result in the lock releasing to the open, or “safe,” default condition.
A more sophisticated and versatile approach is to connect one or more of the FACP output contacts directly to one or more inputs in the ACP (see Figure 1, p. 46). The ACP can then respond to the input signal(s) by unlocking the appropriate doors. Logic internal to the ACP could also allow for a variety of relay responses to suit the different lock types that may be utilized in a building. This approach allows greater flexibility in selecting specific doors to unlock while maintaining secured access in other, unaffected areas of the building.
Changes in technology
These traditional interface methods utilize hard-wired connections to relays and output contacts. But as the quantity of output functions and controlled devices grows, the quantity of contacts, complexity of interconnected wiring and resulting equipment costs all increase. Furthermore, hard-wired interfaces through contacts and relays are best suited to one-way transmission of signals, not readily lending themselves to facilitating data exchange in both directions.
This, of course, changed 10 years ago, when microprocessor-based addressable fire-alarm systems emerged. With this technology, each initiating and control device is assigned an address descriptor uniquely recognized by the FACP. Each device effectively becomes a dedicated zone, allowing building personnel to pinpoint the location and nature of alarm origins. Addressable systems also allow for a greater variety of output responses, which are more closely attuned to particular alarm conditions. This also affords the opportunity for more advanced levels of integration with security systems.
By using microprocessor intelligence and network-based data exchange, data and commands can efficiently be transmitted in both directions between various systems—and even between multiple points within each system—over just one or two pairs of cable. This opens up a variety of opportunities for expanding or fine-tuning the control of system components without the complexity and costs associated with additional contacts, relays and monitor zones. It also allows centralized monitoring. Multiple systems connected in this way are often said to be integrated .
The term integrate can be defined as to make into a whole by bringing all parts together . To an extent, systems are considered as integrated when they share a common platform and protocol over which they can communicate “bi-directionally” with each other. With fire-alarm and security systems, this platform typically consists of a copper or fiber-optic cable backbone network.
Once interconnected by the backbone, the various systems must be able to communicate using a common language and an established protocol for organizing the multidirectional flow of language. In order to achieve full integration, however, these systems must be unified by a central user interface and information processing unit, typically a front-end PC operating an integration software program similar to building-automation systems (See “Fire, Security and BAS,” p. 45).
Whereas traditional hard-wired systems were limited in the flexibility and selectivity of door-lock control, addressable systems greatly facilitate the targeted control of individual doors or groups of doors. This is typically accomplished by providing an addressable fire-alarm control module for a specific door or for an ACP controlling a group of doors (see Figure 2, above). A major benefit of this selectivity is that areas of the building, unaffected by the fire-alarm condition, may remain in their secured mode. As a result, this application is most often seen in airports, manufacturing facilities and other installations containing multiple secured areas (see “Early Road to Integration,” p. 47).
In addition, many of today’s security systems are capable of communicating over an established systems-integration platform through communications ports or gateways. This enables data exchange between the fire-alarm system and the security system without the use of discrete contacts or addressable control modules (see Figure 3, below). Using the systems integration platform for transmitting data and commands to the security system allows greater flexibility in achieving point-by-point door-lock control in secured areas, closed-circuit television (CCTV) camera positioning, the recording of video images and a multitude of other functions. This approach takes fire-alarm and security systems several steps closer to true integration.
A few fire-alarm system manufacturers offer combination systems that perform fire-alarm and security functions. NFPA 72 , National Fire Alarm Code , requires such systems to be listed for dual applications, ensuring that a fire-alarm signal always takes precedence, and that any failure in the security portion of the system does not hamper the fire alarm operation. UL listings for these applications include UL 864, Standard for Control Units for Fire Protection Signaling Systems , and UL 1076, Standard for Proprietary Alarm System Unit Burglary Alarm Equipment .
Combination systems such as these, however, are limited in their ability to handle security functions. Thus, extensive security applications are often better left to standalone systems.
More to come
In the wake of Sept. 11, the focus on fire-alarm/security integration is likely to continue its substantial increase.
On the security side, building owners are requesting more card-access-controlled doors, more secure areas of buildings, increased CCTV camera surveillance and more use of digital video recording. This is accompanied by a desire for increased levels of lighting, HVAC and elevator controls.
On the fire-alarm side, building owners are increasingly requesting systems that exceed code requirements. Fire-alarm systems will be tasked to expand beyond their typical detection functions and assume a greater role in the total building life-safety program, including significant improvements in occupant notification, voice evacuation, smoke management and building egress.
As an example of where integration may be heading, consider the following high-rise scenario:
Public and employee access into the building is only allowed at established security control points, such as the guard station or security desk.
Employees and guest access is limited to specific floors of a building, where face-recognition or other biometric checks must be passed.
Access into elevators and floors is controlled either by card sensors or manually from the security desk. The employee or guest is not allowed to access any other portion of the building, including the stairwells.
CCTV cameras track the movement of employees or guests as they proceed to the specific floor or location, and while the individual is en route to their destination, the security system interfaces with the BAS to ensure that lighting and HVAC systems are operating at proper levels in the appropriate areas.
The fire-alarm system is capable of providing intelligent, point-addressable alarm information to the security system.
The fire-alarm system is capable of providing clearly understood, sufficiently detailed voice-evacuation messaging to occupants, including varied messages in multilingual formats.
The fire-alarm system is capable of unlocking stairwell doors, recalling elevators, notifying emergency response teams with detailed alarm information and providing survivable environments through sophisticated smoke control.
While the fire-alarm system is performing its alarm-condition functions, a parallel response by the security system initiates the positioning of CCTV cameras to allow visual assessment of the problem area, raises lighting levels in refuge areas and egress paths and tracks building occupant movements and locations for the responding emergency teams.
These examples illustrate only some of the valuable possibilities that can come from greater integration between fire-alarm and security systems. There are a number of objectives behind the thrust to integrate these systems.
Having multiple systems act in concert holds the promise of enhancing life safety by creating optimum survivability conditions and better protection against unauthorized intrusions. System integration can also help make buildings themselves less vulnerable to both natural and man-made catastrophes.
Additionally, integration can lead to a more centralized means of assessing and reacting to emergency situations, allowing all of the above to be accomplished in an efficient, cost-effective manner.
Fire, Security and BAS
It has become increasingly commonplace for multiple building systems to be integrated. In most instances, this would include HVAC monitoring and control, lighting control, monitoring of other assorted building system parameters or any combination thereof. Typically, all of the above functions are integrated into a building-automation system (BAS) package that allows all monitoring and control interface functions to be accomplished through a single, front-end PC terminal.
Primarily because of their uniquely important goals, fire-alarm and security systems typically do not lend themselves to a high level of integration with BAS.
Fire-alarm systems are required by NFPA 72, National Fire Alarm Code , to meet standards acceptable to the Authority Having Jurisdiction (AHJ), or to have been tested and found suitable for the specified purpose—most commonly by Underwriters Laboratories (UL). Because BAS equipment is generally not intended or listed for fire-alarm applications, quite often a separate and distinct fire-alarm system must be provided.
At the same time, the fire-alarm system is not prohibited from sending a mono-directional alarm or trouble notification signal to the BAS, perhaps for the purpose of event logging or alerting building operating personnel to monitor building systems response.
It is also possible that a BAS can be UL-listed for smoke-control applications. The BAS would then be able to receive and interpret data from the fire-alarm system and perform functions such as smoke/fire damper or HVAC system control. To the extent that this is acceptable to the local AHJ, this degree of integration between fire alarms and BAS affords potential cost savings to the owner, as separate control points are combined into the BAS.
Integration of security systems with BAS can be problematic for different reasons. A security system may actually be comprised of several distinct subsystems, each with a unique and specialized function—access control, CCTV surveillance, intrusion detection, etc. Each of these subsystems requires its own front-end monitoring and control equipment, as well as dedicated wiring and field devices. In general, BAS software does not have the capability for extensive security-systems monitoring and control, other than perhaps simple point annunciation of door-alarm contacts and the like.
Clearly, the bank of video monitors, switchers and recorders that are incumbent in most CCTV surveillance systems are well beyond the scope of typical BAS capabilities. So, too, are the complexities of multilayered card sensing and door-lock control.
Early Milestone on Road to Integration
Denver International Airport (DIA) is a 7-million sq.-ft., $5.3 billion airport on a 53-sq.-mi. site, consisting of a main terminal building (pictured below), three concourse buildings and several auxiliary/support facilities.
When design of DIA began in 1987, it was envisioned that several of the airport’s electronic systems would be integrated for both current and future needs. The systems originally under consideration were telephone; data; flight and baggage information; fire detection and alarm; security; public address/emergency announcements; master clock; and energy monitoring. Although a forerunner to future airport systems integration, the end result is different than today’s concept of integrated systems.
As with many of today’s integrated systems, the systems at DIA share a fiber-optic cable backbone as the integration platform. That, however, is where the similarity ends.
At DIA, this backbone consists of a multifiber trunk, with several fibers dedicated to each electronic system for current usage and future growth. A truly integrated system would utilize the extensive capability of each fiber to carry data exchange for multiple systems. In this case, the decision was made to dedicate individual fibers or groups of fibers to each electronic system at DIA in order to facilitate operations/maintenance functions, and to enhance capacity, security, redundancy, growth capability, immunity from lightning strikes and protection from electrical interference.
Another factor differentiating a fully integrated approach from that implemented at DIA is the means of front-end user interface. At DIA, this consists of a main airport “operations center” housing separate operator terminals or consoles for each electronic system. Other than being centralized in secured and environmentally controlled confines, these user interfaces are largely separate and discrete from one another. Although not necessarily appropriate for all systems, today’s technology would have allowed several of these stations to be combined into a single front-end user interface.
While the systems-integration approach implemented at DIA was partly the result of the technology available at the time, the configuration was to a greater extent the result of deliberate decisions based on what best serves the present and future needs of the facility.