Lab 2 – PASS Product Specification
1
RUNNING HEAD: LAB 2 – PASS PRODUCT SPECIFICATION
Personal Alert and Safety System
Lab 2 – Product Specification (Sections 2 & 3)
CS 411 Blue Team:
Dan Cox
Jon Szewczak
Brittany Dufort
Marcus Henry
Gordon Bland
Braden Gibson
Gene H. Price
March 20, 2011
Lab 2 – PASS Product Specification
2
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.3 Master Control Module (Jon Szewczak) ................................................. 23
2.2.2.4 Fobs (Dan Cox) ....................................................................................... 26
2.2.2.5 Database (Gordon Bland) ........................................................................ 27
Lab 2 – PASS Product Specification
3
2.2.2.6 Dispatch User Interface (Brittany Dufort) .............................................. 27
2.2.2.7 Simulation Driver Interface (Braden Gibson) ......................................... 28
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.1 Hardware Demonstration (Dan Cox) ...................................................... 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.1 Hardware Demonstration (Dan Cox) ...................................................... 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 Simulation Demonstration ............................................................................. 38
Lab 2 – PASS Product Specification
4
3.1.2.1 Transceivers (Dan Cox) .......................................................................... 38
3.1.2.2 Master Control Module (Jon Szewczak) ................................................. 38
3.1.2.3 Fobs (Dan Cox) ....................................................................................... 39
3.1.2.4 Database (Gordon Bland) ........................................................................ 40
3.1.2.5 Dispatch User Interface (Brittany Dufort) .............................................. 40
3.1.2.6 Simulation Driver Interface (Braden Gibson) ......................................... 40
3.2
Performance Requirements ................................................................................. 41
3.2.1 Hardware Demonstration(Marcus Henry) ..................................................... 41
3.2.2 Simulation Demonstration ............................................................................. 41
3.2.2.1 Transceivers (Dan Cox) .......................................................................... 42
3.2.2.2 Master Control Module (Jon Szewczak) ................................................. 42
3.2.2.3 Fobs (Dan Cox) ....................................................................................... 43
3.2.2.4 Database (Gordon Bland) ........................................................................ 44
3.2.2.5 Dispatch User Interface (Brittany Dufort) .............................................. 44
3.2.2.6 Simulation Driver Interface (Braden Gibson) ......................................... 44
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
Lab 2 – PASS Product Specification
5
3.4.3 Reliability (Braden Gibson) ........................................................................... 50
Lab 2 – PASS Product Specification
6
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
Lab 2 – PASS Product Specification
7
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
Lab 2 – PASS Product Specification
8
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.
Lab 2 – PASS Product Specification
9
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 opensource 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
Lab 2 – PASS Product Specification
10
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 highperformance 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.
Lab 2 – PASS Product Specification
11
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.
Lab 2 – PASS Product Specification
Figure 2. RadioDevice Class Diagram
(This Space Left Intentionally Blank)
12
Lab 2 – PASS Product Specification
Property Name
ID (byte)
Location
(Drawing.PointF)
Mode
(RadioDeviceMode)
Range (float)
RealWorldPosition
(Position)
ReceiveColor
(Drawing.Color)
ReceiveSize
(Drawing.Size)
StandbyColor
(Drawing.Color)
StandbySize
(Drawing.Size)
TransmitColor
(Drawing.Color)
TransmitSize
(Drawing.Size)
Method Name
void Receive (byte[])
byte[] Transmit()
void OnPaint(object,
PaintEventArgs)
13
Description
The 16-bit integer value that identifies the RadioDevice
The location of the object when it’s placed on a Windows Form. The
data type is a Microsoft native drawing type.
Determines the display and signal mode of the RadioDevice. Possible
values are StandBy, Transmit, and Receive. The default is StandBy.
The real world radio frequence transmission range for the object the
RadioDevice is representing.
This is the Latitude and Longitude of the device in simulation space.
The color of the object when the Mode property is set to
Receive. The data type is a Microsoft native drawing type.
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.
The color of the object when the Mode property is set to
StandBy. The data type is a Microsoft native drawing type.
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.
The color of the object when the Mode property is set to
Transmit. The data type is a Microsoft native drawing type.
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.
Description
Takes a 2-byte array as a parameter and stores the array as part of its
internal message for transmitting or processing.
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.
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.
Lab 2 – PASS Product Specification
14
Property Name
Latitude (float)
Description
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
Description
Drawing.PointF ConvertToXY(
Converts the embedded Latitude and Longitude values
Position, Drawing.PointF, Position,
to a Drawing.PointF value that can then be used to map
Drawing.PointF)
the RadioDevice onto a form control.
void ConvertFromXY( Drawing.PointF, Converts the first supplied PointF parameter into
Position, Drawing.PointF, Position,
Latitude and Longitude values that are then stored in
Drawing.PointF)
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.
(This Space Left Intentionally Blank)
Lab 2 – PASS Product Specification
15
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.
(This Space Left Intentionally Blank)
Lab 2 – PASS Product Specification
16
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
(This Space Left Intentionally Blank)
Lab 2 – PASS Product Specification
17
.
Property Name
Count
Method Name
Add(object) – [FobInfo,
TransceiverInfo, IncidentInfo, or
UserInfo object]
Remove(object) – [FobInfo,
TransceiverInfo, IncidentInfo, or
UserInfo object]
Get(integer)
GetAll()
Description
The number of records that are managed by the collection.
Description
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.
Removes an object from the collection. This will trigger
the database interactions to delete the records referenced
by the parameter object.
Returns a single object (FobInfo, TransceiverInfo,
UserInfo or IncidentInfo) from the database based on the
integer ID parameter.
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
ID
UserID
Description
This is an 8 bit integer (byte) value that uniquely identifies
a fob.
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
Lab 2 – PASS Product Specification
Property Name
ID
18
Description
This is an 8 bit integer (byte) value that uniquely identifies
a transceiver.
A float value representing the latitude coordinates of the
position that the transceiver has been installed at.
A float value representing the longitude coordinates of the
position that the transceiver has been installed at.
Lat
Long
Table 5. TransceiverInfo Object Properties and Methods
Property Name
ID
Name
Age
Sex
Description
An integer value that uniquely identifies a user.
A string value that holds the user’s name.
An integer value that holds the user’s age.
A character value that holds the gender of the user (‘M’ or
‘F’).
Table 6. UserInfo Object Properties and Methods
Property Name
ID
Time
TransceiverCount
TransceiverList
Method Name
AddTransceiver(byte)
RemoveTransceiver(byte)
Description
An integer value that uniquely identifies the incident.
Returns the time the incident was first logged.
Returns the number of transceivers that heard the signal
that this incident is tracking.
Returns a List<byte> that corresponds to the transceivers
that have been marked as having heard the signal this alert
is tracking.
Description
Adds an indication in the database that a particular
transceiver heard the signal that is being tracked by the
incident.
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.
Lab 2 – PASS Product Specification
19
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.
Lab 2 – PASS Product Specification
2.1.2.6
20
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.
Lab 2 – PASS Product Specification
21
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
Lab 2 – PASS Product Specification
22
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
Lab 2 – PASS Product Specification
23
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.
2.2.2.3 Master Control Module (Jon Szewczak)
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
Lab 2 – PASS Product Specification
24
parameter. Figure 7 describes the ProcessAlerts flow.
* NOTE: Refer
to Figure 9 for a
detailed look at
the alert location
calculation
process.
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
Lab 2 – PASS Product Specification
25
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
Lab 2 – PASS Product Specification
26
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.
2.2.2.4
Fobs (Dan Cox)
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.
Lab 2 – PASS Product Specification
27
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.
2.2.2.5 Database (Gordon Bland)
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.
2.2.2.6 Dispatch User Interface (Brittany Dufort)
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
Lab 2 – PASS Product Specification
28
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.
2.2.2.7
Simulation Driver Interface (Braden Gibson)
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
Lab 2 – PASS Product Specification
29
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
Lab 2 – PASS Product Specification
30
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.
2.3.2.1
Hardware Demonstration (Dan Cox)
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
Lab 2 – PASS Product Specification
31
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.
(This Space Left Intentionally Blank)
Lab 2 – PASS Product Specification
32
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.
Lab 2 – PASS Product Specification
33
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.
Lab 2 – PASS Product Specification
34
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.
Lab 2 – PASS Product Specification
35
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.
2.3.4.1
Hardware Demonstration (Dan Cox)
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
Lab 2 – PASS Product Specification
36
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
Lab 2 – PASS Product Specification
37
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.
Lab 2 – PASS Product Specification
38
3. Will display relevant information for the User, such as which button was pressed
and how many times it occurred.
3.1.2 Simulation Demonstration
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.
3.1.2.1 Transceivers (Dan Cox)
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.
3.1.2.2
Master Control Module (Jon Szewczak)
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.
Lab 2 – PASS Product Specification
39
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.
3.1.2.3 Fobs (Dan Cox)
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
User event of
clicking on the
map in the SDI
Request for
position translation
between x,y to
Lat,Long
User event of
button press to
switch modes
Description
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.
Output
Preforms a translation of position on
screen to corresponding approximate
position of latitude and longitude.
A new Fob object
that is added to
the
FobInfoCollection
within the MCM.
Returns two floats
containing the
approximate
latitude and
longitude
location.
Switches Fob from Transmit to
StandBy.
Fobs stop
transmitting.
Table 8. Functional Requirements of Fobs
Lab 2 – PASS Product Specification
40
3.1.2.4 Database (Gordon Bland)
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
3.1.2.5 Dispatch User Interface (Brittany Dufort)
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.
3.1.2.6
Simulation Driver Interface (Braden Gibson)
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
Lab 2 – PASS Product Specification
41
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.
3.2.2 Simulation Demonstration
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.
Lab 2 – PASS Product Specification
3.2.2.1
42
Transceivers (Dan Cox)
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.
3.2.2.2
Master Control Module (Jon Szewczak)
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.
Lab 2 – PASS Product Specification
43
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.
3.2.2.3 Fobs (Dan Cox)
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
Lab 2 – PASS Product Specification
44
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.
3.2.2.4
Database (Gordon Bland)
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
3.2.2.5 Dispatch User Interface (Brittany Dufort)
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.
3.2.2.6
Simulation Driver Interface (Braden Gibson)
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
Lab 2 – PASS Product Specification
45
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
There will be no signal interference from non PASS 2.4 GHz
transmissions.
Hardware or Simulation
There will be no signal interference from existing structures.
Simulation
The 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
Simulation
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
Lab 2 – PASS Product Specification
46
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.
(This Space Left Intentionally Blank)
Lab 2 – PASS Product Specification
Condition
Incident reports
not part of
simulation.
Transceiver
health not part
of simulation.
Programming
language ASP
no longer being
used.
No signal
relaying will be
done in
simulation.
No recording of
history statistics
will be done.
47
Effect on Requirements
Removal of functionality from
Dispatch User Interface and Master
Control Module.
Reason
Demonstration
Time
Simulation
Removal of functionality from Master
Control Module and Transceivers.
Time
Simulation
Removal of all web and networkbased requirements.
Time
Simulation
Money
Hardware
Time
Simulation
Time
Simulation
Time
Simulation
Time
Simulation
Removal of signal relaying between
transceivers and to Master Receiver.
Removal of functionality whose
purpose was to collate data from
incidents reports.
Removal of Master Receiver
Emulation of
functionality from simulation,
Master Receiver including all functionality from
will not be
Master Control Module which was
done.
used to communicate with Master
Receiver.
Although Fobs will continue to exist
Fobs can no
from a position, they will not be able
longer move.
to move within the simulation.
Although a primary aspect of the
Fob objects
original design, Fob objects will not
only broadcast
continue to broadcast in the
once.
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.
Lab 2 – PASS Product Specification
48
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.
Lab 2 – PASS Product Specification
49
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
Lab 2 – PASS Product Specification
50
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.
(This Space Left Intentionally Blank)