Fire Protection Technology Manages Data Transmission to Inform Firefighters in Advance

By Jim Byrne, Chief Technology Officer, NetTalon, Fredericksburg, Va., David Kimmel, Director of Engineering, NetTalon,and Chris Spurlock, Coordinator for Municipal Fire Training, Louisiana State University Fire & Emergency Training Institute,Baton Rouge,La June 14, 2005

In the past year several beta sites have been operating in the Virginia region for one particular fire-protection systems. Now, a recent installation of this same system at LouisianaStateUniversity’s Fire and Emergency Training Institute in Baton Rouge, La. has demonstrated its efficacy in action to the fire community.

The system reports alarm conditions to all authorized monitoring stations within two seconds of a sensor or smoke detector going into alarm. Sensor and detector conditions depicting the nature of the evolving emergency are reported virtually immediately on a graphic representation of the building’s floor plan. Icons that represent the various sensors (heat sensors, duress buttons and smoke detectors) are overlaid on the floor plan and change color to indicate alarm conditions. The icons representing the heat sensors display the changing temperature in real-time. The smoke detectors inform the first responders the amount of restricted visibility and potential breathing difficulty; the duress buttons display the locations of personnel trapped by the fire emergency and the temperature sensors report the source of measured heat leading the responders to the source of the fire.

The advantage of the system is its ability to network the local fire department with the building being protected. Firefighters can examine details of a fire and begin to form their strategies before they ever leave the firehouse.

A national study recently concluded that the average arrival time for a fire company is in excess of six minutes following validation of alarm. The system saves much of this time because firefighters will arrive at the scene already understanding where the fire is, where it’s spreading to, where the victims are, and with a deployment plan already formed and understood.

System genesis

The system has been under development for more than five years.Prior to the creation of a corporation, founders of the company that makes this system worked together with another company upgrading an energy management and security (EMS) system for a county school system. A long-term project, it involved moving the county school EMS system from an older, legacy mainframe architecture to an array of distributed Windows-based workstations and an Oracle database server.

When the upgrade was completed, the developers reflected on the problems created when the centralized databases had to be reconciled between each of the two response monitoring facilities: the 911-dispatch center and the county administrative facility. Although advanced at the time of its initial creation, the basic architecture was no longer a viable solution for the increasing demands placed on the system.

There were two dilemmas: using a privatized RF communications infrastructure lacked both bandwidth and viability, and the information source was misplaced and unnecessarily complicated. Since the school system had already begun the implementation of a countywide WAN to support communications between the various school buildings, a network based approach would provide both an inexpensive and bandwidth attractive solution. Further, the developers realized that the site data that defines its configuration and status really belongs in the panel itself, not in any peripheral aspect of the system architecture. These realizations were the genesis of the system.

Intrinsically Net-centric

The system is intrinsically net-centric by design. When the operator connects to the site, the panel provides all needed information on how to interface with its specific site. This includes the background map, the point locations, the point types and the point status. All of that information is carried in the panel itself. Each time the operator “drills down” to another level, this is updated to produce a new screen display.

Another important aspect of the system design is that alarm traffic from the detection system is actually pushed across the network architecture. Instead of the round-robin polling architecture employed by most systems today, the event is pushed across the shared network infrastructure, which may be the Internet, a WAN or a privatized network. Any change in site status is simultaneously transmitted to a list of registered authorized monitoring sites. Each of those sites may be observing different levels of screen displays that are continually updated in real-time.

Where the conventional monitoring system diagram looks like a pyramid in terms of the communications process, developers of this new system took the approach of looking at a plurality of monitoring systems at the same time. The system diagram resembles two diametrically-opposed pyramids, with all the centricities for one event propagating up to a whole host of monitoring systems, such as the dispatch station, the central monitoring station, police and fire vehicles, all at the same time.

Compliance testing

As system development progressed, the developers became indoctrinated into NFPA design procedures, standards and regulations unique to the fire industry.

In 2004 the basic system design and configuration, much of it dictated by code, was completed after five years of development.

The system successfully completed FCC RF emanation and susceptibility testing by Washington Labs. The system was then submitted to Factory Mutual Research Corporation testing for NFPA 72 compliance. This was completed, and the product was Listed by FMRC, in 2004. The system is currently going through the process of listing for UL864 (9thedition) and UL1076.

System details

The decision system (alarm panel) operates on an embedded microprocessor platform connected to a number of distributed sensor/controller interface units (device interface units or DIU). The panel communicates with each DIU over a redundant RS485 communications loop (not multi-drop, as each leg is “daisy-chained”). Each DUI is hosted by an array of microcontrollers that are responsible for each interface‘cluster’ (binary inputs, binary outputs, digital temperature inputs, etc.).

The overall system configuration is quite flexible, allowing anywhere from 1 to 1920 points to be connected, the status of each uniquely visible to response professionals through their laptop computer. System configuration changes are easily managed through the “drag and drop” design toolkit and are updated over the network interface.

Data integrity is maintained through unique addressing and some fundamental industry standard encryption methods. Further, the IP-friendly communications topology works well over virtual private network (VPN) appliances.

Communications systems agnostic

The system can work over a wide variety of IP-friendly architectures, even low-orbit or geostationary satellites. The changing attitudes of the satellites may alter the acceptable delay of acknowledgement, but allowance has been made for that. Packets in transit are tracked so they never get out of sequence.

The system does not use the upper layers of communications management, where connection of virtual links can be lost. Instead, the design takes control of everything above the datagram level. Conventional transport communications are not employed; the system continues to push traffic across until it receives acknowledgement that that data has arrived, insuring both survivability and recoverability. Anytime the link communications is lost, the site icon changes to a “?” (question mark), illuminating the lost link status.

A good example site is a private museum located in a rural setting in western Virginia. DSL was not available there, so the system was connected via a satellite carrier for Internet services. The system protocol has proven to work well over this Internet connection.

The software designers for the system had the goal of keeping it user-friendly: extremely simple and straightforward to simplify operator interface and minimize training time. In the beta installations, large, 400 or 500 point systems have proved straightforward and easy to learn.

A number of government facilities have been installed by dealer-integrators with large site integration requirements. The integration of other client software interfaces (i.e. DVRs, Access Control systems, etc.) into the monitoring interface has entailed minimal engineering changes due to the open architecture of the software design. Screen Icons are associated with client software packages and are activated in new‘windows’ when selected. The system utilizes a simple “point and click” interface.

Demonstrations at LouisianaStateUniversity showed that even lay people, outside the specific firefighting area, could easily grasp the meaning of the system’s visual representations with minimal explanation.

LSU testing

In a preliminary real-time test series at LouisianaStateUniversity’s Fire and Emergency Training Institute in Baton Rouge, LA, a preliminary test series of six fires was started and monitored.

The fire department from St. George, a suburb of Baton Rouge, responded to the test fires in the conventional manner, while LSU fire institute personnel and senior commanders from the St. George company monitored the fire scene remotely using System 3000 technology.

From the time each fire was started, LSU control personnel allowed two minutes to pass to simulate the time it takes to process an alarm signal. Meanwhile, system monitoring stations were viewing smoke activity at multiple points in the building within a few seconds of the fire starting. Within the next 30 seconds, monitoring personnel could view actual fire activity and victim dummy location. All data was received a full 90 seconds before the staged fire company received the dispatch.

After dispatch it was another 4-1/2 minutes before the real-time firefighters located the test fire and victim dummies. Control personnel watching via the system knew the fire’s intensity, location, involvement in the building, spread of smoke, victim location and victim danger long before the fire responders even arrived. This speed of notification and remote real-time intelligence clearly demonstrated to the LSU staff and participating fire department the important advantage the system can give in fire control, victim rescue, personnel safety, and speed and efficiency of the firefighting operation.

On the operations side of the equation, the system can make important fire data available to the commander and the responding crews before they even leave the fire station, theoretically allowing the commander to develop his strategy and tactics, make key, critical decisions, and be farther ahead when he arrives at the fire scene.

These events were simulated at LSU’s multistory burn building. Control personnel determined that the system could detect, identify and provide location of the fire and read out conditions like rate of rise and temperature in the affected area, minutes in advance of crews arriving on the scene.

The involved firefighters included the St. George fire department, other crews from around the state that were in for training, and the Institute’s own staff. Every group tested was able to gather information faster, make decisions faster, and develop sound strategy and tactics much earlier into the training scenario.

LSU’s Fire and Emergency Training Institute gears its training to the needs of the fire-fighting community. It is felt that the early information provided by systems of this sort will be especially helpful for fires in building complexes and high-rise buildings, which are major concerns of fire departments today.

For more information about System 3000 from NetTalon, click here .