Integrating Fire Detection into Building Management Systems

Buildings today can have any number of systems installed in order to control security, heating, lighting and ventilation. It is common practice, particularly in larger scale buildings, to combine these different elements into a single, integrated building management system (BMS). One essential building service has, to date, largely resisted full integration - fire detection. This situation is set to change with the evolution of a new device called OpenConnect Gateway. To understand why this development is so significant it is important to understand why fire detection systems have been kept separate from other building services in the past and explore why integration is now so desirable.

The Complexity of Integration
Firstly, and perhaps most importantly, fire detection is deemed safety-critical. It could therefore be argued that fire detection should take precedence over other building services systems and remain completely independent.

This is why fire detection systems are subject to much stricter standards and controls than other building management services. The regulations governing the integration of fire detection systems are many and various and this can lead to some rather strange anomalies. For example, where a BMS and a fire alarm system are channelled through a common information-gathering system, the cabling must be fireproof. However, a simple wire connection from the fire detection system to the BMS may fall outside this rule.

It is worth noting that there is no legislation as such on the topic of integration, only recommendations. At the European level, there is a draft standard on integration, DD CIC/TS 50398:2009, which states: "the integrated alarm system shall be designed so that any application is not adversely affected by any other application in normal conditions." It therefore takes a highly accomplished system designer and installation engineer to understand the application standards and work out which takes precedence where different systems meet.

Practical Considerations
While regulations may appear to discourage fire system integration, in practical terms interaction between the different elements of a BMS are not only desirable, but also necessary if safety-critical procedures are to be effective. The ability for a fire signal to tell a security system to release certain access doors for use as escape routes is one simple example.

Indeed, some degree of fire detection integration has been satisfied already by the use of interfaces and complex bespoke integrations, which enable a fire alarm to trigger other pieces of plant and equipment. Actions can include opening and closing doors, shutting down air conditioning, or stopping passenger lifts safely at ground level.

However, there are some restrictions associated with the use of interfaces. Even interfaces with built-in isolators do not address the fundamental issue that multiple additional devices are required to facilitate even simple levels of integration between fire devices and other building services equipment. As commercial buildings become larger and more complex, and the expectations of occupants become more sophisticated, adding more and more physical devices to link building services together becomes less and less practical. It is therefore time to return to first principles and ask what it is we are actually trying to achieve.

Finding a Solution
When reduced to basics, integration is actually all about communication. The benefits of having diverse building products and systems co-operating with each other are self-evident. Faster response times, co-ordinated strategies in case of emergency or failure, and pre-planned and pre-programmed evacuation procedures are amongst the most effective results of inter-system communication.

BMS is essentially an attempt to find a common translation for all these different languages so that lighting, heating, ventilation and other equipment can work in harmony.

Apollo Fire Detectors Limited has been developing a solution to fire system integration for some time. The result is a simple, off-the shelf product called OpenConnect Gateway. OpenConnect takes the information from a fire alarm control panel and connects it to a building management system using standard protocols such as BACnet, Modbus or LonWorks. The device is effectively a ‘plug and play' concept that fire panel manufacturers can incorporate into their existing products.

This integration solution has been developed in conjunction with Tridium and uses their well-established Niagra AX software framework, on which many building monitoring, automation and control applications are based. Apollo has also worked closely with leading fire panel manufacturers through its Panel Partnership and will continue to support the development and adoption of OpenConnect as it comes to market. In line with Apollo's belief that collaboration and openness are the best basis for innovation, it will be making the OpenConnect protocol available to participating control panel manufacturers under licence. The licenced manufacturer will be able to develop their own software to incorporate this protocol and will provide a suitable physical connection between their panel and the OpenConnect Gateway. This allows sufficient freedom for the panel manufacturer to continue to offer its own unique design and features while incorporating the option for integration with BMS.

Installers benefit because there is no need for modification of fire detection and alarm devices used in conjunction with OpenConnect-enabled control panels. Nor is there any need for recurring engineering for each new project. End users will enjoy full integration of the fire system and reduced cost through the use of standard software and a single interface, while the integrity of the fire system remains assured. The new integration device is being made available in four base model options: 200 BMS points, 1,600 BMS points, 12,000 BMS points and 25,000 BMS points. For maximum integration, each OpenConnect Gateway includes as standard two Ethernet ports, an RS232 and RS484 port, a 15V dc input and two spare comms card slots.

Conclusion
The precautionary approach adopted in current codes and regulations when giving guidance about integration is understandable but not legally binding, and in practice system designers and specifiers have been moving towards greater integration for several years. Fire product manufacturers have also acknowledged the need for greater communication between fire and building service products through the development of interface units. However, the needs of the market continue to evolve and OpenConnect Gateway is one example of how the issue of integration can be resolved far more effectively using a single device than dozens of individual interfaces or bespoke solutions.

To summarise, fire detection systems evolved for the purpose of protecting lives and property. For this reason they should always be classed as safety-critical, which means that fire detection devices should be physically separate from other building services equipment. That said, there is no reason why closer information integration should not be pursued, especially if it brings practical benefits such as reduced time and cost without compromising the integrity of the fire system.