Fire detection and alarm systems have become pretty sophisticated recently, but they are only scratching the surface of their potential, says Mohamed Cherif Benzerari. Here he envisages integrated systems which provide a wealth of valuable data to engineers and end-users.
There has been remarkable progress in fire alarm systems over the last few decades, especially with the development of analogue addressable systems. They have effectively allowed us far greater flexibility in the programming and monitoring of systems for many kinds of building, with features like staged evacuation and the monitoring of other building management systems such as smoke vents, extinguishing systems, plant and machinery, lifts and door access.
In spite of these advances, these systems can further evolve to monitor other fire safety related aspects of a building and its systems, including information on fire evacuation drills, and the management of data history – in particular the various kinds of false alarms. They can also be re-engineered, just by using more user-friendly menus, to monitor routine tasks and operations such as commissioning, servicing/maintenance and bell tests.
The recorded events history of the majority of analogue addressable systems on the market today – even those that are fully compliant to BS EN54 parts 2 and 4 – are still relatively basic compared to their potential. In particular, current systems lack a quick approach to retrieving and exploring the potentially long list of information they can gather and hold, so at the present time a great deal of this data just ‘sits’ there passively. If this information could be held and classified more like an IT database approach, it could be much more useful and usable. In addition, data for manual fire safety logbooks – which when recorded in traditional hard copy form has limited use – can be integrated with the rest of the system’s information. This integration of system data and human experience can provide a far clearer picture on the status of fire safety and the detection and alarm system of a given building.
The reason for the current limitations of our fire safety systems is, therefore, twofold: limited system design and capabilities in classifying data, and the reliance on human intervention which risks forgetfulness, mistakes and a lack of proficiency or deliberate misconduct. Re-engineering analogue addressable systems to be more grounded in data management may, to some extent, overcome these issues, and may also provide appropriate data and intelligence to inform fire safety strategies and even help to effectively perform fire engineered designs.
The first step is to re-engineer the hardware of the fire alarm panel to enable it to be more data management friendly. It would behave like a regular IT server, with Internet access and sufficient memory space. The software would need to be fully configured, starting from the regional settings related to the local city, time and date, in addition to the automatic bi-annual hour change. This enables the event history database to be fully and accurately populated, with the potential for being retrieved from anywhere in the world.
Events history
Most existing systems classify event histories into three ‘event’ categories only: ‘fire’, ‘fault’ or ‘all events’. But these categories can be broken down further to provide more specific information. To achieve this, I would propose an additional function button on the panel called ‘classify’. In the event of any fault or alarm activation, the user would have to respond to this option before being able to activate the ‘reset’ button. By using this classify function and the menu of options that it pulls up (see figure 1), specific data on the source and type of the activation can be entered or selected and then saved. Once this data has been saved, of course, it can be retrieved by reference to various criteria, such as sorting events by type or date. So, for example, the previous year’s false alarms caused either by malicious, accidental, environmental, or equipment failure can be called up and analysed. In addition, false alarm rates can be automatically calculated by the system, for example, the percentage of false alarms per year and per hundred of devices as basically required by BS 5839, part 1, section 3, clause 32-1 and 32-2 .
At the present time a very few panels do have an intermediate function built in, usually known as an ‘acknowledge’ or ‘accept’ button – to be pressed prior to resetting the system. Such a function could be re-programmed with some additional software upgrading, but for the majority of panels, the whole system hardware would have to be redesigned from scratch to achieve this.
Operation menu
The other likely functions that may be integrated is the ‘operation’ menu with the following functions displayed: ‘bell test’, ‘fire drill’, ‘maintenance’, etc. (see figure 2). Subsidiary functions could be programmed/displayed, providing a tree-style structure designed to display one task at a time with appropriate prompts. Some of the functions can be available only to relevant or authorised people by using appropriate passwords. Additionally, all operations undertaken will be recorded with the name of the person in charge.
Data management-based fire alarm panels can prompt engineers on what needs to be done for each operation. For example during a preventative maintenance visit, it can provide details including the list of zones and devices that need attention. So when, for example, selecting the third preventative maintenance of the year, the system ‘expects’ to receive the alarm threshold analogue values of the list of devices to be tested. The system would have the ability to flag anything that is missed – for example a difficult to access detector in a lift shaft or boiler room – and to prevent engineers exiting the maintenance programme without testing all necessary devices, or at least prompting them to reschedule to the next due service visit if no access is available.
In the case of a bell test operation being selected, for example, the operator is prompted to the call point due to be tested. Once it has been genuinely tested and the system has received the alarm threshold analogue value, it automatically classifies this event in the ‘bell test’ database and prompts the operator to the next call point as pre-programmed, or to exit the bell test menu.
If the commissioning operation is selected, all fire devices have to be fully configured and tested. The system expects to receive location information and device analogue values in order to classify them as fully configured and tested. The system wouldn’t accept any device sitting in the loop circuit without proper configuration, and will keep flagging them until the commissioning is fully accomplished. The configuration file can additionally be saved in the service company’s server as a back up.
Fire drills
Data management-based fire panels can provide an extra dimension to fire drills, even when performed in different environmental conditions, such as when using artificial smoke in an area of the building. In addition to allowing ‘real world’ electronics data acquisition through electronic tagging by means, for example, of employees’ identity cards, it can provide valuable information on who has evacuated. By harnessing the access control receivers at doors and barriers fitted throughout the building, the fire alarm system can be used to monitor the evacuation flow of people and signal the completion of evacuation after the last person has left the building. It can also record the full evacuation report – not only the basic information of the evacuation time taken, but also every person’s escape route, in addition to the evacuation flow of people at any given stage, time or floor. This detailed information can then be analysed for future measures just by uploading it to a 3D CAD or CFD (computational fluid dynamic) programme, along with the building layout, so that the fire drill evacuation can be re-simulated. As a result, good evacuation times can provide a benchmark against which to monitor a building’s evacuation in a real emergency. Such a case study would also be valuable for any future fire evacuation modelling for similar buildings.
In summary
The enhancement of BS EN54 parts 2 and 4 may have a key role to play in bringing about the reality of these data-management based fire alarm systems. While initial costs may be high, these can be offset over time through more efficient and streamlined maintenance procedures, greater automation of procedures and the provision of a wealth of valuable management information. This will be a noteworthy development towards the implementation of more genuine fire safety performance-based design guides, and consequently lead to the right investment for an appropriate fire safety engineered design.
Mohamed Cherif Benzerari Elec.Eng TMIET is a service technician at Drax UK.
Fire detection and alarm systems have become pretty sophisticated recently, but they are only scratching the surface of their potential, says Mohamed Cherif Benzerari. Here he envisages integrated systems which provide a wealth of valuable data to engineers and end-users.
There has been remarkable progress in fire alarm systems over the last few decades, especially with the development of analogue addressable systems. They have effectively allowed us far greater flexibility in the programming and monitoring of systems for many kinds of building, with features like staged evacuation and the monitoring of other building management systems such as smoke vents, extinguishing systems, plant and machinery, lifts and door access.
In spite of these advances, these systems can further evolve to monitor other fire safety related aspects of a building and its systems, including information on fire evacuation drills, and the management of data history – in particular the various kinds of false alarms. They can also be re-engineered, just by using more user-friendly menus, to monitor routine tasks and operations such as commissioning, servicing/maintenance and bell tests.
The recorded events history of the majority of analogue addressable systems on the market today – even those that are fully compliant to BS EN54 parts 2 and 4 – are still relatively basic compared to their potential. In particular, current systems lack a quick approach to retrieving and exploring the potentially long list of information they can gather and hold, so at the present time a great deal of this data just ‘sits’ there passively. If this information could be held and classified more like an IT database approach, it could be much more useful and usable. In addition, data for manual fire safety logbooks – which when recorded in traditional hard copy form has limited use – can be integrated with the rest of the system’s information. This integration of system data and human experience can provide a far clearer picture on the status of fire safety and the detection and alarm system of a given building.
The reason for the current limitations of our fire safety systems is, therefore, twofold: limited system design and capabilities in classifying data, and the reliance on human intervention which risks forgetfulness, mistakes and a lack of proficiency or deliberate misconduct. Re-engineering analogue addressable systems to be more grounded in data management may, to some extent, overcome these issues, and may also provide appropriate data and intelligence to inform fire safety strategies and even help to effectively perform fire engineered designs.
The first step is to re-engineer the hardware of the fire alarm panel to enable it to be more data management friendly. It would behave like a regular IT server, with Internet access and sufficient memory space. The software would need to be fully configured, starting from the regional settings related to the local city, time and date, in addition to the automatic bi-annual hour change. This enables the event history database to be fully and accurately populated, with the potential for being retrieved from anywhere in the world.
Events history
Most existing systems classify event histories into three ‘event’ categories only: ‘fire’, ‘fault’ or ‘all events’. But these categories can be broken down further to provide more specific information. To achieve this, I would propose an additional function button on the panel called ‘classify’. In the event of any fault or alarm activation, the user would have to respond to this option before being able to activate the ‘reset’ button. By using this classify function and the menu of options that it pulls up (see figure 1), specific data on the source and type of the activation can be entered or selected and then saved. Once this data has been saved, of course, it can be retrieved by reference to various criteria, such as sorting events by type or date. So, for example, the previous year’s false alarms caused either by malicious, accidental, environmental, or equipment failure can be called up and analysed. In addition, false alarm rates can be automatically calculated by the system, for example, the percentage of false alarms per year and per hundred of devices as basically required by BS 5839, part 1, section 3, clause 32-1 and 32-2.
At the present time a very few panels do have an intermediate function built in, usually known as an ‘acknowledge’ or ‘accept’ button – to be pressed prior to resetting the system. Such a function could be re-programmed with some additional software upgrading, but for the majority of panels, the whole system hardware would have to be redesigned from scratch to achieve this.
Operation menu
The other likely functions that may be integrated is the ‘operation’ menu with the following functions displayed: ‘bell test’, ‘fire drill’, ‘maintenance’, etc. (see figure 2). Subsidiary functions could be programmed/displayed, providing a tree-style structure designed to display one task at a time with appropriate prompts. Some of the functions can be available only to relevant or authorised people by using appropriate passwords. Additionally, all operations undertaken will be recorded with the name of the person in charge.
Data management-based fire alarm panels can prompt engineers on what needs to be done for each operation. For example during a preventative maintenance visit, it can provide details including the list of zones and devices that need attention. So when, for example, selecting the third preventative maintenance of the year, the system ‘expects’ to receive the alarm threshold analogue values of the list of devices to be tested. The system would have the ability to flag anything that is missed – for example a difficult to access detector in a lift shaft or boiler room – and to prevent engineers exiting the maintenance programme without testing all necessary devices, or at least prompting them to reschedule to the next due service visit if no access is available.
In the case of a bell test operation being selected, for example, the operator is prompted to the call point due to be tested. Once it has been genuinely tested and the system has received the alarm threshold analogue value, it automatically classifies this event in the ‘bell test’ database and prompts the operator to the next call point as pre-programmed, or to exit the bell test menu.
If the commissioning operation is selected, all fire devices have to be fully configured and tested. The system expects to receive location information and device analogue values in order to classify them as fully configured and tested. The system wouldn’t accept any device sitting in the loop circuit without proper configuration, and will keep flagging them until the commissioning is fully accomplished. The configuration file can additionally be saved in the service company’s server as a back up.
Fire drills
Data management-based fire panels can provide an extra dimension to fire drills, even when performed in different environmental conditions, such as when using artificial smoke in an area of the building. In addition to allowing ‘real world’ electronics data acquisition through electronic tagging by means, for example, of employees’ identity cards, it can provide valuable information on who has evacuated. By harnessing the access control receivers at doors and barriers fitted throughout the building, the fire alarm system can be used to monitor the evacuation flow of people and signal the completion of evacuation after the last person has left the building. It can also record the full evacuation report – not only the basic information of the evacuation time taken, but also every person’s escape route, in addition to the evacuation flow of people at any given stage, time or floor. This detailed information can then be analysed for future measures just by uploading it to a 3D CAD or CFD (computational fluid dynamic) programme, along with the building layout, so that the fire drill evacuation can be re-simulated. As a result, good evacuation times can provide a benchmark against which to monitor a building’s evacuation in a real emergency. Such a case study would also be valuable for any future fire evacuation modelling for similar buildings.
In summary
The enhancement of BS EN54 parts 2 and 4 may have a key role to play in bringing about the reality of these data-management based fire alarm systems. While initial costs may be high, these can be offset over time through more efficient and streamlined maintenance procedures, greater automation of procedures and the provision of a wealth of valuable management information. This will be a noteworthy development towards the implementation of more genuine fire safety performance-based design guides, and consequently lead to the right investment for an appropriate fire safety engineered design.
Mohamed Cherif Benzerari Elec.Eng TMIET is a service technician at Drax UK.
