Eva Kosanovic explores the topic
Eva Kosanovic of Apollo Fire Detectors Limited explores the key considerations when integrating fire detection with other building management systems and highlights the latest technological developments
Today’s buildings can have any number of systems installed in order to control security, heating, lighting and ventilation. In larger scale buildings, these different elements will often be combined into a single, integrated building management system (BMS). There is one essential building service that has to date resisted full integration – fire detection.
The status quo is about to change, however, with the evolution of a new device called OpenConnect Gateway®, but to understand why this development is so significant in terms of integration, it is first necessary to understand the reasons why fire detection systems have traditionally been isolated from other building services and explore why integration is now becoming so desirable.
Adopting best practice
Firstly, and perhaps most importantly, fire detection is deemed safety-critical and some may argue that fire detection should take precedence over other building services systems and remain completely independent. For example, there may be some advantages to be gained by several systems sharing information – but there is the potential risk, for example, of the heating system knocking out the fire detection system. In addition, if the fire detection system is kept separate then the user cannot mistake the flashing light on the control panel for anything but a fire alert.
Fire detection systems are, in general, subject to much stricter standards and controls than other building management services. Numerous regulations govern the integration of fire detection systems, which 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 fireproofed. 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 on integration as such, only recommendations. BS5839-1:2002, the code of practice for system design, installation, commissioning and maintenance in the UK, implies that the fire system should always stand alone. Full integration would therefore negate this code. However, there is no law to insist that system designers stick to the code. Building
regulations refer to, but do not insist upon, compliance with the British Standard.
At a European level, there is a draft standard on integration, DD CIC/TS 50398:2009, which has been adopted by the UK. It states that ‘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 should take 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 just one example.
Indeed, some degree of fire detection integration has been satisfied already by the use of interfaces and complex bespoke integrations. These devices translate the signal from the fire system to another system and 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.
There are some restrictions associated with the use of interfaces. When they were first introduced, standard interfaces needed separate isolating devices fitted on either side of them to prevent a short circuit disabling part of the fire detection system. Fitting three devices each time had a significant impact on project time and costs. Manufacturers subsequently developed interface units with built-in isolators to overcome this difficulty.
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.
Identifying the right solution
When reduced to the 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. In other words, it shifts the emphasis from systems integration to information integration. When viewed from this perspective, assimilating fire detection into a BMS does not seem such as daunting prospect; nor does it compromise the issues surrounding the need for life-critical equipment to be physically separate.
Apollo Fire Detectors Limited has been working on a solution to fire system integration for some time. The result is a simple, off-the shelf product called OpenConnect Gateway®. OpenConnect will take the information from a fire alarm control panel and connect 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 its 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 rolls out across the market.
In line with Apollo’s belief that collaboration and openness are the best basis for innovation, the OpenConnect protocol will be made 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 also benefit because there is no need for modification of fire detection and alarm devices used in conjunction with OpenConnect-enabled control panels. Similarly, there is no 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.
The future of integration
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.
The fact remains that fire detection systems have evolved for the purpose of protecting lives and property and therefore they should always be classed as safety-critical, with devices kept physically separate from other building services equipment. However, there is no reason why closer information integration should not be embraced, particularly considering the practical benefits it offers without compromising the integrity of the fire system.
