ODUcpi/old/411/blues11/documents/… · Web viewThe PASS Prototype will be broken in to two...

Lab 2 – PASS Product Specification 1

RUNNING HEAD: LAB 2 – PASS PRODUCT SPECIFICATION

Personal Alert and Safety SystemLab 2 – Product Specification (Sections 2 & 3)

CS 411 Blue Team:Dan Cox

Jon SzewczakBrittany DufortMarcus HenryGordon BlandBraden Gibson

Gene H. Price

March 20, 2011


Table of Contents

List of Figures......................................................................................................................6

List of Tables.......................................................................................................................7

2 General Description.......................................................................................................8

2.1 Prototype Architecture Description.......................................................................8

2.1.1 Hardware (Dan Cox).........................................................................................8

2.1.2 Simulation Demonstration (Jon Szewczak)....................................................10

2.1.2.1 Radio Device (Jon Szewczak)..................................................................11

2.1.2.2 Transceivers (Dan Cox)...........................................................................14

2.1.2.3 Master Control Module (Jon Szewczak)..................................................15

2.1.2.4 Fobs (Dan Cox)........................................................................................18

2.1.2.5 Database (Gordon Bland).........................................................................19

2.1.2.6 Dispatch User Interface (Brittany Dufort)...............................................20

2.1.2.7 Simulation Driver Interface (Braden Gibson)..........................................20

2.2 Prototype Functional Description........................................................................20

2.2.1 Hardware (Dan Cox).......................................................................................20

2.2.2 Simulation Demonstration..............................................................................21

2.2.2.1 Radio Device (Jon Szewczak)..................................................................21

2.2.2.2 Transceivers (Jon Szewczak)...................................................................22


2.2.2.4 Fobs (Dan Cox)........................................................................................26





2.3 External Interfaces...............................................................................................28

2.3.1 Hardware Interface.........................................................................................28

2.3.1.1 Hardware Demonstration (Dan Cox).......................................................29

2.3.1.2 Simulation Demonstration (Jon Szewczak).............................................30

2.3.2 Software Interface...........................................................................................30


2.3.2.2 Simulation Demonstration (Jon Szewczak).............................................32

2.3.3 User Interface..................................................................................................32

2.3.3.1 Hardware Demonstration (Marcus Henry).............................................33

2.3.3.2 Simulation Demonstration.......................................................................33

2.3.3.2.1 Simulation Driver Interface (Jon Szewczak, Dan Cox)....................33

2.3.3.2.2 Dispatch User Interface (Brittany Dufort).........................................35

2.3.4 Communication Protocols..............................................................................35


2.3.4.2 Simulation Demonstration (Dan Cox).....................................................36

3 Specific Requirements.................................................................................................37

3.1 Functional Requirements.....................................................................................37

3.1.1 Hardware Demonstration (Marcus Henry).....................................................37





3.1.2.3 Fobs (Dan Cox)........................................................................................39




3.2 Performance Requirements..................................................................................41

3.2.1 Hardware Demonstration(Marcus Henry)......................................................41




3.2.2.3 Fobs (Dan Cox)........................................................................................43




3.3 Assumptions and Constraints...............................................................................45

3.3.1 Assumptions (Brittany Dufort).......................................................................45

3.3.2 Constraints (Dan Cox)....................................................................................45

3.3.3 Dependencies (Jon Szewczak)........................................................................47

3.4 Non-Functional Requirements.............................................................................49

3.4.1 Security (Gordon Bland).................................................................................49

3.4.2 Maintainability (Marcus Henry).....................................................................49


3.4.3 Reliability (Braden Gibson)............................................................................50


List of Figures

Figure 1. Simulation Demonstration Major Functional Component Diagram.................11

Figure 2. RadioDevice Class Diagram.............................................................................12

Figure 3. Transceiver Class Diagram...............................................................................15

Figure 4. MCM Class Hierarchy......................................................................................16

Figure 5. Fob Class Diagram............................................................................................19

Figure 6. Process Flow for Sending Database Information to the SDI from the MCM....23

Figure 7. ProcessAlerts Method Process Flow.................................................................24

Figure 8. Centroid of a Triangle Example........................................................................25

Figure 9. Alert Location Calculation Flow Diagram.......................................................26

Figure 10. Arduino User Interface...................................................................................32

Figure 11. User Interface of Arduino...............................................................................33

Figure 12. Simulation Driving Interface Screenshot........................................................34

Figure 13. Dispatch User Interface Screenshot................................................................35


List of Tables

Table 1. RadioDevice Object Properties and Methods.....................................................13

Table 2. Position Object Properties and Methods............................................................14

Table 3. MCM Object Collection Class Methods and Properties....................................17

Table 4. FobInfo Object Properties and Methods.............................................................17

Table 5. TransceiverInfo Object Properties and Methods................................................18

Table 6. UserInfo Object Properties and Methods...........................................................18

Table 7. IncidentInfo Object Properties and Methods......................................................18

Table 8. Functional Requirements of Fobs.......................................................................39

Table 9. Database Simulation Specifications...................................................................40

Table 10. Database Performance Specifications..............................................................44

Table 11. Prototype Assumptions.....................................................................................45

Table 12. Constraints........................................................................................................47

Table 13. Security Specifications.....................................................................................49


2 General Description

The PASS Prototype will be broken in to two distinct demonstrations. The first will be a

Hardware Demonstration, which will highlight actual 2.4 GHz radio communication between a

fob, a transceiver, and a microcontroller. The second demonstration will be a software

simulation which will show PASS functioning as it would in a large real world production

environment.

2.1 Prototype Architecture Description

The following sections will highlight the different components that will be used to

construct each demonstration. For the Hardware Demonstration, actual physical components

will be connected together to form the end product. The Simulation Demonstration will be

constructed entirely of software.

2.1.1 Hardware (Dan Cox)

PASS, as originally devised, is a complex set of interlocking systems. Conceived of as

hundreds if not thousands of small transceivers scattered at about 90 feet away from each other.

The system would allow for thousands of additional Fob devices, small hand-held radio

transmitters, to broadcast when a button was pressed. The transceivers, working in concert with

server software and a database, would, once detecting and processing a Fob signal, be able to

point first responders to an approximate physical location. The process to narrow the scope and

costs to a suitable prototype of the system was long and many discussions took place. Finally, the

specifications of the prototype were agreed upon and ordered. The architecture of the Hardware

Demonstration consists of four physical pieces, three external interfaces and one wireless

connection.


The primary components of the Hardware Demonstration are a nRF24L01 Transceiver,

Arduino microcontroller, Nordic Fob and a PC. This hardware list, and the connections between

them, is the entirety of the demonstration. In order for the Hardware Demonstration to be

considered a success, a signal sent from the Fob must be recognized by the Transceiver,

processed by the Arduino and then shown on the PC. Each item however is unique to the overall

architecture.

The largest piece, the Arduino microcontroller, is described on its website as “an open-

source electronics prototyping platform based on flexible, easy-to-use hardware and software”

(Arduino, 2011). The PASS system uses it as the equivalent of a motherboard in the 'computer'

that the transceiver and microcontroller jointly represent. The Transceiver receives the signals

that the Fob sends but is driven by the microcontroller using a software library developed by

Aaron Shrimpton that is used initialize, run and power-down the transceiver (Shrimpton, 2011).

Without the Arduino, the entire prototype would fail. It connects to the PC via a USB cable.

Their interactions, the PC and Arduino, are described in more detail in the External Interfaces

section.

Just as important as the motherboard, the Arduino, the Transceiver, a nRF24L01+ chip

with built-in antenna, is the ear of the system. The Transceiver with its “100m Range at

250kbps” listens for the Fob to transmit a signal (Transceiver, 2011). Once heard, the transceiver

writes to the internal memory of the Arduino for later processing and goes back to listening for

more signals. The interactions between this component and the Arduino are examined in greater

detail in the External Interfaces section.

The Nordic Fob is the transmitter of the system. It has five buttons and is run by a

“ATtiny24 [that] will wake up, transmit the buttons being pressed, a 16-bit integer value of the


total button presses since last battery replacement, and then return to low-power sleep” upon the

pressing of one of the buttons (Nordic, 2011). The PASS Prototype Hardware Demonstration

uses the various buttons on the Nordic Fob as different users. They are processed as one user per

button by Arduino, for a total of five different user combinations.

The PC is the most generic of the components. Because of time and budgetary reasons,

the most probable model used as a stand-in for the PC will be a team member’s laptop. This will

allow for faster development and customization than classroom or even demonstration materials

can provide. The ability to hone the experience down to just the barest of interfaces and

interactions will help make the demonstration of a Fob's signal being processed as streamlined as

possible.

2.1.2 Simulation Demonstration (Jon Szewczak)

The PASS Prototype’s Simulation Demonstration will be a pure software solution. The

simulation application will be constructed in such a way that it can be run on a single high-

performance computer or laptop. The application will have several distinct pieces to it:

1. Simulation Driving Interface (SDI) – an application window that will control the

origination of alert signals in the simulated transceiver network environment.

2. Dispatch User Interface (DUI) – an application window that will display the results of

the alert signal processing. It will closely match the functionality of the real world

product.

3. Master Control Module (MCM) – an application class object that will handle all

communication and processing between the two application windows and the

database.


4. Database – a store-house for the PASS data that will be used to simulate an alert

process.

Figure 1 depicts these objects in a graphical manner that will illuminate more clearly the

communication pathways.

Figure 1. Simulation Demonstration Major Functional Component Diagram

The simulation application will be developed using Microsoft’s C# programming

language. This language was chosen for its ability to quickly and efficiently build robust

graphical applications while maintaining a high level of processing strength. The project team

felt that using this language would benefit them the most.

2.1.2.1 Radio Device (Jon Szewczak)

All simulation objects that will appear on the mapping display in either of the two

graphical displays will inherit from an object called RadioDevice. RadioDevice is base class that

must be inherited. It itself inherits from the Microsoft object Control. The Control object will

provide the RadioDevice object and its inherited children with the logic and procedures

necessary to be rendered in a standard Windows form. Figure 2 describes this relationship

graphically and lists the major properties and methods of the RadioDevice object. Table 1 will

briefly describe each property and method.


Figure 2. RadioDevice Class Diagram

(This Space Left Intentionally Blank)


Property Name DescriptionID (byte) The 16-bit integer value that identifies the RadioDeviceLocation (Drawing.PointF)

The location of the object when it’s placed on a Windows Form. The data type is a Microsoft native drawing type.

Mode (RadioDeviceMode)

Determines the display and signal mode of the RadioDevice. Possible values are StandBy, Transmit, and Receive. The default is StandBy.

Range (float) The real world radio frequence transmission range for the object the RadioDevice is representing.

RealWorldPosition (Position)

This is the Latitude and Longitude of the device in simulation space.

ReceiveColor (Drawing.Color)

The color of the object when the Mode property is set to Receive. The data type is a Microsoft native drawing type.

ReceiveSize (Drawing.Size)

The size of the object when the Mode property is set to Receive. The data type is a Microsoft native drawing type and contains a height and width value.

StandbyColor (Drawing.Color)

The color of the object when the Mode property is set to StandBy. The data type is a Microsoft native drawing type.

StandbySize (Drawing.Size)

The size of the object when the Mode property is set to StandBy. The data type is a Microsoft native drawing type and contains a height and width value.

TransmitColor (Drawing.Color)

The color of the object when the Mode property is set to Transmit. The data type is a Microsoft native drawing type.

TransmitSize (Drawing.Size)

The size of the object when the Mode property is set to Transmit. The data type is a Microsoft native drawing type and contains a height and width value.

Method Name Descriptionvoid Receive (byte[]) Takes a 2-byte array as a parameter and stores the array as part of its

internal message for transmitting or processing.byte[] Transmit() Passes a 2-byte array to a calling procedure. The first byte is the

transceiver ID and the last byte is the internal message to relay.void OnPaint(object, PaintEventArgs)

An overrided method from the parent class. This method tells the form how to draw the RadioDevice control every time it

Table 1. RadioDevice Object Properties and Methods

The Position object is defined as part of the RadioDevice object. This class will hold the

real world coordinate data for each RadioDevice object. This data will be used to aid in placing

the objects on the map in a position that more accurately reflects their real world location. Table

2 lists the properties and methods of the Position object and gives a brief description of each.


Property Name DescriptionLatitude (float) The float value between 0.0 and 90.0 representing the

latitude of the Position object.Longitude (float) The float value between 0.0 and 180.0 representing the

longitude of the Position object.Method Name DescriptionDrawing.PointF ConvertToXY( Position, Drawing.PointF, Position, Drawing.PointF)

Converts the embedded Latitude and Longitude values to a Drawing.PointF value that can then be used to map the RadioDevice onto a form control.

void ConvertFromXY( Drawing.PointF, Position, Drawing.PointF, Position, Drawing.PointF)

Converts the first supplied PointF parameter into Latitude and Longitude values that are then stored in the Position object.

Table 2. Position Object Properties and Methods

2.1.2.2 Transceivers (Dan Cox)

Transceivers, once a primary part of the PASS project, have been now regarded by many

team members as beacons. One team member even called them “mostly useless” once. Their

architecture is derived from the base class of RadioDevice, so that section – the one covering

RadioDevice – should be examined as to how a Transceiver might work in the simulation if they

were not, as was previous stated, mostly useless.

Their architecture, as was stated not two sentences ago, is inherited from the base class

RadioDevice. So, Transceivers must be coded in such a way to support the necessary code to

hold position data, an identification number and be able to draw to the screen its color indicating

its status. Used by Simulation Driver Interface only.



Figure 3. Transceiver Class Diagram

2.1.2.3 Master Control Module (Jon Szewczak)

The Master Control Module, or MCM, is the portion of the software simulation that

performs the majority of the processing and calculations. In a full PASS implementation, the

MCM would be located on a server that was physically connected to the transceiver network.

For the simulation, the MCM will be virtually connected in memory to both the SDI and the

DUI.

The MCM will be constructed as a Microsoft C# class object. Its properties, methods, and

subclasses will allow the other modules to communicate effectively without worrying about the

details of the processing. Figure 4 describes the relationships of the Master Control Module

class and its component classes.



Figure 4. MCM Class Hierarchy

As Figure 3 shows, the MCM abstracts away the details of communication with the

database from the clients that interface with it. The clients only interface with each object

collection in order to obtain the information that is needed and consequently are unconcerned

with how the information is stored and retrieved. Each object collection follows a similar model

and the methods and properties of that model are discussed in Table 3



.

Property Name DescriptionCount The number of records that are managed by the collection.Method Name DescriptionAdd(object) – [FobInfo, TransceiverInfo, IncidentInfo, or UserInfo object]

Adds an object to the collection. This will trigger the database interactions to store the data stored in the parameter object as a new record in the database.

Remove(object) – [FobInfo, TransceiverInfo, IncidentInfo, or UserInfo object]

Removes an object from the collection. This will trigger the database interactions to delete the records referenced by the parameter object.

Get(integer) Returns a single object (FobInfo, TransceiverInfo, UserInfo or IncidentInfo) from the database based on the integer ID parameter.

GetAll() Returns a List<T> of objects that correspond to all records in the database for that collection.

Table 3. MCM Object Collection Class Methods and Properties

Each object collection that is a part of the MCM class hierarchy also has a corresponding

member object. This member object is an intrinsic portion of the abstraction model. Each one

allows the clients to reference the data that is stored in the database as if it were properties of an

object. This allows for far less code and eliminates the need for the clients to understand the

record structure of the database. Tables 4 through 7 will discuss the properties and methods of

each of these objects.

Property Name DescriptionID This is an 8 bit integer (byte) value that uniquely identifies

a fob.UserID This is an integer value that uniquely identifies a user

record within the database. Each fob can be associated with only one user (i.e. a one-to-one relationship).

Table 4. FobInfo Object Properties and Methods


Property Name DescriptionID This is an 8 bit integer (byte) value that uniquely identifies

a transceiver.Lat A float value representing the latitude coordinates of the

position that the transceiver has been installed at.Long A float value representing the longitude coordinates of the

position that the transceiver has been installed at.

Table 5. TransceiverInfo Object Properties and Methods

Property Name DescriptionID An integer value that uniquely identifies a user.Name A string value that holds the user’s name.Age An integer value that holds the user’s age.Sex A character value that holds the gender of the user (‘M’ or

‘F’).

Table 6. UserInfo Object Properties and Methods

Property Name DescriptionID An integer value that uniquely identifies the incident.Time Returns the time the incident was first logged.TransceiverCount Returns the number of transceivers that heard the signal

that this incident is tracking.TransceiverList Returns a List<byte> that corresponds to the transceivers

that have been marked as having heard the signal this alert is tracking.

Method Name DescriptionAddTransceiver(byte) Adds an indication in the database that a particular

transceiver heard the signal that is being tracked by the incident.

RemoveTransceiver(byte) Removes an indication in the database that a particular transceiver heard the single that is being tracked by the incident.

Table 7. IncidentInfo Object Properties and Methods

2.1.2.4 Fobs (Dan Cox)

In the real world project, Fobs are small devices that are used to send radio signals from a

single or small number of buttons. In the simulation however they are limited to the interactions

from a click on the map area in the Simulation Driver Interface. In addition, their functionality

has been reduced.


Their architecture is based on the base class of RadioDevice. Figure 2 shows the full

range of functionality that would be possible for objects that inherit from this base class,

however, because of the constraints of the project, the Fob only has a limited subset of the its

physical counterpart, as previous stated. This subset includes the fact that Fobs will only transmit

once per use and will have only two active modes: transmit, upon the click of a mouse, and

standby, the more dominant state.

Figure 5. Fob Class Diagram

2.1.2.5 Database (Gordon Bland)

The database will provide all required data for to the MCM in the simulation. Data

received from distress signals i.e. location data, event data, etc. The SDI will request information

from the database. Requests are as follows: user information, fob information, transceiver

information, and a list of receivers that sensed the alert and reported back. As the database is the

backbone for information of this system, the MCM object will request information from the

database alone.


2.1.2.6 Dispatch User Interface (Brittany Dufort)

The Dispatch User Interface (DUI) is a specific graphical user interface for the dispatch

station. The prototype DUI will encompass a map of Old Dominion University, a table of active

alerts, as well as extra information such as longitude, latitude, timestamp, and elapsed time. The

interface’s sole purpose is to display the alerts informing the dispatch personnel. It will not take

any input from the user.

2.1.2.7 Simulation Driver Interface (Braden Gibson)

The Simulation Driver Interface (SDI) is a GUI interface that will serve as a simulation

model for the PASS prototype. The GUI will be comprised of a Map of ODU, a table to display

recent history, a drop down menu for selecting a user, and multiple buttons that will each control

a specific event in the windows form. It will function alongside the MCM requesting

information on the User, Fob, and Transceiver while updating the MCM with a list of

transceivers that have received the alert signal. The SDI will take input from the user when

needed by way of either drop down menus or buttons.

2.2 Prototype Functional Description

The following sections will cover the intended workings of each component. For the

Hardware Demonstration this will include the communication pathways, physical connections,

and interface code. This will include the logical workings of each component of the Simulation

Demonstration and how it fits into the overall scheme of the simulation application.

2.2.1 Hardware (Dan Cox)

There are four components in the Hardware Demonstration. Each operates

through different, specific functionality. They are: Arduino, Transceiver, Fob and PC.


The Arduino is a microcontroller controlled by the PC. It runs on compiled code called

sketches that are written and then pushed to the system from the PC. Its functionality is the

processing of signals sent from the Transceiver. It does this by querying the Transceiver via a

series of high and low voltages message.

The Transceiver is wired to the Arduino. As directed by the microcontroller, it listens for

radio frequency signals and then passes them, via a hardwired connection, to the Arduino for

processing. It listens for wireless signals sent from the Fob.

The Fob is a small handheld device. Its primary is to broadcast a short wireless message.

To signal when this should happen, the Fob has a set of buttons. As these buttons are pressed, the

Fob sends out which buttons were pressed and how many times they have been pressed.

The PC is a personal computing unit. During the demonstration, it will replaced with one

of the team member’s laptops. This will be used to verify that the signal, as sent from the Fob, is

being correctly process, via the Arduino. A USB cable connects the Arduino and the PC.

2.2.2 Simulation Demonstration

The Simulation Demonstration will be written as a single Windows application. The

application will make use of two form objects, the SDI and the DUI, a database, and a robust

class object (the MCM). Each of these components and their individual functionalities will be

discussed in further detail in the following sub sections.

2.2.2.1 Radio Device (Jon Szewczak)

The RadioDevice object will provide the majority of the functionality for all objects that

appear on the mapping displays. Its OnPaint method will provide the objects with a method for

being drawn on the screens whenever they are called by the SDI or DUI. It provides properties

to control the size and color of its graphical representation based on the broadcast mode. The


broadcast mode is controlled by setting a property called Mode in the object. It also provides

two methods to handle simulated data transmissions: Transmit and Receive.

The Receive method takes a byte array as a parameter and stores it as a message within

the RadioDevice data structure. However, the Receive method requires that the RadioDevice

object be set to the Receive mode. If it is not in Receive mode, it will throw an exception.

The Transmit method will pass the stored message array to the calling program if the

mode is set to Transmit. The stored message will be a two byte array. If there is no stored

message, the function will set the RadioDevice ID in the second index, set the first to zero, and

return the result. If the stored message has a zero in the first index and a non-zero in the second,

the function will set the RadioDevice ID in the first index, and then return the result. If both

array positions are non-zero then the function will return the message.

2.2.2.2 Transceivers (Jon Szewczak)

In the Simulation Demonstration, the transceivers will be graphical objects that hold a

few bytes of critical data. They will inherit from RadioDevice, as all objects will for display on

the SDI map. Their role in the simulation is critical, because they are the simulated link between

the fob and the MCM.

When a fob is told by the SDI to send its signal, it will send it to any transceiver in range.

The transceiver will hold the ID of the fob as its internal message. When the time comes for the

SDI to alert the MCM of a signal it will query the transceiver again for its message. It will then

build a list of messages to hand over to the MCM. These messages will be the 2-byte arrays that

all RadioDevice objects contain.

Transceivers will be placed on the map via positions stored within the database. When

the SDI is ready it will request a list of transceivers to show from the MCM. Once that list is


obtained, the SDI will create new transceiver objects based on the data retrieved from the MCM.

These new objects will be placed into StandBy mode and await a fob signal.


The MCM handles all exterior communications for the SDI and the DUI. As mentioned

earlier, the DUI only receives data from the MCM. The SDI, on the other hand, receives and

sends data to the MCM.

The MCM interacts with the SDI by sending it data and then receiving data from it.

When the SDI communicates with the MCM to query information about the PASS network

devices (i.e. Fobs, Transceivers, etc.), a standard process is used. Since each subclass in the

MCM is constructed similarly only small changes to the process are needed to suit. Figure

2.2.2.3.A describes this process for a call to get a list of UserInfo objects.

Figure 6. Process Flow for Sending Database Information to the SDI from the MCM

The SDI also communicates with the MCM to send it data about alerts. After the SDI

discovers which transceivers would hear the alert, it collects the messages from those

transceivers, and sends them to the MCM for processing.

The alert processing algorithm is started by the SDI calling the ProcessAlerts

method every time an alert is received. This method takes a list of byte arrays as a parameter.


Figure 7 describes the ProcessAlerts flow.

Figure 7. ProcessAlerts Method Process Flow

The calculation of the location of the alert signal is arguably the single most important

algorithm the MCM must implement. This function must work in order for the simulation to be

deemed a success. To that end the following theory will be used to determine alert location and

tolerance range. Figure X will depict this process flow in a graphic for better understanding.

If three or more alert signals are passed to the MCM to process, only the first three will

be used. From the transceiver locations that these signals reference a triangle can be formed. It

will be assumed that the alert location will lie within this triangle. The MCM will then formulate

and solve for the centroid of this triangle (see Figure X). The centroid can be thought of as the

* NOTE: Refer to Figure 9 for a detailed look at the alert location calculation process.


weighted center of the triangle. The MCM will use this point to locate the alert signal and give

the DUI a tolerance range of 50 feet.

Figure 8. Centroid of a Triangle Example

If there are only two alert signals passed to the MCM to process, then the MCM will

draw a line between the two transceiver locations. The midpoint of this line becomes the

calculated alert signal and a tolerance range of 75 feet is passed along with it. The increased

tolerance range is needed here, because of the added uncertainty involved with only two reported

signals.

Finally, if only one signal is relayed, then that transceiver location is given as the alert

location. The tolerance range is set at 100 feet, which is equivalent to the broadcast range of the

fob itself. It should be noted that 100 feet is the maximum possible tolerance range. Since the

fob has a range of 100 feet, then there is no possible way that any receiver could pick it up

beyond that range. Therefore every alert signal must be within 100 feet of a transceiver that


heard it.

Figure 9. Alert Location Calculation Flow Diagram

Once the MCM has processed the alert signals to obtain the location, the tolerance range,

and the user information; the MCM triggers an event notification and pass the information that

was the result of the processing to as parameters. The DUI will be listening for this notification

and will then handle the display from there.


A simulated Fob, similar in functionality to the physical fob used in the Hardware

Demonstration, is also the smallest unit used. A Fob object inherits from the RadioDevice object

but uses only a subset of all possible options. Because it does not need to receive, it does not

override the base class defaults and only uses the alternative, transmitting.

This transmission functionality, instead of being sent to transceivers and then relayed

ultimately to the Master Receiver, is actually a direct link between the Master Control Module

and the Fob. The Master Control Module is given a two byte array holding the identification of

the Fob and the User associated with that Fob. Each Fob, because it inherits its functionality

from the base class RadioDevice, also has a range.


This range property of the Fob object dictates the extent at which the simulated signal

will travel. The Transceivers that are computed to be within that range are added to a list that is

handled by the SDI and MCM. The Fob object must also handle its own display options.

Everything that inherits from RadioDevice must override the OnPaint functionality of a

Windows Form. This is done to allow different objects direct control over their appearance.

During the initial click, a fob will have a color showing that it in StandBy mode. Upon releasing

the click, the Fob will have a color showing that it is in transmit mode despite not actually

continuing to broadcast its signal.


The database of the PASS system will contain all data required for the simulation. As

opposed to Lab 1, the database schema will be less complex, while retaining the same

functionality. Unneeded parts have been removed just as the simulation requirements became

more specific to simplify the simulation.

The database will provide stored procedures for the MCM in order for data to be

retrieved, added, updated, and deleted. The SQL queries will be required to execute and

successfully terminate within 0.5 seconds to ensure speedy functionality for the PASS

simulation. The database will run Microsoft SQL Express 2008 R2, a freely available database

suite.


The DUI is a graphical user interface written in C#. Its only communication is with the

MCM, in which it is constantly listening for any alerts from the MCM. After the MCM receives

a location of an alert, the program passes the DUI a reference to an MCM object. The DUI will

create an Alert object, in turn doing two things. All active alerts passed to the DUI from the


MCM will be stored in a list. After being stored, the DUI will then draw the location on the map.

It will also print the active alert below the map and information such as the timestamp and

elapsed time to the right of the map. Once the simulation expires an alert, the DUI will remove

the alert from not only the visible interface, but also from the backhand list.


The Simulation Driver Interface will be written entirely in C#. It will inherit all of its

object from a base class called RadioDevice. The SDI communicates directly with the MCM

sending both alerts and a list of transceivers that received the alert. Upon the press of a button on

the SDI an object will be created and displayed on the map. It will provide the means to show

the transceivers on the current map and set the user for the simulated alert. Once a fob object has

been created with a unique ID and drawn on the map, the fob object will broadcast once and be

stored for later use. After a fob is created, any nearby transceivers will become lit up saying they

have received the signal. The Transceiver objects will be created and placed on the map by way

of the RadioDevice and will have a different color than the fob object.

2.3 External Interfaces

Each demonstration will have its own set of interfaces that will not be shared between

them. Hardware, Software, User, and Communication Protocols will be discussed. The separate

demonstrations will each have their own dedicated section to describe their components’

interfaces.

2.3.1 Hardware Interface

The hardware interface section defines the communication layers within and between the

various components of each section. Without these necessary translations, the hardware and


software would not be able to communicate to each other. Each system speaks its own language

and the interfaces translate the languages in use.

2.3.1.1 Hardware Demonstration (Dan Cox)

The Hardware Demonstration consists of four components: PC, Transceiver, Arduino and

Fob. Each component connects to another in a unique way. Collectively however they form a

bridge where a Fob signal can be passed, processed and displayed on the PC. The Hardware

Major Functional Component Diagram shows this flow of data.

Between the Transceiver and the Fob, there is a wireless connection and therefore there is

no physical component. The Transceiver listens for radio frequency signals from the Fob and

then acts upon them. The Fob’s only purpose is to send a two byte data structure and to

communicate this data wirelessly.

The Arduino is connected to the PC via a USB cable. This interface supplies the ability

to control the Arduino device. Sketches, compiled code for low-level hardware, can be uploaded

and messages can be received via this connection while said code is being run.

There is a wired connection between the Transceiver and the Arduino. This connection is a

physical interface between the two devices and is facilitated by directly soldering wires on each

component. Messages, series of high and low voltages, are sent as the means of communicating.

The Hardware Demonstration consists of four components: PC, Transceiver, Arduino and Fob.

Each component connects to another in a unique way. Collectively however they form a bridge

where a Fob signal can be passed, processed and displayed on the PC.

Between the Transceiver and the Fob, there is a wireless connection and therefore there is

no physical component. The Transceiver listens for radio frequency signals from the Fob and


then acts upon them. The Fob’s only purpose is to send a two byte data structure and to

communicate this data wirelessly.

The Arduino is connected to the PC via a USB cable. This interface supplies the ability

to control the Arduino device. Sketches, compiled code for low-level hardware, can be uploaded

and messages can be received via this connection while said code is being run.

There is a wired connection between the Transceiver and the Arduino. This connection is a

physical interface between the two devices and is facilitated by directly soldering wires on each

component. Messages, series of high and low voltages, are sent as the means of communicating.

2.3.1.2 Simulation Demonstration (Jon Szewczak)

There are no external interfaces required other than a mouse and a keyboard to input data

for the simulation as it runs and a screen to monitor the output. The simulation exists solely as a

virtual system. It is controlled and executed on personal computers.

2.3.2 Software Interface

This section describes the software interfaces that will be required for each

demonstration. A software interface can be any piece of software that is not written by the

project team, but is still considered an integral part of the demonstration. Vendor supplied

libraries are an example of a software interface.


The only interface with the code that runs on the Arduino is through the Arduino

Development Environment. This software is a combination code editor, compiler and sketch

uploader. It has several main features.

Derived from several open source Java projects, the Arduino Development Environment

provides the user with the ability to edit code directly. This, a standard among development


environments, does not represent anything major however. The ability to compile and see error

messages before uploading is more meaningful. The code generated this software will eventually

be sent to the Arduino. Any errors must be found and exercised before being programmed into

the hardware because if errors are seen then, it will crash the entire hardware system.

Once the code is visually checked by the programmer and confirmed to compile by the

development environment, it is packaged into sketches. Code written on the most basic level of

programming are called sketches and Arduino Development Environment provides functionality

to write to the Arduino board itself without leaving the program. Simply confirming which

models and any additional specifications and then clicking the necessary button will cause the

hardware to reset and then run the latest sketch. Once the code is running, it is sometimes hard to

see what is going with the hardware directly. The Arduino and development environment

provides an answer to that: a serial monitor.

The Arduino connects to a PC via a USB cable. The computer and the Arduino create a

physical connection upon which a virtual serial interface is built. From within the development

environment, a small window can be used as a way to view output sent from the Arduino and to

also send commands directly to the device while it is running.



Figure 10. Arduino User Interface

2.3.2.2 Simulation Demonstration (Jon Szewczak)

The PASS Simulation Demonstration will use the class structures and presentation

objects defined in the Microsoft .NET C# libraries for Windows application programming.

There are no other external interfaces being used by the Simulation Demonstration. Since the

software is being developed as a self-contained application, there is no need for anything other

than the libraries and software already available.

2.3.3 User Interface

This section describes the different user interfaces required by the PASS prototypes. A

user interface can be considered to be a software program that will display data to the observer.

In some circumstances it will allow the observer to take an active role and provide data input to

the running programs.


2.3.3.1 Hardware Demonstration (Marcus Henry)

The prototype user interface will display which fob button is pressed and how many

times that button is pressed. A picture of what the User will see is shown below. The Arduino

interface which will run on code supplied by the PASS development team.

Figure 11. User Interface of Arduino

2.3.3.2 Simulation Demonstration

The simulation consists of two separate user interfaces. The Simulation Driver Interface

handles the input and monitoring of the simulation. The Dispatch User Interface is used to verify

the accuracy of the simulation; it does not know the simulation is being run.

2.3.3.2.1 Simulation Driver Interface (Jon Szewczak, Dan Cox)

The Simulation Driver Interface is the main application window for the Simulation

Demonstration. From this window, the operator can initiate an alert, switch monitoring zones,

and choose which user to alert for. In essence the SDI is the driving force behind the Simulation

Demonstration.


Figure 12. Simulation Driving Interface Screenshot

Figure 12 shows a mock up of the SDI. The SDI will offer the operator a choice of 5

different maps to display on the form: one large overview and four zoomed in areas. The

operator would select one of the zoomed areas to initate an alert. Once the zoomed area has been

chosen, the operator selects which user to alert from the list at the bottom of the form. Finally, to

initiate an alert, the operator clicks their mouse on the map in the location that is desired. This

will trigger the alert process.

The alert process follows these simple steps. First a fob object is created using

information from the MCM and the selected user from the form. It is placed on the map and

shown in its Transmit mode. Next the SDI compares the fob to all of the transceivers within the

zoomed area. If a transceiver is within in range of the fob, then it is lit up as being in the receive

mode. Once that occurs, the operator can then force the alert call by clicking “Send Alert”

button. This will send all of the messages contained within the activated transceivers to the

MCM for further processing.


2.3.3.2.2 Dispatch User Interface (Brittany Dufort)

The DUI will contain three main areas: the area map, a table of active alerts, and an

extended data section. The map will not be interactive; however clicking on individual active

alerts will display the corresponding extended data. The extended data section will be live

updates of each alert.

Figure 13. Dispatch User Interface Screenshot

2.3.4 Communication Protocols

This section describes the different communication protocols used by each of the

demonstrations. Discussions of communication protocols will include any custom messages and

their delivery between digital and physical components. All other communication topics will be

effectively ignored for this discussion.


The Hardware Demonstration is a singular test. It must show that it can receive, process

and verify that a signal has been sent from a Fob device to a PC. The necessary communication


protocols can be broken down into those three categories: between Fob and Transceiver, between

Transceiver and Arduino, and between Arduino and PC.

A Fob has a simple purpose. It must broadcast some data wirelessly. The communication

between the Fob and Transceiver will be that of radio transmissions, albeit only one way. A Fob

only transmits and a Transceiver only receives. While it would be correct to name the

Transceiver as a Receiver, the functionality will be coded to only get messages, not send them.

Once a Transceiver has received this data from a Fob, it must do something with it. The

result of a successful transmission is the storing of that data in a byte array within the Arduino

memory. Because the Transceiver is wired directly into the Arduino, this writing is done at the

hardware level. The communication, in the strictest sense, is in fact commands sent from the

Arduino to the Transceiver as a series of pulses along the wires connecting them.

The final communication protocol is the retrieval of signals received and processed by

the Arduino. This is accomplished by the Arduino talking to the PC via a USB connection. Over

this connection, a virtual serial interface is created. On the PC, a Java program listens for

messages on this virtual serial interface. The Arduino, because of its programming, is told to

send a message to the PC every time it receives and processes a signal. Thus, a communication

pathway is created between a button being pressed on a Fob and the result of that press being

seen graphically at the PC end.

2.3.4.2 Simulation Demonstration (Dan Cox)

The Simulation Demonstration is mostly self-contained. It talks, via the Master Control

Module, with database software and, in turn, the Dispatch User Interface. The communication

protocols then are character strings that are part of the interface between the MCM and the


Database. The User Interfaces, which talk to the Master Control Module, do so at the application

layer.

3 Specific Requirements

The PASS Prototype Demonstrations are complex entities. In order to achieve maximum

success a set of requirements must be created to ensure that each component accomplishes what

it needs to. Requirements are broken into two categories: Functional and Performance. Each

component will list their specific requirements separately and in accordance with the appropriate

breakdown.

3.1 Functional Requirements

The following section details the functional requirements for the Hardware and

Simulation Demonstrations. Functional requirements are those that describe how each

component will interact with the demonstration as a whole. Each component will list its

responsibilities and needs as a requirement.

3.1.1 Hardware Demonstration (Marcus Henry)

In the PASS product development we will use thousands of these hardware devices to

cover an entire client’s area or grid; therefore it is necessary that we prove we can do it in a

feasible manner. Therefore, the hardware component of the PASS prototype will demonstrate the

team’s capabilities in using wireless technology in the form of a transmitter (fob), transceiver

and microcontroller. What follows are the specific requirements for the system:

1. Will receive a fob signal at a certain frequency.

2. Will relay a signal from the transceiver to a personal computer by use of a

microcontroller.


3. Will display relevant information for the User, such as which button was pressed

and how many times it occurred.


The following section will cover the functional requirements of the Simulation

Demonstration. For ease of discussion, the section is broken into subsections catering to each

component of the simulation. As such, each component will cover its own requirements.


The original PASS design saw the Transceiver as being one of the most important parts.

It handled, among other things, receiving and relaying the signals from the Fobs. In the scaling

down of the requirements in order that a prototype is created much of the functionality was

removed. A Transceiver, in its current form, does little more than hold position data, draw its

own colors to the screen, and maintain alert messages for later retrieval and processing.

The functionality then is a reduced set. It must be able to be queried for its position data,

used to calculate which ones 'heard' a Fob signal during the simulation, and carry out the drawing

functionality as inherited from its base class RadioDevice. When called, it shall “send” its

internal message to whatever calling program asks for it.


As the major element that controls communication between the two user interfaces, the

MCM has many specific requirements. The requirements are listed below in no particular order

of importance.

1. Will perform all communications with the database.

2. Will pass data on users, transceivers, and fobs to the SDI when requested.

3. Will receive signals from the SDI indicating there was an alert that needs to be processed.


4. Will pass data on alerts to the DUI.

a. When the signals are processed for user and location.

b. Will use an event model for notifications

c. Will analyze the alert signals being fed from the SDI.

5. Will log the incidents by storing the data in the database.

a. Will calculate the location of the incident based on alerting transceiver locations.

b. Will send the alert location and user information to the DUI.


The Fobs in the simulation have been stripped of much of its functionality that would

mirror its physical counterpart. For example, instead of repeating the broadcast, the simulated

Fob will only transmit once. Further differences between the two and the requirements can be

seen in the following table.

Input Description Output

User event of clicking on the map in the SDI

Instantiation of a new Fob object inheriting from the base class RadioDevice. Sets the mode to Transmit. Sends its location and a byte array to the MCM - emulation of transceiver relaying.

A new Fob object that is added to the FobInfoCollection within the MCM.

Request for position translation between x,y to Lat,Long

Preforms a translation of position on screen to corresponding approximate position of latitude and longitude.

Returns two floats containing the approximate latitude and longitude location.

User event of button press to switch modes

Switches Fob from Transmit to StandBy.

Fobs stop transmitting.

Table 8. Functional Requirements of Fobs



The database will be an integral module of the PASS system. It will store data required

for the system to run, simulated, or not. It must meet specific requirements as found in the

Database Simulation Specifications table.

Type Specification

Architectural The database will run Microsoft SQL Express 2008 R2.

Functional It will use stored procedures to allow the MCM to retrieve, add, update, or delete data from tables.

Schema The database schema will remain similar, but stripped of unnecessary sections. The same functionality will remain as in Lab 1.

Time SQL queries must execute in no more than 0.5 seconds.

Table 9. Database Simulation Specifications


The prototype DUI will be very similar, if not identical to the real world product DUI. All

of the functional requirements are requirements that need to be fulfilled in the prototype

simulation. The actual map will differ between networks. For example, XYZ Corporation will

have a map of the area containing their transceivers, not a map of ODU. The same information

and data of each alert will be displayed. Testing of the DUI will be a very good representation of

how the real world DUI works.


These functions will provide a GUI for the simulation of the PASS Prototype. Its

functionality is summarized below. The following functions will be provided as part of a

Windows form.

1. Allow a user to identify the location of an alert signal anywhere on the map


2. Allow a user to select a portion of the map or display the entire map on the screen

3. Show the transceivers that are located on the current map display

4. Display and store past history of alerts

5. Allow a user to choose a person from a preset user database for the simulated alert signal

3.2 Performance Requirements

The following section details the performance requirements for the Hardware and

Simulation Demonstrations. Performance requirements are those that describe how each

component must complete its work in order to serve the rest of the demonstration. To simplify

much of the complexity, each component will list its own requirements.

3.2.1 Hardware Demonstration(Marcus Henry)

The prototype hardware will meet these requirements for the purposes of demonstration.

1. Every press of the PASS fob should be picked up by the transceiver/arduino prototype

architecture.

2. The information is directly transferred between electronic devices by a serial usb port and

microcontroller software interface.

3. As soon as a signal is picked up by the transceiver/arduino unit it is displayed to the user

within a 1 cycle period.


The following section will cover the performance requirements of the Simulation

Demonstration. For ease of discussion, the section is broken into subsections catering to each

component of the simulation. As such, each component will cover its own requirements.



As spelled out in the Constraint Section, most of the functionality of Transceivers has

been removed. The ability of it to relay information, transmitting and receiving data over and

over, was removed. Transceivers retain only two functions, holding position data and drawing its

position within the user interface.

Each Transceiver still retains its position because of its necessity in the computation of

which of the Transceivers would have ‘heard’ a signal. Despite the Transceiver no longer

playing a large role in the simulation, the positions of each device is still needed. The Dispatch

User Interface must display where a Fob signal was heard and this is computed using the

positions held within the Transceivers objects.

Each instantiated object of the type Transceiver has a color and a position. The color

serves to be a visually distinctive area telling the user, at a glance, if the device is transmitting, in

standby or receiving. However, as stated in the introduction to this section, the Transceiver no

longer handles relaying and thus is always in standby mode. This drawing of the standby color,

functionality from the inheritance of class properties and methods from RadioDevice, must take

place in as little time as possible in order that the entirety of the Simulation Driver Interface be

responsive in an expected manner.


The MCM must be a high performing module in order to supply both user interfaces with

data. As such, multithreading will likely be used to a great extent. A detailed list of

performance requirements are listed below in no order of importance.

1. Upon request, the MCM must be able to return a collection of UserInfo objects that

reflect the state of stored information in the database.


2. Upon request, the MCM must be able to return a collection of FobInfo objects that reflect

the state of stored information in the database.

3. Upon request, the MCM must be able to return a collection of TransceiverInfo objects

that reflect the state of stored information in the database.

4. Upon request, the MCM must be able to return a collection of IncidentInfo objects that

reflect the state of stored information in the database.

5. Upon receiving a list of alerting transceiver byte array signals, the MCM must be able to

process and serve the information to the DUI in less than 1.5 seconds.

6. The alert location calculation must be accurate to:

a. Within 50 feet for three (3) or more alert signals received.

b. Within 75 feet for two (2) alert signals received.

c. Within 100 feet for one (1) alert signal received.


Fobs, as originally designed, would serve as a compliment to the Master Receiver. While

a Fob would only transmit, the Master Receiver would be in listening mode. However, because

of constraints outlined in Constraint Table, Transceivers have been stripped of their relaying and

the Master Receiver is no longer in the simulation. The result of those changes is that any

performance time that was a consideration when the Fob signal was passed from Transceiver is

eliminated. The processing requirement of the Master Receiver too, gone since it is no longer

part of the simulation, means that the Fob signal can be acted upon faster. The Fob now directly

talks to the Master Control Module and so communication lag has been dramatically reduced.

Similar to Transceivers, Fobs also inherit from the RadioDevice base class and must also

call the necessary drawing functions in order that its status be shown. Again, because of


constraint of time, the Fob need only show two modes. The first, transmit, it shows upon the

initial mouse click when this event fires. The second, standby, is the mode and display color that

be dominant throughout the simulation. Once a Fob has broadcast, it remains in standby in the

simulation until cleared or the simulation closed.


The database must meet various performance expectations. These requirements will cover both issues of time, hardware, and design. The requirements may be found in the Database Performance Specifications table.

Type Specification

Time Database procedures and functions must execute and successfully terminate within 0.5 seconds.

Hardware Hardware will meet or exceed the minimum requirements for Microsoft SQL Express 2008 R2

Design Procedures and functions shall provide all data as requested by the MCM.

Table 10. Database Performance Specifications


The DUI has no performance requirements. It must operate according to the dictation of

the user at the Simulation Driver Interface. The Dispatch User Interface only reacts within the

Simulation.


The Simulation Driver Interface shall meet the following performance requirements:

1. Respond to any action request received from the user after the click of a button

2. Send information to the MCM with no loss of data

3. Update the display after an object or transceiver has been updated


3.3 Assumptions and Constraints

As with any project as large as PASS, there is a certain amount of scope reduction that

must take place. This reduction is often the result of simplification of operating conditions to

suit the available tests. The following sections will cover the conditions under which the

prototype demonstrations will operate.

3.3.1 Assumptions (Brittany Dufort)

Since PASS is a complex product, the prototype is mainly a simulation. This requires a

list of assumptions that help minimize the scope of the project. Most assumptions are for the

simulation; however there are a few needed for hardware as well.

Prototype Condition Assumptions Hardware or SimulationThere will be no signal interference from non PASS 2.4 GHz transmissions. Simulation

There will be no signal interference from existing structures. SimulationThe selected areas for simulation represent realistic expectations of campuses. Simulation

Weather will have no effect on signal strength or direction. Simulation

When the alert is turned off via the SDI, it is assumed it is turned off via the dispatch personnel. Simulation

All 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

Testing of one fob will represent multiple fobs Hardware

Table 11. Prototype Assumptions

3.3.2 Constraints (Dan Cox)

The PASS system, being unique in its duality of existence across two different

demonstrations, has two primary constraints as well a number of manageable secondary

constraints. Because the development environment of this project is the confines of a classroom,


a number of decisions have been made that dictate the design and development. These design

decisions have been listed in a table, but draw from the two primary constraints: time and money.

A single semester is a reduced time frame and thus, in order that the project be presented

and graded within the given time, this constraint must be accounted for and be in the forefront of

all major decision making processes. Its influence can be seen most profoundly in the paring

down of much of the original functionality of the PASS system simulation into just the

functionality needed for the demonstration. This constraint, time, has and will continue to have

profound effects on the functionality that is released or even worked on within the development

of this system.

The other dominant constraint is that of money. Each team is given a small stipend to

cover the material requirements that they might need for their development. The PASS team,

because of the large size of the original project, experienced frequently discussions in the process

of reducing the cost of prototype construction. These conversations were driven by the need to

meet the cost requirement. Thus, just as time has influenced design, so has money. The ultimate

response to this constraint can be observed in the following table.



Condition Effect on Requirements Reason DemonstrationIncident reports not part of simulation.

Removal of functionality from Dispatch User Interface and Master Control Module.

Time Simulation

Transceiver health not part of simulation.

Removal of functionality from Master Control Module and Transceivers. Time Simulation

Programming language ASP no longer being used.

Removal of all web and network-based requirements. Time Simulation

No signal relaying will be done in simulation.

Removal of signal relaying between transceivers and to Master Receiver. Money Hardware

No recording of history statistics will be done.

Removal of functionality whose purpose was to collate data from incidents reports.

Time Simulation

Emulation of Master Receiver will not be done.

Removal of Master Receiver functionality from simulation, including all functionality from Master Control Module which was used to communicate with Master Receiver.

Time Simulation

Fobs can no longer move.

Although Fobs will continue to exist from a position, they will not be able to move within the simulation.

Time Simulation

Fob objects only broadcast once.

Although a primary aspect of the original design, Fob objects will not continue to broadcast in the simulation.

Time Simulation

Table 12. Constraints

3.3.3 Dependencies (Jon Szewczak)

The PASS prototype demonstrations have several dependencies. The first is the

availability of computer hardware that will have enough computational power to run the

Simulation Demonstration software effectively. Additional dependencies are those of the correct

software execution environment and displaying of results.


The computer hardware dependency will be alleviated with the use of a high-end laptop.

If a laptop is not available, then University equipment will have to be substituted. This is not an

ideal solution since it is unknown if that hardware would be sufficient for the task. However, the

unavailability of the laptop is not deemed to be a serious risk and therefore it is a low priority

dependency.

The second dependency, that of the correct software execution environment, is met in the

installation of the Microsoft .NET Framework 3.5 or higher on the demonstration laptop. The

Simulation Demonstration software will be developed using the Microsoft C# programming

language which takes full advantage of the .NET Framework. If the .NET Framework is not

installed, the simulation program will not run - therefore the Framework installation is deemed to

be a high-priority requirement.

Finally, for the Hardware Demonstration, the prototype will connect to a computer for

data display. Again, a laptop computer will be utilized for this purpose. The laptop must have

the proper libraries, drivers and software installed to allow control of the Arduino prototyping

board. Without this software, the test will largely be a failure, because the results of the received

fob signals will not be displayed and therefore cannot be verified for success.

It is worth mentioning that the Hardware Demonstration will not be possible if the

necessary components are not available. Likewise, if the simulation software is not complete, or

has many bugs in it, then the demonstration cannot be qualified as a success. These are critical

and intrinsic pieces of each demonstration, so it should be fairly evident that they can also be

counted as dependencies.


3.4 Non-Functional Requirements

Most of this document has been concerned with technical implementations, methods, and

challenges. However, there is a component of non-functional behavior that deserves attention.

This section covers those components in a general case.

3.4.1 Security (Gordon Bland)

Due to the nature of the PASS system, data for the system must be secured. There will be

measures taken to ensure the system is secured within reason. An example of this is that the

operators of the system are not going to leak information.

Type Specification

Data Information on the database will not be retrievable by only the DBA and the MCM operator.

Fob Owner information is accessible from the MCM or directly through the database; however, the fob ID will cannot be linked to the owner without proper authority.

Location Data

The location of a fob can only be retrieved on the PASS grid and if the button is pressed to send a distress beacon.

Transceiver Transceivers of the PASS system will only receive signals given PASS fobs.

Table 13. Security Specifications

3.4.2 Maintainability (Marcus Henry)

The PASS prototype product contains two different technological components, hardware

and software. The hardware side of the prototype is made up of a fob, a transceiver, and a

microcontroller. Looking at the maintenance associated with this aspect of the prototype, it is

clear that the fob will need no upkeep as it is a commercial off the shelf product. However, the

transceiver in conjunction with the arduino microcontroller is of greatest concern, due in large

part to the prototype using wires that lead from the microcontroller to the proto board, and then

from the to the transceiver. It is important that these wires are kept in useable condition and


replaced if they begin to fray or burn over use. Another concern is that these components are not

touched at all, unless there are anti-static materials present.

On the software side of the Pass prototype, the code used for the PASS Simulation

itself will be thoroughly tested and debugged by the Pass Research and Development team. It is

important to note that there may be changes in the simulation. For instance, if the location of the

transceivers change, or if the client wishes to see more fobs used in a trial run. These actions

could result in unforeseen errors in the source code. Therefore, the debugging and testing of the

software will continue as long as the prototype is active and being put through tests by the client.

It is possible for the PASS team to send a software engineer to a client as is necessary.

3.4.3 Reliability (Braden Gibson)

The PASS prototype must be able to receive 100% of the signals sent from the key fob

and able to correctly translate the data received. Both the key Fob and transceivers must be able

to function 24/7 for the prototype to work consistently. All unwanted signals must be blocked in

order for the transceivers to receive only valid signals and maintain constant protection for the

user. The server will need to be on 24/7 so that the MCM can relay the user information to both

the Dispatch User Interface and Simulation Driver Interface. The Dispatch User Interface and

the Simulation Driver Interface both need to be able to communicate with each other and the

MCM for the simulation to work correctly.


ODUcpi/old/411/blues11/documents/… · Web viewThe PASS Prototype will be broken in to two...

Documents

Transcript of ODUcpi/old/411/blues11/documents/… · Web viewThe PASS Prototype will be broken in to two...