Triton_Lab2.doc

Triton Team

Lab II

Prototype Product Specification

April 4, 2008

Triton Lab II – Prototype Product Specification

Table of Contents

1 INTRODUCTION.......................................................................................................41.1 Purpose..............................................................................................................51.2 Scope...............................................................................................................111.3 Definitions, Acronyms, and Abbreviations........................................................121.4 References.......................................................................................................141.5 Overview..........................................................................................................15

2 GENERAL DESCRIPTION.....................................................................................152.1 Prototype Architecture Description...................................................................162.2 Prototype Functional Description.....................................................................192.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..................................................................................273.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.........................................................................................37

3.1.11 Swimmer Simulation.................................................................................373.2 Performance Requirements.............................................................................38

3.2.1 Underwater Communication.....................................................................39

3.2.2 Detection Algorithm..................................................................................393.3 Assumptions and Constraints..........................................................................403.4 Non-Functional Requirements.........................................................................41

3.4.1 Security.....................................................................................................42

3.4.2 Maintainability...........................................................................................42

3.4.3 Reliability..................................................................................................42

2


Table of Contents

4 APPENDIX..............................................................................................................434.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


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


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


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


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 RuBeeTM 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.


7


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


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.


9


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


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 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


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


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


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


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


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.


16


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


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.

Actual wristbands will not be created; however, software will simulate swimmers wearing wristbands.

RuBeeTM tags RuBeeTM tags will be specifically designed by Visible Assets Inc. Tags will be equipped with pressure and wet/dry sensors.

There are no sensors equipped on RuBeeTM tags. Pressure and wet/dry readings will be simulated.

RuBeeTM receivers and antennas

RuBeeTM receivers will be purchased from Visible Assets Inc. Antennas will be attached and placed in the pool.

Receivers and antennas are donated by Visible Assets Inc. 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.

2. Alert and Display which displays a potential drowning victim information and location.

3. Drowning Detection which uses the drowning detection algorithm to recognize a potential drowning victim.

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.

4. Prototype Detection Algorithm.

5. Pool Alert View.

6. Prototype Settings.

7. User Administration.

18


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


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 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

20


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 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.


21


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


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


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


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, RuBeeTM 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

http://en.wikipedia.org/wiki/Programming_language

http://en.wikipedia.org/wiki/Object-oriented_programming


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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.


40


Conditions Type Effect on Requirements

There will be at most four swimmers in the pool.

AssumptionThe 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.

3. Swimmer in the pool moving down and up.

4. Swimmer drowning.

AssumptionAlgorithm will not be tested on other scenarios.

RuBee™ tags transmit data every one second.

Assumption Time delay may not be tested.

Actual pressure and wet/dry readings will not be recorded.

ConstraintActual pressure and wet/dry readings will be simulated by Triton System Prototype software.

Actual time and depth data will not be recorded.

ConstraintFor each swimmer, time and depth data will be simulated. There will be 60 seconds worth of data.

An ODU laptop is available to host the application.

Dependency Otherwise, a student laptop will be used.

The drowning detection algorithm is used to detect drowning cases.

DependencyThe software functional components of the prototype will fail if the algorithm does not work.

RuBee™ demo kit will be used to demonstrate Triton’s ability to work underwater.

DependencyThe hardware functional components will fail if tags do not work.

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


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


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


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

Triton_Lab2.doc

Documents

Transcript of Triton_Lab2.doc