Triton_Lab2.doc

794 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
794
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Triton_Lab2.doc

  1. 1. Triton Team Lab II Prototype Product Specification April 4, 2008
  2. 2. Triton Lab II – Prototype Product Specification Table of Contents 1 INTRODUCTION........................................................................................................................4 1.1 Purpose..............................................................................................................................5 1.2 Scope...............................................................................................................................11 1.3 Definitions, Acronyms, and Abbreviations........................................................................12 1.4 References.......................................................................................................................14 1.5 Overview.........................................................................................................................15 2 GENERAL DESCRIPTION.......................................................................................................15 2.1 Prototype Architecture Description..................................................................................16 2.2 Prototype Functional Description....................................................................................19 2.3 External Interfaces...........................................................................................................24 2.3.1 Hardware Interfaces......................................................................................................25 2.3.2 Software Interfaces......................................................................................................25 2.3.3 User Interfaces.............................................................................................................26 2.3.4 Communication Protocols and Interfaces....................................................................27 3 SPECIFIC REQUIREMENTS..................................................................................................27 3.1 Functional Requirements................................................................................................28 3.1.1 RuBeeTM Setup...........................................................................................................28 3.1.2 Underwater Communication Demonstration...............................................................29 3.1.3 User Login Interface....................................................................................................30 3.1.4 Swimmer Registration and Administration Interfaces.................................................31 3.1.5 Pool Alert View Interface ...........................................................................................33 3.1.6 Prototype Detection Algorithm Interface .....................................................................33 3.1.7 Prototype Settings Interface..........................................................................................35 3.1.8 User Administration Interface.......................................................................................35 3.1.9 Access Database............................................................................................................36 3.1.10 Simulated Data............................................................................................................36 3.1.11 Swimmer Simulation..................................................................................................37 3.2 Performance Requirements ............................................................................................38 3.2.1 Underwater Communication ........................................................................................38 3.2.2 Detection Algorithm.....................................................................................................39 3.3 Assumptions and Constraints ..........................................................................................39 3.4 Non-Functional Requirements .........................................................................................41 3.4.1 Security ........................................................................................................................42 3.4.2 Maintainability .............................................................................................................42 3.4.3 Reliability .....................................................................................................................42 4 APPENDIX................................................................................................................................43 2
  3. 3. Triton Lab II – Prototype Product Specification 4.1 Formal Resource Request Document.............................................................................43 List of Figures Figure 1. Triton Major Functional Components Diagram...............................................................8 Figure 2. Triton Location Algorithm.............................................................................................10 Figure 3. Triton Prototype Architecture.........................................................................................17 Figure 4. RuBeeTM Tag Demonstration Process Flow.................................................................20 Figure 5. Login Table....................................................................................................................21 Figure 6. Registration Process Flow..............................................................................................22 Figure 7. Drowning Detection Algorithm Process Flow...............................................................23 Figure 8. Disabling an Alarm Process Flow..................................................................................24 Figure 9. User Interface Map.........................................................................................................27 Figure 10. Hardware Connection Set Up.......................................................................................29 Figure 11. RuBeeTM Finder Software Screen Shot......................................................................30 List of Tables Table 1. RuBeeTM Characteristics.................................................................................................7 Table 2. Triton Feature Comparison between Full Product and Prototype...................................19 Table 3. Assumptions, Dependencies, and Constraints on Prototype Requirements....................41 3
  4. 4. Triton Lab II – Prototype Product Specification 1 INTRODUCTION Over 2,000 children and teenagers silently drown every year in pools staffed with certified lifeguards. The victims of silent drowning do not display any warning signs, and since it occurs so quickly, lifeguards cannot recognize the situation in time. Considering it takes less than a minute for a child to drown, the time it takes lifeguards to react is very important to prevent unintentional drownings and near-drowning injuries. In 2005, according to the U.S. Centers for Disease Control and Prevention, there were 3,582 unintentional drownings in the United States in which 30% of the victims were children and teenagers (CDCP, 2008). In addition, drowning is considered the number one leading cause of death for children under the age of five and the second leading cause of unintentional injury-related death for children under the age of fifteen (CDCP, 2007). Different studies have been developed to find solutions and reduce the number of victims. Jeff Ellis & Associates performed a study in more than 90 U.S. pools that measured the time it took lifeguards to detect a manikin laying at the bottom of the pool. The study proved that lifeguards took an average of one minute and fourteen seconds to recognize and get the manikin out of the water. In a different study designed to measure lifeguards’ vigilance capacity, Jeff Ellis & Associates proved that lifeguards’ vigilance capacity is only 30 minutes; factors such as heat, noise, distraction, monotony, stress, fatigue, poor diet, and dehydration affected the lifeguards’ performance (Brener & Oostman, 2002). Every second counts in a drowning incident. Considering the studies’ results and in response to silent drowning, some swimming pool facilities and waterparks have installed drowning detection systems to assist lifeguards in detecting hazardous 4
  5. 5. Triton Lab II – Prototype Product Specification situations. Currently, there are three very expensive camera based systems available in the market, Poseidon System, Swimguard Safety System, and Drowning Early Warning System (DEWS). The Swimguard Safety System operates similar to a security surveillance system. On the other hand, the Poseidon System and DEWS utilize a series of algorithms to recognize the swimmers behavior and trajectories. The three main disadvantages that the Poseidon System, Swimguard Safety System, and DEWS share are price, visibility, and environment adaptability. The cost of a camera based system ranges from $60,000 to $150,000. Because the systems are camera based, visibility becomes a real issue if the pool’s water is not in optimum conditions. Also, the systems fail to work in different environments such as lakes and beaches (Orange Team, 2007). As a solution to the previous disadvantages, the Triton System was conceived. The Triton System is a low cost automated sensor based surveillance system that uses RuBeeTM technology to communicate underwater and alert lifeguards of the victim’s position, in real time, when a drowning situation is detected. 1.1 Purpose The Triton System was designed with the solid purpose to help lifeguards detect possible silent drowning victims. It employs new technology capable of underwater signal transmission. Triton uses customized wristbands, worn by swimmers, with pressure and wet/dry sensors to send wireless signals to antennas installed in a pool. The antennas transfer the signals through wires to their pre-established receiver, which converts the signals into data and transfers it to the base station. Once the data has been transferred to the base station, a drowning detection algorithm analyzes the data and determines if a swimmer is potentially drowning or not. If the calculated data is 5
  6. 6. Triton Lab II – Prototype Product Specification greater than the established threshold, an alert displaying the swimmer’s information and location is sent to the lifeguard monitor’s station for the proper action. The innovative sensor technology employed by Triton makes the Triton System adaptable to work in different environments such as wave pools, lakes, and beaches. It makes the system an inexpensive alternative for small waterparks and swimming pool facilities, and it does not violate swimmers privacy. Since radio frequency identification (RFID) tags cannot transmit signals underwater very well and their signals cannot pass through concrete or steel, Triton will use a new technology called RuBeeTM. RuBeeTM will enable Triton to develop a system that works in difficult concrete-underwater environments. Also, since the Triton System needs to use pressure and wet/dry sensors, RuBeeTM tags facilitate sensor attachment due to their central processing unit (CPU) that they have built in. In addition to the technological advantages over RFID tags, RuBeeTM is not expensive. For example, while a RFID base price ranges from $500 to $1,500, a RuBeeTM base price ranges from $1 to $200 (Stevens, 2006). Table 1 summarizes the different characteristics between RFID and RuBeeTM. [This space is intentionally left blank] 6
  7. 7. Triton Lab II – Prototype Product Specification Table 1. RuBeeTM Characteristics The Triton System has five major functional pieces that are illustrated by Figure 1. The first functional piece is a waterproof wristband that contains a RuBee TM tag and sensors. The RuBeeTM tag has a unique ID, which is assigned to each swimmer for later identification. A pressure and wet/dry sensors are attached to the RuBeeTM tag to get data that will be used later in the process of identifying potential drowning victims. [This space is intentionally left blank] 7
  8. 8. Triton Lab II – Prototype Product Specification Figure 1. Triton Major Functional Components Diagram The second functional piece consists of antennas and RuBeeTM receivers. The antennas are located at the bottom of the pool, and they are used to capture wireless signals from RuBeeTM tags. The antennas are connected to RuBeeTM receivers, which receive the signals that the antennas sent through wires. Then, the RuBeeTM receivers convert the signals into data and send the data to the base station. The third functional piece is the base station. The base station stores the Triton System’s main program application. Based on the data that the pressure and wet/dry sensors transmitted, the application uses the pre-established parameters, water density, gravity, atmosphere pressure, and the swimmers’ arm length to calculate depth. If, after repeating the calculation process, depth remains the same for more than fifteen seconds, the application determines that there is a potential drowning case. After the calculation process, the major function of the base station is to transmit the information 8
  9. 9. Triton Lab II – Prototype Product Specification to the Lifeguard Station. The Triton System’s main program application will be developed using C# (C-sharp). The fourth functional piece is the Triton Software, which is an application that will be developed in C#. The Triton Software is based on three main interfaces, Registration and Administration, Drowning Detection, and Alert and Display. The Registration and Administration interface will allow inputting the information of a swimmer, such as name, age, sex, medical information, et cetera, as well as the information for the users of the system. All the previous information will be stored in a database developed in MySQL. The database and the Triton Software must be installed in the base station. The Drowning Detection interface will allow waterparks to define the parameters to calculate the depth of a swimmer and determine when a drowning scenario occurs. The fifth functional piece is the Lifeguard Station. The Lifeguard Station is a touch screen monitor that lifeguards will use to acknowledge a hazardous situation. The purpose of the touch screen is to make lifeguards’ interaction with the Alert and Display interface easy. The Alert and Display interface is a real time simulation of the swimming pool or area under surveillance. When a potential drowning victim is detected, an alert is sent to the Alert and Display interface; the alert will display the swimmer’s information and location. The location of the victim is based on the intersection of the range covered by the antennas that transferred the signals. Figure 2 illustrates the location algorithm process. [This space is intentionally left blank] 9
  10. 10. Triton Lab II – Prototype Product Specification Figure 2. Triton Location Algorithm Triton’s market is divided into two categories: artificial and natural, artificial being Triton’s primary market. The artificial category consists of outdoor and indoor waterparks and swimming pool facilities. Currently, there are more than one thousand waterparks in the United States and over six hundred in other countries; these numbers keep increasing every year. According to the World Waterparks Association (n.d.), the average attendance growth per year is three to five percent, and the estimated attendance at water parks in the United States was about 73 million during the summer of 2004. Assuming that the entry to a waterpark costs $30 per person, during the summer of 2004, approximately $2,190 million was generated. In the artificial category, Triton only has three main competitors, the Poseidon System, Swimguard Safety System, and DEWS. On the other hand, the natural category consists of private beaches and lakes, mainly owned by hotels, clubs, and resorts. This category has not been explored by Triton’s competitors because they fail to work in natural environments 10
  11. 11. Triton Lab II – Prototype Product Specification due to water movement and clarity. Once the Triton System has been successfully proven to work on the first category, Triton will immediately pursue the second category. 1.2 Scope The Triton prototype will demonstrate that its sensor based surveillance system is feasible. Triton will prove two main things: communication underwater between RuBeeTM tags and an antenna connected to a RuBeeTM receiver and detection of a possible drowning scenario. The first functional objective deals with underwater communication. It is very important to successfully demonstrate that RuBeeTM tags can send signals to a RuBeeTM receiver. The RuBeeTM receiver will use an antenna to capture signals from RuBeeTM tags; furthermore, Triton will use the RuBeeTM Finder Software, provided by Visible Assets Inc., to show the unique ID of each RuBee TM tag that is read by the antenna. The RuBeeTM receiver will transfer the data to a laptop, provided by the ODU Computer Science department, used to simulate the base station where the RuBeeTM Finder Software will be installed. The second functional objective deals with the detection of a possible drowning scenario. Based on a formula and pre-established parameters such as water density, gravity, atmospheric pressure, and the swimmer’s arm length, the formula returns the depth of the swimmer. In addition, the Triton System Prototype needs data from a wet/dry and pressure sensor, which will be simulated, to determine when a swimmer is in the pool and underwater. The formula is applied every second. If the swimmer is in the pool, underwater, and the depth does not change after 15 seconds, an alarm with the swimmer’s information and location is displayed on the Pool Alert View Interface. Only authorized users such as lifeguards or administrators will be able to acknowledge 11
  12. 12. Triton Lab II – Prototype Product Specification the alarm and disable it once the swimmer is not longer underwater. To demonstrate how the Triton System Prototype GUI works, Triton will use pre-seeded data to simulate different scenarios. 1.3 Definitions, Acronyms, and Abbreviations Algorithm: Well-defined series of instructions that intend to solve a problem. C# (C-Sharp): Object-oriented programming language developed by Microsoft as part of the .NET initiative. Drowning detection algorithm: Set of instructions designed to recognize potential drowning scenarios. Drowning Early Warning System (DEWS): Automated system that detects early drowning behavior by analyzing swimmer movements in a pool. Graphical User Interface (GUI): User interface that allows people to interact with a computer and computer-controlled devices. Institute of Electrical and Electronic Engineers (IEEE): Professional organization which sets transmission system standards and protocols. Jeff Ellis and Associates: Renowned firm specializing in aquatic risk management, aquatic facility management, swimming instruction, and leaders in innovation for the aquatics industry. Microsoft Access: Program used to create relational databases. It is part of the Microsoft Office Suite. MySQL: Open source multi-user database management system. 12
  13. 13. Triton Lab II – Prototype Product Specification Poseidon System: A computer-aided video surveillance composed of a network of underwater and overhead cameras connected to a computer. Poseidon detects a drowning behavior by analyzing the swimmer’s trajectories. Radio Frequency Identification (RFID): Wireless, automatic identification method. Data collection technology uses electronic tags for storing and remotely retrieving data. RFID tags are inexpensive and small and therefore incorporated into a variety of products in many different applications. RuBee™: A two way, active wireless protocol that uses long wave magnetic signals to send and receive short (128 byte) data packets in a local regional network. RuBee™ receiver: Device that receives and demodulates RuBee™ signals. RuBee™ tag: Device that sends long wave magnetic signals to antennas. Silent Drowning: Term used to describe when victim is found motionless in the water and victim was not seen submerging in the water. Swimguard Safety System: Video surveillance system composed of a network of underwater and overhead cameras. The system depends on a human response to determine possible drowning behavior. Transmission Control Protocol/Internet Protocol (TCP/IP): Networking protocol used to get data from one network device to another. Threshold: The point that must be exceeded to begin producing a given effect or result or to elicit a response. Visible Assets: Leader in the development of product and asset visibility solutions that use wireless RuBee™ technology. 13
  14. 14. Triton Lab II – Prototype Product Specification 1.4 References Barbieri, Cesar. (2008). Lab 1.1 – Triton Product Description. Virginia Beach, VA: Author. Brener, J. & Oostman, M. (2002, May). Lifeguards watch, but they don’t always see! World Waterpark Magazine. Retrieved October 22, 2007, from: http://www.poseidon-tech.com/us/pressArticleWWA0205.pdf. Centers for Disease Control and Prevention. (2008, January 23). WISQARS Injury Mortality Reports, 1999 – 2005. Retrieved February 03, 2008, from Centers for Disease Control and Prevention Web site: http://webappa.cdc.gov/sasweb/ ncipc/mortrate10_sy.html. Centers for Disease Control and Prevention. (2007, November 20). Downloadable Leading Causes Charts. Retrieved October 15, 2007, from Centers for Disease Control and Prevention Web site: http://www.cdc.gov/ncipc/osp/charts.htm. Orange Team. (2007, November). Triton Marketing Plan. Retrieved February 22, 2008, from Triton Web site: http://www.cs.odu.edu/~cpi/cpi-f2007/triton/docs/ MarketingPlan.doc. Document created during CS 410 at Old Dominion University. Stevens, John. (2006, November). RuBee™ Visibility Networks IEEE P1902.1 (Pending). Retrieved February 3, 2008, from IEEE RFID 2007 Web site: www.ieee-rfid.org/2007/documents/Camus-IDTechV1-5-Stevens.ppt. World Waterpark Association. (n.d.). Waterpark Industry General & Fun Facts. Retrieved October 22, 2007, from World Waterpark Association Web site: http://www.waterparks.org/otherArticles/Generalfacts.pdf. 14
  15. 15. Triton Lab II – Prototype Product Specification 1.5 Overview This product specification document provides the hardware and software configuration, external interfaces, capabilities, and features of the Triton prototype. Due to budget limitations, data that should be provided by wet/dry and pressure sensors will be simulated. Triton will use a RuBee™ demonstration kit provided by Visible Assets Inc. The kit includes an antenna, a receiver, tags (without wet/dry and pressure sensors attached), a CD-ROM with RuBee™ Finder Software, a demo kit manual, a power supply, and cables; furthermore, an aquarium, a brick, an ODU laptop, a database developed with Microsoft Access, and the Triton System Prototype software will be required during the prototype demonstration. The Triton System Prototype software has seven major interfaces: User Login, Swimmer Registration, Swimmer Administration, Prototype Detection Algorithm, Pool Alert View, Prototype Settings, and User Administration. These interfaces will be used to simulate different swimmer scenarios, which will help to prove that Triton is capable of detecting and sending an alarm when a swimmer is drowning; however, a set of functional, performance, and non-functional requirements need to be met in order to demonstrate a working prototype. 2 GENERAL DESCRIPTION Triton’s prototype will demonstrate that its sensor based surveillance system is feasible. Triton will prove two main things: communication underwater between RuBeeTM tags and an antenna connected to a RuBeeTM receiver and detection of a possible drowning scenario by the drowning detection algorithm. This section includes a description of the Triton prototype architecture, major functional components, hardware, software, and user interfaces. 15
  16. 16. Triton Lab II – Prototype Product Specification 2.1 Prototype Architecture Description Figure 3 illustrates the major functional components of the Triton System Prototype. RuBeeTM tags without pressure and wet/dry sensors attached and a RuBeeTM receiver with an antenna will be used to implement the Triton prototype. The RuBeeTM receiver needs to be connected to a laptop, provided by ODU’s Computer Science department, through a Universal Serial Bus (USB) port. The antenna needs to be connected to the RuBeeTM receiver. To test RuBeeTM technology and prove that communication underwater is possible, an aquarium and a brick will be used to simulate a pool environment. The information of RuBee TM tags, antennas, and RuBeeTM receivers will be stored in a database developed using Microsoft Access 2007, where a unique ID will be assigned to each element. The IDs assigned to RuBee TM tags and antennas will help identify two things, who the swimmers are and swimmers’ pool location in case of a drowning scenario. Simultaneously, this database will also store the information of users that have access to the system. [This space is intentionally left blank] 16
  17. 17. Triton Lab II – Prototype Product Specification Figure 3. Triton Prototype Architecture The Triton System Prototype, software developed by the Triton, is responsible for five major operations, grant access to authorized users, register swimmers and users, add and delete swimmers or users, detect and display when a swimmer is drowning, and load different scenarios to show the functionality of the Triton prototype. To accomplish the five major operations, the Triton System Prototype contains the following interfaces: User Login, Swimmer Registration, Swimmer Administration, Prototype Detection Algorithm, Pool Alert View, Prototype Settings, and User Administration. The Triton System Prototype will be installed on the laptop where the RuBeeTM receiver is connected. The laptop will be used to simulate the touch screen 17
  18. 18. Triton Lab II – Prototype Product Specification display and the base station. Table 2 provides a summary of the differences between the complete Triton System and the prototype version of it. Features Real World Project Prototype Wristbands Waterproof wristbands will be Actual wristbands will not be created; equipped with RuBeeTM tags. however, software will simulate Wristbands can be resized. swimmers wearing wristbands. RuBeeTM tags RuBeeTM tags will be specifically There are no sensors equipped on designed by Visible Assets Inc. Tags RuBeeTM tags. Pressure and will be equipped with pressure and wet/dry readings will be simulated. wet/dry sensors. RuBeeTM RuBeeTM receivers will be purchased Receivers and antennas are receivers and from Visible Assets Inc. Antennas will donated by Visible Assets Inc. antennas be attached and placed in the pool. There are only one receiver and two antennas available. The Triton A user friendly GUI application that The GUI will have more Software allows park administrators to add functionality than the real world and remove users from the system. product. The software is called Also, it alerts lifeguards of potential Triton System Prototype. Triton drownings. The software includes System Prototype includes seven three major modules: major interfaces: 1. Administration and 1. User Login. Registration which adds and removes swimmers and 2. Swimmer Registration. users. 3. Swimmer Administration. 2. Alert and Display which displays a potential drowning 4. Prototype Detection victim information and Algorithm. location. 5. Pool Alert View. 3. Drowning Detection which uses the drowning detection 6. Prototype Settings. algorithm to recognize a potential drowning victim. 7. User Administration. Features Real World Project Prototype 18
  19. 19. Triton Lab II – Prototype Product Specification Swimmer Registration, Swimmer Administration, and User Administration have the same functionality as the real world product’s Administration and Registration module. Pool Alert View has the same functionality as the Alert and Display module. Prototype Detection Algorithm shows how the Drowning Detection module works. Prototype Setting allows pool configuration and swimmer data files to be loaded into the software. Application The Triton software will be hosted on The Triton System Prototype server and a dedicated application server. Touch software will be installed on an ODU touch screen screen monitors will be used as laptop, which will simulate the monitor lifeguard stations. lifeguard station. Database MySQL. Microsoft Access will be used. Environment Wave pools. An aquarium will be used. Drowning Park patrons. It will be simulated in the software. victim Table 2. Triton Feature Comparison between Full Product and Prototype 2.2 Prototype Functional Description The major functional components of the Triton prototype include the following: underwater RuBeeTM communication, secure access, registration and administration, drowning detection process, settings, and alert and display. Proving that RuBeeTM technology allows underwater communication is a very important factor in the development of the Triton prototype. An antenna, located under the aquarium, will be 19
  20. 20. Triton Lab II – Prototype Product Specification connected to a RuBeeTM receiver, which will be connected to an ODU laptop. The laptop will run RuBee‘sTM Finder Software. The software application will display any RuBee TM tags that are or are not in the range of the antenna. Figure 4 illustrates the RuBee TM tag process flow. Figure 4. RuBeeTM Tag Demonstration Process Flow To provide secure access, the database requires a login table. This table will have three fields: username (primary key), password, and type. Figure 5 illustrates the login table. The User Login Interface allows users with a matching username and password to successfully login into the system. The three valid types of users that have access to different levels of the system are admin, lifeguard, and cashier. The admin will have full access to the system; this user will be able to add and remove swimmers and users, load and run pre-seeded data, and have access to all interfaces. The lifeguard will only have access to the Pool Alert View and Prototype Setting Interfaces. The 20
  21. 21. Triton Lab II – Prototype Product Specification cashier will only have access to the Swimmer Registration, Swimmer Administration, and Prototype Setting interfaces. Figure 5. Login Table To accomplish the registration and administration functional component, the interfaces required are Swimmer Registration, Swimmer Administration, and User Administration. The Swimmer Registration allows cashiers to add swimmers to the system by verifying that the swimmer has not been registered already; furthermore, swimmers are assigned a unique ID, which must be link to a working RuBeeTM tag. Figure 6 illustrates the registration process flow. The Swimmer Administration allows cashiers to delete swimmers information from the system when they leave the pool facility. The User Administration allows an admin to add and remove users from the Login table in the database and grant users different access levels to the system. [This space is intentionally left blank] 21
  22. 22. Triton Lab II – Prototype Product Specification Figure 6. Registration Process Flow Drowning detection process, implemented with the drowning detection algorithm, allows swimmers real time vigilance. Every swimmer that has been issued a unique ID is monitored. Drowning detection process displays data reports in a tabular form. These data reports consist of the swimmers’ depth per each second they are in the pool. If based on a repeated depth calculation that involves water density, gravity, atmospheric pressure, and the swimmer’s arm length a swimmer is underwater for more than a pre- defined time, the drowning detection process communicates with Pool Alert View Interface to alert lifeguards. Figure 7 illustrates the drowning detection algorithm process flow. 22
  23. 23. Triton Lab II – Prototype Product Specification Figure 7. Drowning Detection Algorithm Process Flow To demonstrate that the Triton System Prototype works as described, different settings are necessary. The Prototype Setting Interface will be used to load the system with pre-seeded data. The pre-seeded data will provide four different swimmer scenarios. The first scenario will show a swimmer outside the pool. The second scenario will show a swimmer in the pool, but above the water level. The third scenario will show a swimmer moving down and up. The last scenario will simulate a swimmer drowning. Alert and display demonstrates that based on the data received by the drowning detection process, a drowning alert message with the victim’s location in the pool will be displayed on the Pool Alert View Interface. Once a drowning situation has been 23
  24. 24. Triton Lab II – Prototype Product Specification acknowledged by lifeguards and the situation is under control, only users with a valid password and proper access level, either a lifeguard or an admin, will be able to disable the alarm. The user disabling the alarm will have to verify that the RuBee TM tag ID involved is working fine by checking the reading from the wet/dry sensor; the reading needs to be “dry” to prove that the tag is not longer underwater and working fine. Figure 8 illustrates the disabling an alarm process flow. Figure 8. Disabling an Alarm Process Flow 2.3 External Interfaces This section identifies the logical and physical interfaces used within and by the Triton prototype. The interfaces included in this section are hardware, software, user interface, and communication protocols. The major hardware interfaces are a laptop, a RuBeeTM demo kit, and an aquarium. The major software interfaces are RuBee TM Finder Software, Microsoft Access, and Visual C#. The major user interface is the Triton System Prototype software. The communication protocols used are TCP/IP and IEEE P1902. The following sub-sections provide a detailed description of the interfaces. 24
  25. 25. Triton Lab II – Prototype Product Specification 2.3.1 Hardware Interfaces A laptop and a RuBeeTM demo kit donated by Visible Assets Inc. will be used to implement the Triton prototype. The RuBeeTM demo kit includes the following: four RuBeeTM tags, two antennas, and one RuBeeTM receiver. RuBeeTM is a bi-directional peer-to-peer technology that operates at low frequencies. RuBeeTM tags have a built in CPU and memory; furthermore, sensors such as temperature, pressure, wet/dry, humidity, among others, can be attached to the tags. In addition, RuBee TM tags are designed to work in a network of more than a thousand tags and they have a range of 3 to 100 feet (Stevens, 2006). Based on the range, the antennas detect RuBeeTM tags and transfer the signal to a RuBeeTM receiver which converts the signal into data. This RuBeeTM receiver will be connected to an ODU laptop that will be used to monitor the tags recognition and run the Triton System Prototype software application. Also, an aquarium will be required to simulate a pool environment and test communication underwater. 2.3.2 Software Interfaces Three software applications are required to implement Triton’s prototype. RuBeeTM Finder Software will be used to demonstrate underwater communication by displaying the unique ID of RuBeeTM tags that are active (in range) and inactive (out of range) according to the antennas’ settings. In addition, C#, an object-oriented programming language developed by Microsoft, will be used to develop the Triton System Prototype software, which will be used to register swimmers and users, detect a possible drowning scenario, and display an alert and the position of the victim in the pool; furthermore, since the Triton System Prototype software needs a database to 25
  26. 26. Triton Lab II – Prototype Product Specification store and read RuBeeTM tags and users’ information, Microsoft Access will be used to develop Triton’s database. All software applications will be installed and run on the ODU laptop. 2.3.3 User Interfaces The Triton System Prototype software has seven user interfaces. The interfaces are User Login, Swimmer Registration, Swimmer Administration, Prototype Detection Algorithm, Pool Alert View, Prototype Settings, and User Administration. The User Login Interface provides access to authorized users only. If the username and password do not match the information in the database, an error is displayed with the proper message. The Swimmer Registration Interface allows a user to collect swimmers’ information and uniquely identify each swimmer by assigning him a RuBee TM tag ID. Before assigning a RuBeeTM tag ID, the system checks if the RuBeeTM tag is working properly and if the ID exists in the database. The Swimmer Administration Interface allows a user to view and remove swimmers information. The Prototype Detection Algorithm enables a user to setup the parameters that will be used to determine a drowning case. The Pool Alert View Interface displays an alarm with the swimmers information and location when a drowning scenario is detected. The Prototype Settings Interface allows a user to upload files with different pools and swimmers’ information. The User Administration Interface enables a user to register new users and grant them access levels to the system. Figure 9 illustrates the interaction of the seven user interfaces. 26
  27. 27. Triton Lab II – Prototype Product Specification Figure 9. User Interface Map 2.3.4 Communication Protocols and Interfaces The Triton prototype will use the Transmission Control Protocol/Internet Protocol (TCP/IP) and IEEE P1902.1 protocol. The TCP protocol is responsible for an error free connection between two computers, while the IP protocol is responsible for the data packets sent over the network. The IEEE P1902.1 is a long wavelength wireless network protocol that ensures the interoperability of RuBeeTM technology (Stevens, 2006). 3 SPECIFIC REQUIREMENTS The following sections describe the specific functional, performance, and non- functional requirements of the Triton prototype. To make the Triton product feasible, these functional and performance requirements need to be met. The last section will describe the non-functional requirements of the Triton prototype. The non-functional requirements will address the Triton prototype’s security, maintainability, and reliability. 27
  28. 28. Triton Lab II – Prototype Product Specification 3.1 Functional Requirements The functional requirements of the Triton prototype will specify the particular behavior and capabilities of the prototype. Each requirement will be grouped into a functional area and will contain a statement describing a key attribute of the prototype. The functional requirements include details on RuBee™ setup, underwater communication, user login, swimmer registration and administration, pool alert, prototype detection algorithm, prototype settings, user administration, and the access database of the Triton System Prototype. 3.1.1 RuBeeTM Setup To demonstrate RuBee’s™ ability to communicate underwater, Triton will utilize software and hardware provided by Visible Assets Inc. Visible Assets Inc. provided Triton with a RuBee™ demonstration kit to use during the Triton prototype’s demonstration. The following is an inventory of the demonstration kit’s contents and requirements for setup: 1. Receiver 2. Ranger Antenna 3. Four RuBee™ Radio Tags 4. CD-ROM with RuBee™ Finder Software & Demo Kit Manual 5. Associated Cables and Power Supplies In order to successfully demonstrate that the RuBee™ hardware will work as intended, the RuBee™ Finder Software must be installed on the ODU student laptop in accordance with the provided Visible Assets software demo kit manual (see 3.1.2 for 28
  29. 29. Triton Lab II – Prototype Product Specification software requirements). The associated hardware will have to be connected as shown in Figure 10. Figure 10. Hardware Connection Set Up 3.1.2 Underwater Communication Demonstration In order to use the RuBee™ Finder Software to validate the functional requirements for underwater communication, the Finder Software must be installed according to the directions provided by Visible Assets Inc. in the demo kit manual. Figure 11 illustrates the RuBee™ Finder Software, which will be used to display and verify the following functional requirements: 1. The RuBee™ receiver can read a tag in a dry environment within the range of the antenna. 29
  30. 30. Triton Lab II – Prototype Product Specification 2. Using an aquarium filled with water, the RuBee™ receiver can read a submerged tag within the range of the antenna. 3. The RuBee™ receiver can read a submerged tag covered with a brick within the range of the antenna. Figure 11. RuBeeTM Finder Software Screen Shot 3.1.3 User Login Interface The purpose of the User Login Interface is to grant access and authorization level to official users. The User Login Interface will adhere to the following functional requirements: 1. Accept a username and password combination. 2. Validate the entered username and password with the stored information in the login table in the database (see functional requirement 3.1.9 for database requirements). 30
  31. 31. Triton Lab II – Prototype Product Specification 3. Allow users with the correct username and password combination to log into the system, and grant the users the proper authorization level (administrator, lifeguard, or cashier) as listed below. a. An administrator will have access to the following interfaces: Swimmer Administration, Swimmer Registration, Pool Alert View, Prototype Detection Algorithm, Prototype Settings, and User Administration. b. A lifeguard will have access to the following interfaces: Pool View Alert and the Prototype Setting interfaces. c. A cashier will have access to the following interfaces: Swimmer Registration, the Swimmer Administration, and the Prototype Setting interfaces. 4. Unauthorized users (users without a correct username and password combination) will not be granted access to the system at all, and a login error message will be displayed. 5. Authorized users will be allowed to logout from the system while using any other interface. 3.1.4 Swimmer Registration and Administration Interfaces The Swimmer Administration and Registration interfaces have similar functional requirements; therefore, they are combined in this section. The Swimmer Registration Interface will allow authorized users to register swimmers, and assign each swimmer a unique wristband ID / RuBee™ tag ID. The Swimmer Administration Interface will allow authorized users to remove previously registered swimmers from the Triton System 31
  32. 32. Triton Lab II – Prototype Product Specification Prototype. The Swimmer Administration and Registration interfaces will adhere to the following functional requirements: 1. When a swimmer is registered, the following information will be required: a. Swimmer First Name b. Swimmer Last Name c. Swimmer Arm Length (Measured from the swimmers nose to the wrist) d. Swimmer Gender (Male / Female) e. Swimmer Age (Child / Adult) f. Swimmer Wristband ID g. Emergency Contact First Name h. Emergency Contact Last Name i. Emergency Contact Phone Number It will be optional to enter additional information about the swimmer or emergency contact. 2. Swimmer information is tied to a unique wristband ID. If a new swimmer is registered to a wristband that is already in use, the swimmer registration request will fail and an error message will be displayed. 3. The Swimmer Administration Interface will display a list of the wristbands currently in use by the system. The user will be able to select a swimmer and view the swimmer’s information. 4. The Swimmer Administration Interface will allow the user to either remove a single swimmer or all of the swimmers from the system. 32
  33. 33. Triton Lab II – Prototype Product Specification 3.1.5 Pool Alert View Interface The Pool Alert View Interface will display a view of the pool and the location of the antennas in the pool. The user will be able to select swimmers from a list and view their location in the pool. It will also alert the lifeguard of a potential drowning swimmer. The Pool Alert View Interface will adhere to the following functional requirements: 1. An aerial view of the pool and RuBee™ antenna locations will be displayed along with the current time. 2. A list of all of the swimmers registered in the system will be displayed. The user will be able to select a swimmer and some of their personal information (Name, Gender, Age, and Additional Information) will be displayed as well as their location in the pool. 3. If a swimmer is drowning, an alarm message will be displayed and the victim’s location in the pool will be shown. 4. An alarm can only be disabled when the wristband sensor readings indicate safe conditions for the swimmer. To disable an alarm, a proper username and password combination must be entered by an authorized lifeguard user. Any errors disabling the alarm will be displayed. 3.1.6 Prototype Detection Algorithm Interface The Prototype Detection Algorithm Interface will show how a swimmer’s depth will be determined by the wristband sensor readings. The user will be able to enter various sensor readings and modify environment variables in order to demonstrate how the wristband depth will be calculated. The Prototype Detection Algorithm Interface will adhere to the following functional requirements: 33
  34. 34. Triton Lab II – Prototype Product Specification 1. The user will be required to enter the following information to compute a depth measurement: a. Pressure Sensor Reading b. Wet/Dry Sensor Reading c. Swimmer Arm Length The following fields will be populated with normal physical constants (assuming standard temperature and pressure): a. Atmospheric Pressure b. Acceleration due to Gravity c. Density of the Pool Water 2. The user will be able to compute the depth of the wristband once all of the above fields are filled with proper information. Any errors (data entry or computational errors) will be displayed to the user. 3. The depth detection algorithm will calculate wristband depth using the following formula: D = (P - S) / (R * g) where: P = water pressure (pascals) S = atmospheric pressure (pascals) R = pool water density (kg / m3) g = gravity (m / s2) D = depth of the object (m) 34
  35. 35. Triton Lab II – Prototype Product Specification 4. The depth will be displayed to the user in inches (converted from meters). 3.1.7 Prototype Settings Interface The purpose of the Prototype Settings Interface is to provide a mechanism to load swimmer data and swimmer scenario files into the Triton System Prototype software. This allows the user demonstrating the system to easily show various capabilities of the system as if there were actual swimmers using the system (see functional requirement 3.1.11 for the swimmer simulation requirements). The Prototype Settings Interface will adhere to the following functional requirements: 1. The user will be able to load a list of swimmers and their information into the system (see 3.1.10.1 for the simulated data requirement for swimmers). 2. The user will be able to load various swimmer scenarios, which will display the various drowning and swimming scenarios that the system will be expected to handle (see 3.1.10.2 for the simulated data requirement for scenarios). 3.1.8 User Administration Interface The User Administration Interface will allow a system administrator to add and remove users from the system. The User Administration Interface will adhere to the following functional requirements: 1. The administrator user will be able to add a new user to the system, specifying the user’s password and user’s type. 2. The User Administration Interface will display a list of users with their authorization levels. 3. An administrator user will be allowed to remove users from the system. 35
  36. 36. Triton Lab II – Prototype Product Specification 4. An administrator user will be allowed to reset the password of any other user. 5. The username and password combination will be stored with the user’s authorization level in the login table in the database. 3.1.9 Access Database The Access Database must be created with two tables; the first table login is used to store login information for users of the Triton System Prototype. The second table ID relates wristband IDs to RuBee™ tag IDs. The Access Database will adhere to the following functional requirements: 1. The table Login will have the following schema: a. Login will have three attributes: username, password, and type. b. The primary key of the Login table will be username. c. The password attribute cannot not be null (empty). d. The user type attribute values will be either admin, cashier, or lifeguard. 2. The table ID will have the following schema: a. ID will have two attributes: wristbandID and tagID. b. The primary key of the ID table will be wristbandID. c. The tagID attribute cannot be null (empty). 3.1.10 Simulated Data Because of the existing limitations of the RuBee™ demo kit, the Triton System Prototype software cannot connect to the RuBee™ hardware. The RuBee™ will be shown to work as per functional requirements 3.1.1 and 3.1.2, but in order to show that 36
  37. 37. Triton Lab II – Prototype Product Specification the Triton System prototype software works, simulated sensor reading and locations must be used. The various pre-seeded data will include different swimmer information and swimmer scenarios. The data will be loaded into the software from various files of the user’s choice. The pre-seeded simulated data must meet the following requirements: 1. The pre-seeded swimmer information data will include all of the information required to register a swimmer as per functional requirement 3.1.4.1. 2. The pre-seeded swimmer scenario data will include swimmer locations in the pool as well as simulated wet/dry and pressure sensor readings tied to specific RuBee™ tag IDs per time-step (one second) for a various length of time. 3.1.11 Swimmer Simulation In order to simulate swimmers in the Triton System Prototype, swimmer simulation scenarios will be used. Simulated data for swimmers and scenarios will be pre-made according to the functional requirements in 3.1.10. In order to demonstrate swimmers actively swimming, all three types of users will be able to load various swimming scenarios and control which particular time-step the scenario is at. The simulation of active swimmers must meet the following requirements: 1. All three types of users will be able to access the Prototype Settings Interface as per functional requirement 3.1.3.3 and load simulated swimmer data and scenarios from it. 2. When a swimming scenario is loaded, the user will be able to move forward or backward in time for each time-step to properly demonstrate the system. 37
  38. 38. Triton Lab II – Prototype Product Specification 3. The depth detection algorithm will run on the data for each swimmer at each time-step (see functional requirement 3.1.6.3). If a swimmer’s wristband is determined to be underwater (depth of the wristband is greater than the arm length) for more than 15 seconds, an alarm will be sounded in the pool alert view. 4. The sensor data for each time-step must be stored in an archive file along with the wristband ID and personal information, so that in case of a drowning incident, administrators can review the sensor readings. 3.2 Performance Requirements The following performance requirements will be used to measure the functions, behaviors, and capabilities of the Triton prototype. Each performance requirement will have numeric boundaries, stated in measurable terms. Some modules may have more than one performance requirement; however, each requirement will be an individual statement with a unique identifier. [This space is intentionally left blank] 3.2.1 Underwater Communication 1. RuBee’s™ antenna will meet the following performance requirements: a. Ability to receive RuBee™ communications within a six to twelve foot range. b. Capability of reading up to four RuBee™ tags simultaneously. 38
  39. 39. Triton Lab II – Prototype Product Specification 2. RuBee’s ™ receiver and Finder Software will meet the following performance requirement: a. Ability to receive communication from four tags simultaneously. 3. RuBee™ radio tags will meet the following performance requirements: a. Capability of storing up to 10KB. b. Capability of transmitting 1KB per second. c. Ability to maintain 4,000 days of battery life. 3.2.2 Detection Algorithm The Detection Algorithm will: 1. Communicate with the Pool Alert View Interface and alert if swimmer’s depth exceeds swimmer’s arm length for 15 consecutive seconds (see 3.1.11.3 functional requirement for swimmer simulation). 2. Be capable of processing up to four swimmer’s simultaneously, including sending alerts. 3. Be capable of sending an alert within two seconds of swimmer meeting the alert criteria. 3.3 Assumptions and Constraints Due to limitations and constraints associated with the Triton prototype, the Triton group developed a list of assumptions. It is necessary to document any assumptions, constraints, and dependencies because they often affect the requirements of the product or relate to incompleteness in the prototype. For example, the Triton group will 39
  40. 40. Triton Lab II – Prototype Product Specification not be able to demonstrate simultaneous communication with more than four tags because only four tags were provided by Visible Assets Inc. Table 3 contains a complete list of assumptions, constraints, and dependencies associated with the Triton prototype. [This space is intentionally left blank] 40
  41. 41. Triton Lab II – Prototype Product Specification Conditions Type Effect on Requirements There will be at most four The effectiveness of the algorithm on more Assumption swimmers in the pool. than four swimmers will not be tested. There will be four swimmer scenarios: 1. Swimmer outside the pool. Algorithm will not be tested on other 2. Swimmer in the pool, but Assumption scenarios. above water level. 3. Swimmer in the pool moving down and up. 4. Swimmer drowning. RuBee™ tags transmit data Assumption Time delay may not be tested. every one second. Actual pressure and wet/dry readings will Actual pressure and wet/dry Constraint be simulated by Triton System Prototype readings will not be recorded. software. For each swimmer, time and depth data Actual time and depth data Constraint will be simulated. There will be 60 seconds will not be recorded. worth of data. An ODU laptop is available to Dependency Otherwise, a student laptop will be used. host the application. The drowning detection The software functional components of the algorithm is used to detect Dependency prototype will fail if the algorithm does not drowning cases. work. RuBee™ demo kit will be The hardware functional components will used to demonstrate Triton’s Dependency fail if tags do not work. ability to work underwater. Table 3. Assumptions, Dependencies, and Constraints on Prototype Requirements 3.4 Non-Functional Requirements Non-functional requirements characterize the performance of the product and they are present in the background, as well as throughout each functional component. Many non-functional requirements impact directly or otherwise interrelate with many of 41
  42. 42. Triton Lab II – Prototype Product Specification the prototype’s functional requirements. These requirements involve security issues, maintainability, and reliability. 3.4.1 Security Access control is critical to make sure that users cannot abuse the system. If the User Login Interface is created according to functional requirement 3.1.3, unauthorized users will not be granted access to the system and authorized users will be given access to the appropriate interfaces. Another major security concern is having a user disable an alarm when they should not be allowed to (see functional requirement 3.1.5.4). 3.4.2 Maintainability The two main things that need to be maintained are the swimmer information and the hardware functionality. Once swimmers are added to the system, their information is stored internally in the prototype software. Accordingly, the swimmer’s information will be removed from the system once the swimmer leaves the park and turns the wristband back in. Hardware, including laptop, tags, receiver, antenna, and associated cabling will also be visually inspected and tested by Triton group members periodically and prior to prototype demonstration. 3.4.3 Reliability For the Triton prototype to be considered successful, it must meet certain reliability standards. The RuBee™ tags must be able to establish two way communications with the receivers and have 100% transmission quality, with no lost 42
  43. 43. Triton Lab II – Prototype Product Specification packets or abnormal signal degradation. The prototype software must also work correctly with no fatal errors, and it should be free of any race conditions and other errors that could cause the software to lock up. The databases that the software will access should also be able to store and query data whenever necessary. 4 APPENDIX The appendix contains additional documentation regarding Triton’s prototype. 4.1 Formal Resource Request Document Team: Orange/Triton Project Manager: Kate Nguyen The following resources are required to be purchased for the prototype development and demonstration of the Triton System product: Hardware Purchase (list all items required for purchase) 1. Aquarium (to demonstrate underwater communication) a. Make, Model: GAL HIGH AQUARIUM ROSEWOOD. Dimension: 24 X 12 X 16. Code: 4749711112 b. Vendor: PERFECTO MANUFACTURING. http://www.petswarehouse.com/Vpasp/shopexd.asp?id=257721&zmam= 90031077&zmas=12&zmac=62&zmap=257721 c. Cost: $38.24 d. Date required: April 23 43
  44. 44. Triton Lab II – Prototype Product Specification e. Deliver to: Triton 2. Concrete Bricks (to demonstrate RuBeeTM ability to work around bricks) a. Make/Model: Any b. Date required: April 23 c. Deliver to: Triton Software Purchase (list all items required for purchase): None. All free versions of software were already acquired. The following university resources are required to support the prototype development and demonstration: None. University laptop was already acquired. 44

×