Lab 1 – Traffic Wizard Description
Traffic Wizard - 1
Running Head: Lab 1 – Traffic Wizard Description
Lab 1 – Traffic Wizard Product Description
Traffic Wizard – Blue Team
Old Dominion University
CS 411 - Brunelle
Author: Andrew Crossman
Last Modified: February 25, 2012
Version: 3.0
Lab 1 – Traffic Wizard Description
Traffic Wizard - 2
Table of Contents
1.
Introduction ........................................................................................................................................... 3
2.
Traffic Wizard Product Description ...................................................................................................... 4
3.
2.1.
Key Product Features and Capabilities ......................................................................................... 4
2.2.
Major Components........................................................................................................................ 8
2.3.
Target Market / Customer Base .................................................................................................. 10
Traffic Wizard Product Prototype Description ................................................................................... 12
3.1.
Prototype Functional Goals and Objectives ................................................................................ 12
3.2.
Prototype Architecture ................................................................................................................ 14
3.3.
Prototype Features and Capabilities ............................................................................................ 16
3.4.
Prototype Development Challenges ............................................................................................ 20
4.
Glossary .............................................................................................................................................. 22
5.
References ........................................................................................................................................... 25
List of Figures
Figure 1: Traffic Wizard Update Process ..................................................................................................... 5
Figure 2: Traffic Wizard Data Flow ............................................................................................................. 7
Figure 3: Traffic Wizard Major Functional Components ............................................................................. 9
Figure 4: Prototype Major Functional Components ................................................................................... 15
List of Tables
Table 1: Prototype Features Table .............................................................................................................. 19
Lab 1 – Traffic Wizard Description
Traffic Wizard - 3
1. 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 1 – Traffic Wizard Description
Traffic Wizard - 4
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.
2. Traffic Wizard Product Description
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 onto a phone by a user, or traced when a user drives their route. 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.
2.1.Key Product Features and Capabilities
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 1 – Traffic Wizard Description
Traffic Wizard - 5
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 1 – Traffic Wizard Description
Traffic Wizard - 6
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 1 – Traffic Wizard Description
Traffic Wizard - 7
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 is an effective means of providing timely and accurate predictions on traffic.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 8
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.
2.2.Major Components
Figure 3 illustrates the major functional components of the Traffic Wizard app and server
and the interaction between them. All user interaction will be with a smartphone app, while all of
the route analysis and majority of computations will occur on the server. The driver profile
feature, route pre-weighting system, and map interface will reside on the downloaded app. The
app also uses a caching and identification system for virtual checkpoints as it prepares to be used
along a route. The regional servers will contain the processes that resolve traffic statuses from
uploaded travel data as a set of algorithms and will also hold the databases for necessary mass
storage.
[Space intentionally left blank]
Lab 1 – Traffic Wizard Description
Traffic Wizard - 9
Figure 3: Traffic Wizard Major Functional Components
Drivers who use the Traffic Wizard app while driving will experience a minimalistic
interface during their drive to mitigate the risk of being a distraction to the driver. This
specialized interface will still be functional and useable to allow the driver to learn of current
traffic conditions with ease. When a user utilizes the Route Pre-Weighting System to pre-analyze
their trip, an initial traffic status is determined by the server and sent to the app along with a list
of coordinates for checkpoints expected to be along the planned route. This list of checkpoint
coordinates is cached to the device to be used when the driver begins their trip. This allows the
app to be prepared for when the user begins their drive and can begin locally comparing GPS
coordinates to determine when to upload travel information to the server.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 10
The server side of the Traffic Wizard system handles all processing of uploaded travel
data and manages driver profiles and defined virtual checkpoints. A specialized set of algorithms
is utilized to aggregate the travel information coming in and compute resulting traffic conditions
for involved virtual checkpoint locations. In addition to assessing traffic for delay, other
algorithms will be used for special cases, such as determining when a blockage has occurred in
the road or when checkpoints need to be reallocated due to some cause. The output from this set
of algorithms is converted into a more definitive traffic status for road segments to be sent back
to the user to inform them of conditions on the route ahead.
Two distinct databases will be used in Traffic Wizard operations, along with a reference
to a public speed limit database. A virtual checkpoint database is used to store the GPS location
(a set of latitude and longitude coordinates on a road segment) and traffic conditions at each
checkpoint. When travel information arrives at the server, the data is parsed by the server while
important traffic information (such as the average speed at a particular checkpoint) is stored with
its associated checkpoint. This database is heavily utilized in route analysis operations since the
information within has to be updated to maintain real-time effectiveness. A reference to a public
speed limit database will also be necessary to determine what the optimal speeds are on each
road being analyzed.
2.3.Target Market / Customer Base
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 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
Lab 1 – Traffic Wizard Description
Traffic Wizard - 11
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.
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. Figure 5 compares the market for the
main smartphone operating systems for the beginning of 2010 and 2011.
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 certainty 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.
[Space intentionally left blank]
Lab 1 – Traffic Wizard Description
Traffic Wizard - 12
3. Traffic Wizard Product Prototype Description
The Traffic Wizard system is purposed at saving the driver time on their typical trip,
which means the data being used to inform them must be accurate and as real-time as possible.
For this reason, the system must be tested with a prototype to ensure that the data exchange
process is effective and works as designed. The prototype of Traffic Wizard will consist of a set
of simulations to represent realistic traffic scenarios through a main simulation console. These
simulations will be able to demonstrate how the virtual checkpoint and data exchange systems
would operate in various use cases. Fake driver entities will need to be created to act as vessels
to trigger events for data exchange and will use real world data for latitude and longitude
coordinates for the area being represented. These simulations will show how the system will
perform over time in both short term and long term. The prototype will prove short term benefits
through demonstrating that a driver entity can avoid heavy with an alternate suggested route and
save a few minutes in reaching their destination. Long term benefits can be assessed when a big
picture demonstration is performed where a majority percentage of users on the road are using
Traffic Wizard and learning about traffic conditions on their route ahead of time. Ultimately, this
reduces the number of drivers participating in existing traffic congestion.
3.1.Prototype Functional Goals and Objectives
The goal of the prototype is to demonstrate that the major components of Traffic Wizard
are feasible and effective. Through a predefined set of traffic scenarios, the system will run a
simulation that most accurately represents the typical traffic conditions for each scenario. For
example, rush hour traffic conditions can be simulated by issuing a high volume of driver entities
on most roadways which often results in traffic congestion at specific points. This scenario
would demonstrate how virtual checkpoints could be labeled for very slow traffic at those
Lab 1 – Traffic Wizard Description
Traffic Wizard - 13
locations or traffic moving at suboptimal speeds. Each simulation will run over a period of
simulated time to represent the situations in the most realistic manner possible.
The areas used in demonstration will be reduced in scope by limiting the geographical
area covered. For the prototype simulations, these locales will be chosen specifically by the Blue
Team. The reduced scope is to simplify understanding how the system components interwork
with each other without the complexity of a vast area being displayed for the same purpose.
Areas chosen will range from a small scale area, such as the roads around Old Dominion
University in Norfolk, VA to larger scale areas that show Hampton Roads arteries such as I-64.
Usability of the Traffic Wizard app must be demonstrated as well to prove that the
software is beneficial to the user. Proving this will rely on two factors – demonstrating that
interaction with the app will cause minimal distraction and showing that the app is easy is
understand and use. A prototype graphical user interface will be shown to confirm these claims.
Auditory declarations of traffic updates will be utilized to reduce the amount of interaction the
driver experiences with their device during travel. An organized and easily understood mapping
of menu screens will prove to allow a user to access all features of Traffic Wizard available to
them without difficulty.
When the various simulations are run, the server uses the simulated driver data to run the
algorithms and produce a resulting traffic status for each checkpoint involved. Since multiple
drivers will be passing checkpoints at distinct times throughout an area, the server must be able
to handle an increased load of drivers sending data and requesting updates. Optimizing the load
on the server is a critical step in ensuring scalability of the Traffic Wizard server and must be
demonstrated in the prototype. By efficiently parsing and accepting useful traffic data that is
Lab 1 – Traffic Wizard Description
Traffic Wizard - 14
passed to the algorithms, the server load can be reduced to avoid potentially overloading it with
data packet requests.
Various factors will be combined to create a number of traffic scenarios to be
demonstrated in the prototype. Generic characteristics of traffic conditions can be identified and
joined with other generalities to create a unique traffic condition. High or low volume is one
attribute of traffic, while knowing a road segment is obstructed or not is another general
attribute. A slight amount of traffic congestion can occur when there is a low volume of traffic or
no congestion at all. Even with a high volume of traffic, different roads are more accommodating
for the increased amount of cars and may have little congestion while other roads may act as a
bottleneck and result in heavy traffic congestion. These differing attributes are matched to make
combinations to be used in the prototype demonstration.
3.2.Prototype Architecture
The major functional components of the Traffic Wizard prototype are shown in Figure 7.
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 (Figure 8) in Section 3.3
to 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.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 15
Figure 4: 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 will hold a subset of the data that the full real world product
database would hold. Each virtual checkpoint’s designated coordinates will be 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
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.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 16
3.3.Prototype Features and Capabilities
The main capability of the Traffic Wizard prototype will be to demonstrate the data
exchange process between each virtually-created driver and the server. At each event where a
simulated driver’s GPS coordinates match those of a specific virtual checkpoint, a packet will be
sent to the server with the speed and heading of the car, as well as the ID of the checkpoint
passed. The server takes this information and runs it through the appropriate algorithms before
storing information in the database. Each of the Traffic Wizard algorithms are used, but are
scaled-down versions of the real world product’s algorithms. This scaling down is due to the
reduction in scope for the prototype demonstration in terms of geographical area covered and
travel data being sent to the server. These algorithms produce a resulting traffic status to
associate with the checkpoint, which is stored in the virtual checkpoint database. In the real
world product, the data that gets stored with a checkpoint in the database is available for
download by any drivers traveling a route that uses that same checkpoint. It is this way that other
drivers can be receiving real-time updates for traffic at the upcoming GPS coordinates on their
route.
The data that is contained in the packet sent by a simulated driver to the server contains
an ID for a virtual checkpoint, a current speed, and a determined heading to be used in the
various algorithms that belong to the Traffic Wizard system. Formulas involved can aggregate
incoming speeds into a more defined speed of traffic and determine if the data coming in
indicates that there may be a blockage on the road. In a scenario where there may exist a
blockage on the road that halts traffic, there needs to be an algorithm that can discover that the
blockage exists solely from the incoming data from drivers on that route. If a blockage is
determined, then the checkpoint at that location can be labeled as such to inform other drivers
Lab 1 – Traffic Wizard Description
Traffic Wizard - 17
who on their way to that location. By utilizing these and other specialized algorithms, incoming
data can be assessed to determine what the conditions are for a driver’s route and perform
estimates on the expected delay due to traffic congestion. The resulting traffic status from the
output of these algorithms is associated with the appropriate checkpoint and stored in the
database. Any updates to the driver’s estimated delay and list of virtual checkpoints along their
route are then downloaded back to their app to complete the data exchange.
The Traffic Wizard Virtual Checkpoint System is very supportive of changing traffic
conditions and patterns since they can be digitally reassigned at any moment. Virtual checkpoints
only exist in the software, so they can naturally be reallocated as needed to accommodate
changing traffic conditions. For example, there may be less virtual checkpoints on the road
during the middle of the day than during rush hour in the morning or evening. Routes with heavy
traffic congestion would benefit from more allocated checkpoints, which increases accuracy of
the data and helps determine where the congestion is worst. Checkpoint reallocation must occur
in moderation, however, since drivers who are using Traffic Wizard would be downloading any
updated checkpoints to their route each time they pass a checkpoint. If checkpoints are
reallocated too often, drivers would always be downloading a large list of updated checkpoints to
cache to their phone, which would negatively affect the data usage of the driver’s device.
Checkpoint reallocation will be demonstrated by using various sets of coordinates to represent
checkpoints that can be swapped in and out to represent the reallocation process.
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
Lab 1 – Traffic Wizard Description
Traffic Wizard - 18
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
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).
Table 1 shows the distinctions between the final Traffic Wizard product and the
developed prototype. The main difference is that the final product will use real-time travel
information that gets uploaded from drivers whereas the prototype uses a data set with simulated
entities as drivers with GPS coordinates as though they were really driving. The New User,
Settings, and Route Tracer GUI screens will not be implemented due to the reduction in scope
for the prototype. The remaining GUI screens for traveling and editing trips will be implemented
to show the Traffic Wizard driver profile feature. Databases used with the prototype are of the
same design as the final product, but use a set of test users and select virtual checkpoints instead
of real world information.
[Space intentionally left blank.]
Lab 1 – Traffic Wizard Description
Features
Data Miner
Traffic Conditions
GUI
Login
New User
Settings
Trip Editing
Route Tracer
Travel Map
End of Trip
Simulation Console
Virtual Checkpoints
GPS
Latitude/Longitude
Coordinates
Driver
Acknowledgement
Data Exchange
Database
Driver Profile
Database
Virtual Checkpoint
Database
Speed Limit
Database
Algorithms
Traffic Wizard - 19
Final Product
It will retrieve real-time travel
information from drivers using the
app.
Allows user entry of authentication
credentials.
Allows a user to create an account
and select a membership.
Allows user to alter application
settings and options.
Allows user to specify a new route
to be saved or modify an existing
route.
Program function to track a route to
be saved as it is driven by the user.
Non-interactive screen that displays
current traffic conditions while
driving.
Presents statistics about last trip
and any appropriate options to edit
the stored route.
Not implemented in Final Product.
Associates GPS coordinates along
roads with 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.
Stores customer account
information, credentials, and
payment method.
Stores checkpoint coordinates,
current traffic status, and historical
statistics.
Stores static information on speed
limits for public access.
Prototype
Simulated driver metadata to
use in analysis.
Restricted to specific test users.
Not implemented because of
scope.
Not implemented because of
scope.
Restricted to limited test area.
Not implemented because of
scope.
This is implemented.
This is implemented.
Demonstration interface for
simulated driving scenarios.
Simulated coordinates for
hand-selected checkpoints.
This is implemented on
simulated checkpoints.
This is implemented on
simulated checkpoints.
This is implemented with test
users.
This is implemented with
simulated checkpoints.
This is implemented.
Aggregate Speeds
Analyzes and filters driver inputs to
determine current traffic speed.
This is implemented.
Checkpoint
Allocation
Initial assignment of GPS
coordinates to initialize checkpoints.
Not implemented because of
scope.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 20
Algorithms
Blockage Finder
Redistribution of checkpoints along
roads as determined by current
checkpoint statuses and historical
patterns.
Calculate delays, outputs alternate
route suggestions
Estimates time to arrival at next
checkpoint from client side for
GPS/Data/Battery management.
Determines the closest Virtual
Checkpoint or set of checkpoints to
a given GPS coordinate or set of
coordinates.
Determines points on roads where
traffic flow is completely blocked.
Driver Generator
Not implemented in Final Product.
Checkpoint
Reallocation
Route Analysis
Next Checkpoint
ETA
Route Matcher
Only implemented on specific
driving scenarios.
This is implemented.
This is implemented.
This is implemented.
This is implemented.
Randomly generates virtual
drivers with speeds for testing
purposes.
Table 1: Prototype Features Table
3.4.Prototype Development Challenges
Even though the prototype for Traffic Wizard will not have the full functionality of the
final product, challenges will be encountered in development. For the prototype to demonstrate
the capabilities described in Section 3.3., all data involved must have its integrity ensured. This
means that the simulated driver data that gets sent to the Traffic Wizard server needs to represent
realistic travel data that would be sent in the final product. If the data being used in the prototype
to demonstrate and prove the concepts used in Traffic Wizard features is not befitting of real
world data, then the prototype will not truly model the Traffic Wizard system. Data used in the
Traffic Wizard prototype will be derived from real GPS coordinates along roads in Hampton
Roads, Virginia. The members of Blue Team, as developers, will be performing driving runs
with the app running and polling GPS data. From this, it can determined what sets of data can be
made to create a realistic traffic scenario.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 21
Not only does the data being used need to be verified for purity, but the data exchange
that occurs between drivers and the server must be managed in a timely manner. Information
being exchanged always acts as real-time data and therefore must be processed quickly to
provide updated statuses to checkpoints in the system. If the management of data transfer is not
timely enough, the updates on traffic conditions may be too late to be practical to drivers. For the
prototype, the simulated drivers must have knowledge of what the traffic conditions are on the
remainder of their trip in order to decide what route to take. Virtual checkpoint updates must be
provided timely enough to reach devices before too much time has passed in order to be useful.
Since the simulated drivers will all be sending and receiving data packets to and from the
server, the server software must be designed to support the load and potentially simultaneous
requests. The server must be able to handle multiple data packets incoming with various
parameters to be analyzed by the prototype algorithms and distribute necessary updates to the
simulated drivers that are eligible for them. This overall load to the server must be optimized in a
way that keeps the server from being overloaded and potentially faulting from too much input.
Ensuring that the incoming and outgoing data flow is timely is practical to the prototype
demonstration and keeps the server from becoming overburdened.
[Space intentionally left blank]
Lab 1 – Traffic Wizard Description
Traffic Wizard - 22
4. Glossary
3G Internet Connection: Standard for mobile telecommunication that is used for cellular
telephones and mobile Internet access.
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.
Communication Protocol: A defined set of rules for the exchange of digital messages and
telecommunications.
Custom Route: Any user-entered route that is saved to the phone to be driven later.
Customer Investment: The risk that involves keeping customer interest in the product and
ensuring continuing financial support from the customer base.
Customer Risks: Risk category that consists of potential issues that are related to Traffic Wizard
customers (e.g., ease-of-use to customer, driver distraction).
Data Mining: Refers to the collection of travel metadata from drivers using the Traffic Wizard
app for analytic purposes.
Database: Organized data storage for Traffic Wizard server operations – including information
on traffic patterns and associated data for virtual checkpoints.
Distraction: Any interaction with a driver while they are driving in which their attention is
diverted from focusing on the road ahead. This is renowned as a potentially deadly state for a
driver to be in while driving.
Driver/End User: Customers who purchase and use Traffic Wizard.
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 app.
Functionality Testing: Component of testing phases that involves ensuring Traffic Wizard
features are operational as expected and performing their respective functions.
Global Positioning System (GPS): Satellite navigation technology that provides latitude and
longitude coordinates for a specific location that is typically used in route navigation.
Goal(s): Planned future accomplishments for development by the Traffic Wizard team.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 23
Google Maps API: Web mapping service provided by Google that is utilized by Traffic Wizard
for route analysis.
GUI Functionality: User interaction with the graphic user interface to perform an operation on
the Traffic Wizard app.
Hardware Failure: Inevitable risk of technical failure of Traffic Wizard server equipment.
Incidental Traffic Congestion: Traffic congestion caused by an unexpected event such as an
accident or emergency situation.
Latency: Delay in digital communication that represents the time between a message being sent
and that message being received.
Network Maintenance: Upkeep of server hardware, network traffic, and integrity of server
Internet connection.
Optimization (Server): Performing calculations for route analysis in the most efficient manner
available in order to return practical real-time results.
Periodic Traffic Congestion: Traffic congestion that occurs as a result of a planned activity
(such as construction) or a regular time of heavy traffic (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.
Pre-weighting system: App feature that allows users to configure their stored routes to be
analyzed for traffic conditions and status at a time prior to the expected travel time.
Prototype: Early development stage of Traffic Wizard that involves simulation of data exchange
and proof-of-concept for announced features.
Real-time: Data that represents the current traffic conditions (at the current time of day).
Return on Investment: Company net gain after investment for production and after public
release.
Road Segment: Any defined, unbroken partition of road that lies between intersections to be
used in assembling custom routes.
Route: Particular set of roads that a user drives to reach their destination.
Route Analysis: Main app feature that focuses on the route that a user is currently driving on.
Routes being driven are analyzed for traffic status to report to the user (and make alternate route
suggestions if applicable).
Lab 1 – Traffic Wizard Description
Traffic Wizard - 24
Server Infrastructure: Organizational structure of the Traffic Wizard server.
Server Load Testing: Testing phase for the Traffic Wizard server involving a purposed mass
data-sending routine in order to test the server’s ability to handle that amount of input.
Simulation Console: Application developed during prototype stage to be used as a
demonstration platform for Traffic Wizard proof-of-concept. Will hold data for multiple driving
scenarios to be called for demonstration.
Smartphone: Personal cellular devices that are equipped with a mobile operating system such as
iOS or Android.
Software: Programs and data that are involved in Traffic Wizard computations.
Timestamp: A small note of the current time of day to accompany the data packet containing
driver location and speed during travel data collection.
Traffic Avoidance: Goal and main focus of Traffic Wizard which will be utilized to reduce the
delay that a driver experiences during their average trip.
Traffic Wizard: Traffic-monitoring smartphone app developed by the CS 411 Blue Team.
Travel Data Collection: Time-stamped information about a driver’s position, speed, and
direction that is uploaded to the Traffic Wizard server from the app.
Trip: Entire driving process from when a user first begins driving (and using the app) to arrival
at their destination.
User Interface: Set of menu and map screens used in the app to make Traffic Wizard features
accessible through a GUI.
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.
Lab 1 – Traffic Wizard Description
Traffic Wizard - 25
5. References
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/