Traffic Wizard – Lab 2
1
CS 411W Lab II
Prototype Product Specification
For
Traffic Wizard
Prepared by: Binh Dong – Blue Team
Date: 03/14/2012
Traffic Wizard – Lab 2
2
Table of Contents
1
Introduction ............................................................................................................................... 3
1.1 Purpose ............................................................................................................................... 4
1.2 Scope .................................................................................................................................. 7
1.3 Definitions and Acronyms.................................................................................................. 8
1.4 References ........................................................................................................................ 10
1.5 Overview .......................................................................................................................... 11
2
General Description ................................................................................................................ 12
2.1 Prototype Architecture Description .................................................................................. 12
2.2 Prototype Functional Description ..................................................................................... 14
2.3 External Interface ............................................................................................................. 16
2.3.1 Hardware Interfaces ................................................................................................... 16
2.3.2 Software Interfaces .................................................................................................... 16
2.3.3 User Interfaces ........................................................................................................... 17
2.3.4 Communication Protocols / Interfaces ....................................................................... 17
List of Figures
Figure 1: Prototype Major Functional Components ................................................................................... 12
Figure 2: Checkpoint Workflow. ................................................................................................................. 15
Figure 3: GUI Sitemap ............................................................................................................................... 17
List of Tables
Table 1: Prototype vs Final Features............................................................................................................. 7
Traffic Wizard – Lab 2
1
Introduction
Currently, there are seven ways in getting traffic conditions: Visual Cues, Media, Word of
Mouth, Traffic Cameras, Mobile Applications, GPS devices and personal experience and
patterning. The issue with all of these stated methods is that they possess latency. Traffic
conditions that are relayed in these methods are delayed or incorrect because when the driver
gets the information it is outdated or unreliable. Traffic wizard will eliminate or reduce
significantly this latency, outdated and unreliable traffic data.
Traffic Wizard is an innovative mobile application to relay reliable and timely traffic
information to the end user. A driver’s limited awareness of adverse traffic conditions increases
his/her potential to get caught in heavy traffic congestion. Traffic Wizard addresses this societal
problem by being an innovative mobile application. This application will supersede current
traffic reporting techniques and informational media channels to give the driver real-time
knowledge of the current conditions so the end user can choose a best route.
Currently the methods of a driver gathering traffic information are unreliable and subject to
latency. The current methods of gathering traffic information are: Visual Cues, Media, Word of
Mouth, Traffic Cameras, Mobile Apps, GPS devices and personal experiences and patterning.
All of which are error-prone, unreliable and latent.
With people being stuck in traffic, precious time and fuel are being consumed in excess.
According to the Texas Transportation Institute, 4.8 billion hours of excess commute time and
1.9 billion gallons of excess fuel consumed were due to traffic. With Traffic Wizard, these
numbers shall be lower.
3
Traffic Wizard – Lab 2
4
The objective of Traffic Wizard is to design a simplistic innovative mobile traffic
application for smartphones. Traffic Wizard’s end user application will be run on smartphones
specifically the iPhone for the prototype. As Traffic Wizard matures it will be available to other
smartphone device platforms. The smartphone application will be customizable to the user and
store frequent routes. The application shall analyze the stored routes before and during travel
time while providing accurate traffic information based on custom routes and virtual checkpoint
information. The innovative approach to Traffic Wizard is the Virtual Checkpoint System.
Virtual Checkpoints will provide efficient data exchange between Traffic Wizard Internet-based
servers and the smartphone running the application.
1.1
Purpose
The Traffic Wizard smartphone application will provide real-time traffic information the end
user. Traffic Wizard has many key product features and capabilities that make up the application.
It will use a personalized profile system to determine the best route for a driver utilizing the
innovative Virtual Checkpoint System, Real-Time Data Exchange, Traffic Analysis and Driver
Profiles. For the prototype Traffic Wizard will be tested on iOS.
Traffic Wizard’s target market customer base will be drivers with smartphones in
metropolitan areas and drivers of commercial applications. Rising smartphone sales with
increasing population, there will be more automobiles and smartphones on the road. The more
vehicles on the roads will lead to higher traffic. The drivers in metropolitan areas that possess
smartphones will be prime target market base as there is usually high vehicular traffic in these
areas. With many automobiles in these metropolitan areas, traffic data will be more robust then a
rural area with less driver data. In metropolitan areas, colleges, taxies and buses will be targeted
as well. Commercial shipping companies will be targeted as these companies have many vehicles
Traffic Wizard – Lab 2
5
on the road at a time. With commercial vendors having Traffic Wizard in their vehicles it will
improve traffic data for metropolitan users. More data equals better accuracy.
Traffic Wizard will be implemented using smartphones. The application will first be
prototyped on the iOS operating system utilized on iPhones. Traffic Wizard must provide the end
user with reliable and real-time traffic data. The traffic data will be analyzed by polling global
positioning satellite system’s (GPS) data. The smartphone will pull the GPS data that contains
latitude/longitude point and speed-readings. The GPS data will then be uploaded to the Traffic
Wizard’s server to be analyzed. With Traffic Wizard’s implementation of Virtual Checkpoints
shall reduce data exchange size while being able to provide the user with on-time, reliable traffic
data.
The virtual checkpoint system will enable Traffic Wizard to minimize data exchange
between the Traffic Wizard smartphone and Traffic Wizard’s servers. The virtual checkpoints
are latitude/longitude specific points along roadways. They identify road segments by the
amount of traffic congestions and can be dynamically re-allocated as roads and traffic patterns
change.
GPS data will be analyzed after the smartphone polls the GPS data and sends the GPS
data up to Traffic Wizard’s Server. Within the GPS data, it will contain latitude, longitude and
speed of the driver. Traffic Wizard’s server will have algorithms to combine and analyze
multiple Traffic Wizard users’ data to determine traffic conditions. Traffic Analysis will be
calculated in real-time on the Traffic Wizard’s server and not the smartphone.
The graphical user interface shall be very simplistic. Provided for the user will be the
ability to: log in, set and edit their personal driver profile, set and edit their personal routes, set
Traffic Wizard – Lab 2
6
notifications and trace routes. The login screen will contain a place for the driver to input their
credentials. The driver profile will be a custom profile catered to the driver. Traffic Wizard will
use this profile to set up how a route will be displayed or calculated. The personal routes will be
set by the user or automatically set via a trace route. The routes information will then be used for
future traffic condition notification.
[This space intentionally left blank]
Traffic Wizard – Lab 2
1.2
7
Scope
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
Features
Database
Driver Profile Database
Virtual Checkpoint
Database
Speed Limit Database
Algorithms
Final Product
It will retrieve real-time travel information
from drivers using the app.
Simulated driver metadata to use in
analysis.
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.
Restricted to specific test users.
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.
Final Product
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.
Blockage Finder
Analyzes and filters driver inputs to determine
current traffic speed.
Initial assignment of GPS coordinates to
initialize checkpoints.
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.
Speed Aggregator
Checkpoint Allocator
Checkpoint Reallocator
Route Analyzer
Next Checkpoint
Estimator
Route Matcher
Prototype
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 handselected checkpoints.
This is implemented on simulated
checkpoints.
This is implemented on simulated
checkpoints.
Prototype
This is implemented with test users.
This is implemented with simulated
checkpoints.
This is implemented.
This is implemented.
Not implemented because of scope.
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 vs Final Features
Table 1 shows the differences between the final and prototype for Traffic Wizard. For the
final product, Traffic Wizard will be able to cover enormous geographic areas across the nation.
Traffic Wizard – Lab 2
8
Traffic Wizard will have servers in main metropolitan areas across the nation to allow greater
coverage then in the prototype stage. In the prototype stage, Traffic Wizard’s scope will be
decreased to a smaller scale. The smaller scale will consist of roads in Hampton Roads, Virginia.
With a reduced scope, Traffic Wizard will be able to demonstrate its concepts and effectiveness
conceptually.
1.3
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.
Traffic Wizard – Lab 2
9
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.
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.
Traffic Wizard – Lab 2
10
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.
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 – Traffic Wizard Product Description, CS411, Blue Team, Spring 2012
Brownlow, Mark. "Smartphone Statistics and Market Share." September 2011. Email Marketing
Reports. Retrieved from http://www.emailmarketing-reports.com/wirelessmobile/smartphonestatistics.htm
Dr. M. Weigle, interview, October 19, 2011
Traffic Wizard – Lab 2
11
Liang, Quincy. "Worldwide PND Shipments to Peak Around 42 M. in 2011-2012: Berg Insight."
October 19, 2011. CENS. Retrieved from
http://news.cens.com/cens/html/en/news/news_inner_38131.html
Lomax, Time, David Schrank and Shawn Turner. Texas Transportation Institute. (2011). Annual
Urban Mobility Report. College Station, TX. Retrieved from
http://mobility.tamu.edu/ums/
Schroeder, Stan. "Smartphone Sales Up 85% Year-Over-Year." May 19, 2011. Mashable Tech.
Retrieved from http://mashable.com/2011/05/19/smartphone-sales-q1-2011-gartner/
Stiles, Matt. “Census Map Shows Population Growth by County.” June 16, 2010. The
Texas
Tribune. http://www.texastribune.org/texas-counties-and-demographics/census/censusmap- shows-population-growth-by-county/
U.S. National Highway Traffic Safety Administation, Traffic Safety Facts. Retrieved from
http://www.census.gov/compendia/statab/2012/tables/12s1108.pdf
1.5
Overview
Traffic Wizard consists of three elements: the user with the smartphone application, the
server, and the communication medium. The prototype smartphone application must work and be
robust enough to take in GPS data and send it up to Traffic Wizard’s virtual servers. The server
must be able to receive the data from the smartphone application and process the data with
Traffic Wizard’s algorithms. The communication medium, whether it is 3G, WiFi, or 4G must be
able to handle the demands, though the demands will be minimal, from the server and mobile
application. The communication medium must be able to send and receive messages in a timely
manner for Traffic Wizard to process the data.
[This space intentionally left blank]
Traffic Wizard – Lab 2
2
12
General Description
Traffic Wizard is an application that must provide to the driver reliable and accurate traffic
data. Traffic Wizard uses smartphone hardware and server hardware and software to be able
to be run, simulated and tested. There are many parts to Traffic Wizard. This section will
describe various parts that make up Traffic Wizard.
2.1
Prototype Architecture Description
Figure 1: Prototype Major Functional Components
Traffic Wizard’s major functional prototype will be the same as the final product plus
multiple simulation components. For the prototype stage we will be using sample testing
Traffic Wizard – Lab 2
13
smartphone devices to test data exchange (Figure 3). The server will contain simulation
algorithms, Traffic Wizard main algorithms and each database (Figure 3). The Traffic Wizard
Prototype will consist of both the server and smartphone.
As shown in Figure 3, In the Traffic Wizard prototype there will be three simulation
algorithms plus the main Traffic Wizard algorithms. These algorithms include: simulation data
generator, simulation checkpoint allocator, artificial driver engine, and route evaluation
algorithms. A simulation data generator will create data randomly to simulate traffic conditions.
A simulation checkpoint allocator will define virtual checkpoints in regards to the simulated
traffic conditions. The artificial driver engine will simulate a driver driving a road pre-defined
road coarse. The route evaluation algorithms will calculate traffic conditions with simulated
traffic data. These algorithms will test how well Traffic Wizard handles input data.
During the prototype phase, Traffic Wizard will have a working mobile application written
for iOS. The application will be able to collect data as a driver drives a route and be able to
upload to Traffic Wizard’s servers. The prototype mobile application will be ready to deploy.
For the prototype stage, a virtual machine will be utilized instead of an actual server to
collect data and analyze traffic data. The server will act as if it were a final product in this
prototype stage. The server will be a Linux virtual server hosted by Old Dominion Computer
Science department.
[This space intentionally left blank]
Traffic Wizard – Lab 2
2.2
14
Prototype Functional Description
The prototype will consist of the smartphone application, server and simulation console.
Traffic Wizard will be designed for in-house testing and will be designed with functionality as if
it were to be released to the public. Most functions should work with the limitations of most of
the data will be simulated for prototype purposes.
The prototype server will do most of the operations as the final product server. The only
thing that will be different is the scale and the simulated data that will be inputted. The server
will have the algorithms and will calculate traffic information. The server will also host user
information in a secure driver profile database. The main difference between the prototype and
final product’s server is the creation of data.
The smartphone GUI will have several working options in the prototype: Login, New
User, New/Edit Route, Delay Notification, and settings. The login gui must allow the user to log
into Traffic Wizard. The new user gui will allow the new user to Traffic Wizard to create an
account. New and edit route gui will allow the user to set user specific routes. Delay notification
will notify the user of traffic conditions before their scheduled route. Settings gui will be where a
user can set setting for Traffic Wizard and set their driver profiles.
The driver profile will be a custom profile catered to the driver. Traffic Wizard will use
this profile to set up how a route will be displayed or calculated. The personal routes will be set
by the user or automatically set via a trace route. The routes information will then be used for
future traffic condition notification.
Virtual Checkpoints are latitude and longitude points in Traffic Wizard. These checkpoints
will be used the same in the prototype and final product. The checkpoints will be utilized as
Traffic Wizard – Lab 2
15
explained in the diagram below.
Figure 2: Checkpoint Workflow.
The last part of the Traffic Wizard’s prototype is the simulation console, which will not
be used in the final product. The simulation console will generate virtual drivers and simulate
traffic data. The simulation console will be separate of the server and it will act as a smartphone
application sending data to the server to be processed. This will test Traffic Wizard’s server
efficacy and algorithm robustness.
Traffic Wizard – Lab 2
2.3
16
External Interface
This section goes over the devices and software used within Traffic Wizard’s prototype
stage. Traffic Wizard uses hardware and software. It contains user interfaces and communication
devices. Server and smartphone client application will be described as well.
2.3.1 Hardware Interfaces
Traffic Wizard consists of four hardware devices. Traffic Wizard will contain the
smartphone, GPS module and an Internet connection module, and virtual server. iOS devices will
be the main focus for the prototype smartphone application. A Internet connection like 3G will
be used to transfer data wirelessly. The GPS module will be provided by the smartphone device
which will give Traffic Wizard GPS longitude and latitude information. ODU Computer science
department will provide the virtual machine for a server for Traffic Wizard to prototype on.
These four devices are the hardware that Traffic Wizard needs to prototype.
2.3.2 Software Interfaces
Traffic Wizard uses several software interfaces. The server will be used to host all
databases. Traffic Wizard’s servers will use MySQL for databases. These databases will be
needed for calculation of traffic conditions. PHP will also be used to format the database
correctly. Most of the prototype for Traffic Wizard will be programmed using .NET.
[This space intentionally left blank]
Traffic Wizard – Lab 2
17
2.3.3 User Interfaces
Figure 3: GUI Sitemap
The user interface for Traffic Wizard’s prototype will be designed for the smartphone.
The only user interfaces that a end user can use will be designed for the smartphone. The Figure
3 demonstrates the workflow of a GUI for the user. Traffic congestion will be displayed to the
user as red, yellow and green points. The user will be able to define their profiles using the GUI.
2.3.4 Communication Protocols / Interfaces
Traffic Wizard will use two protocols: User Datagram Protocol (UDP) and Transmission
Control Protocol/Internet Protocol (TCP/IP). The smartphone application will use UDP to
transfer info to the server hosted by ODU. TCP/IP will be used when the simulation console is
used to ensure reliable data transmission.