Scope:

 

References:

·        First Responder Networking, Draft 4 – 1/12/2007, Spectracom Proposal.

·        Interface Control Document, Revision .1 – 2/12/2007

Overview:            

 

Applications are the ultimate consumers of the information collected by sensors. The display is developed with a design emphasis on extensibility, a structured architecture and provisions to easily adapt itself to other sensor and operating environments.

 

Display Abilities:

 

• Flexibility: The system easily integrates multiple type of sensors in a common framework

·        Real time and latency guarantees: The VSM system software shall send GPS position, heart rate monitor, air temperature etc information to the base station computer. The system ensures that all the data fields are processed in real time minimize the elapsed time between occurrence of an event and detection by system. Once interest is expressed, the framework should have the ability to proactively disseminate collected data to interested parties. The display application should not have to wait for response (blocked), nor should it be made to keep on re-querying the same information (polling).

• Introduce very little or no overhead in terms of time delay and network load.
• Provide Security Mechanisms: This includes authentication, authorization, data integrity and non-repudiation.

 

• To provide a common and platform independent technology base easy to integrate with existing applications.

 

·        The VSM system software shall be able to receive data from the base station computer.

 

 

 

 

 

 

 

 

 

Software Architecture:   

 

The display is designed with an extensible architecture in mind: it is modular and layered at all levels of the design and implementation and is developed as a platform independent tool.

 

A .NET environment is chosen because it offers portability as well as concise GUI and display functionality across a wide range of computers and operating systems. The .Net framework abstracts most of the internal logic that handles the remoting details of method calls and Visual Studio.Net builds support for Web Services directly into the development environment

 

The architecture of the display consists of the following parts:

 

• Embedded System:

Data originates from sensors in incident responder’s embedded units. This data consists of position coordinates, and physiological/environmental measurements from each embedded unit.  As data is collected it must be sent into the embedded device network.

• Input Handling

The content of the raw data sent by the embedded system and delivered to the base station via the embedded device network, must be determined in order to process it correctly. 

• Real-time processing:

The data that enters the base station is processed in real time.  Processing consists of decoding, categorizing and organizing the data by specific device which the data originated, thereby associating information with a specific individual.  There is an emphasis on efficiency and speed to satisfy real time constraints. 

• Data Filtering:

The Processed data is filtered based on preset thresholds for specific physiological and environmental conditions.  Depending on what values a specific embedded device measures and by the amount these values deviate from the thresholds, the device and therefore the device carrier is given a priority.  Device information in a certain priority range can be displayed while information of other priorities can be logged.  In other words the Incident Responders that are in danger is given a high priority and therefore information about those responders is displayed while safe responders’ information is only logged.

• Visualization:

Information that has been collected processed and filtered by the system is mapped into a three-dimensional rendering engine to be displayed via the Graphical User Interface. This rendering engine should be capable of incorporating a model of the current location of the incident and the relative positions of the responders.  

• Graphical User Interface:

The Graphical User Interface (GUI) must not be cluttered with excessive options and functionality.  It must have exactly what an Incident commander wants to use, no more, no less.  An Intuitive GUI design is essential to a successful project. 

Software Architecture Diagram:

 

This includes:

• Embedded System Network:

The embedded systems are the units that each incident responder carries.  Each embedded unit has sensors attached that monitor certain physiological and environmental conditions in real time.  These measurements are sent into a network of embedded units and are delivered to the base station.

 

• Network Interface:

The Network Interface is the entry point of data into the base station.  It transforms raw data from the embedded system network into meaningful data chunks that can be processed and used in the base station.   These data chunks will be assembled following the specifications in the Interface Control document reference. 

 

• Processing Module Set: 

All data passing through the network interface goes to the processing module set.  The data is then categorized and organized according to specific device and sensor from which it originated, thereby associating information with a specific individual.  Based on the sensor from which the data comes, it is dispatched to the proper processing module for further processing and filtering.  The processing module returns the processed data which is then assembled into messages to be given to the database manager.

 

 

• Processing Modules: 

Each processing module is for processing data from a specific sensor.  This is where any formatting, filtering, and prioritizing of data occurs.  When a new sensor is added to the system a new processing module must be added to process data from the new sensor.

 

• Database: 

The database is where all of the processed data is stored.  It is implemented as a relational database.   The relational information stored here includes device ID, device wearer, time, priority/severity, position, and all sensor data values at the given time.

 

• Database Manager: 

The database manager is responsible for all reading and writing to the database.   It will request data from the control module on a set time interval and will not incur delays in displaying real time data.  The database manager will also be responsible for exporting data to external applications. 

 

• Control Module:

The control module maintains the User Interface of the base station.  It is responsible for handling user requests and keeping the visual display updated with real time information.  It accomplishes this by maintaining a real time model of the incident environment constructed from processed data that has been received.  Past data will be delivered to the database manager on a set time interval.   

 

• External Applications:

Data that is written to the database can also be exported to make it available for use by external applications.  This may include exporting data to a tab delineated file or perhaps a printer.

 

• Visualization Module:

The visualization module displays the final data and interface to the user in real time and in an intuitive manner.  When critical priority data (ie, someone is going into cardiac arrest) is displayed, it is very obvious and conveys the urgency of the problem.

 

 

 

System Architecture:

 

• DB Input system/DB embedded: Data is accessed and stored from sensors
• Access points: Data is accessed for different users at different levels.
• Devices that connect to the Display.