Triton Team
Lab II
Prototype Product Specification
April 4, 2008
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
3
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
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
2
Triton Lab II – Prototype Product Specification
Table of Contents
4
APPENDIX ............................................................................................................. 43
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
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
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
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, RuBee TM 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 RuBee TM 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
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 RuBee TM tag to get
data that will be used later in the process of identifying potential drowning victims.
[This space is intentionally left blank]
7
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 RuBee TM 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
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
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
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 RuBee TM receiver and detection of a
possible drowning scenario. The first functional objective deals with underwater
communication. It is very important to successfully demonstrate that RuBee TM 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 RuBeeTM 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
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
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
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
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 RuBee TM 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
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 RuBeeTM 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 RuBeeTM 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
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
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
equipped with RuBeeTM tags.
Wristbands can be resized.
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
receivers and
antennas
RuBeeTM receivers will be purchased Receivers and antennas are
from Visible Assets Inc. Antennas will donated by Visible Assets Inc.
be attached and placed in the pool.
There are only one receiver and
two antennas available.
The Triton
Software
A user friendly GUI application that
allows park administrators to add
and remove users from the system.
Also, it alerts lifeguards of potential
drownings. The software includes
three major modules:
1. Administration and
Registration which adds and
removes swimmers and
users.
Actual wristbands will not be
created; however, software will
simulate swimmers wearing
wristbands.
The GUI will have more
functionality than the real world
product. The software is called
Triton System Prototype. Triton
System Prototype includes seven
major interfaces:
1. User Login.
2. Swimmer Registration.
3. Swimmer Administration.
2. Alert and Display which
displays a potential drowning
victim information and
location.
4. Prototype Detection
Algorithm.
5. Pool Alert View.
3. Drowning Detection which
uses the drowning detection
algorithm to recognize a
potential drowning victim.
6. Prototype Settings.
7. User Administration.
18
Triton Lab II – Prototype Product Specification
Features
Real World Project
Prototype
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
server and
touch screen
monitor
The Triton software will be hosted on
a dedicated application server. Touch
screen monitors will be used as
lifeguard stations.
The Triton System Prototype
software will be installed on an ODU
laptop, which will simulate the
lifeguard station.
Database
MySQL.
Microsoft Access will be used.
Environment
Wave pools.
An aquarium will be used.
Drowning
victim
Park patrons.
It will be simulated in the software.
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
19
Triton Lab II – Prototype Product Specification
development of the Triton prototype. An antenna, located under the aquarium, will be
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
RuBeeTM tags that are or are not in the range of the antenna. Figure 4 illustrates the
RuBeeTM 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
20
Triton Lab II – Prototype Product Specification
will only have access to the Pool Alert View and Prototype Setting Interfaces. The
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 RuBee TM 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
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 predefined time, the drowning detection process communicates with Pool Alert View
Interface to alert lifeguards. Figure 7 illustrates the drowning detection algorithm
process flow.
22
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
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 RuBeeTM 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 RuBeeTM 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
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
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 RuBeeTM 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Triton Lab II – Prototype Product Specification
Conditions
There will be at most four
swimmers in the pool.
Type
Assumption
Effect on Requirements
The effectiveness of the algorithm on
more than four swimmers will not be
tested.
There will be four swimmer
scenarios:
1. Swimmer outside the
pool.
2. Swimmer in the pool, but
above water level.
Assumption
Algorithm will not be tested on other
scenarios.
Assumption
Time delay may not be tested.
3. Swimmer in the pool
moving down and up.
4. Swimmer drowning.
RuBee™ tags transmit data
every one second.
Actual pressure and wet/dry
Constraint
readings will not be recorded.
Actual time and depth data
will not be recorded.
Constraint
Actual pressure and wet/dry readings will
be simulated by Triton System Prototype
software.
For each swimmer, time and depth data
will be simulated. There will be 60
seconds 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
algorithm is used to detect
Dependency the prototype will fail if the algorithm does
drowning cases.
not 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
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
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
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