On July 8, 2013 FireLite Alarms announced a software incompatibility between certain versions of panel software and their download software. It used to be that folks would turn away from a product that had incompatibilities, but now it is the hallmark of a corporation that has embraced the ideal that there is only so much you can keep compatible as you maintain controlled development of your products.
To know of an issue is far better than discovering it...
Since the late 80's, fire alarm has enjoyed an awakening of sorts. In the mid to late 80's was when the first "addressable" controls came out. Slow kludgy things with 4 digit displays and code sheets reminiscent of the Little Orphan Annie Decoder Ring from "A Christmas Story".
You could tell exactly where an alarm or trouble was coming from by reading an "A" for Alarm, "E" for Error and "F" for Fault then the 3 numbers of the device 123 - 1 being the particular Loop and 23 being the device address number on that loop. We even got a new Circuit name and Styles to go with it. The Loop became a Signaling Line Circuit (SLC) and Styles 4, 6 & 7 replaced the old Class A and B.
In the beginning, input devices like Smoke Detectors, Heat Detectors, Pull Stations, Water Flows, etc... were the same as the devices used on conventional "Zoned" systems. We had new devices or modules to put in between the input device and the system. These Monitor Modules were the devices that watched the input device and sent the alarm or trouble signal to the panel via the SLC. Eventually these monitoring circuits would be built into the smokes and heats allowing us to change the characteristics.
Output devices were redesigned to become Intelligent Relays or Intelligent NACs and software - not wires - connected the input devices to the output devices so that we could get our CBE or Control By Event Programming.
Now our techs had to have a new tool in their vans: a computer...
These were fairly simple units by today's standards, and incompatibility between firmware (the software on the control panel boards) and software (the programming software used to download the input to output relationships or CBE) never happened because manufacturers used to create new firmware as they developed new features in their software. UL was only concerned that the new firmware chip's manufacturer's part number matched, regardless of the version of firmware being loaded into it.
In some cases, the panel manufacturer would write firmware for a particular building because they had too much RFI and the smoke detectors would go missing every day at 8 AM until 9 PM. It was simple to just change the trouble parameters and make the system fit the installation. No one was watching...
There were cases where programs were modified to enhance certain features - real or imagined - by ESDs, Engineers, AHJ's. Federal Express got rich shipping EPROM Firmware all across the country to clear up the part of the system that was dead or malfunctioning when a new feature was introduced into the mix (it happened to me on the island of Guam at 5PM on a Friday. Thank God there was no fire that weekend. We added Alarm Verification to a system and lost all of the Output Modules in the program, never to be seen until Monday, when the new chips arrived).
UL eventually wised-up and began to police firmware in the early to mid-90s. Now, not only did it cost money for UL to change their files every time the firmware version changed, a manufacturer had to show the hours and documentation proving that the system was tested to be backwards compatible to older system components in case a new module was used to repair and older system. Manufacturers could still modify their Programming Download Software as they saw fit, and as long as they showed some sort of Revision Control, they were left on their own.
That was until NFPA 72 2002 code came out with its requirements for Reacceptance Testing of software based systems. They realized that testing the part of the program that was changed was not enough. UL required testing of parts of the system that should not have changed to prove that the new program wasn't buggy or incompatible. Reacceptance testing of software based fire alarms included 100% of what was changed and 10% of the system that wasn't involved (not to exceed 50 devices).
NFPA 72 2002 also required that a copy of the site specific software be made available to the building owner. In the 2007 version of NFPA 72, the authors specified that the site specific software be stored on site on non-volatile media. Lending credence to the idea that the programming software was an actual part of the control panel and belonged to the building owner - not the installing contractor or ESD.
UL 864 (the standard that dictates the engineering of fire alarms by the manufacturers) was also tightening up, and with their 9th edition UL spelled out in exacting detail the means by which the manufacturers needed maintain the revision control on not just the firmware, but the programming software as well.
Visit any Fire Alarm manufacturer’s site and you will find lists, matrices, and narratives of their different Systems, Firmware revisions and Programming Software revisions. These manufacturers are forced to spend more time in testing and proving out the compatibility of the software that drives them. Now, they are finding the incompatibilities the technician's used to find and they are letting contractors know before they lose money on a job.
From simple General Alarm, to "Fire-Floor, Floor-Above, Floor-Below" programming, to today’s high-tech interconnected Smoke Control and Stair Pressurization, all the way to Mass Notification Systems ready to take control of all media and internet traffic to alert citizens of impending danger, the software that runs the show had better run smoothly and be fully tested and integrated so that we all can feel safe and trust in the direction these systems give us.
The evolution of testing Fire Alarms is next…
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|