Lab 1 – Revision 4 - PASS Product Description 1
Running Head: LAB 1 – REVISION 4 – PASS PRODUCT DESCRIPTION
Lab 1 – Revision 4 - PASS Product Description
Dan Cox
Gene H. Price
March 16, 2011
Lab 1 – Revision 4 - PASS Product Description 2
Contents
1.
INTRODUCTION ........................................................................................................................ 4
2. PRODUCT DESCRIPTION ............................................................................................................ 7
2.1
Key Product Features and Capabilities ..................................................................................... 7
2.2
Major Components.................................................................................................................... 9
2.3
Target Market.......................................................................................................................... 32
3. PROTOTYPE DESCRIPTION ....................................................................................................... 32
3.1
Prototype Functional Objectives ............................................................................................. 38
3.2
Prototype Architecture ............................................................................................................ 42
3.3
Prototype Features and Capabilities ........................................................................................ 43
3.4
Challenges and Risks .............................................................................................................. 46
GLOSSARY ......................................................................................................................................... 48
REFERENCES ..................................................................................................................................... 51
List of Figures
Figure 1. Map of Crime at ODU .......................................................................................................... 5
Figure 2. Various Fobs .......................................................................................................................... 7
Figure 3. Major Functional Component Diagram for RWP ................................................................. 9
Figure 4. RWP MFCD. ....................................................................................................................... 11
Figure 5. Software Processes in RWP ................................................................................................ 15
Figure 6. Database Schema ................................................................................................................. 18
Figure 7. Example Layout of Transceivers ......................................................................................... 31
Figure 8. Hardware Processes in Prototype ........................................................................................ 40
Figure 9. Software Processes in Prototype.......................................................................................... 42
Lab 1 – Revision 4 - PASS Product Description 3
Figure 10. Prototype MFCD ............................................................................................................... 42
List of Tables
Table 1. List of Crimes around ODU from Virginian Pilot.................................................................. 6
Table 2. Transceiver RWP Algorithms ............................................................................................... 12
Table 3. Fob RWP Algorithms ............................................................................................................. 13
Table 4. First Responder Fob RWP Algorithms................................................................................... 13
Table 5. Master Receiver RWP Algorithms ......................................................................................... 14
Table 6. Transceiver Status Byte Codes .............................................................................................. 14
Table 7. MCM Algorithms ................................................................................................................... 21
Table 8. Database Algorithms .............................................................................................................. 25
Table 9. DUI RWP Algorithms ............................................................................................................ 26
Table 10. Dispatch User Interface Web Algorithms in RWP ............................................................... 28
Table 11. Fob User Registration Algorithms ....................................................................................... 29
Table 12. Transceiver Registration Algorithms ................................................................................... 29
Table 13. Dispatch Web Interface ASP Algorithms in RWP ............................................................... 30
Table 14. Microcontroller-driven Transceiver Algorithms ................................................................. 34
Table 15. Transceiver Network Simulation........................................................................................ 36
Table 16. Features Comparison RWP vs. Prototype ........................................................................... 38
Table 17. Assumptions ........................................................................................................................ 45
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 4
1. INTRODUCTION
Campuses, especially those of major universities and colleges, represent a unique challenge
in the arena of personal safety. Patrolling and monitoring the large physical spaces that
compose these campuses requires a large amount of diligence. With some even small campuses
containing thousands and thousands of people, the number of potential emergency incidents can
be quite large.
Old Dominion University, as an example of a typical university, experiences many criminal
events around its periphery and within its own campus. Concern for the amount has caused many
organizations to investigate this matter. Figure 1 and Table 1 give details of reported crimes as
gathered by the newspaper The Virginian Pilot demonstrating the frequency of activity even
within the short time period of Fall 2010 (Wilson, 2010).
Given this need of personal safety and the problems that arise from large numbers of
people in the same area, a number of solutions have been proposed. Each of these solutions have
tried to approach the security of a campus from a different angle. Some have been successful
while others have not.
The traditional solution to emergency problems is to contact police and medical professionals
using a local telephone number. The victim of a crime or a witness to an emergency incident can
use either their own cell phone or some other stationary telephone to contact the authorities.
Those who respond to the situation are then relayed information from a dispatch station that
received the phone call. It is during this information exchange process that the location of the
incident is determined and then relayed. This layer of communication is also the point at which
the most latency is introduced into the system.
Lab 1 – Revision 4 - PASS Product Description 5
The Personal Alert and Safety System aims to reduce this latency with a system that gives
first responders a quick approximate location of each incident. Personnel unique to each campus
would have a fob, a small two-button device, in order to signal that an incident has occurred.
That signal would be received and relayed through a sensor grid of transceivers to a dispatch
station. First responders, acting from the station or a place nearby, could receive such location
data, as received and calculated by the dispatch station itself, and quickly proceed to the
indicated area of need.
Figure 1. Map of Crime at ODU
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 6
Table 1. List of Crimes around ODU from Virginian Pilot
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 7
2. PRODUCT DESCRIPTION
The Personal Alert and Safety System, using a combination of hardware and software
components, allow someone to report an incident. Once received, these reports are processed
before being acted upon. Dispatch stations, from which first responders might be sent, are able to
see an approximate location for said incident.
2.1
Key Product Features and Capabilities
The PASS system presents many different key features that separate it from its competitors
that already exist in the market. PASS brings a unique solution to the market that includes but
not limited to the use of traditional method of reporting. The use of a fob highlights this idea.
Unlike the traditional method of using a telephone, PASS uses a small device to signal that
an incident has occurred. Using a two-button press, a user can report that they are need of
assistance. Figure 2 shows what fobs look like and the various models that can be manufactured.
Figure 2. Various Fobs
Each fob communicates to a grid of transceivers. A user therefore would not need to use
verbal communication to explain where they were in relation to an incident. The transceivers,
who have fixed positions, would be able to produce this information from the initial fob signal.
This same signal, after it has been processed by the master receiver, would be used to show
the dispatch station an approximate location via a graphical user interface. Since fobs are linked
Lab 1 – Revision 4 - PASS Product Description 8
to users, the dispatch station would also be able to see information about the potential victim or
personnel in the incident. This ability is the key to the PASS system.
Since all incidents are logged into a database, a history of all events can be generated. This
history can then be analyzed for trends in reporting incidents, isolating areas that might require
greater surveillance by security personnel. These isolated areas could then be provided a greater
police presence.
PASS works primarily with radio frequencies and therefore can potentially have a very fast
reaction time even with adding new hardware to the system. Each new transceiver added to the
system extends the listening range. The communication between transceivers is rarely affected
by weather, the radio signals pass right through most precipitation.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 9
2.2
Major Components
Figure 3. Major Functional Component Diagram for RWP
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 10
The PASS system, because of its size and complexity, is broken into three different subsystems. The first, hardware, consists of all physical objects. The second, software, is the logic
and mechanics that govern the interactions between the hardware. The third and final subsystem is the Dispatch User Interface.
The basic unit of the PASS system is a fob. This small device enables a user to signal that
they are in need of assistance by relaying a short message of four bytes. The first set of bytes
represents what network, campus system, it is a part of and the second set of bytes indicates what
the identification number is. Fobs communicate with transceivers using a series of bytes that are
detailed in Table 2.
Representing the most active hardware within the system, transceivers work to listen for and
then relaying all signals coming from fobs within the system. They are enclosed by a weatherproof external layer that protects the internal circuits from damage. Drawing power from either
an internal power source such as a battery or via solar power, transceivers do the heavy lifting of
making sure signals are heard. They communicate to each other using a variety of signals that
are broken down in Table 2 and Table 3. Figure 4 represents an artistic interpretation of the
various paths signals can travel.
The deployment of the transceivers is such that use of algorithms to limit the flow of signals
must be used. Figure 6 demonstrates an example layout and Table 2 lists these algorithms. The
use of a hop counter, or number of nodes that a signal passes through, helps to limit the endless
echoing of signals. Before a signal is relayed, the hop count is reduced by one. Signals are then
only relayed if the hop counter is greater than zero.
The final piece of the hardware sub-system is the master receiver. This hardware device
consists of an antenna and a radio receiver that listens for all incoming signals from the
Lab 1 – Revision 4 - PASS Product Description 11
transceiver network. Since signals are getting relayed around the network, their paths will
inevitably lead them to the master receiver. This piece accepts all signals and then hands them to
the software components to be broken apart and analyzed.
Figure 4. RWP MFCD.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 12
Transceivers
Name
Input
ReceiveSignal
4 bytes
Output Description
This algorithm assumes that the incoming signal is
from a PASS fob. It assembles a 12-byte code
consisting of the transceiver ID, the fob ID, the
hop count, and the status byte. If the fob ID is all
ones or if the network ID 2-byte code is not the
12
same as the transceiver's network ID, then the
bytes
incoming message is ignored.
ReceiveSignal
12 bytes
12
bytes
RequestHop
12
bytes
This algorithm assembles a 12-byte code to send
out to any surrounding transceivers to query their
hop count. The bytes for the fob and hop count
are all zeros. It passes the assembled code to
SendSignal
Sees the status message of the incoming 12-byte
code as SENDING HOP. It sets its own stored
hop count value as the received code + 1, if and
only if the incoming hop is less than the already
stored hop. However, if it is the first received (i.e.
its own hop cout equals 0) then store it without
comparing. If the message is received and the
hop count is already set and the transceiver ID is
not its own, then the message is ignored.
Messages with the SENDING HOP status are not
retransmitted.
12 bytes
12
bytes
Sets the outgoing 12-byte message as such: the
transceiver ID will be the same as the requesting
transceiver ID, the fob ID as all zeros, its own hop
count, and then the status message of SENDING
HOP and then passes the signal to SendSignal.
12 bytes
12
bytes
Sends the 12-byte signal out to other transceivers.
Before sending it will decrement the outgoing
signals hop count byte if the status is NORMAL.
none
ReceiveHopReply 12 bytes
SendHopReply
SendSignal
This algorithm examines the status byte and routes
the signal to the appropriate algorithm.
12
bytes
Table 2. Transceiver RWP Algorithms
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 13
Client Fobs
Name
ReadButtons
SendSignal
Input
button press(es)
bit
ReceiveSignal 4 bytes
Output Description
bit
Determines if the correct combination of
buttons was pressed to transmit a signal.
Sends SendSignal a bit value.
4 bytes
Transmits the 4-byte ID code if the
incoming bit equals 1. Starts the
internal timer by setting the time value to
30. With each clock tick it decrements
the stored value. Once it reaches zero, it
sends the ID again and resets the stored
time value to 30. The timer cycle will
only stop if the stored value equals -1.
none
If the incoming 2-byte code for fob ID is
all ones, then the stored time value will
be set to -1.
Table 3. Fob RWP Algorithms
First Responder Fob
Name
Input
ReadButtons
SendSignal
button press
none
Output Description
If a button press is recorded, then initate
none
SendSignal.
4 bytes
Transmitts a 4-byte code of all ones,
where the first two bytes are the network
ID and the last two bytes are all ones.
Table 4. First Responder Fob RWP Algorithms
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 14
Master
Receiver
Name
Input
ReceiveSignal 12 bytes
Output Description
This algorithm assumes that the
incoming signal is from a PASS
transceiver. It first checks the incoming
signal's network ID. If the network ID
matches its own, then it sends the 12
bytes over a wire to the MCM. If they
12
do not match then the signal is not sent to
bytes
the MCM.
Table 5. Master Receiver RWP Algorithms
Byte Code
0000 0000
1111 1111
0101 0101
0111 0111
1111 0000
Alias
Description
The state which tells any
listening transceiver or
NORMAL
Master Receiver that the
received signal should be
treated as an alert signal.
A health pulse value that
signifies that the sending
OK
transceiver is in good working
order.
A REQUEST_HOP
transmission is sent out by a
newly installed transceiver.
REQUEST_HOP
The signal is an interrogation
of surrounding transceivers'
hop count.
A SENDING_HOP
transmission is sent by the
SENDING_HOP
surrounding transceivers of a
newly installed device.
A health pulse value that
signifies that there is
MAINTENANCE
something wrong with the
sending transceiver.
Table 6. Transceiver Status Byte Codes
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 15
The second sub-system, software, is as complex if not more so than the hardware system.
All hardware is governed by software of some sort and each different hardware piece requires its
own special and unique software starting with the smallest units on up through the server
application suite. Figure 5 shows the interconnections of this software.
Figure 5. Software Processes in RWP
Each fob is governed by a special set of software that holds its unique pair of network and
identification numbers. This software holds the unique data to the fob. Every time the two
buttons are pressed in tandem, that pair is broadcast for each transceiver to receive, process and
relay toward the master receiver.
Transceivers are controlled by an even greater set of algorithms. As detailed earlier in Table
2 and Table 3, each transceiver has its own hop count, identification number and monitors its
individual status. When it is not receiving or processing signals from other transceivers or fobs,
it periodically sends out a health pulse letting the master receiver know that it is still in working
Lab 1 – Revision 4 - PASS Product Description 16
condition. Upon hearing a signal from a fob or another transceiver, however, it prepares to send
data outward.
Detecting a signal from a fob starts the process of developing a packet, or envelope, to carry
the identification number of the received fob. The transceiver attaches it own network and
identification numbers to the front of the fob signal while also attaching its hop count and the
current operating status to the back. This completed packet is sent on out into the network to be
relayed between transceivers.
Upon hearing a signal from another transceiver, each device performs the action of checking
the hop counter portion of the packet of data. If the hop counter zero, it does not relay the signal.
However, if the hop counter is greater than zero, it decreases the count by one and then further
relays the message through the network, eventually reaching the master receiver.
At as close to the center of the system as possible sits a master receiver. This hardware, as
discussed earlier, receives signals from the transceiver network. Upon receiving a signal, it
sends a message to software that is monitoring the receiver notifying it that a signal is incoming.
The Master Control Module receives data and notifications from the Master Receiver. As it
gathers signals, it breaks each one into its component parts and starts the process of logging
information into the database. It also provides an interface to the database from other
applications.
The database (See Figure 5) holds all necessary information for the completion of all other
software. Storied with the database are a series of procedures that handle all database
transactions and serve as a layer of security and abstraction to the other applications that wish to
talk to the database. Two different registration applications talk to these procedures and set the
initial values for later algorithms, the user and transceiver registration applications.
Lab 1 – Revision 4 - PASS Product Description 17
Each fob is linked to a user number. The process by which this is done is through the user
registration application. Taking input from user interaction, this data is logged to the database
for later usage in the Dispatch User Interface.
For the location algorithm to have accurate data, each transceiver’s location must be within
the database. A transceiver registration application handles this process by allowing users to
enter and update the locations of transceivers as well as the hop count per device. Maintenance
staff would have this large task to complete.
The last major software component is a web server. This software system serves content
using a standard communication protocol over networked computers. Using a server-client
model, the web server acts as a gateway to the web client component of the Dispatch User
Interface communication with the database and stored procedures.
The final sub-system of PASS is that of the Dispatch User Interface. This system uses
graphical displays as a layer of abstraction granting a lesser detail of control over the content but
presenting it in a way that is easily processed. This sub-system is broken into two different
areas: an application and a web client.
Within the dispatch station, there are areas used to receive calls and other incoming flows of
information. At these areas, computers are used to record this flow of information so that
emergency service personnel can be directed toward the necessary locations of incidents. It is on
these computers that an application will run that allows dispatch stations to interact with the
database procedures. Using a map and tables of transceiver statuses and user information, the
Dispatch User Interface allows easy access to information received from the MCM as deposited
in the database. This interface also allows for dispatch personnel to record descriptions of
Lab 1 – Revision 4 - PASS Product Description 18
incidents as well as the time it took first responders to arrive on the scene for later analysis.
Figure 3 shows a preliminary design of the interface.
Figure 6. Database Schema
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 19
Master
Control
Module
Algorithms
Name
ReceiveSignal
DisectSignal
Input
12
bytes
12
bytes
GetTransceiver 2 bytes
GetFob
2 bytes
Output
Description
12 bytes
This algorithm utilizes a hardware interrupt
watching the USB port for a call from the
Master Receiver.
None
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.
Uses the 2 byte input as an unsigned integer
and retrieves the transceiver data from the
database calling select_transceiver_recordID.
Transceiver Once the data is retrieved it uses that data to
object
build a Transceiver object.
Fob object
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.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 20
Name
Input
GetUser
integer
Output Description
Uses the integer value of stored in the fob object for
the user id to access the user info from the database
User
using select_user_recordid. Once the data is
object
retrieved it uses the data to build a User object.
GetStatus
1 byte
enum
Uses the 1 byte array for status and returns an
enumeration coinciding with the byte code value.
none
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 as such. It will call: ProcessAlert.If
the status is OK / MAINTENANCE we know it
was a health pulse. It will call ProcessHealthPulse.
none
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 than 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.
RouteData
ProcessAle
rt
statusEnum
Transceiver
Object, Fob
Object, User
Object
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 21
Name
Input
Output
ProcessAlert
Transceiver
Object, Fob
Object, User
Object
none
Description
This algorithm processes a health pulse
Transceiver
signal. It sets the status of a transceiver
object,
based on the StatusEnum. It will call:
ProcessHealthPulse StatusEnum
none
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 function/procedure. The alert
object has two primary properties/fields:
center and radius. The center of the alert
is the center point of overlapping
Alert
transceiver receiving signal circles and the
getLocation
IncidentLogId object
radius is the margin of error.
This algorithm queries the database for the
entire incident logs between (inclusive) of
startDate
the dates provided. For each record
(datetime),
collection
returned by select_incidentLog_Dates, an
endDate
of Incident Incident object is created from the data
getAllIncidents
(datetime)
Objects
stored in the record.
This algorithm queries the database for all
collection
of the transceiver records using:
of
select_transceiver_all. For each record
Transceiver returned a new Transceiver object is
getAllTransceivers None
Objects
added to the collection.
updateIncident
Incident
Object
Table 7. MCM Algorithms
none
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
Lab 1 – Revision 4 - PASS Product Description 22
Database
Procedures
Name
Input
update_IncidentLog
Record ID for
deletion
RecordID (integer),
FobID (integer),
Description (string),
ResponseTime
(integer)
create_IncidentLog
FobID (integer),
Description (string),
ResponseTime
(integer)
delete_IncidentLog
Output
Description
Integer number of rows
affected. 0 means that
no deletion occured.
Removes a row
from
INCIDENT_LOG
Integer number of rows
affected. 0 means that
no update occured.
Updates an
INCIDENT_LOG
row.
integer number of rows
affected. 0 means that
the create failed.
Creates a new row
in
INCIDENT_LOG
table
select_incidentLog_All
none
record set
Gets all Incidents
logged to the
database
select_incidentLog_RecordID
RecordID (integer)
record set (one row)
Gets the record with
the ID provided.
record set
Gets all incidents
logged between
(inclusive) the dates
provided.
StartDate
select_incidentLog_Dates
(datetime), EndDate
(datetime)
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 23
Name
Input
Output
Description
Creates a new
row in
USER_INFO;
called from
registerUser
update_user
OrganizationID
(string), Age
(integer), Sex
(char)
RecordID
(integer),
OrganizationID
(string), Age
(integer), Sex
(char)
select_user_all
none
record set
select_user_recordID
RecordID
(integer)
record set (one row)
Updates a row
in the User_Info
table.
Gets all
User_Info
records
Gets the record
with the ID
provided.
Integer number of rows
affected. 0 means that no
deletion occured.
Removes a row
from the
User_Info table.
Integer number of rows
affected. 0 means the create
failed.
Creates a new
row in the
Fob_Info table.
Updates a row
in the Fob_Info
table.
Gets all rows
from the
Fob_Info table.
create_user
Integer number of rows
affected. 0 means the
create failed.
Integer number of rows
affected. 0 means the
update failed.
create_fob
RecordID
(integer)
RecordID
(integer), UserID
(integer), IsActive
(boolean)
update_fob
RecordID
(integer), UserID
(integer), IsActive
(boolean)
Integer number of rows
affected. 0 means the
update failed.
select_fob_all
none
record set
select_fob_recordid
RecordID
(integer)
record set (one row)
select_fob_all_active
none
record set
delete_user
[Space left intentionally blank]
Gets the record
with the ID
provided.
Gets all rows
from the
Fob_Info table
that are marked
as active.
Lab 1 – Revision 4 - PASS Product Description 24
Name
deactivate_fob
Input
RecordID
(integer)
delete_fob
RecordID
(integer)
IncidentID
(integer),
TransceiverID
(integer)
create_incident_transceiver
RecordID
(integer),
IncidentID
update_incident_transceiver
select_incident_transceiver_all
select_incident_transceiver_recordID
Description
none
Integer
number of
rows
affected. 0
means the
delete
failed.
Sets isActive to false
Integer
number of
rows
affected. 0
means the
create
failed.
(integer),
TransceiverID
(integer)
Integer
number of
rows
affected. 0
means the
update
failed.
none
RecordID
(integer)
record set
record set
(one row)
IncidentID
select_incident_transceiver_incidentID (integer)
delete_incident_transceiver
Output
RecordID
record set
integer
number of
rows
affected.
[Space left intentionally blank]
Removes a row from the
Fob_Info table.
Creates a new record in
the
Incident_Transceiver_List
table.
Updates a record in the
Incident_Transceiver_List
table.
Gets all rows from the
Incident_Transceiver_List
table.
Gets the record with the
ID provided.
Gets all rows from the
table that match the
provided IncidentID
Removes a row from the
Incident_Transceiver_List
table.
Lab 1 – Revision 4 - PASS Product Description 25
Name
Input
IncidentID
delete_incident_transceiver_incidentI
D
create_transceiver
update_transceiver
(integer)
RecordID,
Latitude(float),
Longitude(float
), Status
(integer)
RecordID,
Latitude
(float),
Longitude
(float),
Status (integer)
select_transceiver_all
none
RecordID
select_transceiver_recordid
(integer)
RecordID
delete_transceiver
(integer)
Output
Integer
number
of rows
affected.
0 means
the
delete
failed.
integer
number
of rows
affected.
0 means
the
create
failed.
number
of rows
affected.
0 means
the
update
failed.
record
set
record
set (one
row)
Integer
number
of rows
affected.
0 means
the
delete
failed.
Table 8. Database Algorithms
[Space left intentionally blank]
Description
Removes all rows from
the
Incident_Transceiver_Lis
t table that have a
matching IncidentID
Creates a record in the
Transceiver_Info table.
Updates a record in the
Transceiver_Info table.
Gets all of the records in
the Transceiver_Info
table.
Gets the record with the
ID provided.
Removes a row from the
Transceiver_info table.
Lab 1 – Revision 4 - PASS Product Description 26
Dispatch User Interface Application
Name
Input
Output
DisplayMap
none
graphic display
DisplayLogInfo
Incident object
from MCM
graphic display
DisplayAlertOnMap
Alert object
graphic display
UpdateLog
values from web
form controls
Incident Object
DisplayUserInfo
User object from
MCM
graphic display
ShowTransceiverStatus none
graphic display
Table 9. DUI RWP Algorithms
[Space left intentionally blank]
Description
This algorithm displays an
indication of a map on the UI
screen.
This algorithm displays the
Incident Log 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 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
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 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 (getAllTransceivers) and
displays the results on a separate
UI screen from the map.
Lab 1 – Revision 4 - PASS Product Description 27
Dispatch User Interface - Web
Name
Input
getAllIncidentsByDate
getIncident
getUserInfo
getTransceiverStatus
getAllTransceiverStatus
Output
Time period x
and y
HTML fragment
produced from the
results of a Web API
call to getAllIncidents
Incident ID
HTML fragment
produced from the
results of a Web API
call to getIncident
Fob ID
HTML fragment
produced from the
results of a Web API
call to getUserInfo
Transceiver ID
HTML fragment
produced from the
results of a Web API
call to
getTransceiverStatus
none
HTML fragment
produced from the
results of a Web API
call to
getAllTransceiverStatus
Description
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.
Makes an AJAX call to the
Dispatch Web 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.
Makes an AJAX call to the
Dispatch Web 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.
Makes an AJAX call to the
Dispatch Web Server calling
function getTransceiverStatus
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
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.
Lab 1 – Revision 4 - PASS Product Description 28
Name
getAllUsers
setIncidentLog
pollServer
drawPoint
Input
Output
Description
none
HTML fragment
produced from the
results of a Web
API calls to
getAllUsers
Makes an AJAX call to the
Dispatch Web Server calling
function getAllUsers 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.
Text, Incident
ID
HTML fragment
message stating
success or failure
to send
Makes an AJAX call to the
Dispatch Web Server calling
function setIncidentLog and
sending text.
none
Point x; Point x,
y; Point x, y, z
JSON object
representing any
current messages
Draws necessary
circles or triangles
showing
approximate
location of
incident
Table 10. Dispatch User Interface Web Algorithms in RWP
[Space left intentionally blank]
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.
Using data from pollServer's
response, it draws the point of
intersection between one to three
points.
Lab 1 – Revision 4 - PASS Product Description 29
User Registration Program
Name
Input
Output
addUser
User, ID, age,
sex
True or False upon
result of DB call.
addFob
ID
True or False upon
result of DB call.
linkUserToFob
ID; User ID
True or False upon
result of DB call.
deleteUser
User ID
deleteFob
Fob ID
deactiveFob
Fob ID
True or False upon
result of DB call.
True or False upon
result of DB call.
True or False upon
result of DB call.
Description
Calls database using create_user
call and supplying necessary
variables.
Calls DB using create_fob and
supplying necessary variables
Calls database using update_fob
and supplying necessary
variables
Calls database using delete_user
Calls database using delete_fob
Calls database using
deactive_fob
Table 11. Fob User Registration Algorithms
Transceiver Registration Program
Name
Input
Output
Description
addTransceiver
ID, Latitude,
Longitude
True or False upon
result of DB call.
Calls DB using
create_transceiver
True or False upon
result of DB call.
True or False upon
result of DB call.
Calls DB using
delete_transceiver
Calls DB using
update_transceiver
deleteTransceiver
Transceiver ID
updateTrasceiver
Transceiver ID
Table 12. Transceiver Registration Algorithms
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 30
Dispatch Web Server - ASP
Name
Input
Output
getAllIncidentsByDa
te
Time
period x
and y
getIncident
Incident
ID
getUserInfo
Fob ID
Collection of objects
populated that match time
period
Custom object reflecting
values retrieved from DB
call
select_IncidentLog_Recor
dID
JSON object reflecting
values of DB entry for
User ID
getTransceiverStatus
Transceiv
er ID
JSON object containing
status of transceiver
Description
Calls DB procedure
select_IncidentLog_Dates
requesting all incidents from time
period x to y.
Calls DB requesting a single
incident.
Calls DB requesting a single user's
information using the linked Fob
ID.
Calls select_transceiver_recordID
and parses the row for the status
field and then 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
transceiver ID.
getAllTransceiverSta
tus
none
getAllUsers
none
JSON indexed by
transceiver ID and
containing each
transceiver's status.
JSON object populated by
all users in the system
setIncidentLog
Text,
Incident
ID
JSON object detailing
success or failure
Calls DB select_user_all
Calls DB update
select_IncidentLog_RecordID and
then calls DB again using returned
data but changing Description for
update_IncidentLog
JSON object holding any
recent activity
Upon signalling of
nodifyApplicaiton from MRL, it
requests the current incident details
from the DB using
select_IncidentLog_RecordID and
replies to the message sent from
the client using the Comet method
of AJAX call with data pulled from
select_incident_transceiver_incide
ntID.
pollServer
none
Table 13. Dispatch Web Interface ASP Algorithms in RWP
Lab 1 – Revision 4 - PASS Product Description 31
Figure 7. Example Layout of Transceivers
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 32
2.3
Target Market
The PASS system was designed for campuses. Although initially conceived of as a way to
decrease the reporting latency between incidents occurring and dispatch stations hearing about
them on universities, the system is easily deployable on other campuses such as business parks
and large commercial property. It can be used on any campus.
3. PROTOTYPE DESCRIPTION
In order to demonstrate the ability to create and deploy such a complex system as PASS, a set
of small prototypes were developed. Consisting of two distinct tests, each show the viability of
using certain technologies and examples of how user interfaces would be designed and
implemented. These tests are detailed in the following sections.
The first test is that of the hardware. Because of the complex and expensive nature of the
hardware components in PASS, a subset of the overall hardware was selected to demonstrate a
number of key interactions. An additional constraint of time was also applied to the project and a
further reduction as made to the demonstration.
The ability of a transceiver to receive data from a fob is an integral part of PASS and thus is
also part of the prototype. Using a turn-key solution from a hardware vender, a premade and
pre-programmed fob was purchased. It has a five-button pad that will be used to generate the
signals from five different fobs, one for each button.
The interaction between transceivers and computers is another integral part of the PASS
system. The Master Receiver must be able to communicate with the MCM. In order to
demonstrate this functionality in the prototype, a simplified interface is created between a
microcontroller and a computer.
Lab 1 – Revision 4 - PASS Product Description 33
Attached to the microcontroller and governed by it is the physical hardware of the
transceiver. The microcontroller locks the transceiver into receive mode only and waits for any
signals. As the transceiver receives signals, the microcontroller performs minimum processing
and passes these same signals to a listening program on the computer. This application will
display to the user which fob button was pressed.
Since fob identification is also requirement of the system, each button, as stated earlier,
represents a fob identification number. The listening program on the computer will translate the
received data of which button and convert that into which fob identification number was received
during each session of testing. This program, because of the time constraint on the project, will
be console-based.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 34
Microcontroller-driven Transceiver
Name
Input
Output
ReceiveSignal
4 bytes
2 bytes
WriteConsole
2 bytes
character array
Fob
Name
Input
Output
ReadButtons
button press
4 bytes
SendSignal
4 bytes
4 bytes
Description
Receives 4 bytes from fob.
Ignoring the later 2 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 USB connection to
listening program on
computer.
Description
Determines which button was
pressed. Adds to the total
button presses. Sends both
numbers, 4 bytes total, to
SendSignal.
Transmits 4 bytes. First set
of 2 bytes representing the
button pressed and the later 2
bytes as the total number of
button presses.
Table 14. Microcontroller-driven Transceiver Algorithms
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 35
The complexity of the transceiver network is such that it must be simulated in software.
Several of the dominant features of the network including fob detection, transceiver intercommunication and the location algorithm are also major parts of the simulation. Other parts of
the software simulation are a database that is consistently the same as the RWP’s and an
implementation of the Dispatch User Interface.
Using an approach of two different windows, the simulation will allow a user to click on a
map to simulate the transmission of a fob within that area. The simulation will then demonstrate
how that signal would be process and then relayed through the transceiver network as it
ultimately comes to the Master Receiver and Master Control Module. Table 6 lists the
algorithms involved in this process.
The second window will be an implementation of the Dispatch User Interface and show what
a user using the application in a dispatch station might see and interact with using the same
graphical shorthand. Refer to the last section of Table 6 for the algorithms used in the Dispatch
User Interface as they apply to the simulation.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 36
Transceiver Network Simulation
Name
Input
location x and
getTrancieverLocation y
getAllIncidents
mouse click
getUserInfo
User ID
StartTranceiverWave
location x and
y
getFobLocation
location x and
y
getTrancieverStatus
Point x; Points
x,y; Points
x,y,z
location x and
y from
transceiver
getFobID
Fob ID
drawPoint
Table 15. Transceiver Network Simulation
Output
Description
Displays location
of individual
location x, y
receiver.
Starts the
network
Simulation,
draws a circle
calls drawPoint(),
around key fob
getUserInfo(),
and outputs data
getFobID(),getFobLocation() to GUI.
User object reflecting values
of input document for User
Displays User ID
ID
on the GUI.
Uses the location
from first
transceivers to
receive the signal
and then
increments it,
increments the location until causing all
its bounds are out of the last transceivers in
tranceiver's reach
the path to blink.
gets location of
Fob from
transceivers in
calls getTrancieverStatus()
range.
Uses location
data from
transceivers listed
as reporting to the
incident ID
Displays circle(s) or triangle passed to and
of approximate location of
processed by
incident
incidentAlert.
status of 1 or 0 showing if it
is in range of key fob
User object reflecting values
of input document for Fob
ID
Finds the closest
Displays fob ID.
Lab 1 – Revision 4 - PASS Product Description 37
As mentioned in the earlier section, there are limits that stop an even greater scope of
prototype. The two primary limitations are the price of a more expansive set of hardware and the
timeframe that the entire prototype and simulation must be finished within in order that they be
presented as due. This sentence is filler.
The cost of each component part of the transceivers runs a low but manageable price for a
very small subset. Due to the need of thousands to cover and test a full system, it was cost
prohibitive to do that. So, we will not be ordering thousands or hundreds but just one.
The purchasing the large number of transceivers needed for a full test of system was
impractical. A test of the communication between transceivers will then be done in software
through a simulation of the entire system. This was approved and will be sufficient to
demonstrate the system.
.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 38
3.1
Prototype Functional Objectives
The prototype will attempt to demonstrate to a satisfactory standard the various pieces and
technologies that would make up the PASS system as conceived in the Real World Product.
Before any functional goals can be discussed then, a comparison between the prototype and the
RWP must be made. Table 7 is a list of such differences between the two systems.
Features
Real World Product
Prototype
Nordic Fob (WRL08602).
One transceiver
incorporated into an
Arduino prototype board
(Hardware Test).
Network of transceivers
will be simulated using
software.
Fob
Custom, manufactured.
Transceivers
A network of thousands of transceivers,
each encased in a weather-proof 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.
Simulated using
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 an independent web server that
manages communication for customer
support, base package quotes and product
registration.
Not simulated or tested
for this phase.
Microsoft SQL Server database server.
Microsoft SQL Server
Express on test platform.
Database Server
Table 16. Features Comparison RWP vs. Prototype
Lab 1 – Revision 4 - PASS Product Description 39
The demonstration of the prototype falls into two different categories: hardware and
software. Each has its own specific goals and objectives that show its functionality. These goals
also demonstrate the ability of the group to manifest the project through a reduction of
presentation.
The first test of the prototype system comes in the use of hardware to show that a single fob’s
signals can be received, processed and displayed. This test uses one fob, one transceiver and one
computer. Figure 7 shows these processes.
After a button is pressed on the fob, that signal is checked against the expected result on the
computer display. Since each system the signal passes through can report on exactly what it saw,
there is a process of logging and analyzing per step in the process. The computer display is run
by a console-based reporting program.
The transceiver is to be locked into receive mode only and is listening for the fob only. As it
receives the signals, they are processed and sent to the listening program on a computer for
display on a console window. As was stated, this listening program, because of the constraint of
time, has limited functionality.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 40
Figure 8. Hardware Processes in Prototype
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 41
The second category of the prototype is in the simulation of the transceiver network’s
communication and results as seen from the Dispatch User Interface. Figure 9 shows this
general interaction between the simulation code and the Dispatch User Interface. The following
section details some of that interaction.
This simulation includes most of the functionality of the Master Control Module and its
ability to receive, interpret and record all necessary content into the database. Developed as
shared functionality within the simulation, this software abstraction would need to demonstrate
that it is correctly translating data it gets from the Master Receiver software as seen through the
software that also drives the transceivers. The Master Control Module also provides an interface
to the database.
Accepting data from a user as they click on a map, the simulation would create an instance of
a fob going off within the real system. This fob’s information is then transferred between
transceivers as it would in the RWP. The simulation will demonstrate this capability by having a
wave pattern occur on the screen that would mirror the transceiver interact in the RWP. Once
this wave pattern reaches the location of the Master Receiver, it would trigger code that clues the
Dispatch User Interface into the fact that it is now needed.
The Dispatch User Interface would not know that it was run as part of a simulation. Because
it only reads data from the database anyway, it would have no knowledge that a simulation was
run. It would read the location of transceivers and the user’s information as if it was running in a
production or RWP environment. The location algorithm then, as part of the preparation for the
Dispatch User Interface, would act as normal, selecting the approximate area within its own map
that the incident had occurred.
Lab 1 – Revision 4 - PASS Product Description 42
Figure 9. Software Processes in Prototype
3.2
Prototype Architecture
Figure 10. Prototype MFCD
The prototype architecture is a subset, as stated before in many sections, of the full
production system. It can be divided into two areas: signal processing and network simulation.
Both areas are covered in greater detail in other areas. This sentence is filler.
The signal processing portion (shown in Figure 8 and Figure 10) consists of one fob, one
transceiver and a microcontroller which speaks to the transceiver and the computer. Signals are
passed from the single fob to the listening transceiver. The microcontroller, connected to the
transceiver, receives the signals digitally from the transceiver.
Lab 1 – Revision 4 - PASS Product Description 43
The network simulation (shown in Figure 9 and detailed in the previous section) is composed
of code that will mirror a transceiver network and the Dispatch User Interface. The simulation,
containing fobs, transceivers and a master receiver, is made to show that the location algorithm
works. This sentence is filler.
3.3
Prototype Features and Capabilities
The prototype is designed into two concurrent phases. The first and primary phase is the
hardware test. The second phase, conceptually more complex than the hardware, is that of
software simulation. Both phases are detailed in the following sections.
In order that the hardware demonstration is considered successful, two different goals must
be met. The first and foremost is that a fob device, once a button has been pressed, is able to be
perceived and translated into the correct button pressed by the microcontroller as read by the
console on a connected computer. A second goal is that a signal, once processed and presented
by the microcontroller, can be logged into a database correctly and the retrieved by another
interface demonstrating that the processes, independent of each other, read the same data.
For the software simulation to be considered successful, several different but similar goals to
the hardware test must pass inspection. Each hardware test is design to demonstrate some
necessary conditions of the project. They are detailed in the following sections.
Similar to the hardware portion, the software simulation must also be able to detect when a
fob has been activated and relay that signal to the necessary listening hardware. Unlike the
hardware test however, the transceivers themselves must also be tested and show that they
correctly can handle both valid signals and malfunctions as they occur within the system.
Transceivers, representing the second of three steps in messing passing communicate with the
Master Receiver.
Lab 1 – Revision 4 - PASS Product Description 44
Once the signals reach the Master Receiver, it too must show that the signal it got from the
transceivers is the same as the one broadcast originally by the fob. After processing, the signal is
passed to the final part, Dispatch User Interface. This is where the user sees the results.
As each other area has had different goals, so too does the Dispatch User Interface. It must
show that the signals sent to it and calculated through the location algorithm are, in fact, the
same as the original signals that the fob broadcast as part of the very beginning of the simulation.
All technologies carry with them a risk that must be considered. For PASS, the biggest
potential risk is that the system is quite expensive. Even in the purchasing of a small subset of
the whole, the price is relatively high. Within the prototype, we are mitigating this by reducing
the hardware portion to only one transceiver and one fob.
The other risk that is worth considering for the prototype is the introduction of false or
malformed signals with the system. For the RWP, this is a major problem and will need time
and resources to combat. For the prototype, we are using the set of assumptions as described in
Table 8 to nullify the required code and time that would require planning, designing and coding
for such negative forces on the prototype. We will also be implementing limited functionality
that produces interference within the simulation to truly emulate the effects of signals of that
nature within the greater simulation.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 45
Prototype Condition
Assumptions
There will be no signal
interference from non PASS
2.4 GHz transmissions.
There will be no signal
interference from existing
structures.
Weather will have no affect
on signal strength or
direction.
All users who access PASS
via the DUI will be
authorized users. Therefore
no secure login abilities will
be required.
Full testing of transceiver to
transceiver is not required to
prove that communication
across the 2.4 GHz RF band
is achieved as desired.
Hardware or
Simulation
Simulation
Simulation
Simulation
Simulation
Hardware
Table 17. Assumptions
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 46
3.4
Challenges and Risks
When faced with the monumental challenge of trying to create an entire system that
wirelessly reports to each other, tracks user’s location and then is also an application by two
different methods, it is easy to surrender in sheer exhaustion. The PASS system is massive both
in scope and time requirements. Many, many different systems have to interact with each other
smoothly and the entire group must have a firm understanding of the system, is components and
their interactions.
It is a challenge then to communicate the layers and protocols of communication within
PASS to just the group members. The system is complex, yes, but so is the challenge of keeping
six different people on the same track and abreast of any changes. If there is one aspect of the
management of this project that will require the most effort to keep, it will be creating and
maintain clear channels of information between groups members about responsibilities and tasks
as the project is iterated upon and improved over time.
A further complication in the realm of group cohesiveness and communication is the
realization that the group lacks true experts in the many fields that the project covers. Already,
an expert on wireless technologies has been in conversation with the group on how that part of
the system would work. Algorithms that would govern transceiver interaction has been
discussed extensively.
Additional lack of knowledge also includes the area of software for the hardware involved.
Several of the group members have had past experience on parts of the required knowledgebase
but no one member has all the necessary skills to complete the hardware, even for the prototype,
alone. This lack of knowledge then compounds the next concern, time management.
Lab 1 – Revision 4 - PASS Product Description 47
As mentioned earlier, time management is a major concern for the group. The code needed
to correctly simulate the transceiver network is expansive. Each object that would exist within
the system in the RWP must also be created and run as objects within the simulation. Because of
the necessity of keeping the simulation as real as possible, the database as well as at least initial
work on all twenty-five stored procedures must also be done as the interface for both the
simulation and the Dispatch User Interface will need to communicate with that system.
The Dispatch User Interface also represents a unique challenge to the project. As part of
both the RWP and the prototype, it represents the area that the most work will need to put into in
order that it be finished and professional looking for the final demonstration. All necessary
forms and graphical displays must be designed and at least preliminarily implemented so that the
basic functionality can be shown.
[Space left intentionally blank]
Lab 1 – Revision 4 - PASS Product Description 48
GLOSSARY
AJAX (Asynchronous JavaScript And XML): A method of requesting data by a web browser
that does not require the page to be refreshed. AJAX is a technology that has become
commonplace in web applications that require updating page content during sessions of
user interaction.
Alert Signal: A specially crafted RF packet of information detailing that an incident has
occurred.
Algorithm: A set of instructions that do one transaction or action representing a single function.
Arduino: A microprocessor connected to a printed circuit board often used for hobby projects.
ASP (Active Server Pages): A web server suite and program developed by Microsoft.
Bit: The lowest form of information storage in computers represents two states: 1 or 0.
Browser: A program that reads HTML or other markup languages from web servers and often
has a client-side language, JavaScript, interpreter bundled together to allow for
interactions to take place after a page has been loaded.
Byte: A collection of eight bits.
C#: A programming language developed and maintained by Microsoft.
Comet: A process of maintaining connections to a server open for an extended period of time.
Console: A graphical representation of information that is usually restricted to text.
Database: A collection of records and software that governs the rules between records.
Database Procedures: A way of adding a layer of security and performance to database
applications. Algorithms can be written and stored on the server running the database
software, increasing performance.
Dispatch Station: The station at which the dispatch or security headquarters is located.
Dispatch Personnel: Employees of a company or university who respond to emergency events.
Dispatch User Interface: The interface layer between the database and the dispatch personnel
allowing for work with the database through a layer of abstraction.
Dispatch Web Server: The computer serving the necessary pages and content to the browser
through a network connection and via standard communication protocols.
Lab 1 – Revision 4 - PASS Product Description 49
Driver: A set of code to work directly, on a hardware level, with a device.
Fob: A small device used often as a method to remotely activate something. Traditionally seen
with at least one button and used for only one action such as unlocking a vehicle.
Fob Registration: The software needed to link a Fob ID with a certain User ID.
GUI (Graphical User Interface): A layer of abstraction and interaction that allows a user to
work with a lower level system through graphical representations of processes.
Hardware Enclosure: The physical covering for a transceiver.
Health Pulse: A specially crafted RF packet of data from a transceiver stating whether it is still
operating properly or not.
Hop Count: The count of how many transceivers a signal should need to travel through in order
to reach the master receiver.
HTML (Hyper-Text Markup Language): A way of representing content and styling of said
content as one integrated file. The most often form of web pages content.
JavaScript: A scripting language most frequently seen as part of web browsers in order to
promote dynamic changing of content.
JSON (JavaScript Object Notation): A way of representing JavaScript data. It is used most
frequently in communication between browsers and servers as a way to conveniently
messages.
Location Algorithm: An algorithm that, when fed coordinates, can provide an increasingly
improved approximate location within the intersection of points.
Master Control Module: Set of control and application software that communicates, directs
and otherwise dictates the information between subsystems within the module.
Master Receiver: The receiver that works in only listening, receiving, mode.
MCM: See Master Control Module
Microcontroller: A single integrated circuit used in conjunction with printed circuit boards to
provide the necessary logic to drive the digital and mechanical aspects of machinery.
ODU (Old Dominion University): The University where the PASS system was created.
PASS (Personal Alert and Safety System): A system of transceivers and fobs that allow a user
to remotely signal an emergency quickly.
Lab 1 – Revision 4 - PASS Product Description 50
Prototype: A product with has a subset of the requirements and specifications of a Real World
Product and that demonstrates a certain aspect a proof of concept.
Receiver: A radio device that interprets RF only.
Real World Product: A way of describing the necessary code and hardware to meet the
specifications and requirements of a completed system deployed outside an academic
or laboratory setting.
RF (Radio Frequency): The transmission and receiving of energy waves that oscillate within a
known time period.
RWP: See Real World Product.
Schema: A descriptive method of demonstrating how content within a database is organized.
Solar Panel: A hardware component that uses sunlight, through a chemical process, to create
electrical charge.
SQL Server: Database software created and maintained by Microsoft.
Stored Procedure: A set of instructions that shares nomenclature with database procedures.
Transceiver: A device that reads and sends RF signals.
Transceiver Network: A collection of transceivers that work toward a goal such as relaying
messages.
Transceiver Registration Program: A program used to add transceivers to a database and
transceiver network.
Transmitter: A device that sends RF signals only.
Turn-key solution: A prepared set of hardware or software that is designed to be used with a
low number of changes between different projects or environments.
User Registration Program: A program used to add users to a system.
USB (Universal Serial Bus): A method of delivering data and power across specially designed
cables and connections using a unified communication standard.
Lab 1 – Revision 4 - PASS Product Description 51
REFERENCES
Wilson, Patrick (2010, November 03). “Robbery crimes at or near campus”. The
Virginian-Pilot, p. B3.