1
Lab 2- Traffic Wizard Prototype Product Specification
Running Head: Lab 2-Traffic Wizard Prototype Product Specification
Lab 2 - Traffic Wizard Prototype Product Specification
Sujani Godavarthi
CS 411
Professor Janet Brunelle
Old Dominion University
March 28th, 2012
Version Two
2
Lab 2- Traffic Wizard Prototype Product Specification
Table of Contents
1 Introduction ……………………………………………………………………………...3
1.1 Purpose ………………………………………………………………………………4
1.2 Scope ………………………………………………………………………………...7
1.3 Definitions and Acronyms ………………………………………………………… 11
1.4 References …………………………………………………………………………...13
1.5 Overview …………………………………………………………………………….13
2 General Description ……………………………………………………………………..13
2.1 Prototype Architecture Description………………………………………………….14
2.2 Prototype Functional Description……………………………………………………15
2.3 External Interfaces…………………………………………………………………...17
2.3.1 Hardware Interfaces …………………………………………………………17
2.3.2 Software Interfaces…………………………………………………………..17
2.3.3 User Interfaces ………………………………………………………………18
2.3.4 Communication Protocols / Interfaces………………………………………18
List of Figures
Figure 1: Traffic Wizard Update Process………………………………………………5
Figure 2: Virtual Checkpoint System ………………………………………………….5
Figure 3: Traffic Wizard Data Flow……………………………………………………6
Figure4: Prototype Major Functional Component ……………………………………14
Figure 5: Checkpoint Data Exchange …………………………………………………16
Figure6: Traffic Wizard Prototype App Site Map……………………………………..18
List of Tables
Table 1: Prototype Features Table ……………………………………………………..7
3
Lab 2- Traffic Wizard Prototype Product Specification
1. Introduction
Traffic Wizard is developed as a smartphone application that will provide assistance to
drivers to avoid heavy traffic along their stored custom and new routes. Due to the increase of
heavy traffic being congested in regions where population growth is more than usual, high and
traffic is congested, drivers and commuters experience delays. 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). A driver’s limited awareness of adverse
traffic conditions increases his/her potential to get caught in heavy traffic congestion.
Heavy traffic factors are many reasons like Visual Cues, Media, Word of Mouth, Traffic
Cameras and Mobile Applications. With the traffic delays, drivers cannot completely depend
with above factors and receiving unreliable traffic data. Current mobile applications with apps
(manually done) are a distraction to the driver while travelling. News and other media are helpful
but subject to change within some areas and unexpected blockages. GPS devices provide
directions to assist navigation but the information being provided is very limited to the driver.
With Traffic Wizard smartphone application, statistics numbers to be reduced (Texas
Transportation Institute). One of the main features is Virtual Checkpoint System of the Traffic
Wizard app is for labeling specific latitude and longitude coordinates along roads to act as
representations of the traffic status in that area and as flags to trigger data exchange for driver’s
phones. It’s a personalized smartphone app solution to help inform the drivers of travel
conditions before and during the trip by real-time updates. The app will exhibit travel profiles
wherein the drivers store their most frequent routes and current routes and can check destination
time.
4
Lab 2- Traffic Wizard Prototype Product Specification
1.1 Purpose
The innovative aspect of Traffic Wizard lies with its method of data distribution and
collection through the virtual checkpoints. By systematically reducing the amount of data
transmission between the driver app and the server, the Traffic Wizard system will provide the
drivers with real-time traffic updates and route analysis services. This would result in less
distraction to the driver. There will be minimum usage to their smartphone battery or data plan,
instead of draining up for the application to run all the time. Drivers who have access to a
smartphone, which has only the following operating system Android and iOS, will be able to
download and use the features of the Traffic Wizard application. Other innovative features of the
app are Real-Time Data Exchange, Traffic Analysis, Driver Profiles and Virtual Checkpoint
System.
Each registered user has their own driver profile that they can use to keep track of their
most frequently travelled routes. These routes can be manually be entered by the driver or being
traced when a user drives which can be stored into their phone. Before travelling, with the help
of driver profile, they can see the travel time for a particular destination.
Utilizing the Virtual Checkpoints will reduce data exchange size and also provide the
user with current traffic update and reliable traffic data. The virtual checkpoint system will
enable the app to minimize data exchange between Traffic Wizard smartphone and the app
servers. The virtual checkpoints are latitude/longitude specific points along the roads. They
identify the road segments by the amount of traffic congestions and dynamically re-allocated as
roads and traffic patterns change. The server returns information with real-time traffic status
being updated to the smartphone app. Data exchange that occurs between the driver’s app and
the server can be seen in Figure 1.
5
Lab 2- Traffic Wizard Prototype Product Specification
Figure 1: Traffic Wizard Update Process
Figure 2: Virtual Checkpoint System
6
Lab 2- Traffic Wizard Prototype Product Specification
Virtual checkpoints are located with specific latitudes and longitude coordinates and
placed along the road segments. Each checkpoint is noted with color-coded traffic status update
to represent the current traffic. A green traffic status would notate there is a little delay at the
road segment, while a road status shows the traffic is backed or jammed in that particular area.
These virtual GPS locations act as flags for the application Traffic Wizard to upload travel data
to the driver and download the necessary updates while travelling or driving. These checkpoints
can be reallocated with the demand and for special traffic conditions. Checkpoints can be
allocated within a small area to help determine blockages or be used in rush hours or heavy
traffic flow to assist in providing the accurate travel information to the drivers.
Figure 3: Traffic Wizard Data Flow
Exchange of data is an important aspect in the smartphone application and in the Traffic
Wizard server. It receives the conformation updates from the checkpoints that are allocated along
the road segments. Proper speed limits are determined through the speed limit database where
the information will be obtained from the posted speed limits on the road. For the checkpoint
7
Lab 2- Traffic Wizard Prototype Product Specification
transmission, when the phone data is sent to the server and using some of the algorithms and
databases the information will calculated properly and will sent to the driver’s phones.
The important feature of Traffic Wizard is the pre-trip analysis. Every user that uses the
application Traffic Wizard has their customizable driver profile where they can save their
favorite or most frequent routes for easy accessibility. Drivers or users can select a route before
travelling and check for traffic updates. The app send the request to the server with the
preprogrammed route and with the help of virtual checkpoints, traffic updates can be determined.
In this way, the driver device can minimize the usage of network and phone battery.
Drivers using the app are not assured to check for decrease in delays for their trip. It is
also not guaranteed that real-time traffic update will be always available to the drivers. In some
areas the updated information depends on the users travelling with Traffic Wizard app.
Information on blockages cannot always be fully identified as an accident, construction or an
event. If there is delay in traffic, a prediction that there might be a blockage along the route.
Other features are not implemented in Traffic Wizard include detection of emergency response
vehicles on the road and turn-by-turn directions to given destinations.
1.2 Scope
Traffic Wizard as the smartphone application will cover geographical areas across the
metropolitan areas with higher population density. The prototype will be operated on a reduced
geographical area to Old Dominion University and the surrounding areas will be tested in the
appropriate environment. The prototype will run on simulated data. The driver data speed and
direction will be generated based on the information from testing. With this prototype testing, we
can determine the speed, data usage and usage of battery. The various features of the Traffic
Wizard prototype are defined in the Table 1.
8
Lab 2- Traffic Wizard Prototype Product Specification
Features
Data Miner
Traffic Conditions
GUI
Final Product
Prototype
It will retrieve real-time travel
information from drivers Simulated driver metadata
using the app.
to use in analysis.
Route Tracer
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.
Travel Map
Non-interactive screen that
displays
current
traffic
conditions while driving.
This is implemented.
Login
New User
Settings
Trip Editing
End of Trip
GUI
Simulation
Console
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.
Presents statistics about last
trip and any appropriate
options to edit the stored
route.
This is implemented.
Demonstration interface
Not implemented in Final for simulated driving
Product.
scenarios.
Virtual
Checkpoints
GPS
Latitude/Longitude Associates GPS coordinates
Coordinates
along roads with checkpoints.
Recognizes drivers passing
Driver
GPS location (checkpoint) as
Acknowledgement an event.
Simulated coordinates for
hand-selected
checkpoints.
This is implemented on
simulated checkpoints.
9
Lab 2- Traffic Wizard Prototype Product Specification
Data Exchange
Features
Database
Upload user velocity at This is implemented on
checkpoint being passed / simulated checkpoints.
Download necessary traffic
updates for checkpoints along
the route.
Final Product
Prototype
Stores customer account
Driver
Profile information, credentials, and
Database
payment method.
Stores checkpoint coordinates,
Virtual Checkpoint current traffic status, and
Database
historical statistics.
Speed
Limit Stores static information on
Database
speed limits for public access.
Algorithms
Analyzes and filters driver
inputs to determine current
Speed Aggregator traffic speed.
Initial assignment of GPS
Checkpoint
coordinates
to
initialize
Allocator
checkpoints.
Redistribution of checkpoints
along roads as determined by
Checkpoint
current checkpoint statuses
Reallocator
and historical patterns.
Route Analyzer
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.
Calculate delays, outputs
alternate route suggestions
This is implemented.
Estimates time to arrival at
next checkpoint from client
Next Checkpoint side for GPS/Data/Battery This is implemented.
Estimator
management.
Route Matcher
Blockage Finder
Determines the closest Virtual
Checkpoint
or
set
of
checkpoints to a given GPS
coordinate
or
set
of
coordinates.
This is implemented.
Determines points on roads
where
traffic
flow
is
completely blocked.
This is implemented.
10
Lab 2- Traffic Wizard Prototype Product Specification
Driver Generator
Randomly
generates
Not implemented in Final virtual drivers with speeds
Product.
for testing purposes.
Table 1: Prototype Features Table
The geographical scope will cover areas with Hampton Roads, Virginia. The major
testing region itself will be Old Dominion University as many students commute and stay in the
surrounding areas. A complete set of the geographic regions which are used in the prototype are
outlined in Section 3.1.3.1. Also, it will available to the campuses at Norfolk State University,
Tidewater Community College, Old Dominion University, Newport and Hampton Universities.
The server uses the data to provide traffic status and simulated information in the
prototype. Driver Generator algorithm, (Section 3.1.2.8: Driver Generator) will be used to
simulate the event of the driver entering the region and will being continuously monitored at the
time of demonstration. The final product of the prototype depends on the real-time information
being uploaded from the drivers using the application. This simulated data will be received by
the Route Tracer feature which gathers all the latitude and longitude coordinates for the routes
selected by the driver.
The data which is used by the server to provide traffic updates or notifications will be
the simulated information from the prototype. These data is received in a timely systematic
procedure. Real time is exchange of data between the driver or user and the server. With the
Simulation Console (Section 3.1.3), the Traffic Wizard application will provide accurate data to
the driver.
11
Lab 2- Traffic Wizard Prototype Product Specification
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 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.
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.
12
Lab 2- Traffic Wizard Prototype Product Specification
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.
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.
13
Lab 2- Traffic Wizard Prototype Product Specification
1.4 References
Sujani, Godavarthi. “Lab 1 – Traffic Wizard Product Description.” CS 411.Team Blue, Spring
2012.
U.S. National Highway Traffic Safety Administration, Traffic Safety Facts. Retrieved from
http://www.census.gov/compendia/statab/2012/tables/12s1108.pdf
Lomax, T., &Schrank, D., & Turner, S. (2011). Annual Urban Mobility Report.Texas
Transportation Institute. Retrieved from http://mobility.tamu.edu/ums/
1.5 Overview
This product specification document provides a comprehensive explanation of the Traffic
Wizard’s hardware, software, external interfaces, capabilities, and features. The information
provided in the remaining sections of this document includes a detailed description of the
prototype architecture, prototype functional description, and detailed overview of hardware,
software and user interfaces. It also describes the key features of the prototype, their functional
requirements, and the performance characteristics of these features in terms of input, outputs, and
user interaction.
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.
14
Lab 2- Traffic Wizard Prototype Product Specification
2.1 Prototype Architecture Description
The major functional components of the Traffic Wizard prototype are shown in Figure 4. The
client side for the smartphone app and the server are the main categories for the prototype
system. The client app for the prototype will include all the GUI components described in the
Prototype Features Table (Table 1) in Section 3.3 to be used in the simulation. The server will
contain the simulation algorithms, Traffic Wizard algorithms and databases. The prototype for
the smartphone application will be both the server and the smartphone.
Figure 4: Prototype Major Functional Compnents
The simulated data is generated by the server to transmit it to the drivers on the road being
passed through proper algorithms and information is stored in the virtual checkpoint database.
Each virtual checkpoint coordinates are stored in the database and these resulting raffic updates
can be viewed in the simulation protoype where the actual virtual checkpint is located. The
prototype will feature driver profile database by allowing the user to creat a profile and can
15
Lab 2- Traffic Wizard Prototype Product Specification
adding routes. Their profile is stored on the database as a registered user. A public speed limit
database (referenced) will be used in the Traffic Wizard algorithms where the algorithm needs to
determine the proper speed limit of certain roads.
During the process of prototype, a virtual machine will be utilized instead of an actual
server to collect the data and analyze traffic data. The virtual machine softwares consist of
Apache, MySQL, and PHP MyAdmin. The server will be a Linux virtual server hosted by Old
Dominion Computer Science Department.
2.2. Prototype Functional Description
The prototype for the Traffic Wizard system involves the smartphone app, server and
Simulation Console. The Traffic Wizard prototype app is used for the functionality of the
product application and demonstrated within the team. The server will have Driver Profile
Database and Virtual Checkpoint Database to be used for the simulations. Drivers can create and
edit their custom routes in their respective driver profiles where information is stored in the
server. Simulated driver data will be obtained from Driver Profile Database and Virtual
Checkpoint Database.
The smartphone GUI displays the screens in the prototype as 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 create an account for the application Traffic
Wizard. The new user gui will allow the user to set user specific routes. Delay notification will
notify the user of the traffic conditions for pre-travel. There will be a setting option where in the
user can set their preferences and their driver profiles. Traffic Wizard will use the custom profile
created by the driver to show the route. The user can enter manually or store their custom routes.
Based on this information, calculations and analysis will be done before travel.
16
Lab 2- Traffic Wizard Prototype Product Specification
Virtual checkpoints are latitude and longitude points in the Traffic Wizard. In diagram 5,
utilization of checkpoints will be displayed.
Figure 5: Checkpoint Data Exchange
The final product in the prototype is the Virtual Checkpoints. The use of Virtual
Checkpoints will minimize the data transmission between the smartphone application and the
server. The simulation Console will need to interact with the server for the other algorithms to be
interconnected and execute the date. Simulations need to be executed in time for the driver or
user to receive real-time traffic conditions.
17
Lab 2- Traffic Wizard Prototype Product Specification
2.3.
External Interfaces
Traffic Wizard will require specific hardware interfaces, software interfaces, user interfaces
and communication interfaces. The smartphone GPS module and 3G data will be used in the
smartphone application. The software interfaces will include a database driver and server
interface. Interfaces for the client app and server will be described in the Simulation Console.
2.3.1. Hardware Interfaces
The Traffic Wizard prototype consists of few hardware interfaces. Developing a smartphone
application, the operating system used here is Android and iOS which are the required hardware.
3G Internet connection and GPS module are incorporated into the smartphone hardware will be
utilized in the prototype. Driving information will be collected through GPS smartphone module.
Current speed, current direction and timestamp will be collected. A virtual machine hosted by the
ODU Computer Science Department will act as the Traffic Wizard server and an Old Dominion
University laptop will be running the Simulation Console (Section 3.1.3).
2.3.2. Software Interface
The software interface involves the server and MYSQL database using SQL queries and
PHP scripts. Using PHP, results obtained from the database and updated on the server and
required information will be sent to the respective driver. Sever applications will be built in the
languages Java and Perl in order to have the algorithms and the server working. The Simulation
Console for the application Traffic Wizard prototype is written in C# using the .NET 4.0
platforms, which will help maintain the communication in Traffic Wizard server.
18
Lab 2- Traffic Wizard Prototype Product Specification
2.3.3. User Interfaces
The user interface is the only application used in Traffic Wizard which is a smartphone
application. The prototype application contains the GUI screens outlined in Section 3.1.4.1. This
interface provides features like driver profiles, driver information and the Route Tracer. The site
map for the prototype application is displayed in the Figure 6.
Figure 6: Traffic Wizard Prototype App Site Map
Testing information will be used to authenticate a user and create a driver profile and stored
in the Driver Profile Database (Section 3.1.1.1.). These features can be supported creating and
editing routes, Route Tracer utility uses the latitude and the longitude of the smartphone device
and GPS system.
2.3.4. Communication Protocols/ Interfaces
There are two protocols that are used for the Traffic Wizard product. The first one is the
Transmission Control Protocol/ Internet Protocol (TCP/IP) over a standard Ethernet connection.
The second protocol is the Hypertext Transfer Protocol (HTTP) for the World Wide Web
19
Lab 2- Traffic Wizard Prototype Product Specification
communication. The User Datagram Protocol (UDP) is one of the core members of the Internet
Protocol. The usage of UDP is computer applications can send messages, to other hosts on the IP
network. Sockets will used for prototype data transmission. The smartphone will utilize sockets
for data request to minimize network resource and establish host-to-host communications.