Laboratory 1 - Old Dominion Universitycpi/411/blues11/documents/411/Lab... · Web viewThis...

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


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


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]


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.


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



Table 1. List of Crimes around ODU from Virginian Pilot



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

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.


2.2 Major Components


Figure 3. Major Functional Component Diagram for RWP


The PASS system, because of its size and complexity, is broken into three different sub-

systems. 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 sub-

system 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 weather-

proof 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

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.


Transceivers Name Input Outpu Description


t

ReceiveSignal 4 bytes12 bytes

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 same as the transceiver's network ID, then the incoming message is ignored.


This algorithm examines the status byte and routes the signal to the appropriate algorithm.

RequestHop none12 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

ReceiveHopReply 12 bytes12 bytes

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.

SendHopReply 12 bytes12 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.

SendSignal 12 bytes12 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.

Table 2. Transceiver RWP Algorithms



Client Fobs

Name InputOutput Description

ReadButtons button press(es) bit

Determines if the correct combination of buttons was pressed to transmit a signal. Sends SendSignal a bit value.

SendSignal bit 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.

ReceiveSignal 4 bytes 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


ReadButtons button press noneIf a button press is recorded, then initate SendSignal.

SendSignal none 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



Master Receiver



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 do not match then the signal is not sent to the MCM.

Table 5. Master Receiver RWP Algorithms

Byte Code Alias Description

0000 0000 NORMAL

The state which tells any listening transceiver or Master Receiver that the received signal should be treated as an alert signal.

1111 1111 OK

A health pulse value that signifies that the sending transceiver is in good working order.

0101 0101 REQUEST_HOP

A REQUEST_HOP transmission is sent out by a newly installed transceiver. The signal is an interrogation of surrounding transceivers' hop count.

0111 0111 SENDING_HOP

A SENDING_HOP transmission is sent by the surrounding transceivers of a newly installed device.

1111 0000 MAINTENANCE

A health pulse value that signifies that there is something wrong with the sending transceiver.

Table 6. Transceiver Status Byte Codes



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


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.


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


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



Master Control Module AlgorithmsName Input Output Description

ReceiveSignal12 bytes 12 bytes

This algorithm utilizes a hardware interrupt watching the USB port for a call from the Master Receiver.

DisectSignal12 bytes 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.

GetTransceiver 2 bytesTransceiver object

Uses the 2 byte input as an unsigned integer and retrieves the transceiver data from the database calling select_transceiver_recordID. Once the data is retrieved it uses that data to build a Transceiver object.

GetFob 2 bytes 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.



Name Input Output Description

GetUser integerUser object

Uses the integer value of stored in the fob object for the user id to access the user info from the database using select_user_recordid. Once the data is retrieved it uses the data to build a User object.

GetStatus 1 byte enumUses the 1 byte array for status and returns an enumeration coinciding with the byte code value.

RouteData statusEnum 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.

ProcessAlert

Transceiver Object, Fob Object, User Object 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.




ProcessAlert

Transceiver Object, Fob Object, User Object none

ProcessHealthPulse

Transceiver object, StatusEnum none

This algorithm processes a health pulse signal. It sets the status of a transceiver based on the StatusEnum. It will call: update_transceiver.

getLocation IncidentLogIdAlert object

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 transceiver receiving signal circles and the radius is the margin of error.

getAllIncidents

startDate (datetime), endDate (datetime)

collection of Incident Objects

This algorithm queries the database for the entire incident logs between (inclusive) of the dates provided. For each record returned by select_incidentLog_Dates, an Incident object is created from the data stored in the record.

getAllTransceivers None

collection of Transceiver Objects

This algorithm queries the database for all of the transceiver records using: select_transceiver_all. For each record returned a new Transceiver object is added to the collection.

updateIncidentIncident Object 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

Table 7. MCM Algorithms

Database


ProceduresName Input Output Description

delete_IncidentLogRecord ID for deletion

Integer number of rows affected. 0 means that no deletion occured.

Removes a row from INCIDENT_LOG

update_IncidentLog

RecordID (integer), FobID (integer), Description (string), ResponseTime (integer)

Integer number of rows affected. 0 means that no update occured.

Updates an INCIDENT_LOG row.

create_IncidentLog

FobID (integer), Description (string), ResponseTime (integer)

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.

select_incidentLog_Dates

StartDate

record set

Gets all incidents logged between (inclusive) the dates provided.

(datetime), EndDate(datetime)




create_user

OrganizationID (string), Age (integer), Sex (char)

Integer number of rows affected. 0 means the create failed.

Creates a new row in USER_INFO; called from registerUser

update_user

RecordID (integer), OrganizationID (string), Age (integer), Sex (char)

Integer number of rows affected. 0 means the update failed.

Updates a row in the User_Info table.

select_user_all none record set

Gets all User_Info records

select_user_recordIDRecordID (integer) record set (one row)

Gets the record with the ID provided.

delete_userRecordID (integer)

Integer number of rows affected. 0 means that no deletion occured.

Removes a row from the User_Info table.

create_fob

RecordID (integer), UserID (integer), IsActive (boolean)


Creates a new row in the Fob_Info table.

update_fob

RecordID (integer), UserID (integer), IsActive

Integer number of rows affected. 0 means the update failed.

Updates a row in the Fob_Info table.(boolean)

select_fob_all none record set

Gets all rows from the Fob_Info table.

select_fob_recordidRecordID (integer) record set (one row)


select_fob_all_active none record set

Gets all rows from the Fob_Info table that are marked as active.




deactivate_fobRecordID (integer) none Sets isActive to false

delete_fobRecordID (integer)

Integer number of rows affected. 0 means the delete failed.

Removes a row from the Fob_Info table.

create_incident_transceiver

IncidentID


Creates a new record in the Incident_Transceiver_List table.

(integer), TransceiverID(integer)

update_incident_transceiver

RecordIDInteger number of rows affected. 0 means the update failed.

Updates a record in the Incident_Transceiver_List table.

(integer), IncidentID

(integer), TransceiverID(integer)

select_incident_transceiver_all none record set

Gets all rows from the Incident_Transceiver_List table.

select_incident_transceiver_recordIDRecordID (integer)

record set (one row)


select_incident_transceiver_incidentIDIncidentID

record set

Gets all rows from the table that match the provided IncidentID(integer)

delete_incident_transceiver RecordID

integer number of rows affected.

Removes a row from the Incident_Transceiver_List table.




delete_incident_transceiver_incidentID

IncidentID Integer number of rows affected.0 means the delete failed.

Removes all rows from the Incident_Transceiver_List table that have a matching IncidentID(integer)

create_transceiver

RecordID, Latitude(float), Longitude(float), Status (integer)

integer number of rows affected. 0 means the create failed.

Creates a record in the Transceiver_Info table.

update_transceiver

RecordID, Latitude

number of rows affected. 0 means the update failed.

Updates a record in the Transceiver_Info table.

(float), Longitude(float),

Status (integer)

select_transceiver_all nonerecord set

Gets all of the records in the Transceiver_Info table.

select_transceiver_recordid

RecordID record set (one row)

Gets the record with the ID provided.(integer)

delete_transceiver

RecordIDInteger number of rows affected. 0 means the delete failed.

Removes a row from the Transceiver_info table.(integer)

Table 8. Database Algorithms



Dispatch User Interface Application Name Input Output Description

DisplayMap none graphic display

This algorithm displays an indication of a map on the UI screen.

DisplayLogInfoIncident object from MCM graphic display

This algorithm displays the Incident Log information in an easily editable manner on the UI screen.

DisplayAlertOnMap Alert object graphic display

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.

UpdateLogvalues from web form controls Incident Object

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

DisplayUserInfoUser object from MCM graphic display

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

ShowTransceiverStatus none graphic display

This algorithm makes a call to the MCM (getAllTransceivers) and displays the results on a separate UI screen from the map.

Table 9. DUI RWP Algorithms



Dispatch User Interface - WebName Input Output Description

getAllIncidentsByDateTime period x and y

HTML fragment produced from the results of a Web API call to getAllIncidents

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

getIncident Incident ID

HTML fragment produced from the results of a Web API call to getIncident

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.

getUserInfo Fob ID

HTML fragment produced from the results of a Web API call to getUserInfo

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.

getTransceiverStatus Transceiver ID

HTML fragment produced from the results of a Web API call to getTransceiverStatus

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.

getAllTransceiverStatus none

HTML fragment produced from the results of a Web API call to getAllTransceiverStatus

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.



getAllUsers 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.

setIncidentLogText, 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.

pollServer none

JSON object representing any current messages

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.

drawPointPoint x; Point x, y; Point x, y, z

Draws necessary circles or triangles showing approximate location of incident

Using data from pollServer's response, it draws the point of intersection between one to three points.

Table 10. Dispatch User Interface Web Algorithms in RWP



User Registration ProgramName Input Output Description

addUserUser, ID, age, sex

True or False upon result of DB call.

Calls database using create_user call and supplying necessary variables.

addFob IDTrue or False upon result of DB call.

Calls DB using create_fob and supplying necessary variables

linkUserToFob ID; User IDTrue or False upon result of DB call.

Calls database using update_fob and supplying necessary variables

deleteUser User IDTrue or False upon result of DB call. Calls database using delete_user

deleteFob Fob IDTrue or False upon result of DB call. Calls database using delete_fob

deactiveFob Fob IDTrue or False upon result of DB call.

Calls database using deactive_fob

Table 11. Fob User Registration Algorithms

Transceiver Registration Program


addTransceiverID, Latitude, Longitude

True or False upon result of DB call.

Calls DB using create_transceiver

deleteTransceiver Transceiver IDTrue or False upon result of DB call.

Calls DB using delete_transceiver

updateTrasceiver Transceiver IDTrue or False upon result of DB call.

Calls DB using update_transceiver

Table 12. Transceiver Registration Algorithms


Dispatch Web Server - ASP



getAllIncidentsByDate

Time period x and y

Collection of objects populated that match time period

Calls DB procedure select_IncidentLog_Dates requesting all incidents from time period x to y.

getIncidentIncident ID

Custom object reflecting values retrieved from DB call select_IncidentLog_RecordID

Calls DB requesting a single incident.

getUserInfo Fob ID

JSON object reflecting values of DB entry for User ID

Calls DB requesting a single user's information using the linked Fob ID.

getTransceiverStatusTransceiver ID

JSON object containing status of transceiver

Calls select_transceiver_recordID and parses the row for the status field and then returns that.

getAllTransceiverStatus none

JSON indexed by transceiver ID and containing each transceiver's status.

Calls DB select_transceiver_all and parses each row for status field. Returns an array of pairs of all status messages indexed by transceiver ID.

getAllUsers noneJSON object populated by all users in the system Calls DB select_user_all

setIncidentLog

Text, Incident ID

JSON object detailing success or failure

Calls DB update select_IncidentLog_RecordID and then calls DB again using returned data but changing Description for update_IncidentLog

pollServer noneJSON 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_incidentID.

Table 13. Dispatch Web Interface ASP Algorithms in RWP


Figure 7. Example Layout of Transceivers



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.


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.



Microcontroller-driven Transceiver Name Input Output Description

ReceiveSignal 4 bytes 2 bytes

Receives 4 bytes from fob. Ignoring the later 2 bytes, it translates these initial bytes into button presses and passes the value to writeConsole.

WriteConsole 2 bytes character array

Receives the button presses from ReceiveSignal and calls native println() sending data along USB connection to listening program on computer.

FobName Input Output Description

ReadButtons button press 4 bytes

Determines which button was pressed. Adds to the total button presses. Sends both numbers, 4 bytes total, to SendSignal.

SendSignal 4 bytes 4 bytes

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



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 inter-

communication 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.



Transceiver Network Simulation Name Input Output Description

getTrancieverLocationlocation x and y location x, y

Displays location of individual receiver.

getAllIncidents mouse click

calls drawPoint(), getUserInfo(), getFobID(),getFobLocation()

Starts the network Simulation, draws a circle around key fob and outputs data to GUI.

getUserInfo User ID

User object reflecting values of input document for User ID

Displays User ID on the GUI.

StartTranceiverWavelocation x and y

increments the location until its bounds are out of the last tranceiver's reach

Uses the location from first transceivers to receive the signal and then increments it, causing all transceivers in the path to blink.

getFobLocationlocation x and y calls getTrancieverStatus()

gets location of Fob from transceivers in range.

drawPoint

Point x; Points x,y; Points x,y,z

Displays circle(s) or triangle of approximate location of incident

Uses location data from transceivers listed as reporting to the incident ID passed to and processed by incidentAlert.

getTrancieverStatus

location x and y from transceiver

status of 1 or 0 showing if it is in range of key fob Finds the closest

getFobID Fob ID

User object reflecting values of input document for Fob ID Displays fob ID.

Table 15. Transceiver Network Simulation


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.

.



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

Fob Custom, manufactured.Nordic Fob (WRL-08602).

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.

One transceiver incorporated into an Arduino prototype board (Hardware Test). Network of transceivers will be simulated using software.

Master Receiver

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

Simulated using software.

Master Control Module Suite of software.

Single process, different threads simulating different aspects of RWP suite.

Dispatch User InterfaceBrowser-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.

Database Server Microsoft SQL Server database server.Microsoft SQL Server Express on test platform.

Table 16. Features Comparison RWP vs. Prototype


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.



Figure 8. Hardware Processes in Prototype



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.


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.


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.


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.



Prototype Condition Assumptions

Hardware or Simulation

There will be no signal interference from non PASS 2.4 GHz transmissions. SimulationThere will be no signal interference from existing structures. SimulationWeather will have no affect on signal strength or direction. SimulationAll users who access PASS via the DUI will be authorized users. Therefore no secure login abilities will be required. Simulation

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

Table 17. Assumptions



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.


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.



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.

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.

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.

REFERENCES

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


Virginian-Pilot, p. B3.

Laboratory 1 - Old Dominion Universitycpi/411/blues11/documents/411/Lab... · Web viewThis...

Documents

Transcript of Laboratory 1 - Old Dominion Universitycpi/411/blues11/documents/411/Lab... · Web viewThis...