Happy 2014! The New Year is a time for all of us to look toward the future, and for me to discuss new trends and issues for the fire alarm industry. Since the rest of the year I have to stick to strict facts and code numbers, the opportunity to gaze into my crystal ball to simply offer my opinions seems like a breeze!
Remember, beyond these trends and issues, it is prudent for all fire alarm installing companies to educate themselves about the newest requirements and provisions in fire alarm standards. Looking forward to changes ahead and proactively anticipating how your company will address these issues will position you as an industry leader.
Issue: More Programming Capabilities
While providing real freedom to enable devices to operate in any number of ways, the programming capabilities of control units and associated devices also allow more room for error. Software changes made to an output may result in unintended operations, or even the failure of required functions. For example, mapping all smoke detector outputs to the NACs may reset the required function of a lobby smoke detector to recall elevators to the correct level. For the factory to provide all the programming options they believe we may possibly ever need, it requires a level of complexity that may allow unintended changes to seemingly unrelated functions go unnoticed.
I am not familiar with all programming software, and possibly some already incorporate some of what I will suggest here, but I think that all software should include a partition between global and individual points. In this way, if a box denoting “Elevator Recall Functions” were checked, this section could not be affected by other global programmable functions. This could prevent, for example, mistakenly enabling a manual pull box to activate an elevator recall function.
Similarly, un-checking certain key boxes as programming options, would cause a pop-up warning. For example, a warning box could pop up telling the programmer that “un-checking this feature means the Elevator Recall Functions will no longer be provided.” Required functions like these should be protected from inadvertent changes.
Warnings should appear not just on-screen, but in the printed report as well. A warning such as, “This device has no output associated with it” should be followed by another pop-up that asks, “Are you sure?” Some capabilities should be blocked from programming, such as the ability to “cross-zone” two smoke detectors that already have been programmed to provide alarm verification upon activation. A pop-up should be provided for any operation that is prohibited by NFPA 72, like the one mentioned above, so that a technician doesn’t look for a work-around.
Other software warnings should be mandatory, such as, “while this control unit is capable of silencing the horns while allowing the strobes to remain flashing, the DOJ/ADA has ruled that this is not allowed where public notification is performed.” Being given a lot of control panel programming options is like being given a lot of rope — insert your own “hang yourself” or “tangled mess” analogy here.
Trend: CO Detection & Combo Units
When your state’s new residential (one- and two-family home) building code is adopted, be sure to look for any new CO requirements in the code in the section following the paragraph requiring smoke alarms. For commercial buildings, the Building Code will require Carbon monoxide alarms in Group ‘I’ or ‘R’ occupancies which contain “a fuel-burning appliance” or are part of “a building which has an attached garage” (not ventilated parking structures and open parking).
Since “carbon monoxide detection systems which include CO detectors and audible notification appliances” are permitted, I expect the use of combination smoke/CO detectors will become more prevalent, in lieu of providing separate detectors for each. This application can give the professional alarm company an edge.