Bland_Lab_1

8/7/2019 Bland_Lab_1

1/37


2/37

February 9, 2011

2

Table of Contents

1 Introduction ............................................................................................................................... 42 Product Description .................................................................................................................. 8

2.1 Key Product Features and Capabilities .............................................................................. 82.1.1 - Product Features ........................................................................................................... 92.1.2 Capabilities ................................................................................................................ 10

2.2 Major Components ........................................................................................................... 102.2.1 User Hardware ........................................................................................................... 132.2.2 Other Software ........................................................................................................... 142.2.3 Dispatch User Interface (DUI) .................................................................................. 152.2.4 Master Control Unit Software (MCU)....................................................................... 18

3 Target Market and Customer Base ......................................................................................... 223.1 Initial Market: Old Dominion University......................................................................... 223.2 Campuses ......................................................................................................................... 223.3 Business Complexes and Other ........................................................................................ 23

4 Product Prototype Description ................................................................................................ 24


3/37

February 9, 2011

3

4.1 Prototype Function Goals and Objectives ........................................................................ 254.2 Prototype Architecture ..................................................................................................... 26

4.2.1 Hardware ................................................................................................................... 264.2.2 Software ..................................................................................................................... 28

4.3 Prototype Features and Capabilities ................................................................................. 32Glossary ........................................................................................................................................ 34

A, B, C ....................................................................................................................................... 34D, E, F ....................................................................................................................................... 34G, H, I ........................................................................................................................................ 35J, K, L ........................................................................................................................................ 35M, N, O ..................................................................................................................................... 35P, Q, R ....................................................................................................................................... 36S, T, U ....................................................................................................................................... 36V, W, X, Y, Z ............................................................................................................................ 36

References ..................................................................................................................................... 37


4/37

February 9, 2011

4

1 Introduction

Personal safety has become more of a concern at college campuses with crimes occurring

on defenseless students. At Old Dominion University, crime on and near the campus is

problematic despite having a campus police force to help protect and serve the students and

faculty. Just over the course of two months, twelve crimes were reported around the Old

Dominion University campus in September and October of 2010 (Fig. 1 & 2).

When a crime is committed, it is not always feasible to contact the police immediately for

help. In stances where a person is being held against their own will, whether it is a kidnapping or

a robbery, a simple push of a button could save a life and aid in the prosecution of criminals.

With the Personal Alert and Safety System, no longer will a person have to fumble around trying

to call on their cell phone when time is of the essence. With smartphones these days, unlocking a

phone has become increasingly difficult in order to secure our phones better, but PASS allows a

beacon for help to be sent with your location with a simple button press.


5/37

February 9, 2011

5

Figure 1 - Locations of Crimes in September & October 2010


6/37

February 9, 2011

6

Figure 2 - Key Figure 1 With Crime Details

Even though some campuses, such as Old Dominion University, have their own private

police forces, the victims typically cannot contact the police until afterthe crime has occurred.

For some crimes, this is not adequate, but instead immediate help is needed. The Personal Alert

and Safety System, or PASS, is a product conceived by the Old Dominion University CS410Blue


7/37

February 9, 2011

7

Group in the fall semester of 2010. This product is a system designed to aid is faster response

times with better directions to better assist victims. With PASS implemented on a campus such

as Old Dominion University, where a private police force is present, the campus or facility may

be better protected and the private police force may be better utilized to extend resources.

The Personal Alert and Safety System consists of alert fobs, a system of transceivers, and

various components for the police force. In a crime where a victim was unable to call the police,

they would have the opportunity to send a silent alert to the police of their location and need for

help by simply pressing the button on the fob. The campus police will now be able to find the

person and stop the crime in progress.

Figure 3 - US Department of Justice, Office of Justice Programs, Bureau of Justice

Statistics


8/37

February 9, 2011

8

2 Product Description

PASS will essentially be a personal panic button much like those found on car key fobs.

The difference is that this one does not make a loud noise to scare an assailant off, but instead,

private police or security forces are alerted to your location to assist you. Due to this system

being silent, it is less likely to anger an assailant to harm the victim.

2.1 Key Product Features and Capabilities

There are other personal security devices, but none quite like PASS. PASS will be

expandable for large campuses and it will feed location and profile information to the police

forces. Each user of the PASS system will be linked to a particular fob, and to that fob, a profile

of the user. In this manner, alerts will not only tell the police and security forces where the crime

has been committed, but also who the suspected victim is with a some other biological

information such as height, age, sex, etcetera.

Figure 4 - Comparison Chart of Similar Systems


9/37

February 9, 2011

9

Figure 5 - General High-Level Operation View

2.1.1 - Product Features

The Personal Alert and Safety System will consist of three general modules:

1. Fobs These Devices will be used to silently and quickly alert police for help.

2. Transceivers These small transceivers will both receive the alerts from the users, but it

will also relay the message to the police.


10/37

February 9, 2011

10

3. Master Unit This part will include the brains of the system. It will start from the

receiving the alerts to the interface that alerts the police. This will also include the main

database where all the data for the system will be stored.

2.1.2 Capabilities

PASS will:

Send alerts to private police forces.

Police will receive an approximated location for alerts and a profile of the fobs owner.

The system will be expandable for a growing campus. No one PASS is the same, so it

was designed to customizable.

2.2 Major Components

Major components are:

Fobs Custom made for PASS. In the case of college campuses, it is suggested every

faculty member and student be given one.

Transceivers Number depends on size of application, geography, etc.

Master Receiver - A minimum of two transceivers set to receive only mode. One

transceiver will be used as the MR and at least one for backup.

Master Control Module (MCM) Software for receiving alerts, location information,

and user profile information.

Dispatch User Interface (DUI) - Browser-based web forms application using ASP.NET

or equivalent technologies.


11/37

February 9, 2011

11

Database Server - Microsoft SQL Server database server

Features Real World Product

Fob Custom, manufactured

Transceivers

A network of thousands of transceivers, each encased in

a weatherproof enclosure with a solar power /

conventional battery power option. They will be

mounted to a building, pole or other existing structure.

Master Receiver

A minimum of two transceivers set to receive only

mode. One transceiver will be used as the MR and at

least one for backup.

Master Control Module Suite of software

Dispatch User InterfaceBrowser-based web forms application using ASP.NET

or equivalent technologies.

Website

Hosted on an independent web server that manages

communication for customer support, base package

quotes and product registration

Database Server Microsoft SQL Server database server

Figure 6 - Real World Product Hardware


12/37

February 9, 2011

12

Figure 7 - Data Flow Map


13/37

February 9, 2011

13

Figure 8 - Database Schema

2.2.1 User Hardware

The user hardware will consist of a security fob. This fob will send signals to the

transceivers when the mechanism is depressed. The fob will have a unique identity that points to

a unique user profile to which the fob is assigned. In this way abuse may be curbed, and better

aid given via user profiles.


14/37

February 9, 2011

14

Figure 9 - Various Fobs

2.2.2 Other Software

Other software will include a security fob registration component. This software will

allow the user profiles to be built that will be linked to each fob. Here the bio user may be built.

Typical information stored here may be, but not limited to: user photo, name, sex, eye color,

height, weight, ethnicity, important medical information, etc.

Table 1 - User Registration Program Algorithms

Name Description

addUserCalls DB using create_user call and

supplying necessary variables.

addFobCalls DB using create_fob and supplying

necessary variables

linkUserToFobCalls DB using update_fob and supplying

necessary variables

deleteUser Calls DB using delete_user

deleteFob Calls DB using delete_fob

deactiveFob Calls DB using deactive_fob

Table 2 - Transceiver Registration Algorithms

Name Description

addTransceiver Calls DB using create_transceiver

deleteTransceiver Calls DB using delete_transceiver

updateTrasceiver Calls DB using update_transceiver


15/37

February 9, 2011

15

2.2.3 Dispatch User Interface (DUI)

The Dispatch User Interface, or DUI, will include the software at which police will

receive the alerts from. This will have an interactive map of the particular PASS system site,

with the initial site being Old Dominion University. When alerts are received, the location will

be displayed on the map, and further information may be brought up such as the bio of the user.

Figure 10 - Dispatch User Interface (DUI)


16/37

February 9, 2011

16

Table 3 - Dispatch User Interface (DUI) Application Algorithms

Name Description

DisplayMapThis algorithm displays an indication of a

map on the UI screen.

DisplayLogInfo

This algorithm displays the Incident Log

information in an easily editable manner on

the UI screen.

DisplayAlertOnMap

This algorithm displays an indication of an

alert on the map on the main UI screen. It

will place a red indicator over the center of

the alert area. It will then show circle

indicating the radius of the alert. It will

redraw the incident every 30 seconds or so

based on new input from the transceiver

networks.

UpdateLog

This algorithm takes the information entered

into the UI screen and updates an Incident

Object. That object is then passed to the

MCM (using updateIncident).

DisplayUserInfo

This algorithm displays the User information

that is based on the key fob information

received from the MCM. It will display the

information on the UI screen in an area that is

not editable.

ShowTransceiverStatus

This algorithm makes a call to the MCM

(getAllTransceivers) and displays the results

on a separate UI screen from the map. The

display should have an easy to read way to

display the status. (Green status indicator for

OK, red for MAINTENANCE, BLACK for

dead). Should also display the coordinates of

each transceiver and a way to send those

coordinates to the map.


17/37

February 9, 2011

17

Table 4 - Dispatch User Interface (DUI) Web Interface Algorithms

Name Description

getAllIncidentsByDate

Makes an AJAX call to the Dispatch Web

Server calling the function

getAllIncidentsByDate expecting an

array as a result. The response is then

converted into a HTML fragment to be

placed on the page in real time.

getIncident


Server calling the function getIncidents

expecting a JSON array as a result. The

response is then converted into a HTML

fragment to be placed on the page in real time.

getUserInfo


Server calling the function getUserInfo

expecting a JSON array as a result. The

response is then converted into a HTML

fragment to be placed on the page in real time.

getTransceiverStatus


Server calling function

getTransceiverStatus expecting a JSON

array as a result. The response is then

converted into a HTML fragment to beplaced on the page in real time.

getAllTransceiverStatus


Server calling function

getAllTransceiverStatus expecting a

JSON array as a result. The response is

then converted into a HTML fragment to

be placed on the page in real time.

getAllUsers


Server calling function getAllUsers

expecting a JSON array as a result. Theresponse is then converted into a HTML

fragment to be placed on the page in real

time.

setIncidentLog


Server calling function setIncidentLog

and sending text.


18/37

February 9, 2011

18

pollServer

The client initiates a Comet message using

AJAX and waits for the server to return data.

Upon return, that data is acted upon and

another AJAX message is created and sent.

drawPoint

Using data from pollServer's response, it

draws the point of intersection between one tothree points.

2.2.4 Master Control Unit Software (MCU)

The MCU has software that the DUI runs on top of. They are very similar and can be

considered one in the same. The difference is the side menus that are open.

Figure 11 - Master Control Unit (MCU) Software


19/37

February 9, 2011

19

Table 5 - Master Control Unity (MCU) Algorithms

Name Description

ReceiveSignal

This algorithm utilizes a hardware interrupt

watching the USB port for a call from the

Master Receiver.

DisectSignal

This algorithm splits the signal into its parts

(Transceiver, Fob, Status). Then it builds

objects to be used in other routines. The final

stage calls the RouteData algorithm. Will

call: GetTransceiver, GetFob, GetUser,

GetStatus, RouteData

GetTransceiver

Uses the 2 byte input as an unsigned integer

and retrieves the transceiver data from thedatabase calling select_transceiver_recordID.

Once the data is retrieved it uses that data to

build a Transceiver object.

GetFob

Uses the 2 byte input as an unsigned integer

and retrieves the fob data from the database

calling select_fob_recordid - if and only if the

2 bytes != 0. Once the data is retrieved it uses

the data to build a Fob object.

GetUser

Uses the integer value of stored in the fob

object for the user id to access the user info

from the database using select_user_recordid.

Once the data is retrieved it uses the data to

build a User object.

GetStatus

Uses the 1 byte array for status and returns an

enumeration coinciding with the byte code

value.

RouteData

This algorithm examines the status

enumeration and determines what to do with

the all of the objects that were created in

DisectSignal.

If the status is NORMAL then we know it

was an alert and that we need to treat it assuch. It will call: ProcessAlert

If the status is OK / MAINTENANCE we

know it was a health pulse. It will call

ProcessHealthPulse.


20/37

February 9, 2011

20

ProcessAlert

This algorithm process an alert signal. It

queries the database for an incident with that

fob within 10 seconds of the current time. If

it finds one then it assumes that it is the same

incident and adds the transceiver ID to the

incident_transceiver_list in the database.

If it doesn't find an incident log then it will

create one. And then add the transceiver ID

and new incident log ID to the

incident_transceiver_list in the database.

Once the number of transcievers attached to

an incident log is 3 or greater then the

location algorithm is triggered and the result

is stored in an Alert Object.

A call is then made to the Dispatch User

Interface to display the alert and user info.

This algorithm calls: select_incidentLog_all,

select_incidentLog_recordID,

select_incident_transceiver_all,

create_incident_transceiver,

create_incidentLog

ProcessHealthPulse

This algorithm processes a health pulse

signal. It sets the status of a transceiver based

on the StatusEnum. It will call:

update_transceiver

getLocation

This algorithm uses the locations of thetranscievers associated with the incident to

determine the location of the alert. An alert

object is created and returned to the calling

function/procedure. The alert object has two

primary properties/fields: center and radius.

The center of the alert is the center point of

overlapping transceiver receiving signal

circles and the radius is the margin of error.

getAllIncidents

This algorithm queries the database for all of

the incident logs between (inclusive) of the

dates provided. For each record returned by

select_incidentLog_Dates, an Incident objectis created from the data stored in the record.

getAllTransceivers

This algorithm queries the database for all of

the transceiver records using:

select_transceiver_all. For each record

returned a new Transceiver object is added to

the collection.


21/37

February 9, 2011

21

updateIncident

This algorithm updates the data in the

IncidentLog table of the database based on the

properties of the provided Incident object.

This algorithm is called from the DUI. It

calls: update_incidentLog


22/37

February 9, 2011

22

3 Target Market and Customer Base

The Personal Alert and Safety System has a large market in which it could be applied.

The fact that it is adjustable for individual applications and can grow as large as needed. The

technology is well tested and proven, thus allowing it to easily adjust to many applications.

Because of this, the applicable market is very large, and with various configurations of Personal

Alert and Safety System, even more markets may be reachable.

3.1 Initial Market: Old Dominion University

The initial market will be for Old Dominion University. This will allow statistics and

adjustments for the product to be made before full marketing begins. The location will provide

an ideal location for the initial market, as it is a campus with high crime rates in an urban

environment. With a large student population, faculty, and staff, this will truly be test for proof

of concept and real world use.

3.2 Campuses

College campuses have been the location of many horrific events ranging from minor

fights or robberies to massacres with a deranged student. Because of the dense population in

these areas with easy targets for criminals, these are all ideal locations for a Personal Alert and

Safety System to be installed. The market will grow into this market following the initial

installation at Old Dominion University.


23/37

February 9, 2011

23

3.3 Business Complexes and Other

Later in the development of PASS, the market may be expanded to businesses and other

complexes such as government buildings and hospitals. Complexes such as the Googleplex,

would be also be excellent applications as well where large buildings are present with many

employees. Even prisons would be great applications where prison fights may break out and an

officer may get held hostage. Even high schools could be used as well, but limiting fobs to only

faculty.


24/37

February 9, 2011

24

4 Product Prototype Description

The Personal Alert and Safety System, unfortunately is a large system to prototype fully.

Because of this, the scope of the project must be limited. There are a few key differences

between the real world product and the prototype. In Figure 10, the differences are outlined.

Because the project is so large, previously tested technology will not be the focus of our

prototype, so few transceivers will be used; however, heavy testing will rely on the prototyped

Master Control Module and Master Receiver. This is where PASS will be shown in a proof-of-

concept.

Features Prototype

FobNordic Fob (WRL-08602)

Transceivers

One transceiverincorporated into anArduino prototypeboard (HardwareTest). Network oftransceivers will besimulated usingsoftware.

Master ReceiverSimulated usingsoftware.

Master ControlModule

Single process,different threadssimulating differentaspects of RWPsuite.

Dispatch UserInterface

C# Windowsapplication

Website

Not simulated ortested for this

phase.

Database Server

Microsoft SQLServer Express ontest platform

Figure 12 - Prototype Equivalent Components.


25/37

February 9, 2011

25

4.1 Prototype Function Goals and Objectives

In order to make this prototype feasible, scoping is an issue. Some general assumptions

will need to make made:

Table 6 - Assumptions Table for Prototype

1. Weather We assume that there are perfect atmospheric conditions, i.e. the weather isbright and sunny and a perfect 72 degrees Fahrenheit.

2. Radio

InterferenceNo radio interference exists; therefore we will not worry about signals onthe same wavelength.

3. Simulated Areas The selected areas for simulation represent realistic expectations ofcampuses.

4. Valid Users Anyone accessing the dispatch user interface web application will beassumed to be a valid user negating the need for a login utility.

5. Hardware

Accuracy

For the purposes of simulation, we will also ignore hardware malfunctions.

The three most important assumptions here are weather and hardware accuracy. These

two components are far too complicated to predict in a timely manner for prototyping purposes.

Negating this extra work to calculate, prototyping as a proof-of-concept will be made much more

easily. Another important assumption is that there will be no radio interface. On a larger scale,

this may be impossible to ignore; however, in the case here, it is negligible.


26/37

February 9, 2011

26

4.2 Prototype Architecture

Figure 13 - Prototype Operational View

Figure 13 is the representation of our expected prototype. Specifically the operational

view of the system is show.

4.2.1 Hardware

For prototyping purposes the below tables represent algorithms that will be tested on the

hardware side of the PASS project. These specific algorithms will test the microcontroller-driven

transceiver that will act as the master receiver. A very important command here is ReceiveSignal.

With this command, alert signal from a fob will be received and passed to the MCM.


27/37

February 9, 2011

27

Figure 14 - Hardware Process Model

Table 7 - Microcontroller-Driven Transceiver Algorithms

Name Input Output Description

ReceiveSignal 4 bytes 2 bytes

Receives 4 bytes from fob. Ignoring the lat

bytes, it translates these initial bytes into b

presses and passes the value to writeConso

WriteConsole 2 bytes character array

Receives the button presses from ReceiveS

and calls native println() sending data alon

USB connection to listening program oncomputer.


28/37

February 9, 2011

28

The other hardware aspect to be tested is the fob. Here we must make sure the prototype

will be able to read the button input and send the alert signal via ReadButtons and SendSignal

functions. These are the two main functions of the fob.

Table 8 - Fob-Driven Algorithms

Name Input Output Description

ReadButtons button press 4 bytes

Determines which button was pressed. Add

the total button presses. Sends both numbe

bytes total, to SendSignal.

SendSignal 4 bytes 4 bytes

Transmits 4 bytes. First set of 2 bytes

representing the button pressed and the late

bytes as the total number of button presses

4.2.2 Software

The prototype will rely heavily on software testing as much of the hardware is being

simulated. As the software process model shows, the simulated network will be connected to the

database and the database to the Dispatch User Interface. This is also the general view of the

prototype data flow.


29/37

February 9, 2011

29

Figure 15 - Software Process Model

Because the prototype relies so heavily on the production of software components, many

algorithms and functions were developed to make this possible. The Transceiver Network

Simulation would be a real network of transceivers in the RWP as a hardware component;

however, here, we have a simulation of it as a software component of the prototype.

Table 9 - Transceiver Network Simulation

Name Description

getTrancieverLocation Displays location of individual reciever

getAllIncidents

Starts the network Simulation, draws a

circle around key fob and outputs data to

GUI

getUserInfo Displays User ID on the GUI

StartTranceiverWave

Uses the location from first transceivers to

receive the signal and then increments it,

causing all transceivers in the path to blink

getFobLocation

gets location of Fob from tranceivers in

range

drawPoint

Uses location data from transceivers listed

as reporting to the incident ID passed to and

processed by incidentAlert

getTrancieverStatus finds the closest transceivers to the key fob

getFobID Displays fob ID


30/37

February 9, 2011

30

Table 10 - Database Stored Procedures

Name Description

delete_IncidentLogRemoves a row from

INCIDENT_LOG

update_IncidentLogUpdates an

INCIDENT_LOG row.

create_IncidentLogCreates a new row in

INCIDENT_LOG table

select_incidentLog_AllGets all Incidents logged to

the database

select_incidentLog_RecordIDGets the record with the ID

provided.

select_incidentLog_Dates

Gets all incidents logged

between (inclusive) the

dates provided.

create_user

Creates a new row in

USER_INFO; called from

registerUser

update_userUpdates a row in the

User_Info table.

select_user_all Gets all User_Info records

select_user_recordIDGets the record with the ID

provided.

delete_userRemoves a row from the

User_Info table.

create_fobCreates a new row in the

Fob_Info table.

update_fobUpdates a row in the

Fob_Info table.

select_fob_allGets all rows from the

Fob_Info table.

select_fob_recordidGets the record with the ID

provided.

select_fob_all_active

Gets all rows from the

Fob_Info table that are

marked as active.deactivate_fob Sets isActive to false

delete_fobRemoves a row from the

Fob_Info table.

create_incident_transceiver

Creates a new record in the

Incident_Transceiver_List

table.

update_incident_transceiverUpdates a record in the



31/37

February 9, 2011

31

table.

select_incident_transceiver_all

Gets all rows from the


table.

select_incident_transceiver_recordIDGets the record with the ID

provided.

select_incident_transceiver_incidentID

Gets all rows from the table

that match the provided

IncidentID

delete_incident_transceiver

Removes a row from the


table.

delete_incident_transceiver_incidentID

Removes all rows from the


table that have a matching

IncidentID

create_transceiverCreates a record in the

Transceiver_Info table.

update_transceiverUpdates a record in the


select_transceiver_allGets all of the records in the


select_transceiver_recordidGets the record with the ID

provided.

delete_transceiverRemoves a row from the

Transceiver_info table.

Table 11 - Dispatch User Interface (DUI) Application

Name Description

getAllIncidents

Calls DB procedure

select_IncidentLog_Dates requesting all

incidents from time period x to y.

getIncident Calls DB requesting a single incident.

getUserInfo

Calls DB requesting a single user's

information using the linked Fob ID.

getTransceiverStatus

Calls select_transceiver_recordID andparses the row for the status field and then

returns that.

getAllTransceiverStatus

Calls DB select_transceiver_all and parses

each row for status field. Returns an array

of pairs of all status messages indexed by

transceiver ID.

getAllUsers Calls DB select_user_all


32/37

February 9, 2011

32

setIncidentLog

Calls DB update

select_IncidentLog_RecordID and then

calls DB again using returned data but

changing Description for

update_IncidentLog

incidentAlert

Upon receiving message from MRL's

notifyApplication, it requests data using

select_incident_transceiver_RecordID and

passes it to necessary drawing functions.

drawPoint

Uses location data from transceivers listed as

reporting to the incident ID passed to and

processed by incidentAlert

4.3 Prototype Features and Capabilities

As said before, the prototype is being scaled down in terms of scope. A major change is

the lack of a physical network of transceivers, but instead a simulated network component will

be added for testing purposes. The general product has been kept intact; however as seen in the

chart, certain parts were omitted or replaced to save on money, time, and to eliminate

unnecessary variables for testing purposes.

Features Real World Product Prototype

Fob Custom, manufactured

Nordic Fob (WRL-

08602)

Transceivers

A network of

thousands of

transceivers, each

encased in a

weatherproof

enclosure with a solar

power / conventional

battery power

option. They will be

mounted to a building,

pole or other existing

structure.

One transceiver

incorporated into an

Arduino prototype

board (Hardware

Test). Network of

transceivers will be

simulated using

software.


33/37

February 9, 2011

33

Master Receiver

A minimum of two

transceivers set to

receive only mode.

One transceiver will

be used as the MR and

at least one for

backup.

Simulated using

software.

Master Control

Module Suite of software

Single process,

different threads

simulating different

aspects of RWP suite.

Dispatch User

Interface

Browser-based web

forms application

using ASP.NET or

equivalent

technologies.

C# Windows

application

Website

Hosted on anindependent web

server that manages

communication for

customer support, base

package quotes and

product registration

Not simulated or

tested for this phase.

Database Server

Microsoft SQL Server

database server

Microsoft SQL Server

Express on test

platform

Figure 16 - RWP vs. Prototype Feature Comparison Chart


34/37

February 9, 2011

34

Glossary

A, B, C

AJAX- Shorthand for Asynchronous JavaScript and XML. AJAX is a collection of web

development technologies used together to create interactive webpages.

Algorithm Finite list of well-defined instructions for calculating a function with predefined

input.

Alert Signal When the fob button is depressed, it transmits a signal to the transceivers known

as an alert signal.

Arduino Microcontroller to interface the main system running the software suite and the

master receiver.

ASPActive Server Pages, a Microsoft server-side script-engine.

Bit A unit of digital information that has two distinct states.

Byte A unit of digital information that has 8 bits total.

C# - An object oriented programing language from Microsoft.

D, E, F

Database System that manages data and allows data to be entered and removed.

Database Procedures Commands that allow data to be modified, retrieved, and entered into a

database.

Dispatch Station Location where emergency calls come in.

Dispatch Personnel Operators of the phones and support staff of the dispatch station.


35/37

February 9, 2011

35

Dispatch User Interface Interface of the software in which dispatch personnel will operate the

PASS with.

Dispatch Web Server Server hosting the web interface for a particular PASS installation.

Driver Software to interface computer components to the main machine and operating system.

Fob Transmitter that allows user to send an alert out.

Fob Registration Process of linking a user to a fob i.e. user ID linked to a fob ID.

G, H, I

GUI Graphical User Interface

Hardware Enclosure - Enclosure to house a piece of hardware.

Health Pulse Signal for the health of a transceiver.

Hop Count How many transceivers it takes to link an alert to the master receiver.

HTML Hyper Text Markup Language.

J, K, L

JSON JavaScript Object Notation

LED - Light Emitting Diode

Location Algorithm Algorithm used for determining the location of an alert.

M, N, O

Master Control Module The brains of the PASS installation. This includes the Master

Receiver, servers, etc.

Master Receiver The receiver connected to the MCM. This receiver will be the last to receive

an alert signal.

MCM See Master Control Module.


36/37

February 9, 2011

36

Microcontroller - A small integrated circuit with a dedicated CPU and memory typically used

for embedded applications.

ODU Old Dominion University

P, Q, R

PASS Personal Alert and Safety System

Prototype Original of a product, typically used for initial building statistics and testing.

Receiver Receives radio transmissions.

RF Radio Frequency.

RWP Real World Product

S, T, U

Solar Panel Small panel that that is used to turn solar energy into electrical energy.

SQL Server Database server using SQL.

Stored Procedure Function used to retrieve data.

Transceiver Small piece of hardware that both sends and receives radio transmissions.

Transceiver Network An ad-hoc network of transceivers.

Transceiver Registration Program

Transmitter Sender of a transmission such as a fob.

User Registration Program Program for assigning a fob to a user.

USB (Universal Serial Bus) Interface used for computer peripherals.

V, W, X, Y, Z


37/37

February 9, 2011

References

Faculty and Staff. (2008, November 13). Retrieved February XX, 2011, from Old

Dominion University: http://www.odu.edu/oduhome/faculty.shtml

NOTE: used for personnel statistics

Old Dominion University. (2011, January). Retrieved February XX, 2011, from

Education-Portal.com:

http://education-portal.com/directory/Old_Dominion_University.html

NOTE: used for personnel statistics

Wilson, Patrick (2010, November 03). Robbery crimes at or near campus. The

Virginian-Pilot, p. B3.

Bureau of Justice Statistics. (2007). A National Crime Victimization Survey,

2007--Statistical tables (NCJ 227669).

Bland_Lab_1

Documents