GROUP 39

Phase 3 Document

SDD

Tim Hemingway – Gino Buzzelli – Isaac Elbaz – Jonathan Pahl Sam Pezzino – Matthew Hogan11/12/2012

Table of ContentsSection 1: Assumptions/Limitations/Constraints........................................................2

Section 2: Functional Requirements....................................................................................2

Section 2.1: Major Software Modules..............................................................................2

Section 2.1.1: Vital and Natural Data Acquisition Module (VANDAM). . .2

Section 2.1.2: Strategic Location and Observation Module (SLOM)........3

Section 2.1.3: Light Detection and Ranging Module (LADAR)......................3

Section 2.1.4: Redundancy Acquisition Module for Retrieval of Data (RAMROD)..........................................................................................................................................4

Section 2.1.5: Data Extractor and Retrieval Module (DERP)......................6

Section 2.1.6: Intelligent Parser of Data Service (IPODS)......................7

Section 2.1.7: Traffic Information Module (T.I.M).........................................7

Section 2.1.8: External Data Distribution Service (EDDS).........................8

Section 2.1.9: Enhanced Simple Storage Service (ES3)...................................9

Section 3: User Interface Design.......................................................................................10

Section 4: Change Request Control.....................................................................................11

Section 5: Requirements Trace..............................................................................................12

Section 1: Assumptions/Limitations/ConstraintsOur system will have the following constraints:

Assumption: At least three Wifi transceivers must be strategically placed around the incident site.

Assumption: The Wifi receivers will be able to be amplified to an acceptable strength.

Assumption: That distance will be computed accurately based off of Wifi.

Limitation: Signal attenuating material in walls may degrade accuracy.

Limitation: Extremely dense smoke may adversely affect laser mapping. This would not affect location monitoring.

Limitation: If a sensor on a firefighter is to fail, erroneous data may be reported back to the command center.

Constraint: Time in building must be less than battery life.

Section 2: Functional Requirements

Section 2.1: Major Software ModulesThe software modules are broken up into two main groups: the firefighter module and command center module. An overview is given by the following diagram:

Figure 2.1: Overall System Diagram

Firefighter Module

Section 2.1.1: Vital and Natural Data Acquisition Module (VANDAM) The ability of this application to take vital signs will be done

through the use of a sensor cluster and a wristband connected

wirelessly to the unit. Vitals that will be tracked are O2 levels, body

temperature, pulse/heart rate, air temperature, and CO2 levels

A description of these devices and modules are as follows:

Sensor Cluster – Monitoring of CO2 gas and air temperature will be done

with a sensor cluster located on the SCBA apparatus of the

firefighter.

For first responders, this cluster can be stored in a small module

carried around the neck. An addition of sensors in the mask of the

firefighter would be able to take pulse rate and body temperature of

the firefighter as well as the O2 delivered to the firefighter.

Wristband – Pulse rate and body temperature will be able to be taken

for first responders using a wireless wristband.

Vital signs will be monitored on short time intervals and sent back as

determined by the communications module. This interval will ensure

that if there is any threat to the health of the first

responder/firefighter, a proper alert will be forwarded to the command

center alerting them of a problem. Each sensor will send data

separately to ensure that if one sensor fails, all other sensors will

not be interrupted.

Section 2.1.2: Strategic Location and Observation Module (SLOM)The SLOM module is at the heart of the system. It is responsible

for providing the command center with accurate location of the first

responder. Accuracy is of utmost important in this scenario since an

incorrect location is as good as no location.

The idea of using a regular GPS is quickly discarded because it

is unreliable in providing position inside buildings. Even military

grade GPS is not capable of providing the required degree of accuracy.

Instead, triangulation through WiFi signals is employed, which

provides the necessary level of accuracy while maintaining a high

level of feasibility.

Upon arriving at the scene, two WiFi beacons would be deployed

around the building. Together with the beacon installed in the command

center, these form a triangle which surrounds the area of the

building, providing the command center with the capability of finding

the position of each first responder in the building.

Many indoor tracking systems use this approach, and it has been

proven to be both efficient and cost effective. Its benefits are quite

obvious: ease of deployment, extremely quick location, and great

accuracy given the low cost.

Section 2.1.3: Light Detection and Ranging Module (LADAR)Mapping of the area poses many difficulties. Blueprints of buildings

can take too much time to obtain and may not even be feasible. The use

of LIDAR (Light Detection and Ranging) will enable firefighters and

first responders to map a location as they explore an area. Hot spots

and dangerous areas can be marked as they are encountered. This will

allow for all following first responders/firefighters to have mapped

data of the building minimizing the risk of unknown dangers.

The device would be placed on shoulder or helmet of the firefighter

and take scans in a 360-degree radius and return data to create a 3D

image of the area.

The LADAR will communicate

with the Tracking Module to

create and overlay of the

firefighter/first responder

location on top of the 3D

image.

The command post can then

communicate to the firefighter/first responder where to go and where

to avoid.

Section 2.1.4: Redundancy Acquisition Module for Retrieval of Data (RAMROD)

All of the commercially available projects have a crucial

problem: single point of failure. Although this was acceptable years

ago, these days, due to security concerns, it is not anymore.

For the most part, the redundancy module remains quiet; silently

monitoring the health of the connection with the command center. Once

an issue is observed, the redundancy module kicks in and attempts to

setup a connection to another redundancy module within reach. This

connection is established through WiFi Direct (which has practical

range of up to 660 ft) allowing an almost immediate P2P chord network

to be established, allowing partial continuity of service.

Once the WiFi Direct connections are established (which would not

take more than a few milliseconds due to the high speed of WiFi

direct), all the data that was once sent once to the command center is

Sanborn Total Geospatial Solutions

now flowing across each redundancy-module in a distributed matter. Of

course not every command center function can be simulated by the

distributed redundancy modules, but the most important one can: the

vital signs.

The simulation is rather simple: once an abnormality is found in

the vitals of a firefighter, the redundancy-module installed in that

same unit will send a distress message (together with vitals &

position) to its direct neighbor, which will proceed to flood the

entire network with the same message, allowing each firefighter, in

matter of seconds, to see the status and position of the firefighter

in danger, allowing help to arrive much quicker than the old fashioned

“radio way”.

Section 2.1.5: Data Extractor and Retrieval Module (DERP) The purpose of the data processor is to combine data from the vitals and tracking modules. We are planning on formatting the data as XML. The schema is as follows:

<?xml version="1.0" encoding="utf-8"?><xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Data"> <xs:complexType> <xs:sequence> <xs:element name="FirefighterNumber" type="xs:unsignedByte" /> <xs:element name="Timestamp" type="xs:unsignedInt" /> <xs:element name="VitalSign"> <xs:complexType> <xs:sequence> <xs:element name="HeartRate" type="xs:unsignedByte" /> <xs:element name="Oxygen" type="xs:unsignedByte" /> <xs:element name="C02" type="xs:unsignedByte" />

<xs:element name="BodyTemp" type="xs:unsignedByte" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="LocationData"> <xs:complexType> <xs:sequence> <xs:element name="x" type="xs:unsignedByte" /> <xs:element name="y" type="xs:unsignedByte" /> <xs:element name="z" type="xs:unsignedByte" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="MappingData"> <xs:complexType> <xs:sequence> <xs:element name="DLeft" type="xs:decimal" /> <xs:element name="DRight" type="xs:decimal" /> <xs:element name="DFront" type="xs:decimal" /> <xs:element name="DBack" type="xs:decimal" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

Figure 2.2: XML Schema Visualized

Command Center

Section 2.1.6: Intelligent Parser of Data Service (IPODS)The purpose of the data parser is to parse data from the incoming

traffic module and convert it into a form that is acceptable to the

storage and graphics modules. The data that it receives is listed in

figure 2.1. This will be parsed according to the XML schema. All data

will be sent to the storage module in the event further analysis is

warranted. In addition, all data will also be sent to graphics module

for visualization.

Section 2.1.7: Traffic Information Module (T.I.M)A router located at the command and control center will broadcast

a Wi-Fi signal throughout the premises. The antenna of the router will

be amplified as needed to enable communication between the

firefighters and the command center at extended distances. The signal

will be broadcasted through a series of tubes in WPA2 to ensure secure

communications.

The unit carried by each firefighter will be equipped with a Wi-

Fi adapter to send and receive data to and from the command and

control center. Before being sent to the command center, the data

will pass through a processing module.

Figure 2.3: Wireless data link diagram

Section 2.1.8: External Data Distribution Service (EDDS)The propagator module, located in the command center system is

used to pass unprocessed data to other command centers. This can be

used by other command center systems in fire department buildings or

held by other first responder agencies such as the police, National

Guard, or EMTs.

It accomplishes the previously stated task by passing the

unprocessed data to a networked notification service program. The

program waits until command centers register to it, using the on-site

command center's ID, and when it receives data via WiFi it then sends

out the unprocessed data to each command module's traffic module.

  This acts much like an observer system design, where the

observers are the off-site command centers and the subject is the

networked notification service program.

Section 2.1.9: Enhanced Simple Storage Service (ES3)The storage module is not as simple as assuming the

existence of a database. A database, in its basic essence, allows

for the storage of each of the events/data received by the data

parser module.

Certainly, this data will be used by the GUI module, and the

propagator module, but most importantly, the storage module will

provide a sub-module, named reproduction, which will allow for

the replay of events exactly as they happened in real time,

allowing the command center to replay the mission, in order to

find improvement points, possibly minimizing the chances of those

happening again in the next mission.

This module has deep applications: the best way to protect

the first responder’s life is to avoid placing it in unnecessary

dangerous spots. In the heat of the event, both the command

center and first responders cannot quickly spot mistakes being

done. Once the mission is over, both parties have time to analyze

the mission; having this data available could save more lives

than any other module in the system.

Section 3: User Interface DesignFirefighter Unit: The design of the individual units in possession of

the firefighters is designed with the concept of simplicity and ease

of use. The interface is designed to allow for very minimal

interaction with the operator. The operator will likely be in a loud,

dark, and chaotic environment, which would make operating small

equipment difficult, especially in full gear. The unit comes with a

panic button as the only form of input from the user. The unit

passively collects data on its own and transmits it to the Command

Center with no input from the user. The unit requires no

configurations from the user.

Command Center: The interface of the Command Center is also designed

with the idea of simplicity and ease of use. The operator will also be

in a high stress environment and will need to access functionality of

the Command Center unit quickly and effectively. The Command Center

operator should be able to monitor vitals of all of the firefighters

as well as keeping track of their location and maintain the mapping of

the building that operations are being conducted in. The system is not

designed to replace conventional communication methods, only allow for

monitoring of personnel on the inside. Input from the users is limited

to prevent accidental input. The Command Center units are standard

laptops with the software loaded on it. Diagnostics can be done from

the unit itself as well as basic configurations. Basic configurations

include setting the command center up with individuals’ vitals they

are monitoring.

Section 4: Change Request ControlThe following form is to be used by the client in order to initiate a change in our project.

Name of Requestor: ___________________ How to Contact Requestor: ___________________

Date Reported: ___________________

Summary: ___________________________________________________________

___________________________________________________________

Severity: [ ] Low [ ] Medium [ ] High

Description:

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Possible source of the problem:

________________________________________________________________________________________________________________________________

Workaround taken: __________________________________________________________________

________________________________________________________________

Change Desired: ________________________________________________________________________________________________________________________________

-----------------------------------------------------------

Status: [ ] Approved [ ] Declined [ ] Need More InformationReviewed By: _________________________________Review Date: _________________________________

Action Taken: ________________________________________________________________________________________________________________________________

Response:

___________________________________________________________

___________________________________________________________

___________________________________________________________

Action Date: _______________

Section 5: Requirements TraceCommand Center Interface Control Center ModulePersonnel Unit Interface UI Design, Firefighter ModuleAccuracy STARFIRE Module(4.5cm)Security T.I.MReliability RAMRODData Availability EDDS--Future----Future--

Part B

The initial integration thread will be as follows:

This represents a basic subset of our desired final product. This

initial set of requirements is enough where our product would be

useful, but not overly ambitious. Due to time and equipment

constraints, the majority of this demo will be simulated. We are

confident that our system will be feasible in the real world.