Abstract ........................................................................................................................................................ 3
Introduction ................................................................................................................................................. 4
Literature Review ....................................................................................................................................... 7
Methodology .............................................................................................................................................. 18
Phase 1—Planning .................................................................................................................................. 19
Phase 2—Implementation ....................................................................................................................... 21
Phase 3—Assessment and Analysis ........................................................................................................ 22
Limitations ................................................................................................................................................. 22
Conclusion ................................................................................................................................................. 23
References .................................................................................................................................................. 25
Appendices ................................................................................................................................................. 28
Appendix A - Gantt Chart ....................................................................................................................... 28
Appendix B - Budget .............................................................................................................................. 30
Glossary ..................................................................................................................................................... 32
2

ABSTRACT
Firefighters go into an emergency situation without having all available critical information.
Lack of information hinders accurate decision making in emergency situations which can lead to casualties and property damage. There are useful building sensor data currently not being utilized in emergency situations that would be valuable and potentially crucial to making decisions in emergency response. The purpose of our project is to develop an intelligent emergency sensor system that takes information from these building sensors, processes it, and then delivers it externally to Emergency First Responders in real time. Such a system could be expanded upon to include new sensor and communication technologies. The system will be beneficial to incident commanders in making decisions in emergency response, saving lives and property.
3

INTRODUCTION
In 2007, fire took the lives of over three thousand civilians, injured over seventeen thousand, and caused over $14 billion worth of property damage. In total, fire killed more
Americans than all natural disasters combined ( Quickstats, 2008). In one of the most poignant examples of a recent fire emergency – September 11, 2001 – 343 firefighters and paramedics lost their lives as a result of the collapse of the World Trade Center (de Jong, n.d.).
In a fire emergency, fire related deaths and damages could be reduced if the firefighting personnel were provided with more information about the situation in the building as it develops.
An example of an emergency where lack of information about the situation proved disastrous is the Seattle Warehouse fires of 1994 in which four firefighters lost their lives. In this fire, four firefighters on the upper level of a two-story building encountered very little fire while the firefighters on the lower level witnessed their floor become fully engulfed. The firefighters on the lower level failed to report to the incident commander, resulting in the deaths of the four firefighters on the upper level when the building collapsed (Thiel, 1999). If the incident commander had known the location and severity of the fire, the firefighters on the upper level could have been recalled before the collapse of the building (Thiel, 1999). If the incident commander had been aware of the status of the building in this example, as well as in the World
Trade Center fire, decisions could have been made to protect personnel and determine new plans of attack for the emergency.
Lack of information in an emergency situation results in many preventable casualties. In a fire emergency, firefighting personnel rush into a building knowing little about the status of the fire before arrival (Jones & Bukowski, 2001). Current fire detection systems are used if possible, but most of the assessment occurs on site (“National”, 2007). Even the limited data that are
4

available can be complicated or incomprehensible. Current firefighting procedures base decisions on an Emergency First Responder’s (EFR) first-hand observation of the fire’s development (“National”, 2007). Observations regarding the developing situation are relayed back to the incident commander, who is responsible for the tactical deployment and movement of resources to combat the fire. If this information is inaccurate or not easily understandable, it can cause confusion in the response, leading to inappropriate decisions.
There is a wealth of information that could be gathered and used to aid in the tactical planning and response of EFRs. Access to more information would allow EFRs to make educated decisions to protect the lives of both firefighters and civilians (Davis & Evans, 2004).
Our aim is to investigate how a system can be created that takes information from various building sensors and sends it in real time to the people who need it.
Currently, there are a variety of sensors on the market (Honeywell, 2008). We define sensors as any device in a building that takes in information about the environment. There are sensors associated specifically with fire detections systems as well as also other building automation systems such as security and structural health monitoring systems that could be utilized. Sensors provide information that is useful in making decisions in an emergency situation. For instance, knowing where and when carbon monoxide detectors have gone off can indicate the location and direction of the fire. Knowing the temperature and the humidity in a room may also help in understanding the progression of a fire. A desiccated environment with a high temperature would indicate the possibility of a larger fire than an environment that still retains some moisture and has a lower temperature. With current technology, it is possible to gather critical information about both the status of a fire and, in some cases, the structural stability of a building. This information could be used in order to not only inform Emergency
5

First Responders of the current status of a fire, but also predict when a room’s condition could have lethal effects, due to flashover or structural collapse. Flashover is defined as the point at which the temperature of the gases in a location reaches a critical point such that the air is hot enough to ignite combustible materials (Janssens, 2003).
Our research seeks to answer the question: how can a system be created that takes information from various building sensors and sends it in real time to the people who need it?
First, we will have to explore the abilities of fire sensor system technologies, and what has been done so far to solve the problem of information distribution to EFRs. The remainder of the paper will present in some detail the methods by which we will create our system.
6

LITERATURE REVIEW
Building Tactical Information Project
The ongoing Building Tactical Information project being conducted by the National
Institute of Standards and Technology (NIST) is concerned with the development of technology that aims to make real-time building information available to EFRs. (Holmberg, Davis, Treado &
Reed, 2006). The project has four main objectives: 1) determining which data would be most useful to EFRs in emergency response situations, 2) developing a standard method for dispersing the data collected by buildings to EFRs, 3) demonstrating the effectiveness of the technology proposed by the project, and 4) addressing the security issues in the system proposed
To satisfy the first objective in order to make a system of complexity and sophistication that would be capable of the goals of our project such as reliable external communication, interoperability, and high levels of standardization, it must be determined what information is key to emergency response. To make a complex system for a target group of people such as
EFRs in their case and ours, it is a necessary step of product development to talk to the users to determine user needs and specifications. To achieve this end, NIST held a workshop for
Emergency Responders to define what information they needed during a building emergency to aid them in making decisions. The results of this workshop are presented in the paper entitled
“Workshop to Define Information Needed for Emergency First Responders During Building
Emergencies,” by Jones, Holmberg, Davis, Evans, Bushby, and Reed.
It is important for our project to have the feedback and information generated by users from NIST’s workshop because it was conducted on a scale that would not be feasible for a
Gemstone Team. The following paragraphs introduce information found from the workshop that directly pertains to specifications we need to address.
7

First, the participants in the workshop identified two essential categories of information based on the time frame typically associated with emergency response: “En-Route,” defined as the “first five minutes” and “On the Scene,” after the EFRs arrive at the site of the emergency.
These two time frames represent the important phases of emergency response in which decisions are made. Second, the workshop identified three major areas of information important to creating a system: static information, dynamic information, and the display of information (Jones et al.,
2005). Static information is defined as information available before an emergency occurs. This information includes building plans, sensor layouts, and pre-established escape routes. Also included are the more specific qualities of a structure such as where access points of the building are, locations of elevators, nearby hazard conditions, and the types of power systems that are running in the building (Jones et al., 2005). Dynamic information is defined as the real-time information that would be received from the sensor systems. This information includes direct sensor readings from building fire panels as well as information from “decision support tools” which take in and analyze data in order to give a useful conclusion such as fire location and spread (Jones et al., 2005, p. 8). All of this information would have to be managed in a simple, yet comprehensive display.
For the En-Route display, to be used during the first five minutes of an emergency when responders are on the way to the scene, a comprehensive list of static and dynamic information to be displayed was decided on by the EFRs who took part in the workshop. However, it was noted that given the circumstances of the first five minutes, with the commander and other first responders all en-route to the incident, only so much information could be effectively communicated due to difficulties of reading from computers while in motion. With that in mind,
8

a list of static information was generated; aspects of this list that are relevant to our project are presented below:

Building condition (let burn, unsafe to enter, dangerous roof, sprinklered and other suppression systems)

Building type (single family, commercial, gas storage, school).

Building style (one story, two story, n story, auditorium, sublevels, etc) include square feet.

Building construction (type I, II, III, IV or V; fire resistive, noncombustible or limited combustible,

Ordinary, heavy timber, or wood frame – see reference 2).

Roof construction (light weight metal or wood trusses).

Hazardous materials (Unusual hazards) (above ground propane tank, gas lines, chemicals, etc)

Location of fire hydrants on map with building outline. Nonstandard thread sizes should be noted with the hydrant.

Location of fire department hookups for sprinkler system/standpipes.

Other sources of water nearby.

Location of staging areas and entrances and exits to building.

History of location in case fire stages before police arrive.

Routing information for emergency equipment to reach the building in case of construction.
(Jones et al., 2005, p. 12)
Additionally, the dynamic information generated includes:

Confidence in the incident being real (based on number of sensors in alarm and/or calculated fire size)

Approximate location of fire within building.

Fire size and duration.

Sprinklers are flowing/no sprinklers or other working systems.

Fire growth (fast, medium, or slow).

CBR (chemical, biological, radiation) sensors present and in alarm.

Police on the scene.

Presence of occupants in building

Stairwell smoke/heat conditions for positioning.

Standpipes to use to get to the fire.

Exposures.
(Jones et al., 2005, p. 12-13)
9

The above points of information that would aid in tactical decisions will most likely be available in large commercial structures that have the infrastructure to supply it. In smaller structures, only some of the information is likely to be available. However, any and all of the above information would greatly aid in emergency response. Normally, none of the above information can be obtained en-route and in the best-case scenario, only fractions of it are obtained on scene without the aid of technology.
Once at the scene, incident commanders need more information to make their decisions.
Information crucial to decision-making lies in the floor plans of a building. Ideally, these floor plans would be easily viewable, with relevant information shown in the correct location with respect to the floor being viewed. “The floor plan
(static data) would include layers/overlays that would allow the incident commander to locate:

Doors, windows (with types and which can be used for egress), stairwell risers, fire walls
(with ratings and area separation), roof access, fire sensors.

Security sensors, closed circuit TV cameras, occupancy sensors, security control room.

Fire alarm panel and remote annunciator panels.

Utility shutoff.

Building generator (with indication of what it powers).

Building system controls (HVAC, smoke control, others), areas covered, special operating systems, and which ones should and should not be used by the responders.

Evacuation quality elevators, floors served, and location of elevator overrides and how to control.

Convenience stairs/evacuation stairs.

Areas (zone boundaries) protected by sprinklers or other devices.

Vertical openings.
 Extremely valuable materials.”
(Jones et al., 2005, p. 13)
Currently, the ONYX FirstVision fire panel is being used by NIST to incorporate this kind of information overlay. It clearly labels all floors, all sensor locations, important points of entry/exit, and other aspects of a building useful to emergency responders. Where the FirstVision
10

panel truly excels is in the processing of dynamic information on the scene, as determined by the workshop as the following:

Location of fire detectors in alarm.

Location of CBR sensors in alarm.

Location and size of fire(s).

Duration of the fire/fires.

Location and condition of smoke.

Presence of smoke in elevator shafts or stairwells.

Identification of activation of sprinklers or other devices.

Location of elevators used during incident.

Location of people in need of rescue (911 calls or visual sightings).

Warnings of structural collapse based on material type, fire location, fire size and duration.

Location of operational elevators.

Alarm, occupant, and system histories of building.
(Jones et al., 2005, p. 13)
The kind of system that could take into account all of this information cannot be limited to just fire sensor technology (though the most pertinent information about the movement and severity of the fire comes from such sensors); it would require the incorporation of security system data, HVAC information, facilities management information, such as what floors are elevators located on, and tracking systems to monitor the location of EFRs within a building. A normal fire sensor system would be inadequate on its own. However, fire sensor systems have an important component, the fire panel annunciator, which, if sophisticated enough, can be used to process and analyze information, and, given the right inputs, incorporate other system technologies by using a common communication protocol such as BACnet.
Finally, an incident commander would need to know information about what is going on outside the building, such as who has responded to the emergency (medical personnel, police, firefighters, etc.), what has been dispatched, and where personnel are located, in order to make
11

fully educated decisions. Static information regarding what is going on outside the building to be included in the plot plan consists of:

Building location with street designations.

Location of fire fighting obstacles such as street widths, overhead clearance and elevations.

Location of underground pipelines and other utilities.

Name and phone numbers of building owners and managers.

Name and phone numbers of utility contact people.

Location of police line necessary to isolate the incident.

Indicated runoff or water table problems.

Helicopter landing areas.

Evacuation routes.
Dynamic information displayed on top of the plot plan would include:

Location of responding units (fire, police, and EMS).

Location of units responding but not yet on scene.

Hospital availability.

Helicopter availability.

Hazmat response.

Location of police line necessary to isolate the incident.

Location of triage or evacuation area.

Suggested hazard perimeter.

Local weather conditions and predicted spread directions.

Wind direction and velocity.
The data that could be provided and used by EFRs is extensive and the need for a system that can distribute all of this information is very real. The needs for EFRs in a building emergency determined by NIST’s workshop serve as the backbone for the standards set for our system.
There are, however, concerns that must be considered in designing such a system. Specifically, standardization is a key issue. EFRs expressed concerns with usability of a system, mentioning a need for every system control display to be the same, so there is no new learning curve from
12

building to building, incident to incident. Also, the system has to be fully functional, not partially, as the Fire Service won’t adopt a new, questionable system. The Fire Service cannot be expected to pay for new technology, thus the system must also be affordable to be installed and used in real time when buildings are first constructed (Jones et al., 2005).
Further literature published by NIST addresses the remaining objectives of the Building
Tactical Information project. To address the second objective, NIST proposes a building information server to provide access to tactical information in real-time to EFRs (Holmberg et al., 2006, p. 7). This tactical information includes static building information on a given building’s construction, occupancy type, floor plans, and system schematics, as well as dynamic information collected including alarms and changes in a building’s status as they occur.
According to the project, the desirable features for such a building information server system include the ability to:

Forward alarms and status messages as they occur.

Deliver descriptive building information.

Allow only authorized access.

Allow authentication by multiple accessing connections.

Allow asynchronous access.

Present information in a common format.

Minimize the volume of transmitted information.

Maximize the use of layered communications protocols.

Continue to provide information in the event of partial system failure.
The project also proposes the use of extensible markup language (XML) in messages received and dispatched by the server in addition to the implementation of the Internet TCP/IP suite as the base communication protocol (Holmberg et al., 2006)
13

In addition to the implementation of a building information server, the project also advocates the use of the Sensor Driven Fire Model (SDFM) support system. The SDFM is a prototype decision support system that converts sensor signals to predictions and issues warnings based on these predictions (Holmberg et al., 2006). In order to present the information collected by the building information server and interpreted by the SDFM system, the project proposes both en-route and on-scene information presentation screens. The en-route screen provides information about the area in the immediate vicinity of the building while the on-scene screen presents detailed information about the building’s interior (Holmberg et al., 2006,).
In February 2005, a demonstration of much of the technology described above was held at NIST, accomplishing the project’s third objective. The demonstration was documented on video. The presentation included demonstrations of building sensor data and fire modeling data formatted in XML schema, the transfer of building data to the building information server, and the use of the proposed software client and interface software. (Holmberg et al., 2006). At the demonstration, it was determined that EFRs often are not aware what information is available from the control systems contained in buildings; an educational video was produced to address this deficiency (Holmberg et al., 2006).
To accomplish the fourth objective of the Building Tactical Information Project, NIST outlines a method for allowing only secure access to building information for use in emergency response. The methodology described would permit public safety officials remote access to realtine information. In addition, it would also grant access to EFRs en-route (Treado, Vinh,
Holmberg & Galler, 2007)
14

As proposed, dynamic information would be provided to emergency personnel through a building automation system, which coordinates the activities of HVAC, lighting and access controllers, and fire detection and security systems. The sensor data and video streams provided by these systems would be delivered to EFRs through enhancements to the BACnet building automation system communication protocol (Treado, Vinh et al., 2007). Static information such as floor plans and equipment schematics would already be readily available to public safety officials in building information models (Treado, Vinh et al., 2007).
To access the information being provided by the building automation system, a secure proof-of-identity credential, such as a federal PIV (Personal Identity Verification) would be required. The right to varying levels of the hierarchical database structure would be governed by factors such as identity, jurisdiction, duty status, incident need, and chain-of-command (Treado,
Vinh et al., 2007). The secure connection to these databases would be facilitated by a building information services and control system (BISACS), a system lending itself to standardized protocols and secure communication. The BISACS would be centrally located in a given building and credential reader interfaces at access nodes would permit authenticated internal and external users access (Treado, Vinh et al., 2007). A secure web-based link between the BISACS and the BACnet building automation system (BAS) using a building services interface (BSI) would allow information and resources to be exchanged and shared securely. To maintain security, information would only be permitted to travel in one direction, from BAS to BISACS
(Treado, Vinh et al., 2007).
The system proposed by the Building Tactical Information project will provide a sound foundation for the design and implementation of our team’s own system. The system our team seeks to create will satisfy many of the same design criteria. The background information
15

utilized, data collected, and results to date of the Building Tactical Information project should prove invaluable as the design of our system progresses.
OPNET and Communication Methods
The paper “Simulating the Performance of Building Area Networks as a Communication
Bridge to Emergency Responders” provides information on the development and use of OPNET models as a communication bridge between EFRs inside and outside a building. OPNET is a communication protocol based on Ethernet and IP standards (Treado, Holmberg & Cook, 2007).
Research at NIST shows that a communication model based on this protocol could be used to overcome the limitations of radio communication in an emergency response situation.
According to the paper, existing building network systems such as IT networks, fire alarm networks, and phone networks could be used as a bridge between EFRs inside and outside of a building. Project 25 (P25) provides an open, standard architecture in which such a communication bridge could be developed. P25 involves digital land mobile radio (LMR) services and seeks to standardize public safety communications (Treado, Holmberg & Cook,
2007). P25 provides a standard with which agencies of various levels (local, state, federal, etc.) could communicate (Treado, Holmberg & Cook, 2007). In addition to voice communication, video and data transfer using P25 is currently being considered.
The OPNET model would be used to allow P25 to IP communication. Such a model could have voice, video, and data transfer applications. Specific OPNET model P25 wireless
16

devices communicating via wi-fi are being developed for these applications (Treado, Holmberg
& Cook, 2007).
To test the feasibility of the OPNET communication model, simulations were run consisting of EFRs that connect via 802.11g wi-fi to wireless access points (WAPS) (Treado,
Holmberg & Cook, 2007). These WAPS connect to the Internet through building network switches. Forty-three EFRs were deployed in response to an industrial explosion scenario to test the maximum load of a single access point (Treado, Holmberg & Cook, 2007). Traffic throughout the system, the amount and severity of data loss, and the delay in the network was measured in this scenario. From this test, it was determined that the network delay is negligible and that no more than sixteen EFRs can use a WAP at a time (Treado, Holmberg & Cook, 2007).
Overall, the simulations found that using an OPNET model as a communication bridge is indeed feasible, though bandwidth issues will have to be addressed in order to accommodate video content (Treado, Holmberg & Cook, 2007).
Communication with EFRs is a design goal our team wishes to place particular emphasis on in the development of our system. For this reason, this paper on the possible use of an
OPNET model as a communication bridge with EFRs is particularly relevant. Our team hopes to research further into OPNET and determine a means with which our system can communicate relevant information to EFRs within a building real-time.
17

18

METHODOLOGY
To accomplish our goal of helping EFR personnel make more informed decisions, we will be providing them information on an emergency situation. We envision the creation of a system to fulfill this goal as shown in Figure 1 below.
Smoke
Sensor
Fire Panel
Heat
Building Sensors
CO
Computer
Display
Incident
Command
Fig. 1
Our system covers the area of data processing and delivering. As indicated in Figure 1, we seek to take the dynamic data from the building sensor system and redisplay it along with static information through a display to the incident command of the emergency response. The first component of the system will collect data from all of the networked sensors in a building and relay it to a safer location outside of the building. The raw data will then be processed into useful information for incident commanders. For example, the system could inform the incident commander how long a sensor has been in alarm, indicating how long a fire has been burning in
19

the surrounding area. The information will be displayed to incident commanders to help with their decisions.
Because we view the creation of a usable device to be a solution to our research question, a product design methodology is most appropriate. One advantage of a product design methodology is that in addition to contributing to the body of knowledge on EFR operations, our product, if implemented, can directly benefit the EFR community. We plan to divide the design process into three phases: planning, implementation, and assessment and analysis.
Phase 1: Planning
In order to ensure a useful and adaptable system for providing EFRs with necessary information, our team first needs to investigate what data are available from building sensors, broaden our understanding of existing knowledge and protocols, and obtain the resources necessary for the completion of our project. We will form three independent sub-teams to address each of these topics.
The first sub-team will determine what types of sensors are installed in commercial buildings and will then determine what types of data are available for the team to use in the system. This team will conduct case studies on large campus buildings such as the Comcast
Sports Center or the Kim Engineering Building because both are relatively new buildings with state-of-the-art sensor technologies. The case studies will focus on sensor functionality, product specifications of each sensor found, quantity of sensors, and location of the sensors in the building. The sub-team will also establish the current information profile given to EFRs. As the sub-team identifies useful sensors, they will need to take into account variances in effectiveness of different sensors and possible flaws in the programming, since this affects the usability of the
20

data. Another issue that needs to be taken into account is the lack of standardization across systems. The first sub-team will also study building codes and fire regulations through the
National Fire Protection Association codes and standards, which have been donated to our team by the University of Maryland’s Fire Protection Engineering Department. The sub-team will determine what technical limitations our system will need to satisfy. An interface that seeks to convey information to EFRs will be limited by conditions in the work environment of the EFRs.
To determine what these limitations are, the sub-team will familiarize itself with firefighting standard operating procedures (SOPs), existing communication systems, and the work environment of EFRs. The second sub-team will look into current technology and knowledge in the field of fire protection engineering. The sub-team will investigate previous projects that sought to improve the information provided to EFRs. This sub-team will concentrate on determining which findings are useful for our project, and what issues have not been adequately addressed by other groups. The second sub-team will also maintain contact with other groups currently working to provide EFRs with more information and establish some collaboration. In addition, the second sub-team will look into existing protocols for transmitting and presenting building information. In order to assure interoperability of the information transmissions, we will use BACnet (Davis, Holmberg, Reneke, Brassell, & Vettori, 2005), a protocol designed to standardize data transmission.
The third sub-team is charged with procuring resources and materials. In terms of hardware, the team plans to mount, wire, and program a mock-up of a fire control system.
Various types of sensors will be wired to a control panel and tested both with and without our system in place. The sub-team will procure the necessary tools for this mock-up and the testing done with the mock-up. We hope that companies interested in supporting our research will
21

donate these resources. Contacts at Siemens, Honeywell, and Simplex-Grinnell provide industry input and potentially materials as well. The team will identify all other needs for the research process as well. Grants will provide the resources that are not donated to us.
Phase 2: Implementation
For the design stage of the project, our team will need to determine how to extract building sensor data and distribute it to a number of devices, as well as how to present information about an emergency situation to EFRs. In this phase, we expect to determine algorithms to process sensor data, develop a prototype of our system, and design and revise a user interface. The sub-teams that we will form will need to work closely together to build a complete, usable system that satisfies all of the previously determined requirements. This phase of our project will be an iterative process of development, testing, and revision.
The first sub-team will focus on processing the building sensor data to extract the necessary information in real time. This group will need to design or adapt algorithms for our system to use for processing sensor data. The sub-team must make sure that the algorithms are open to modular addition of new sensors.
The second sub-team will work with the hardware. They will create a mockup of a typical fire detection system with which our system will interface. The hardware sub-team will use the lab space provided by the Department of Fire Protection Engineering at the University of
Maryland to test different types of sensors as well as construct a basic fire display panel setup.
This sub-team will also work to provide the programming sub-team with a way to test their program as they are developing it.
22

A third, smaller sub-team will work with the programming sub-team to work on usability and aesthetics. They will help with the testing, debugging, and revision, focusing on the user’s experience with the system. They will also help the programming team with designing the interface for the system.
Phase 3: Assessment and Analysis
Once we finalize the design of the system and the prototype is complete, our team can move on to assessing the effectiveness of the system. To culminate the research project, our team will design and carry out tests of our system's validity, reliability, and usefulness. We expect to discover the strengths and weaknesses of our system’s user interface. The completion of our thesis will conclude the assessment phase.
The whole team will work together in this phase to synthesize the results of the tests performed in phase two. The final product will be evaluated in terms of its success in meeting the identified needs. The results for sensor verification, system accuracy in reporting data, and usefulness evaluations will be included in the final document.
LIMITATIONS
When conducting our case study in the planning phase, we need to keep in mind that campus fire protection networks may be configured differently than individual, privately owned buildings. The university has its own numbering and identifying system, but we cannot expect all buildings to have the same set-up. We need to recognize that if the system is reliant upon this sort of input, the system will not be generalizable to other set-ups.
The limitations to the hardware used in our research are set by the funds we can raise and
23

the donations we receive. The team expects to receive a fire control panel and sensors with which to create the mock-up. In addition, lab space has been donated to our team by the Fire
Protection Engineering Department at the University of Maryland. Other materials, like voltmeters, wiring, and the display device will be purchased either through Gemstone funds or grants which are currently being researched. The quality and quantity of these items is limited by the funds we can procure.
In the assessment phase we must attempt to ensure that both of our tests maintain an internal and external validity (Leedy & Ormrod, 2005). When conducting the reliability and validity tests, it will be impossible to test every possible configuration of fire and sensor configuration. In addition, due to variations in construction and building codes our tests in the lab will not be representative of all buildings. However, under expert advice, we can choose representative simulations to run. In terms of verifying the tests of the sensors, we can test our measuring devices prior to using them to test the sensors in order to assure reliable data.
In product design methodologies, confounding variables play a minimal role. The product design methodology does not intend to explain a phenomenon, but instead it aims to meet established needs and create better ways to meet those needs. There are certainly many factors that need to be considered in the execution of our project, but confounding variables are not an important consideration in our process.
CONCLUSION
Emergency first responders would have a strong advantage in a building emergency if they could have access to complete information provided by fire sensor systems. Time sensitive data could be conveyed effectively, enabling first responders to better protect both lives and
24

property. It is important for such a system to be easily incorporated into modern structures and must therefore be interoperable across a large variety of sensor technology. Using BACnet, our system will be able to incorporate major companies’ fire sensors as well as other technology like security systems and building health sensors. Our project seeks to create a system that can work with existing technologies effectively with an interface of consistent design, making it easy for first responders to use no matter what technology is involved.
25

References
Davis, W. D., & Evans, D. D. (2004). Interoperable dynamic tactical information for public safety officials. In Fire Suppression and Detection Research Application, 8th Annual
Symposium Proceedings (pp. 1-9). Gaithersburg, MD: National Institute of Standards and
Technology. Retrieved October 23, 2008, from http://fire.nist.gov/bfrlpubs/fire04/art021.html.
Davis, W. D., Holmberg, D. G., Reneke, P. A., Brassell, L., & Vettori, R. (2005). Workshop on the evaluation of a tactical decision aid display (Tech. Rep. No. 7437). Gaithersburg,
MD: National Institute of Standards and Technology. Retrieved October 23, 2008, from http://fire.nist.gov/bfrlpubs/fire05/art105.html. de Jong, Patricia. (n.d.). FDNY LODD - 343 firefighters. Retrieved December 2, 2008, from http://www.fdnylodd.com/9-11-Never-Forget/Memorials/343-Firefighters.html.
Holmberg, D. G., Davis, W. D., Treado, S. J., & Reed, K. A. (2006). Building tactical information system for public safety officials (Tech. Rep. No. 7314). Gaithersburg, MD:
National Institute of Standards and Technology. Retrieved October 29, 2008 from http://fire.nist.gov/bfrlpubs/fire06/art044.html.
Honeywell International Inc. (2008). Honeywell sensing and control . Retrieved October 28,
2008, from http://sensing.honeywell.com/index.cfm/ci_id/154366/la_id/1.htm
.
26

Janssens, M. L. (2003). Basics of passive fire protection. In Arthur E. Cote (Ed.), NFPA fire protection handbook (pp. 103-118). Quincy, MA: NFPA.
Jones, W. W., & Bukowski, R. W. (2001). Critical information for first responders, whenever and wherever it is needed. In
(pp. 1073-1082).
International Interflam Conference, 9th Proceedings: Vol. 2
London: Interscience Communicatons Ltd. Retrieved September 17,
2008 from http://fire.nist.gov/bfrlpubs/fire01/art144.html.
Jones, W. W., Holmberg, D. G., Davis, W. D., Evans, D. E., Bushby, S. T., & Reed, K. A.
(2005). Workshop to define information need by emergency responders during building emergencies (Tech. Rep. No. 7193). Gaithersburg, MD: National Institute of Standards and Technology. Retrieved November 25, 2008 from http://fire.nist.gov/bfrlpubs/fire05/art017.html.
Leedy, P. D., & Ormrod, J. E. (2005). Practical research: Planning and design (8th ed.). Upper
Saddle River, NJ: Davis, K. M.
National Incident Management System. (2007). Incident command system position manual:
Firefighter incident safety and accountability guidelines (Report No. ICS-910).
Riverside, CA: FIRESCOPE. Retrieved October 28, 2008 from http://www.firescope.org/ics-guides-and-terms/ICS%20910.pdf.
Quickstats: The overall fire picture - 2007.
(2008). Retrieved November 12, 2008, from
27

http://www.usfa.dhs.gov/statistics/quickstats/index.shtm.
Thiel, A. (1999). Special report: Improving firefighter communications (Tech. Rep. No. 099).
Emmitsburg, Maryland: U.S. Fire Administration. Retrieved September 17, 2008 from http://www.usfa.dhs.gov/downloads/pdf/publications/tr-099.pdf.
Treado, S. J., Holmberg, D. G., & Cook, S. (2007). Simulating the performance of building area
networks as a communication bridge to emergency responders.
Paper presented at
OPNETWORK, Washington, DC. Retrieved September 23, 2008 from http://www.fire.nist.gov/bfrlpubs/build07/art024.html.
Treado, S. J., Vinh, A., Holmberg, D. G., & Galler, M. (2007). Building information for emergency responders. In N. Callaos, W. Lesso, C.D. Zinn, & H. Yang (Eds.), Systemics,
Cybernetics and Informatics, 11th World Multi-Conference Proceedings: Vol. 3 (pp. 1-6).
Retrieved September 17, 2008, from http://fire.nist.gov/bfrlpubs/build07/art022.html.
28

APPENDIX A – Gantt Chart
The following page is the general timeline that the team has created to document the tasks that need to be completed and their approximated due dates. These tasks come from Gemstone’s
Timeline for Success and the team’s methodology. The milestones represent Gemstone due dates and are based upon previous scheduling of Gemstone dates; these dates will be modified as soon as the actual due dates are given to the team. The tasks that continue for over 300 days are the tasks that need to be done throughout the project. The main tasks of the three phases discussed in the methodology are included in our timeline. Any concerns over in what phase particular tasks fall are answered in the methodology section. In general. Phase 1 starts in Winter 2008 and goes until Fall 2009. Phase 2 starts in Fall 2009 and ends in Spring 2010. Phase 3 starts in Spring
2010 and finishes in Fall 2010.
29

30

APPENDIX B – Budget
Projected Budget
Notes:
According to discussions our team has had with our mentor, Dr. Mowrer, all of the items necessary for us to build a prototype sensor system, including sensors, annunciator panels, and touch screens, would be provided at no charge to us. Therefore, these figures have not been factored into this budget of projected expenses. Lab space may also be provided for us at no charge, but nothing definitive is currently in place. We also plan to supplement our lab work by participating in the NIST Summer Undergraduate Research Fellowship (SURF), an 11-week program that will allow some members of our group to perform research at the NIST Building and Fire Research Laboratory under the guidance of NIST Research Advisors.
Lab Space:
Traveling/Conferences:
$1.00 per square foot per month
15 x 15 lab space = 225 square feet
$225 per month
Total months: 16
Cost: $3,600
4 team members at $220/person
Cost: $880
Miscellaneous Expenses: $100/semester
Cost: $500
31

$880
$500
Lab Space
Conferences
Misc. Expenses
$3,600
32

GLOSSARY
Terms
Addressable - a system where component can be specifically identified by location and function.
Analog - a continuous flow of information from a sensor, as opposed to digital, which sends on/off information only
Dynamic information - the real-time information received from sensor systems that changes according to the situation.
Flashover- the point at which the temperature of the gases reach a high enough temperature to simultaneously ignite all combustible material.
Static information - information available before an emergency occurs that will not change throughout the course of the emergency.
Abbreviations
EFR - Emergency First Responder
NIST- National Institute of Standards and Technology
MFRI - Maryland Fire and Rescue Institute
BFRL - Building and Fire Research Laboratory
SOP - Standard Operating Procedure
GUI - Graphical User Interface
33