1 Technical ApproachThis part of the document will outline the overall technical approach of the prototype by

identifying its major capabilities, facilities and equipment, and the key personnel involved in the

prototype demonstration. Furthermore, it will provide proposed activities to switch from

prototype to product.

1.1 Prototype Capabilities

This part of the document will outline the overall architecture of the prototype by

identifying its major components and their purpose. Furthermore, it will provide a summary of

the functions that the product will provide or perform, generally what they do, and how they

relate to each other.

1.1.1 Prototype Architecture DescriptionThe ThrillTracker prototype will consist of:

A commercial off the shelf (COTS) Phidget 1023 RFID reader that is included in a RFID

developer’s kit provided by the university. Also included in the developer’s kit are several

read-only RFID cards and tags. These cards and tags are pre-coded with a unique identifier.

A student or university provided laptop that will be used to simulate the kiosk environment

through the use of HTML and scripting languages such as PERL and PHP. This HTML and

script code will demonstrate the look and feel of the kiosk GUI as well as perform the

functions of the ThrillTracker application. The Phidget Application Programming Interface

(API) as well as the RFID Event Manager will also reside and run on this laptop.

A MySQL database will be used to store all of the data required to demonstrate ThrillTracker

and will reside on a university server. Data stored in the database includes patron account

data, attraction data and itinerary information. A backup copy of the database will also

reside on the laptop used for the demonstration. The laptop will be installed with all of the

software required to accommodate queries that are sent from the ThrillTracker simulation.

This software will include Apache web server, MySQL, PHP and PERL.

Figure 1 ThrillTracker Prototype Major Functional Component Diagram.1

1.1.2 Prototype Functional DescriptionThe major functional components of the ThrillTracker prototype include the following:

RFID Reader: Used to simulate RFID gates placed at park attractions. The RFID reader

will sense the RFID tag and read the encoded unique identifier.

1 Blue Group, Fall 2007

RFID Interface: A Software application which will provide the interface to the RFID

reader, receive messages containing the tag ID from the RFID reader, and then dispatch

the tag ID to the ThrillTracker database. The interface will utilize the Phidget API

provided with the RFID toolkit and the RFID Event Manager written by a member of

prototype development team.

Application Simulation: HTML and scripting languages such as PERL and PHP will be

used to create a patron GUI and an Administrative GUI. These GUI screens will provide

the simulated functionality of the ThrillTracker application.

o Patron GUI: HTML based application used to simulate the look and feel of the

kiosk GUI. The simulation will cover the features available to ThrillPass patrons

including:

Login and create a user name.

Create and modify a ThrillPass itinerary.

Party location.

Park information.

Party creation and modification.

o Admin GUI: HTML based application used to simulate the look and feel of the

Administrative GUI. The simulation will cover the features available only to

system administrators including:

Access of historical attraction data.

Adding an admission pass to the database.

Access patron data.

Update or delete patron account.

Figure 2 illustrates the logic flow to be used when accessing the Patron GUI simulation.

In this logic flow, the unique ID of the RFID tag is entered in the text box on the welcome

screen. The PERL script simulating the ThrillTracker application checks the database to ensure

that the ID is active. If the ID is not active or invalid, the GUI simulation will display an error.

If the ID is determined to be active, the Patron GUI simulation then queries the database

see if the ThrillPass account has been set up. If there the account has not yet been set up, the

account setup process is called and the account setup screen is presented.

If the account has already been set up, then the account access process is called and the

ThrillPass Patron GUI is presented.

Figure 2 Logic Flow: Patron GUI Access2

2 Blue Group, Fall 2007

1.1.3 External InterfacesThis section will describe the hardware, software, user and communication interfaces of

the ThrillTracker prototype.

1.1.3.1 Hardware Interfaces USB Interface: This is a high-speed USB interface which establishes the data exchange

path between the laptop running the ThrillTracker application and the Phidget 1023 RFID

card reader. Information transferred on this interface will include the unique identifier

code of the RFID tag.

Network Interface: The network interface will allow communication between the laptop

simulating the ThrillTracker application and the remote database server. The

ThrillTracker prototype laptop will utilize the onboard Ethernet port to connect the LAN.

1.1.3.2 Software Interfaces

RFID Interface: A Software application which will provide the interface to the RFID

reader, receive messages containing the tag ID from the RFID reader, and then dispatch

the tag ID to the ThrillTracker database. The interface will utilize the Phidget API

provided with the RFID toolkit and the RFID Event Manager written by a member of

prototype development team.

Database Interface: This interface is provided by the ThrillTracker application and will

send and receive messages to and from the remote MySQL database.

1.1.3.3 User Interfaces

Screen: A screen color display capable of at least 800 by 600 pixels is required.

Keyboard: A keyboard is necessary for data entry.

Mouse: A mouse will be needed to navigate through the ThrillTracker software.

RFID Reader: A RFID reader will be needed to demonstrate one of the ThrillTracker

software functionality.

1.1.3.4 Communications Protocols and Interfaces

ThrillTracker will use the standard TCP/IP networking protocol and the standard Ethernet

interface to communicate with the database server. The EM4102 protocol will be used to

communicate with the Phidget 1023 RFID reader.

1.1.4 Specific Requirements

This section of the document contains all the detailed requirements that have been built

and will be demonstrated during the prototype presentation.

1.1.4.1 Functional Requirements This section will define the functional requirements for the ThrillTracker prototype.

1.1.4.1.1 ThrillPass Patron GUI

1.1.4.1.1.1 ThrillPass Patron Welcome Screen/Process

This function will provide the starting point for the GUI interface for ThrillPass users.

The following functional requirements shall be provided/simulated:

1. The welcome screen will display basic system information.

a. Name of the park.

b. ThrillPass logo.

2. A text box for admission pass ID input.

3. A submit button.

If a patron inputs an invalid ID, an error message will be displayed. If the patron enters a

valid ID for an account that is not yet associated with a user name, then the Setup New Account

Screen will be presented. If the patron enters a valid ID for an account that is associated with a

user name, then the Returning Account Information screen will be presented. In order to limit the

scope of the ThrillTracker prototype, only manual entry of the pass ID will be supported. The

Phidget RFID reader will not be used to input the pass ID.

1.1.4.1.1.2 Setup New Account Screen/Process

This function will provide the ability to set up a new ThrillPass account. The following

functional requirements shall be provided/simulated:

1. The ID of the RFID tag entered at the welcome screen will be displayed.

2. An informative message reminding patrons not to input personal data.

3. A text box for the input of a user name.

4. If the user name is currently in use, an error message will be displayed requesting that the

user input a new user name.

5. A submit button.

The PERL script used to create the screen will query the database and determine if the user

name is in use. If an unused user name is input, the database will be updated with the new user

name. A message informing the patron that the account setup was successful will then be

presented along with a continue button. When the continue button is clicked, the Returning

Account Information screen will presented.

1.1.4.1.1.3 Returning Account Information Screen/Process

This function will provide ThrillPass patrons the ability to access the ThrillPass features.

This screen will only be available to registered ThrillPass users. The following functional

requirements shall be provided/simulated:

1. The name of the park will be displayed.

2. The ThrillPass logo will be displayed.

3. The unique ID of the admission pass and the user name will be displayed.

4. A button which will navigate to the Itinerary Info Screen.

5. A button which will navigate to the Party Information Screen.

6. A button which will navigate to the Park Information Screen.

7. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.1.4 Itinerary Info Screen/Process

This function will provide ThrillPass patrons a view of the current ride itinerary. This

screen will only be available to registered ThrillPass users. The following functional

requirements shall be provided/simulated:

1. The current ride itinerary for the account will be displayed.

2. A button which will navigate to the Modify Itinerary Screen.

3. A button which navigates back to the Returning Account Information Screen.

4. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.1.5 Modify Itinerary Screen/Process

This function will provide ThrillPass patrons the ability to modify the ride itinerary. This

screen will only be available to registered ThrillPass users. The following functional

requirements shall be provided/simulated:

1. A group of check boxes representing each attraction that can be placed on the itinerary.

2. A group of check boxes representing the available timeslots for the attraction.

3. Checked boxes will indicate a ride that is currently active on the itinerary. Removing a

check from a checked a box will indicate that a ride is to be removed from the itinerary.

4. A submit button, that when clicked, will update the itinerary and navigate back to the

Itinerary Information screen.

5. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.1.6 Park Information Screen/Process

This function will provide a ThrillPass patron with a map of the park, display the

current location of the patron and current wait time of various attractions. This screen will

only be available to registered ThrillPass users. The following functional requirements

shall be provided/simulated:

1. A map of the park with an arrow indicating current location of the simulated kiosk in use.

2. When an attraction is clicked, a popup window will open and display current wait time

information for the selected attraction.

3. A button which navigates back to the Returning Account Information Screen.

4. A logout button, which when clicked, will navigate back to the initial Welcome screen.

Only one kiosk will be simulated and the location will remain static. The PERL script

used to create the screen will query the database when an attraction is clicked. The PERL script

will use the information from the query to simulate the attraction wait time information in the

pop up window.

1.1.4.1.1.7 Party Information Screen/Process

This function will provide ThrillPass patrons the ability to access the Party Information

features. This screen will only be available to registered ThrillPass users. The following

functional requirements shall be provided/simulated:

1. The current members of the patron’s party will be displayed.

2. A button which will navigate to the Find Party Member Screen.

3. A button which will navigate to the Modify Party Screen.

4. A button which navigates back to the Returning Account Information Screen.

5. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.1.8 Find Party Member Screen/Process

This function will provide ThrillPass patrons a display of the last known location of a

party member. This screen will only be available to registered ThrillPass users. The following

functional requirements shall be provided/simulated:

1. A list of party members and their last recorded location.

2. A button which navigates back to the Party Information Screen.

3. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.1.9 Modify Party Screen/Process

This function will provide ThrillPass patrons the ability to set up a party as well as add or

remove party members. A patron can only be a member of one party at a time. Addition or

removal of party members will be accomplished by inputting either the user name or admission

pass RFID tag ID. This screen will only be available to registered ThrillPass users. The

following functional requirements shall be provided/simulated:

1. A list of current party member’s user names and admission pass IDs will be displayed.

2. A text box for user name input.

3. A text box for ID input.

4. A remove member button.

5. An add member button.

6. A button which navigates back to the Party Information Screen.

7. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.2 ThrillTracker Admin GUI

1.1.4.1.2.1 Admin Welcome Screen/Process

This function will provide the starting point for the GUI interface for ThrillTracker

administrators. When a valid user name and password are submitted, buttons which navigate to

other administrative features will be made available. In order to limit the scope of the prototype,

administrative user names and passwords will be pre-loaded into the database. The following

functional requirements shall be provided/simulated:

1. The welcome screen will display basic system information.

a. Name of the park.

b. ThrillTracker logo.

2. A text box for user name input.

3. A text box for password input.

4. A login button.

If an invalid user name or password is entered, an error message will be displayed. If a

valid user name and password are entered, then a welcome message including the user name will

be displayed along with the following buttons:

5. A button which navigates to the Access Data by Attraction Screen.

6. A button which navigates to the Access Patron Data Screen.

7. A button which navigates to the Patron Account Administration Screen.

8. A logout button, which when clicked, will navigate back to the initial Welcome screen.

In order to limit the scope of the ThrillTracker prototype, attraction information and

timeslot availability will remain static. There will be no support for adding or removing

attractions. There will also be no support for modifying the number of available timeslots for a

particular attraction.

1.1.4.1.2.2 Setup New Admission Pass Screen/Process

 

This process will provide an administrator the ability to enter the unique ID of the RFID

tag embedded in an admission pass into the database. The following functional requirements

shall be provided/simulated:

1. A text box for admission pass ID input.

2. A checkbox labeled ThrillPass.  

3. A Submit button.

4. A button which navigates back to the Admin Welcome Screen.

If the submit button is clicked and no ID is input, an error message will be displayed. If

an ID is entered and the ThrillPass checkbox is checked to indicate that the ThrillPass option has

been purchased, then the ID will be entered into the database as an active ThrillPass. If the ID is

entered and the checkbox is not checked, the ID is entered into the database as a normal

admission pass.           

1.1.4.1.2.3 Access Data by Attraction Screen/Process

This function will provide buttons which will navigate to data screens for each attraction

monitored by ThrillTracker. The following functional requirements shall be provided/simulated:

1. A button for each ride monitored by ThrillTracker twill navigate to the Attraction data

screen for the associated attraction when activated.

2. A button which navigates back to the Admin Welcome Screen.

3. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.2.4 Individual Attraction Data Screen/Process

This function will provide the administrator with statistical data for the associated ride. The

following functional requirements shall be provided/simulated:

1. Name of the attraction.

2. Attraction data.

a. Number of ThrillPass patrons in line.

b. Number of non ThrillPass patrons in line.

c. Current wait time for each line.

d. Average wait time for each line.

e. Current number of patrons riding the attraction.

3. A button which navigates back to the Access Data by Attraction Screen.

4. A logout button, which when clicked, will navigate back to the initial Welcome screen.

In order to limit the scope of the prototype, historical data will be simulated.

1.1.4.1.2.5 Access Patron Data Screen/Process

This function will provide the administrator with the ability to retrieve a patron’s account

data. Patron data will be accessed by inputting either the user name or admission pass RFID tag

ID. The following functional requirements shall be provided/simulated:

1. A text box for user name input.

2. A text box for ID input.

3. A submit button.

4. A display of patron data.

a. User name and pass ID.

b. Last recorded location.

c. Itinerary.

5. A button which navigates back to Admin Welcome Screen.

6. A logout button, which when clicked, will navigate back to the initial Welcome screen.

1.1.4.1.2.6 Patron Account Admin Screen/Process

This function will provide the administrator with the ability to modify or delete a patron’s

account. A Patron account will be accessed by inputting either the user name or admission pass

RFID tag ID. The following functional requirements shall be provided/simulated:

1. A text box for user name input.

2. A text box for ID input.

3. A submit button.

4. A button which navigates back to Admin Welcome Screen.

5. A logout button, which when clicked, will navigate back to the initial Welcome screen.

If an invalid user name or pass ID is entered, an error message will be displayed. If a

valid user name or pass ID is entered, then a new screen will be displayed with the following:

6. A display of patron data.

a. User name and pass ID

7. A text box for the input of a new user name.

8. A submit button.

9. A delete patron button which deletes the associated account from the database.

10. A button which navigates back to the Patron Account Admin Screen.

If the user name is currently in use, an error message will be displayed requesting that the

administrator input a new user name. If an unused user name is input, the database will be

updated with the new user name. A message informing the administrator that the account setup

was successful will then be presented along with the patron account data and a continue button.

When the continue button is clicked, the Patron Account Admin Screen will presented.

1.1.5 Performance Requirements

The ThrillTracker prototype shall meet the following performance requirements:

1. The design of the database tables, database queries and GUI screen layouts should be

such that no single GUI screen takes longer than three seconds to load.

2. A ThrillPass itinerary will allow no more then six rides per day.

3. Each attraction will allow 15 time slots every 15 minutes.

4. Party size will be limited to a maximum ten patrons. A patron can only be a member of

one party at a time.

1.1.6 Non-Performance Requirements This section will define the non-functional requirements for the ThrillTracker prototype.

1.1.6.1 Security ThrillPass features will only be accessible to patrons who have purchased the premium

ThrillPass service upon park entry. The unique ID of the RFID tag embedded in the admission

pass will be entered into the database at the time of purchase.

Administrative features will not be delivered by the ThrillPass kiosk GUI. A valid

administrative username and password combination is required to access the administrative

features of ThrillTracker.

1.1.6.2 PrivacyThrillTracker will not collect or store personal information. Patrons will be warned not to

use personal information.

1.1.6.3 Maintainability The ThrillTracker system will require two levels of maintenance. The first level can be

covered by a single systems administrator who will be skilled enough to install update patches,

monitor the system and correct networking issues. The second level will require a person skilled

in repairing and replacing hardware present in the park environment.

1.1.6.4 ReliabilityThe effect of a ThrillTracker system failure is dependent upon the extent of the failure. The

ability of a patron to access an attraction must not be hindered by the ThrillTracker system. If a

critical component of the ThrillTracker system should experience a failure, ThrillTracker will not

be able to deliver the premium ThrillPass service or collect real-time data for the park. When

ThrillTracker recovers from the failure, the information contained in the database will refer to

the state of the system prior to the failure. Data collected around the time of a ThrillTracker

system failure should not be included when performing historical analysis because the data may

be inaccurate. If the ThrillPass service becomes unavailable during normal park operating hours,

the park will likely have to refund all or a portion of the ThrillPass purchase price.

Components critical to the operation of the ThrillTracker system are:

Database Server

ThrillTracker Application Server

RFID Server

Local Area Network

1.2 Proposed Activities to Transition Prototype to Product

Numerous activities will be performed during Phase 2 to transition the prototype into the

product. One of the most important of these activities will be communicating with the

amusement park to ensure that the product performs to their expectations. Interviews will need to

be conducted with representatives from the amusement park to ensure that ThrillTracker matches

the needs of the company. During this time, ThrillTracker staff will gather information about the

amusement park’s policies and procedures. In addition, the desired format of the historical and

real-time data gathering component of the ThrillTracker product will be defined. This shall allow

the ThrillTracker staff to understand how to update the prototype so that the product will fulfill

the amusement park’s expectations. This will require each component of the prototype to be

redesigned and developed.

In addition, security will need to be implemented in the product. As stated in the

Prototype Specification, the prototype does not utilize any type of security measures except for a

user name and password to login to the system. The product shall encrypt information that is sent

over the Internet and will encrypt the information stored in the database. The ThrillTracker

software shall be modified to address secure issues and errors.

1.3 Key Personnel Project Manager: This person is responsible for the coordination and completion of the

overall project and assign tasks to members of the team. The person in this role also sets

deadlines and monitors overall project progress.

Software Engineer: Plans, designs, develops, and debugs the software required for

ThrillTracker, Inc. Also responsible for support and modification of these software

applications.

Quality Assurance Engineer: Inspects the quality of code, software, and hardware modules

that are produced by ThrillTracker, Inc. Should be grounded in software design and initially

set up coding standards that will be used for the lift time of the project.

Web Developer: Responsible for development and maintenance of the ThrillTracker, Inc.

website and also responsible for production of web-based software solutions that are to be

used for the ThrillTracker product. Will work closely with the Database Special and

Software Engineers, as well as the GUI Developer.

Database Specialist: Responsible for creating preliminary database design, creation of DB's,

tables, defining data types within those tables. Creating flow charts for the flow of data and

data decomposition. Additionally, responsible for writing SQL code for database and table

access, and maintenance of the databases.

Technical Writer: Responsible for the creation of technical documentation of code modules

Also responsible for the creation of users manual and documentation for the ThrillTracker

product.

Network Engineer: Responsible for the development of network topology based upon the

target customer. Tests to ensure that communications between network devices are kept

secure, reliable, efficient and fast.

IT Specialist: Configures, installs, and maintains hardware and software for the team.

Performs software and hardware audits. Also helps deploy the final ThrillTracker product

and insures compatibility with any existing systems.

GUI Developer: Develops user-friendly, intuitive GUI designs that integrate well with

software modules developed by Software Engineers, and web pages developed by Web

Developers. Should keep a common theme between any GUI elements developed for web

deployment and kiosk deployment.

1.4 Facilities and Equipment

Item Part Number Quantity Price CostRFID Antennae Gates EnvisionWare 6 $2,000 $12,000RFID Writer GAOF5 2 $80 $160RFID Cards Mifare 1K 100 $0.70 $70Development Servers Dell 2950 5 $3,200 $16,000Application Servers Dell 2950 5 $3,200 $16,000RFID Kiosk Slab X2 3 $3,000 $9,000Routers Cisco 2611 5 $365 $1,825Notebook Workstations HP nx6325 11 $875 $9,625MS SQL Developer Toolkit 1 $50 $50MS Visual Studio Pro 4 $799 $3,196MS SQL 2005 5 $13,819 $69,095

RFID Antennae Gates- Several working RFID Antennae gates will be required to simulate attraction conditions and to determine strengths an weakness of the technology.

RFID Kiosk- Working kiosks will be required to simulate park conditions and to familiarize the team with the development environment and interface.

HP nx2611 Laptops – There will be 11 team members in phase 2, so naturally 11 workstations will be required. The systems will have Microsoft Windows XP Professional, Microsoft Office Microsoft Visual Studio Pro will be required for the development staff. Laptops were chosen for this phase due to their portability.

Dell PowerEdge 2950 – (Servers) the server will hold as our mock datacenter for initial testing. The server will be installed with Windows® Server 2003, Web Edition.

Cisco 2611 Routers –In phase 2 we will be developing and testing the functional prototype and we will need to simulate a large, stable network used to connect our RFID equipment, Kiosks and Servers together.

All software must be updated as new versions are released and as new hardware is purchased.