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)