Lab 2 – Traffic Wizard Prototype Specification
Running Head: Lab 2 – Traffic Wizard Prototype Specification
Lab 2 – Traffic Wizard Prototype Product Specification
Traffic Wizard – Blue Team
Old Dominion University
CS 411 - Brunelle
Author: Andrew Crossman
Last Modified: March 8, 2012
Version: 2.0
1
Lab 2 – Traffic Wizard Prototype Specification
2
Table of Contents
1. Introduction ............................................................................................................................. 4
1.1. Purpose ............................................................................................................................. 5
1.2. Scope .............................................................................................................................. 10
1.3. Definitions and Acronyms ............................................................................................. 14
1.4. References ...................................................................................................................... 16
1.5. Overview ........................................................................................................................ 17
2. General Description ............................................................................................................... 17
2.1. Prototype Architecture Description ................................................................................ 17
2.2. Prototype Functional Description................................................................................... 19
2.3. External Interfaces.......................................................................................................... 21
2.3.1. Hardware Interfaces ......................................................................................................... 21
2.3.2. Software Interfaces ........................................................................................................... 22
2.3.3. User Interfaces .................................................................................................................. 22
2.3.4. Communication Protocols / Interfaces .......................................................................... 23
3. Specific Requirements ............................................................Error! Bookmark not defined.
3.1. Functional Requirements.................................................Error! Bookmark not defined.
3.1.1. Databases (Kennedy) .......................................................... Error! Bookmark not defined.
3.1.2. Algorithms ............................................................................ Error! Bookmark not defined.
3.1.3. Simulation Console (Crossman) ........................................ Error! Bookmark not defined.
3.1.4. GUI ........................................................................................ Error! Bookmark not defined.
3.2. Performance Requirements .............................................Error! Bookmark not defined.
3.2.1. Database Read/Write Speed (MacLeod) .......................... Error! Bookmark not defined.
3.2.2. Smartphone Resource Management (Godavarthi) .......... Error! Bookmark not defined.
3.2.3. Wireless Data Transmission/Fidelity (Dong) .................. Error! Bookmark not defined.
3.2.4. Algorithm Efficiency (McKnight) .................................... Error! Bookmark not defined.
3.2.5. Simulation Demonstration (Crossman) ............................ Error! Bookmark not defined.
3.3. Assumptions and Constraints ..........................................Error! Bookmark not defined.
3.4. Non-functional Requirements (Godavarthi)....................Error! Bookmark not defined.
3.4.1. Security (Godavarthi) ......................................................... Error! Bookmark not defined.
3.4.2. Maintainability (Godavarthi) ............................................. Error! Bookmark not defined.
3.4.3. Reliability (Godavarthi) ...................................................... Error! Bookmark not defined.
3.4.4. Server Uptime/Redundancy (Godvarthi) ......................... Error! Bookmark not defined.
Lab 2 – Traffic Wizard Prototype Specification
3
List of Figures
Figure 1: Traffic Wizard Update Process ....................................................................................... 7
Figure 2: Traffic Wizard Data Flow ............................................................................................... 9
Figure 3: Prototype Major Functional Components ..................................................................... 18
Figure 4: Checkpoint Data Exchange ........................................................................................... 20
Figure 5: Traffic Wizard Prototype App Site Map ....................................................................... 23
Figure 6: Driver Profile Database ERD ........................................... Error! Bookmark not defined.
Figure 7: Virtual Checkpoint Database ERD................................... Error! Bookmark not defined.
Figure 8: Speed Limit Database ERD .............................................. Error! Bookmark not defined.
Figure 9: Checkpoint Allocator Road Model................................... Error! Bookmark not defined.
Figure 10: Next Checkpoint Estimator Schematic........................... Error! Bookmark not defined.
Figure 11: Traffic Wizard Login and Main Screen ......................... Error! Bookmark not defined.
Figure 12: New Trip Menu Screens ................................................. Error! Bookmark not defined.
Figure 13: Route Tracer Screen ....................................................... Error! Bookmark not defined.
Figure 14: Current Trips Menu and Trip Details Screen ................. Error! Bookmark not defined.
Figure 15: End of Trip Screen ......................................................... Error! Bookmark not defined.
Figure 16: Delay Notification Screen .............................................. Error! Bookmark not defined.
Figure 17: Simulation Console Site Map ......................................... Error! Bookmark not defined.
Figure 18: Simulation Console Main Menu .................................... Error! Bookmark not defined.
Figure 19: Traffic Simulation Window............................................ Error! Bookmark not defined.
Figure 20: Simulation Dashboard Expanded ................................... Error! Bookmark not defined.
List of Tables
Table 1: Prototype Features Table ................................................................................................ 11
Table 2: Driver Profile Database .................................................................................................. 26
Table 3: Virtual Checkpoint Database .......................................................................................... 27
Table 4: Speed Limit Database ..................................................................................................... 29
Table 5: Assumptions and Constraints ......................................................................................... 61
Lab 2 – Traffic Wizard Prototype Specification
1.
4
Introduction
What could easily be considered as one of the world’s most inconvenient societal
problems is that of heavy traffic in high population areas. In regions where population growth
exceeds the road capacity, traffic flow often becomes congested, which delays many drivers on
the way to their respective destinations. Americans suffer 4.8 billion hours of excess commute
time every year while 1.9 billion gallons of excess fuel is consumed while waiting in traffic
(Texas Transportation Institute, 2011). These costs tend to be incurred the most in very largely
populated areas when the data is grouped and analyzed. The amount of traffic on the road is a
time-sensitive statistic, which makes it difficult to accurately predict what traffic conditions will
be like as a driver travels a specific route. There are many factors involved in the way we
currently handle heavy traffic avoidance, each with their own liabilities.
Current methods for determining if heavy traffic lies ahead are not reliable enough to be
considered effective. Visual cues are too dependent on environmental factors and are not timely
enough to be considered practical in avoiding traffic. Information on traffic conditions through
the media, traffic cameras, or a friend is simply not timely enough to be accurate and cannot
always be accessed easily. GPS devices sometimes have a traffic monitoring feature, but these
devices are prone to connectivity issues and errors when their software becomes outdated.
Current mobile apps are a source of distraction and are known to promptly deplete a user’s
battery level and put a burden on their network data usage. These risks with smartphone apps
need to be mitigated through a means that puts less strain on a user’s smartphone battery and
minimizes the amount of data usage needed, but still provide timely traffic information.
Traffic Wizard is a personalized smartphone app solution to help inform drivers of traffic
conditions in real-time before and during their trip. The app will feature travel profiles that let
Lab 2 – Traffic Wizard Prototype Specification
5
drivers store their most frequent routes and set times for their route to be analyzed by the server
prior to travel time. By advising alternate routes during a trip to avoid unfavorable traffic
congestion, Traffic Wizard will reduce the amount of delay that a driver encounters on their trip.
1.1.
Purpose
The goal of Traffic Wizard is to inform drivers of poor traffic conditions in real-time,
meaning the information can be utilized in a timely enough manner for a driver to take an
alternate route if they wish. Each registered user has their own driver profile that they can use to
keep track of their most frequently travelled routes. These routes will have the capability to be
manually entered by a user, or traced when a user drives to be stored on their phone. Through
their driver profile, users can select a route (such as their drive from work to home) to be
analyzed by the Traffic Wizard server at a slightly earlier time prior to the expected travel time.
This allows the user to get a quick idea of what the current traffic conditions are before they go
to drive the route.
The foundation of the Traffic Wizard user base will be drivers with smartphones who live
in high population areas, since they are the ones most likely to experience traffic congestion.
Areas with the largest population sizes tend to suffer the most significiant costs from traffic
congestion. Very large population areas incur the highest aggregate cost, most hours delayed,
and highest amount of fuel excess out of various population sizes ranging from large to small
(Texas Transportation Institute, 2011). While the app will be accessible to drivers all over the
United States, these more densely populated areas are the expected focus for Traffic Wizard
operational activity. Users who live in these regions are recognized as having the largest
potential to benefit from the Traffic Wizard system of updates.
Lab 2 – Traffic Wizard Prototype Specification
6
The other main factor for determining the Traffic Wizard customer base is the
accessibility of the software app. Only drivers who have access to a smartphone that runs an
Android or iOS operating system will be able to download and use Traffic Wizard. While this
may seem like a limiting factor in defining the scale of the customer base, studies have shown
that smartphones are rapidly gaining popularity each year. With research proving that
smartphones powered by Android and iOS operating systems are on the rise (Email Marketing
Reports, 2011), the Traffic Wizard app can be released on this market with confidence and
guaranteed accessibility.
Another prospective user base for gathering useful information for traffic patterns are
commercial group vehicles, such as shipping vans. If a device running the Traffic Wizard
software is present in a commercial vehicle, then any delays encountered can be assessed for
statistics useful for determining traffic patterns at different times of the day or specific days of
the year. These findings can be very beneficial in saving time and money for a business willing
to incorporate the Traffic Wizard system.
The main feature of Traffic Wizard is the service of delivering real-time traffic updates to
drivers within a specific geographic proximity. For this information to be assessed and delivered
effectively, an innovative data collection system is used called the Virtual Checkpoint System.
Using this system for mining traffic data from all phones on the road, the Traffic Wizard server
can receive and analyze incoming data, which includes latitude and longitude coordinates,
current speed, and heading. The server then returns information on the traffic status in real-time
to other devices that request the updates. Data exchange that occurs between the driver’s app and
the server triggers the analysis of upcoming roads, as seen in Figure 1. The added feature of a
driver profile allows users to have their saved routes analyzed in an efficient manner.
Lab 2 – Traffic Wizard Prototype Specification
7
Figure 1: Traffic Wizard Update Process
Virtual checkpoints are simulated entities that are associated with specific latitude and
longitude coordinates and are strategically placed along roads. Each checkpoint is noted with a
color-coded traffic status as well to represent the traffic conditions in that area. A green traffic
status would notate that there is little to no congestion causing delay at that road segment, while
a red status would indicate that traffic is very congested or halted in that area. These virtual GPS
locations act as flags for the Traffic Wizard app to upload travel data for the driver and download
necessary updates for upcoming roads as determined by the server. This travel data includes their
location (the checkpoint they are passing), speed, and heading. Since virtual checkpoints have
the functionality of roadside nodes and the benefit of being digitally defined, checkpoints can be
Lab 2 – Traffic Wizard Prototype Specification
8
reallocated on demand for special traffic conditions. Checkpoints could be allocated within a
small area to help determine blockages, or could be moved around on a larger scale during times
like rush hour to assist in bringing more accurate updates to users.
Data exchange is set to occur when a driver’s current GPS location matches the
coordinates of a known virtual checkpoint. The app sends the information to the server and
receives updates to the status of upcoming checkpoints if that status has changed since the last
update. If checkpoints along the remainder of a driver’s route have a new traffic status,
indicating that traffic conditions have changed there, the app will display the new status once it
receives this update from the server. This feature of Traffic Wizard makes an effort to reduce the
typical drain on a user’s data usage and battery life by using a caching system for the
checkpoints along a user’s route. When a driver selects a route to be driven, the app performs an
initial download of the list of checkpoints that occur on that route and any immediate alternative
routes. With these coordinates downloaded, the app can do GPS comparisons locally to
determine when it has passed a checkpoint, as opposed to always polling the server for the next
location to send the travel data. The app will have the option to turn off the GPS entirely if
determines that the time until the next checkpoint is a longer duration.
[Space intentionally left blank.]
Lab 2 – Traffic Wizard Prototype Specification
9
Figure 2: Traffic Wizard Data Flow
Through this efficient method of data exchange, useful information for traffic analysis is
uploaded to the Traffic Wizard server. When the server receives this metadata, it runs a set of
algorithms on the travel information to determine if traffic flow is optimal at that checkpoint or if
there is any congestion to identify. The output from these algorithms can return that the multiple
speeds being uploaded at a specific checkpoint are all below the known speed limit, which would
indicate that traffic is becoming increasingly congested in that area. Proper speed limits are
determined through a speed limit database that is used to reference public information on posted
speed limits for every road. The checkpoint that is associated with that status may be labeled as
yellow to indicate the level of congestion. This system of using real-time travel data as it is being
uploaded to properly analyze traffic conditions is an effective means of providing timely and
accurate predictions on traffic.
Lab 2 – Traffic Wizard Prototype Specification
10
Every user of Traffic Wizard is given a customizable driver profile – where they can save
their favorite or most frequent routes for easy accessibility. Users are able to select a route and
add the time periods that they typically have to drive that route or just enter the time they know
they will be traveling that route next. By doing this, the app can send a request to the server with
the preprogrammed route to download and cache a list of checkpoints for the route in advance.
This assists in keeping data usage at a minimum for the user’s device and provides a quick way
to know what the upcoming traffic status will be like for a regular trip.
Some traffic-monitoring features and guarantees will not be available through the Traffic
Wizard system. Drivers who use the app are not guaranteed to see a decrease in delay for their
trip since there are other factors that determine when a driver gets delayed on their trip. It is also
not guaranteed that real-time traffic information will be available to drivers in certain areas
depending on the number of Traffic Wizard users who drive that route. Traffic Wizard is not a
utility that promises to prevent traffic congestion, but instead offers assistance in helping drivers
reduce the delay they experience in their normal trip. Another limitation to Traffic Wizard
information is that when a blockage is found during traffic analysis, that blockage cannot be fully
identified as an accident, construction, or other event. Only the fact that a blockage exists and is
delaying traffic is told to the user when this occurs. Other features not implemented in Traffic
Wizard include detection of emergency response vehicles on the road and turn-by-turn directions
to a destination.
1.2.
Scope
Traffic Wizard, as a final product, will cover large geographic areas across the country
and focus on metropolitan areas with higher population densities. This will ultimately be
accomplished through Traffic Wizard regional centers for the necessary servers to cover these
Lab 2 – Traffic Wizard Prototype Specification
11
regions. As a prototype, the scope of Traffic Wizard must be decreased to accommodate testing
and demonstrating the system on a smaller scale. The geographical area covered, driver data
being used, driver profile routes, and server processes will all be affected by the reduced scope of
the prototype. By demonstrating the Traffic Wizard systems on a smaller scale, and proving that
the system is efficiently scalable, the innovative concepts of this system can be proven as
effective. The various features of the Traffic Wizard prototype can be observed in Table 1.
Features
Data Miner
Final Product
Prototype
It will retrieve real-time travel
information from drivers using the
app.
Simulated driver metadata to
use in analysis.
Login
Allows user entry of authentication
credentials.
Restricted to specific test users.
New User
Allows a user to create an account
and select a membership.
Not implemented because of
scope.
Settings
Allows user to alter application
settings and options.
Not implemented because of
scope.
Trip Editing
Allows user to specify a new route to
be saved or modify an existing route.
Restricted to limited test area.
Route Tracer
Program function to track a route to
be saved as it is driven by the user.
Not implemented because of
scope.
Travel Map
Non-interactive screen that displays
current traffic conditions while
driving.
This is implemented.
End of Trip
Presents statistics about last trip and
any appropriate options to edit the
stored route.
This is implemented.
Not implemented in Final Product.
Demonstration interface for
simulated driving scenarios.
Associates GPS coordinates along
roads with checkpoints.
Simulated coordinates for handselected checkpoints.
Recognizes drivers passing GPS
location (checkpoint) as an event.
Upload user velocity at checkpoint
being passed / Download necessary
traffic updates for checkpoints along
the route.
This is implemented on
simulated checkpoints.
Traffic Conditions
GUI
Simulation Console
Virtual Checkpoints
GPS
Latitude/Longitude
Coordinates
Driver
Acknowledgement
Data Exchange
This is implemented on
simulated checkpoints.
Lab 2 – Traffic Wizard Prototype Specification
Features
Database
12
Final Product
Prototype
Driver Profile
Database
Stores customer account
information, credentials, and
payment method.
This is implemented with test
users.
Virtual Checkpoint
Database
Stores checkpoint coordinates,
current traffic status, and historical
statistics.
This is implemented with
simulated checkpoints.
Stores static information on speed
limits for public access.
This is implemented.
Speed Aggregator
Analyzes and filters driver inputs to
determine current traffic speed.
This is implemented.
Checkpoint
Allocator
Initial assignment of GPS coordinates
to initialize checkpoints.
Not implemented because of
scope.
Checkpoint
Reallocator
Redistribution of checkpoints along
roads as determined by current
checkpoint statuses and historical
patterns.
Only implemented on specific
driving scenarios.
Route Analyzer
Calculate delays, outputs alternate
route suggestions
This is implemented.
Next Checkpoint
Estimator
Estimates time to arrival at next
checkpoint from client side for
GPS/Data/Battery management.
This is implemented.
Route Matcher
Determines the closest Virtual
Checkpoint or set of checkpoints to a
given GPS coordinate or set of
coordinates.
This is implemented.
Blockage Finder
Determines points on roads where
traffic flow is completely blocked.
This is implemented.
Not implemented in Final Product.
Randomly generates virtual
drivers with speeds for testing
purposes.
Speed Limit
Database
Algorithms
Driver Generator
Table 1: Prototype Features Table
The geographical scope will be reduced to cover areas within Hampton Roads, Virginia.
Since the development team (Team Blue) for Traffic Wizard is localized in Norfolk, Virginia at
Old Dominion University, the starting region will be the university and surrounding roads. A full
set of the geographic regions to be used in the prototype are outlined in Section 3.1.3.1. Old
Dominion University is being used as the smallest region, with larger areas in Norfolk and
Portsmouth being used for the medium and largest regions of the demonstration. In the larger
Lab 2 – Traffic Wizard Prototype Specification
13
regions, highway corridors and interstates will be the focus to determine how the Traffic Wizard
system handles traffic updates in that situation.
Data being used by the server to produce traffic statuses will be simulated information in
the prototype. Since the final product relies on real-time information being uploaded from drivers
using the app, the prototype will be unable to benefit from this stream of data. A specialized
Driver Generator algorithm (Section 3.1.2.8.) will be used to simulate the event of a driver
entering the region being monitored during the demonstration. The simulated data will be
derived from real world coordinates obtained by Team Blue members using the Traffic Wizard
Route Tracer feature to gather coordinates and speeds for various routes. This data will not be
used directly in the simulation, but will act as a foundation for calculations in determining the
rate of traffic flow.
Since the demonstration of Traffic Wizard’s systems will be a simulation, the data will be
exchanged in a time-stepping manner. As the simulation time advances to represent real time,
data will be exchanged between virtual driver entities in the simulation and the server based on a
virtual clock. Events such as new drivers entering the region or reaching their destination are
based on simulation time that must be incremented as the simulation runs. With supported
animation in the Simulation Console (Section 3.1.3.), this process will make the movement of
virtual drivers and data exchange seem as though it is occurring at real-time, which the final
product will do.
Lab 2 – Traffic Wizard Prototype Specification
1.3.
14
Definitions and Acronyms
Alpha Testing – First testing phase for Traffic Wizard that will be available to select institutions
(closed access) for a duration of 30 days.
Beta Testing – Second testing phase for Traffic Wizard that will be available to the public (open
access) as a demo for a duration of 90 days.
Blockage Finder – The server algorithm that determines if a blockage exists that is slowing or
stopping traffic flow.
Checkpoint Allocator – The server algorithm that associates virtual checkpoints to their initial
latitude and longitude coordinates for a specific region.
Checkpoint Re-allocator – The server algorithm that continuously adds and removes virtual
checkpoints from the Virtual Checkpoint Database to improve accuracy and performance
when evaluating traffic conditions.
Custom Route – Any user-entered route (start and end location) that is saved to the phone to be
driven later.
Driver Generator – The Simulation Console component that is responsible for creating and
handling virtual driver entities during prototype simulation demonstrations.
Driver Profile – App feature that allows users to store their most frequent (or favorite) routes that
they travel to be saved on their device. Stored routes can be pre-analyzed by the server.
Driver Profile Database – The Traffic Wizard secure database that contains login information
and payment details for users that have purchased the app.
Google Maps API – Web mapping service provided by Google that is utilized by Traffic Wizard
for route analysis.
Lab 2 – Traffic Wizard Prototype Specification
15
Incidental Traffic Congestion – Traffic congestion caused by an unexpected event such as an
accident or emergency situation.
Next Checkpoint Estimator – The client app algorithm that uses the list of known virtual
checkpoints along a route to estimate when the next virtual checkpoint will be passed.
Periodic Traffic Congestion – Traffic congestion due to the patterned rise and fall in volume of
cars travelling on a road at predictable times (such as rush hour).
Pre-travel Analysis – Route analysis report that is computed by the Traffic Wizard server prior to
the time that the user expects to drive that route.
Road Segment – Any defined, unbroken partition of road that lies between intersections to be
used in assembling custom routes.
Route – Particular set of road segments that a user drives to reach their destination.
Route Analyzer – Main app feature and server algorithm that focuses on the route that a user is
currently driving on to be analyzed for traffic status and report to the user (and make
alternate route suggestions if applicable).
Route Matcher – The server algorithm that determines the closest virtual checkpoint to a given
set of GPS coordinates in order to define the route being driven.
Simulation Console – Application developed during prototype stage to be used as a
demonstration platform for Traffic Wizard. This platform will hold data for multiple
driving scenarios to be called for demonstration.
Speed Aggregator – The server algorithm that accepts raw driver speed data and calculates
weighted averages per virtual checkpoint.
Speed Limit Database – The database that will be referenced by the server when determining the
appropriate speed for drivers to be travelling at on a given road.
Lab 2 – Traffic Wizard Prototype Specification
16
Traffic Scenario – A representation of a set of realistic and unique traffic conditions to be used in
the Simulation Console demonstrations.
Traffic Wizard – Traffic-monitoring smartphone app and server system developed by the CS 411
Blue Team.
Trip – A specific instance of travel along a user’s custom route.
Virtual Checkpoints – Traffic Wizard system for labeling specific latitude and longitude
coordinates along roads to act as representations the traffic status in that area and as flags
to trigger data exchange for drivers.
Virtual Checkpoint Database – The database that holds metadata (ID, latitude and longitude
coordinates, and traffic status) on all virtual checkpoints being used in traffic monitoring
and analysis.
Virtual Driver – Entities used in the Simulation Console demonstrations that simulate real-world
drivers using preset routes and destinations.
1.4.
References
Lab 1 – Crossman, Andrew – Traffic Wizard Product Description. CS 411. Spring 2012.
Brownlow, M. (September 2011). Smartphone Statistics and Market Share. Email Marketing
Reports. Retrieved from http://www.emailmarketing-reports.com/wirelessmobile/smartphonestatistics.htm
Lomax, T., & Schrank, D., & Turner, S. (2011). Annual Urban Mobility Report. Texas
Transportation Institute. Retrieved from http://mobility.tamu.edu/ums/
Schroeder, S. (May 19, 2011). Smartphone Sales Up 85% Year-Over-Year. Mashable Tech.
Retrieved from http://mashable.com/2011/05/19/smartphone-sales-q1-2011-gartner/
Lab 2 – Traffic Wizard Prototype Specification
1.5.
17
Overview (8 lines)
Specific requirements for the Traffic Wizard prototype are outlined in this document to
provide a foundation for building the various components involved in the system. Specifications
for the Traffic Wizard prototype include functional, non-functional, and performance
requirements. These requirements define how the prototype system should operate within the
assumptions and constraints as defined in Section 3.3. The purpose of this document is to guide a
programmer who is assigned to build certain components of the Traffic Wizard prototype with
exact requirements for each part of the system. The information in Sections 2 and 3 can be
utilized to create the full prototype as designed by Team Blue.
2.
General Description
The Traffic Wizard system offers features that require cooperation among software and
hardware components in order to bring timely information to end users. In order to do this, the
prototype must put the planned concepts and designs to be tested against simulated data to prove
that the system works. Operation of these various components requires specific functionality in
order to accomplish these features, such as smartphone app stability and server algorithm
efficiency. This section describes how the prototype system for Traffic Wizard will be designed
to prove the defined concepts.
2.1.
Prototype Architecture Description
The major functional components of the Traffic Wizard prototype are shown in Figure 3.
The prototype system is comprised of two main divisions – the client-side smartphone app and
the server, which will reside on a virtual machine and consist of software to run algorithms and
the prototype Traffic Wizard databases. The client app for the prototype will have all the
functional GUI components described in the Prototype Features Table (Table 1) in Section 3.3 to
Lab 2 – Traffic Wizard Prototype Specification
18
be used in the simulation. The app will take server output as though the app were being used
during a trip and display the appropriate information to inform of traffic conditions on the
created checkpoints. The prototype server will be responsible for generating dynamic drivers
virtually with specific parameters to match the real world input from drivers. Using these data
sets, which are modeled according to the various scenarios, the server parses the data and runs
the necessary algorithms to return a traffic status for the data’s associated virtual checkpoint.
Figure 3: Prototype Major Functional Components
The simulated data that the server generates to represent drivers on the road is passed
through the appropriate algorithms and stored in the virtual checkpoint database. The virtual
checkpoint database in the prototype holds a subset of the data that the full real world product
database would hold. Each virtual checkpoint’s designated coordinates are stored within the
database, along with a determined traffic status. These resulting traffic statuses can be viewed in
the simulation at the coordinates where that virtual checkpoint is located. The prototype will
Lab 2 – Traffic Wizard Prototype Specification
19
feature a scaled-down version of the driver profile database as well by allowing a user to create a
profile and start adding routes. Their profile is stored on the database as a registered user. To run
the Traffic Wizard algorithms, a reference to a public speed limit database will also be used
when the algorithm needs to determine the proper speed limit of certain roads during analysis.
The Traffic Wizard virtual machine server will require some software packages to become
functional and work with the other components of the system. This mainly consists of Apache,
MySQL, and PHP MyAdmin.
2.2.
Prototype Functional Description
The prototype of the Traffic Wizard system involves three main components: the
smartphone app, server, and Simulation Console. The Traffic Wizard prototype app, while not
available for public users to download and experience, will be designed to support most of the
functionality of the final product app. Along with transitioning GUI menus properly, the app
must be stable enough during operation to not terminate due to a software bug.
The prototype server will contain most of the elements that the final product server will,
but on a reduced scale to handle the simulated driver data that is being used. This server will still
have a Driver Profile Database and Virtual Checkpoint Database to be used in the simulations.
The prototype versions of driver profiles will still support creating and editing custom routes
along with setting pre-analysis times for the route by the server. These profiles will be manually
created templates for information and will not be actual user profiles as expected in the final
product.
Virtual checkpoints used in the prototype will still function as they would in the final
product. Instead of having a virtual checkpoint’s GPS location compared to an actual driver’s
coordinates, it would be compared with a simulated set of coordinates for a virtual driver. This
Lab 2 – Traffic Wizard Prototype Specification
20
data should not differ between the two scopes, so the checkpoints can be used as designed for the
final product. Virtual checkpoints used in the prototype act as agents for sending virtual driver
data (speed and heading) to the server to be processed and have resulting traffic updates sent
back to the virtual driver. This process of exchanging data can be observed in Figure 4.
Figure 4: Checkpoint Data Exchange
The most physical part of the Traffic Wizard prototype is the communication between a
smartphone running the app and the Traffic Wizard server. Since a prototype app will be
developed for deployment on a mobile device, that app will have capabilities to send information
to the Traffic Wizard server when necessary. In the prototype, the only information that will be
sent from the device is a list of GPS coordinates that were polled on the device using its own
GPS functionality. This is to prove the information can be sent to the server from the Traffic
Lab 2 – Traffic Wizard Prototype Specification
21
Wizard app, and not to demonstrate how the app will be utilized in the real world product. Since
the prototype will not be available to be driven around, the data sent from a device running the
prototype app will not be in the standard format for the data packet (checkpoint ID, speed, and
heading).
The platform used to implement these features and demonstrate the prototype is the
Simulation Console. This system will have the means to generate virtual drivers using a Driver
Generator and display a simulation of the traffic monitoring process based on a selected traffic
scenario and region size (Section 3.1.3.) The Simulation Console will need to interact with the
server in order to call necessary algorithms for the simulation being executed. Simulations will
need to be executed in a timely enough manner, including all calls to the server for computations,
to accurately represent real-time traffic conditions.
2.3.
External Interfaces
This section outlines the physical and logical interfaces used within the Traffic Wizard
prototype. This includes hardware, software, and user interfaces, as well as the communication
protocols involved. Interfaces for the client app and server will be described, as well as the
prototype-exclusive Simulation Console.
2.3.1. Hardware Interfaces
The Traffic Wizard prototype consists of only a few hardware interfaces. Since a
prototype smartphone app is being developed, the smartphone (Android and iOS) is the main
hardware interface. A 3G Internet connection module and GPS module are integrated into
smartphone hardware and will both be utilized in the prototype. As for the prototype simulations
of the system, an Old Dominion University laptop will be running the Simulation Console
(Section 3.1.3.) while a virtual machine hosted by the ODU Computer Science department will
Lab 2 – Traffic Wizard Prototype Specification
22
act as the Traffic Wizard server. These are the only hardware interfaces involved in the Traffic
Wizard prototype.
2.3.2. Software Interfaces
Team Blue administrators will interface with the server and MySQL database using SQL
queries and PHP scripts. Using PHP, results from the database can be formatted accordingly
depending on what server component has called for the information. Server applications will be
built in Java and Perl in order to run algorithms and interface with server operations. The
Simulation Console interface, used for demonstrating the Traffic Wizard prototype, will be built
using the .NET 4.0 platform and will contain functionality for displaying demonstrations and
changing parameters for simulations.
2.3.3. User Interfaces
The only user interface involved in the Traffic Wizard prototype is for the smartphone
app. This prototype app will contain the GUI screens as outlined in Section 3.1.4.1. This
interface is not meant for public use but instead acts as a proof-of-concept for specific Traffic
Wizard features, such as driver profiles and the Route Tracer utility. The site map for the
prototype app is displayed in Figure 6.
[Space intentionally left blank.]
Lab 2 – Traffic Wizard Prototype Specification
23
Figure 5: Traffic Wizard Prototype App Site Map
Functionality of the smartphone user interface will be limited for demonstration purposes.
The Login screen will not support actual user credentials, since there will not be any real Traffic
Wizard users to authenticate for this process. Test information will be used to authenticate a user
and create a driver profile to be stored on the Driver Profile Database (Section 3.1.1.1.). Route
creation and editing will be supported, as well as the Route Tracer utility, which will utilize the
smartphone GPS system to record the latitude and longitude coordinates of the device.
2.3.4. Communication Protocols / Interfaces
Two main protocols are used in Traffic Wizard server operations, Transmission Control
Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol (UDP). TCP/IP will be used by
the Simulation Console to establish a connection with the Traffic Wizard server on the Old
Dominion University network to be used as necessary during simulations. UDP will be used by
the smartphone app to demonstrate pushing driver data (location, speed, and heading) to the
server without the need to establish and acknowledge a connection.