Post on 24-May-2015
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.