Personal Alert and Safety System

Lab 1 – Personal Alert and Safety System Product Description

Gordon Bland

CS411

Gene Price

February 9, 2011
 February 9, 2011

Table of Contents

1 – Introduction ............................................................................................................................... 4  

2 – Product Description .................................................................................................................. 8  

2.1 – Key Product Features and Capabilities .............................................................................. 8  

2.1.1 - Product Features ........................................................................................................... 9  

2.1.2 – Capabilities ................................................................................................................ 10  

2.2 – Major Components ........................................................................................................... 10  

2.2.1 – User Hardware ........................................................................................................... 13  

2.2.2 – Other Software........................................................................................................... 14  

2.2.3 – Dispatch User Interface (DUI) .................................................................................. 15  

2.2.4 – Master Control Unit Software (MCU)....................................................................... 18  

3 – Target Market and Customer Base ......................................................................................... 22  

3.1 – Initial Market: Old Dominion University......................................................................... 22  

3.2 – Campuses ......................................................................................................................... 22  

3.3 – Business Complexes and Other ........................................................................................ 23  

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

2
 February 9, 2011

4.1 – Prototype Function Goals and Objectives ........................................................................ 25  

4.2 – Prototype Architecture ..................................................................................................... 26  

4.2.1 – Hardware ................................................................................................................... 26  

4.2.2 – Software ..................................................................................................................... 28  

4.3 – Prototype Features and Capabilities ................................................................................. 32  

Glossary ........................................................................................................................................ 34  

A, B, C....................................................................................................................................... 34  

D, E, F ....................................................................................................................................... 34  

G, H, I ........................................................................................................................................ 35  

J, K, L ........................................................................................................................................ 35  

M, N, O ..................................................................................................................................... 35  

P, Q, R ....................................................................................................................................... 36  

S, T, U ....................................................................................................................................... 36  

V, W, X, Y, Z ............................................................................................................................ 36  

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

3
 February 9, 2011

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.

4
 February 9, 2011

Figure 1 - Locations of Crimes in September & October 2010

5
 February 9, 2011

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 after the 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
6
 February 9, 2011

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

7
 February 9, 2011

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

8
 February 9, 2011

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.

9
 February 9, 2011

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 fob’s 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.

10
 February 9, 2011

• Database Server - Microsoft SQL Server database server

Features Real World Product

Fob Custom, manufactured

A network of thousands of transceivers, each encased in

a weatherproof enclosure with a solar power /
Transceivers
conventional battery power option. They will be
mounted to a building, pole or other existing structure.

A minimum of two transceivers set to receive only

Master Receiver mode. One transceiver will be used as the MR and at
least one for backup.

Master Control Module Suite of software

Browser-based web forms application using ASP.NET

Dispatch User Interface
or equivalent technologies.

Hosted on an independent web server that manages

Website communication for customer support, base package
quotes and product registration

Database Server Microsoft SQL Server database server

Figure 6 - Real World Product Hardware

11
 February 9, 2011

Figure 7 - Data Flow Map

12
 February 9, 2011

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.

13
 February 9, 2011

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
Calls DB using create_user call and
addUser
supplying necessary variables.
Calls DB using create_fob and supplying
addFob
necessary variables
Calls DB using update_fob and supplying
linkUserToFob
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

14
 February 9, 2011

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)

15
 February 9, 2011

Table 3 - Dispatch User Interface (DUI) Application Algorithms

Name Description
This algorithm displays an indication of a
DisplayMap
map on the UI screen.
This algorithm displays the Incident Log
DisplayLogInfo information in an easily editable manner on
the UI screen.
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
DisplayAlertOnMap
indicating the radius of the alert. It will
redraw the incident every 30 seconds or so
based on new input from the transceiver
networks.

This algorithm takes the information entered

into the UI screen and updates an Incident
UpdateLog
Object. That object is then passed to the
MCM (using updateIncident).

This algorithm displays the User information

that is based on the key fob information
DisplayUserInfo received from the MCM. It will display the
information on the UI screen in an area that is
not editable.

This algorithm makes a call to the MCM

ShowTransceiverStatus
(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.

16
 February 9, 2011

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

Name Description
Makes an AJAX call to the Dispatch Web
Server calling the function
getAllIncidentsByDate expecting an
getAllIncidentsByDate
array as a result. The response is then
converted into a HTML fragment to be
placed on the page in real time.
Makes an AJAX call to the Dispatch Web
Server calling the function getIncidents
getIncident 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.

Makes an AJAX call to the Dispatch Web

Server calling the function getUserInfo
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.

Makes an AJAX call to the Dispatch Web

Server calling function
getTransceiverStatus expecting a JSON
getTransceiverStatus
array as a result. The response is then
converted into a HTML fragment to be
placed on the page in real time.

Makes an AJAX call to the Dispatch Web

Server calling function
getAllTransceiverStatus expecting a
getAllTransceiverStatus
JSON array as a result. The response is
then converted into a HTML fragment to
be placed on the page in real time.

Makes an AJAX call to the Dispatch Web

Server calling function getAllUsers
expecting a JSON array as a result. The
getAllUsers
response is then converted into a HTML
fragment to be placed on the page in real
time.
Makes an AJAX call to the Dispatch Web
setIncidentLog Server calling function setIncidentLog
and sending text.

17
 February 9, 2011

The client initiates a Comet message using

AJAX and waits for the server to return data.
pollServer
Upon return, that data is acted upon and
another AJAX message is created and sent.
Using data from pollServer's response, it
drawPoint draws the point of intersection between one to
three 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

18
 February 9, 2011

Table 5 - Master Control Unity (MCU) Algorithms

Name Description
This algorithm utilizes a hardware interrupt
ReceiveSignal watching the USB port for a call from the
Master Receiver.
This algorithm splits the signal into its parts
(Transceiver, Fob, Status). Then it builds
objects to be used in other routines. The final
DisectSignal
stage calls the RouteData algorithm. Will
call: GetTransceiver, GetFob, GetUser,
GetStatus, RouteData

Uses the 2 byte input as an unsigned integer

and retrieves the transceiver data from the
GetTransceiver database calling select_transceiver_recordID.
Once the data is retrieved it uses that data to
build a Transceiver object.

Uses the 2 byte input as an unsigned integer

and retrieves the fob data from the database
GetFob 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.

Uses the integer value of stored in the fob

object for the user id to access the user info
GetUser from the database using select_user_recordid.
Once the data is retrieved it uses the data to
build a User object.

Uses the 1 byte array for status and returns an

GetStatus enumeration coinciding with the byte code
value.
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

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

If the status is OK / MAINTENANCE we

know it was a health pulse. It will call
ProcessHealthPulse.

19
 February 9, 2011

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.

ProcessAlert 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

This algorithm processes a health pulse

signal. It sets the status of a transceiver based
ProcessHealthPulse
on the StatusEnum. It will call:
update_transceiver

This algorithm uses the locations of the

transcievers associated with the incident to
determine the location of the alert. An alert
object is created and returned to the calling
getLocation 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.

This algorithm queries the database for all of

the incident logs between (inclusive) of the
getAllIncidents dates provided. For each record returned by
select_incidentLog_Dates, an Incident object
is created from the data stored in the record.

This algorithm queries the database for all of

the transceiver records using:
getAllTransceivers select_transceiver_all. For each record
returned a new Transceiver object is added to
the collection.

20
 February 9, 2011

This algorithm updates the data in the

IncidentLog table of the database based on the
updateIncident properties of the provided Incident object.
This algorithm is called from the DUI. It
calls: update_incidentLog

21
 February 9, 2011

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.

22
 February 9, 2011

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.

23
 February 9, 2011

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
Nordic Fob (WRL-
Fob 08602)
One transceiver
incorporated into an
Arduino prototype
board (Hardware
Test). Network of
transceivers will be
simulated using
Transceivers software.
Simulated using
Master Receiver software.
Single process,
different threads
simulating different
Master Control aspects of RWP
Module suite.
Dispatch User C# Windows
Interface application
Not simulated or
tested for this
Website phase.

Microsoft SQL
Server Express on
Database Server test platform
Figure 12 - Prototype Equivalent Components.

24
 February 9, 2011

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 is
bright and sunny and a perfect 72 degrees Fahrenheit.
2. Radio No radio interference exists; therefore we will not worry about signals on
Interference the same wavelength.
3. Simulated Areas The selected areas for simulation represent realistic expectations of
campuses.
4. Valid Users Anyone accessing the dispatch user interface web application will be
assumed to be a valid user negating the need for a login utility.
5. Hardware For the purposes of simulation, we will also ignore hardware malfunctions.
Accuracy

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.

25
 February 9, 2011

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.

26
 February 9, 2011

Figure 14 - Hardware Process Model

Table 7 - Microcontroller-Driven Transceiver Algorithms

Name Input Output Description

Receives 4 bytes from fob. Ignoring the later 2
ReceiveSignal 4 bytes 2 bytes bytes, it translates these initial bytes into button
presses and passes the value to writeConsole.
Receives the button presses from ReceiveSignal
and calls native println() sending data along
WriteConsole 2 bytes character array
USB connection to listening program on
computer.

27
 February 9, 2011

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

Determines which button was pressed. Adds to
ReadButtons button press 4 bytes the total button presses. Sends both numbers, 4
bytes total, to SendSignal.
Transmits 4 bytes. First set of 2 bytes
SendSignal 4 bytes 4 bytes representing the button pressed and the later 2
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.

28
 February 9, 2011

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
Starts the network Simulation, draws a
circle around key fob and outputs data to
getAllIncidents GUI
getUserInfo Displays User ID on the GUI

Uses the location from first transceivers to

receive the signal and then increments it,
StartTranceiverWave causing all transceivers in the path to blink
gets location of Fob from tranceivers in
getFobLocation range
Uses location data from transceivers listed
as reporting to the incident ID passed to and
drawPoint processed by incidentAlert

getTrancieverStatus finds the closest transceivers to the key fob

getFobID Displays fob ID

29
 February 9, 2011

Table 10 - Database Stored Procedures

Name Description
Removes a row from
delete_IncidentLog
INCIDENT_LOG
Updates an
update_IncidentLog
INCIDENT_LOG row.
Creates a new row in
create_IncidentLog
INCIDENT_LOG table
Gets all Incidents logged to
select_incidentLog_All
the database
Gets the record with the ID
select_incidentLog_RecordID
provided.
Gets all incidents logged
select_incidentLog_Dates between (inclusive) the
dates provided.
Creates a new row in
create_user USER_INFO; called from
registerUser
Updates a row in the
update_user
User_Info table.
select_user_all Gets all User_Info records
Gets the record with the ID
select_user_recordID
provided.
Removes a row from the
delete_user
User_Info table.
Creates a new row in the
create_fob
Fob_Info table.
Updates a row in the
update_fob
Fob_Info table.
Gets all rows from the
select_fob_all
Fob_Info table.
Gets the record with the ID
select_fob_recordid
provided.
Gets all rows from the
select_fob_all_active Fob_Info table that are
marked as active.
deactivate_fob Sets isActive to false
Removes a row from the
delete_fob
Fob_Info table.
Creates a new record in the
create_incident_transceiver Incident_Transceiver_List
table.
Updates a record in the
update_incident_transceiver
Incident_Transceiver_List

30
 February 9, 2011

table.

Gets all rows from the

select_incident_transceiver_all Incident_Transceiver_List
table.
Gets the record with the ID
select_incident_transceiver_recordID
provided.
Gets all rows from the table
select_incident_transceiver_incidentID that match the provided
IncidentID
Removes a row from the
delete_incident_transceiver Incident_Transceiver_List
table.
Removes all rows from the
Incident_Transceiver_List
delete_incident_transceiver_incidentID
table that have a matching
IncidentID
Creates a record in the
create_transceiver
Transceiver_Info table.
Updates a record in the
update_transceiver
Transceiver_Info table.
Gets all of the records in the
select_transceiver_all
Transceiver_Info table.
Gets the record with the ID
select_transceiver_recordid
provided.
Removes a row from the
delete_transceiver
Transceiver_info table.

Table 11 - Dispatch User Interface (DUI) Application

Name Description
Calls DB procedure
getAllIncidents select_IncidentLog_Dates requesting all
incidents from time period x to y.
getIncident Calls DB requesting a single incident.
Calls DB requesting a single user's
getUserInfo information using the linked Fob ID.
Calls select_transceiver_recordID and
parses the row for the status field and then
getTransceiverStatus returns that.
Calls DB select_transceiver_all and parses
each row for status field. Returns an array
of pairs of all status messages indexed by
getAllTransceiverStatus transceiver ID.
getAllUsers Calls DB select_user_all

31
 February 9, 2011

Calls DB update
select_IncidentLog_RecordID and then
calls DB again using returned data but
changing Description for
setIncidentLog update_IncidentLog
Upon receiving message from MRL's
notifyApplication, it requests data using
select_incident_transceiver_RecordID and
incidentAlert passes it to necessary drawing functions.
Uses location data from transceivers listed as
reporting to the incident ID passed to and
drawPoint 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

Nordic Fob (WRL-
Fob Custom, manufactured 08602)
A network of
thousands of
transceivers, each
encased in a
weatherproof One transceiver
enclosure with a solar incorporated into an
power / conventional Arduino prototype
battery power board (Hardware
option. They will be Test). Network of
mounted to a building, transceivers will be
pole or other existing simulated using
Transceivers structure. software.

32
 February 9, 2011

A minimum of two
transceivers set to
receive only mode.
One transceiver will
be used as the MR and
at least one for Simulated using
Master Receiver backup. software.

Single process,
different threads
Master Control simulating different
Module Suite of software aspects of RWP suite.
Browser-based web
forms application
using ASP.NET or
Dispatch User equivalent C# Windows
Interface technologies. application

Hosted on an
independent web
server that manages
communication for
customer support, base
package quotes and Not simulated or
Website product registration tested for this phase.
Microsoft SQL Server
Microsoft SQL Server Express on test
Database Server database server platform
Figure 16 - RWP vs. Prototype Feature Comparison Chart

33
 February 9, 2011

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.

ASP – Active 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.

34
 February 9, 2011

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.

35
 February 9, 2011

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

36
 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).

37