Security Dealer & Integrator

JAN 2014

Find news and information for the executive corporate security director, CSO, facility manager and assets protection manager on issues of policy, products, incidents, risk management, threat assessments and preparedness.

Issue link: http://sdi.epubxp.com/i/246277

Contents of this Issue

Navigation

Page 39 of 69

SPECIAL FOCUS: STATE OF THE INDUSTRY By Greg Kessinger, SET, CFPS, IMSA, CDT Game-Changers Trends and issues that will impact the fire alarm industry in 2014 H "When your state's new residential (oneand two-family home) building code is adopted, be sure to look for any new CO requirements." 38 appy 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 a bit 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 have already 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 does not 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. www.SecurityInfoWatch.com | SD&I; | January 2014

Articles in this issue

Links on this page

Archives of this issue

view archives of Security Dealer & Integrator - JAN 2014