Home>Fire>Alarms and Detection>No Cause for Alarm

No Cause for Alarm

02 October 2020

On Wednesday 29 July, Fire Safety Matters ran another event in its popular webinar series, this time focused on ‘Ensuring Compliance and Improving Efficiency of Fire Alarm Systems’ and featuring detailed input from solution specialists at LAN Control Systems. Brian Sims reports on proceedings

FIRE ALARM logbooks. Put simply, they demonstrate compliance for alarm system end users and help improve the efficiency of fire alarm maintenance. They used to be in paper format. Most of them still are, in fact. As such, they’re prone to being lost or simply unavailable when needed. If there’s a fire, of course, any such logbook could well be lost forever. 

Is there a suitable alternative? Viewers of Fire Safety Matters’ recent webinar involving guest presenters Adam Welton (founder and head of sales) and his colleague Peter Martin (sales manager) from LAN Control Systems will know that the answer’s very much in the affirmative. 

Electronic logbooks have been available for some time now. The 2017 amendments to BS 5839: Fire Detection and Fire Alarm Systems for Buildings outlined where a logbook may be kept in an electronic format, but needs to be accessible for all interested parties. Welton and Martin duly used the hour-long online event as a platform to assess in some detail the requirements of, the drivers for and the parties involved with fire alarm logbooks.

“As a consequence of making a fire alarm logbook electronic, this will introduce a host of new features and functions that simplify, automate and enhance fire alarm system servicing and maintenance,” asserted Welton by way of his opening gambit.

BS 5839 recommends that a logbook is maintained to record the names of premises management/‘Responsible Persons’/delegated persons, brief details of maintenance arrangements, the dates and times of all fire alarm signals, the causes of (and circumstances surrounding) all false alarms as well as their category, the dates, times and types of all fire alarm tests, the dates, times and types of all faults and defects and also the dates and types of all maintenance (scheduled or otherwise). The logbook should also include all handover and acceptance documentation. Typically, this will encompass system diagrams, operation and maintenance instructions as well as any other necessary site and system-specific documentation.

“Any variations from the British Standard need to be outlined,” asserted Welton, who served as a guest on Episode 9 of the Fire Safety Matters Podcast. “Fire events plus any damage, defects, faults and repairs should be included in addition to radio communication system signal levels.”

Key drivers

The drivers for keeping a fire alarm logbook are many and varied. Life safety is top of the list. Then there’s legislation in the form of the Regulatory Reform (Fire Safety) Order 2005. “In general,” continued Welton, “compliance is a driver, so too insurance, best value and Best Practice. Transparency between service companies and end users is another, as is transparency between service companies and auditors.”

An electronic logbook changes the way in which fire alarm activity is recorded. Most fire alarm panels have a finite memory for storing events, with later ones being overwritten by the most recent, thereby limiting the ability to analyse what has happened and take corrective action. An automated electronic logbook, on the other hand, can provide an infinite log of the key data. When arranged in a common and consistent format, this allows filters to be applied, data analytics to be performed and detailed reports to be generated.

“An electronic logbook is available to any number of users,” continued Welton. “This enables collaboration between interested parties. Permissions can be set to allow specific users access to particular sites and/or functions, in turn maintaining compliance with the Data Protection Act as well as the General Data Protection Regulation.”

Alarm feedback can be delivered through mobiles and desktop computers to end users operating in any location. The scheduling of tasks that need to be performed regularly such as weekly testing and servicing is taken care of. It’s even possible to schedule which devices should be serviced during a specific service visit. “Notifications may be sent by e-mail, mobile phone apps or dedicated PC applications to any number of recipients,” stated Welton. “Mobile phones introduce interaction. The user can record in the logbook why an alarm activated or why a specific fault appeared.”

Further, listing the incumbent devices in a fire alarm system – such as Call Points and detectors – facilitates what Welton described as a “true understanding” of that system’s assets. “This allows further opportunities to analyse the data. The causes of unwanted or false alarms, for example. Warranty periods. Applications within different environments.”

Genesis of Nimbus

Back in 2008 when the Nottingham-based business was born, LAN Control Systems originally produced an SMS pager as one of its first products. This was designed to report fire alarm control panel events for a client that manufactured a number of different types of fire panel. The product consolidated and presented control panel events in a format that was easy to read and respond to. When the client subsequently asked how it could query and save the SMS messages, the development of Nimbus was set in motion.

“Nimbus has evolved to become an industry standard and something of a disruptor,” suggested Welton, “changing the way in which fire alarm companies and end users manage their fire alarm systems, not to mention the servicing and maintenance of the same. It’s a source of truth in respect of which devices have been tested.”

In operation, fire alarm panel data is communicated to the Nimbus cloud via the Nimbus gateway. This then sits in the database. The database is administrated through a web portal. Users are subscribed to receive event notifications via Control Room Monitor (itself a dedicated application), e-mails or via mobile phone. Engineers can interact with their servicing while they’re carrying out their duties. Nominated persons (ie a building’s fire marshal, a warden or a caretaker) are able to transact weekly system testing. 

“When you drill down,” stated Welton, “it might be quite challenging to ensure that operatives carry out weekly testing and that the manual Call Point tests are being rotated. One of our customers has a site with over 20 stand-alone fire alarm systems. A couple of people are assigned to carry out weekly tests and, upon completion, asked to print out the test results. These are then filed in the Estates’ Department’s office. As you can imagine, the last four years’ worth of test results are consuming a good deal of space in the office to the point where it’s becoming unmanageable. They haven’t always known if all manual Call Points have been tested or if some testing has been duplicated.”

With Nimbus, a nominated person could be prompted via an application to carry out a test. Usually, it will be on the same day and time each week. How many tests and which manual Call Points to test can be defined. 

“This information can be delivered to the nominated person through the app. Once data is recorded, it’s written back into the database. Other data can be recorded against the test. Being able to export that log into a pre-formatted Excel spreadsheet allows data to be shared and informs key collaboration.”

On notification

Another function that an electronic fire alarm logbook provides is notifications. Fire alarms signal through bells, sounders, beacons and remote primary signalling equipment. An electronic solution can support and complement those signals, but doesn’t replace them. 

Traditionally, fire alarm signalling comprises a digital signal over a phone line to indicate either fire or fault. The Alarm Receiving Centre operator would only know the site name and if the signal meant a fire or a fault. Now, specific event data may be communicated. For example, an event notification could include the site, the date, the time, the event (fire or fault), the device description, the zone description and even the device type, be it a Call Point or a smoke/heat detector. This event data allows for direct response without physical attendance at the fire alarm control panel display.

“Fire alarm logbooks are often an afterthought and may only be updated with limited information,” concluded Welton. “That may be down to end users being unable to locate the physical logbook. Notify apps will complete 90% of the legwork for them. They need only to record the actions taken against the event. That task will be carried out on their mobile. The process has been simplified. Meaningful data can be captured and analysed. Positive action can be taken to reduce false or unwanted alarms.”

False alarms

Peter Martin began his presentation by focusing on false alarm management and repeating a familiar statement. “The causes of false fire alarms are largely preventable, but to prevent we need data. Data that, typically, should come from a logbook. If that logbook hasn’t been kept up-to-date, it’s going to mean scrolling through and trying to extract the right information while on site. Data is always going to be key to what action is taken next.”

Live data that’s accessible remotely reveals trends around, for example, unwanted alarm activations. “That’s the kind of advantage electronic solutions can offer in order to prevent false alarms. By connecting a fire alarm system to Nimbus, for example, we’re able to receive and view events remotely. Information stored digitally in the cloud is available on an infinite footing. It will never ‘drop off’. The Call-Out process can be improved. Engineers can be sent to site with the right equipment because they’ll know what task is in front of them before they arrive.”

It’s essential that fire alarm systems are subject to periodic inspection and servicing such that faults are identified. Preventative measures can be taken to ensure the continued reliability of the system. False alarm problems are identified and suitably addressed and the user is made aware of any changes to the building that affect the protection afforded by the system.

Given that ‘tech’ is becoming ever-more apparent within the fire industry, data is now a ‘must have’ for validating devices. “End clients are not satisfied with a scribble that 25% of the systems have been tested,” said Martin. “They want to know exactly what systems have been tested and when. Automated validation of device testing is the key.”

The validation of zonal information is essential on any site. It’s not often checked down the line for errors after a fire alarm system has been commissioned. Zonal changes across the years may not be passed on to those who need to know such fine detail. Fire alarm servicing companies need to ensure that fire alarm panels are displaying accurate data, but some of the ways in which to do this can be administration heavy and time-consuming. 

“Picture the scene,” said Martin. “Remedial action has typically been written down and recorded at the end of a service visit. For example, a detector needs centralising on a wall or a given device is over ten years old. Call Point height may be incorrect and require adjustment. Perhaps a detector is damaged. Electronic solutions allow the recording of corrective/remedial action which can be associated with a specific device and supporting images. In this way, the duplication of device testing can be eliminated.”

*To view ‘Ensuring Compliance and Improving Efficiency of Fire Alarm Systems’ on demand visit www.fsmatters.com and click on the ‘Webinars’ tab. One CPD Hour is available thanks to Fire Safety Matters’ partnership agreement with the Institute of Fire Safety Managers