Running Head: LAB I
1
Lab I
Author(s):
Version:
For:
Professor:
Document Purpose:
Andrew McKnight
2
CS411
Brunelle
Describe and compare the prototype and
final product.
Last updated: February 28, 2012
LAB I
Team Blue
2
Table of Contents
1
2
Introduction ............................................................................................................................... 3
Traffic Wizard Product Description.......................................................................................... 6
2.1 Key Product Features and Capabilities ................................................................................. 7
2.2 Major Components................................................................................................................ 9
2.3 Target Market Customer Base ............................................................................................ 15
3 Traffic Wizard Product Prototype Description ..................................................................... 166
3.1 Prototype Functional Goals and Objectives ...................................................................... 177
3.2 Prototype Architecture ........................................................................................................ 19
3.3 Prototype Features and Capabilities.................................................................................. 211
3.4 Prototype Development Challenges .................................................................................. 233
4 Glossary ................................................................................................................................ 245
5 References ............................................................................................................................... 27
List of Figures
Figure 1: Prototype system data flow ............................................................................................. 8
Figure 2: Major functional components of the final product ........................................................ 10
Figure 3: Major functional components of the prototype ............................................................. 10
List of Tables
Table 1: Prototype and final product features. ............................................................................ 232
LAB I
Team Blue
3
1 Introduction
More than three centuries ago, man invented the automobile, and what started out as a
mere toy has today become an inextricable part of many people’s lives (Martin 2005). People
now can make trips in hours that would have taken days by horse-drawn vehicles or steamboat.
However, this invention that promised ease and efficiency in bringing people and cities closer
together has led to problems of its own. So many cars exist now that current road systems simply
cannot accommodate them. Highly populated areas have daily rush hours of gridlock, and even
on a rural road, there is always a possibility of backup due to accidents, trains, construction, or
the odd cow in the road.
A few other more modern inventions exist that can help solve this problem. First, the
telegraph and telephone enabled instantaneous communication across arbitrary distances
between fixed locations. The cell phone went a step further and enabled the same instantaneous
communication from any location visible from a satellite. Now there are smartphones, a
combination of the cell phone and supercomputer, providing the potential to perform precise,
intensive, and meaningful location specific computation.
Traffic Wizard uses multiple smartphone capabilities to gather accurate and timely traffic
information, providing drivers the opportunity to make the best possible travel decisions, both
before they leave and while en route. Through minimal resource usage, a smartphone app can
help to avoid situations that incur measurable dollar costs through lost time and fuel spent. It
does not solve the overall problem of traffic in the context of total car volume, but any driver
using the application who has an opportunity to avoid congestion is enabled to do so.
Traffic can be classified into two general categories: periodic traffic congestion and
LAB I
Team Blue
4
incidental traffic congestion. Periodic traffic is a function of the aggregate travel needs of all the
people using a specific roadway, usually known as the “rush hour” when most people are
heading to and from work. Hampton Roads has particularly heavy periodic traffic congestion
caused by the bottlenecks at tunnels and bridges..
Incidental traffic, on the other hand, is not directly caused by a bottleneck or certain
volume of cars but by a factor that is external to the car-road system. Breakdowns, accidents,
road construction and other blockages create new bottlenecks or completely cut off passage. At
this point, the volume of cars might amplify the congestion that results, but had the incident not
occurred, they would be free to travel at or above the posted speed. If the road is completely
blocked, no volume of traffic, no matter how low, will magically provide passage across the
blockage.
Besides planned construction, incidental traffic is unpredictable for drivers whose sphere
of knowledge extends little past the frame of their car. The senses of touch, smell and hearing are
limited to the cabin area, especially at higher speeds. Line of sight depends on the geography of
the area, but even in flat regions, one can only see so far. In mountainous areas, drivers need to
know a blockage exists around a given bend so as not to collide with it.
Several resources exist to help push the boundaries of what drivers know about local
traffic conditions. The least technologically reliant method is word of mouth—hearing other
people talk about where they just came from could be important if one is about to travel in the
same direction. This method is the least reliable, with extremely low odds of hearing information
relevant to a person’s next upcoming travel.
Television news programs all have traffic segments and live feeds to traffic cameras.
Additionally, the Internet has made every traffic camera available for live streaming. While this
LAB I
Team Blue
5
is a wonderful way to get the latest information up to the point of departure, it presents an
overwhelming disadvantage to people currently driving. One could perhaps watch a broadcast on
their smartphone, but this is dangerous and potentially illegal. Of course, this only applies to
drivers with no passengers.
Where television news and live cameras fail, radio stations compensate by broadcasting
updates, and sometimes signs along highways will even alert drivers on which station to listen to.
Unfortunately, the quality of these broadcasts, commonly over AM airwaves, is usually too low
to understand a single word. Regardless, the time taken for a story to get from a reporter to a
driver renders it “old news” in this context.
Several technologies have been developed to bring real-time information into cars’
cabins. Companies that previously developed purely navigation devices, like TomTom and
Magellan, as well as car manufacturers like BMW and Mercedes-Benz, now offer traffic
services, too. These are usually included in a lofty paid subscription package and require a
dedicated hardware component—either the navigation device itself, or a receiver that
communicates with an onboard dash computer or smartphone.
MapQuest, Google, and Yahoo all have live traffic reporting capabilities, and Google in
particular uses GPS data from users’ smartphones to determine the traffic status (Chito 2009).
The problem with that approach is that the program is not guaranteed the person using the
application is driving at any certain time—they could be running, biking, or riding in a taxi, bus,
or tram. The other problem is that the program would constantly need to check users’ activity to
determine when they have probably started driving or riding in a car to start paying attention to
their data.
The next logical step in the progression of technologies to aid in traffic avoidance is a
LAB I
Team Blue
6
personalized traffic assistant: an application that knows where the user will go and when they
will leave to get there, and checks traffic conditions before leaving and while driving. Users can
program custom trips by supplying information about the departure and arrival locations and
time of travel or letting it track routes users typically drive. Not only does Traffic Wizard
provide these conveniences, but it is also a valuable service to users who are behind the wheel
and need to stay informed of developing situations in a minimally distracting way.
By analyzing users’ traveling activities, Traffic Wizard provides alternatives for a driver
to try and avoid traffic where possible. To achieve the lowest possible level of distraction, it
communicates with the driver in ways that do not require their constant attention. The
application can run in the background, or not at all, and users will still receive notifications via
text, email, telephone, and push notification services. The user can then quickly open the
application—if it is not already open—and interact with it through voice commands.
Overall, the goal is to help individual drivers make the best choices given any state of
traffic and their current location. A positive side effect of this would be an actual reduction in
congestion, if only the incidental variety. Even though periodic congestion is much harder to
cure, many useful statistics can be gathered that could lead to alleviation of this type of traffic as
well, whether through software solutions or through new techniques in road design.
2 Traffic Wizard Product Description
The final product version is a client-side smartphone application that interacts with a
server-side application and databases across a cellular network. The servers are constructed in a
modular fashion, so it can be deployed in multiple coverage areas and networked together. To
seed the customer base, an extended beta testing phase will be opened to the public and
promoted in a variety of mediums for each new coverage area.
LAB I
Team Blue
7
2.1 Key Product Features and Capabilities
Traffic Wizard provides real-time traffic condition reports to users in several different
ways. When a user is not driving, they can visually inspect a map with overlays displaying traffic
conditions in a given area. This is a direct visualization of the Virtual Checkpoint System, a key
feature of Traffic Wizard. While they are driving, they may receive alerts that guide them to
choosing the best route to take in any situation. While driving, their smartphones constantly send
location and speed information to the server while receiving data compiled from submissions of
users ahead of them on the road. In turn, the data they send helps drivers that will pass through
the same location within a given timeframe.
The Virtual Checkpoint System is one Traffic Wizard’s most innovative concepts. Each
checkpoint is really a location specified by latitude and longitude values, also associated with
statistics like speed and flow. Roadways are divided into segments using Virtual Checkpoints,
with one checkpoint on each end of the segment. The amount of checkpoints on a given road is
constantly updated by the Checkpoint Reallocator, which mines data from the database of
checkpoints. The addition and subtraction of checkpoints allows for a balance between a
necessity for a certain amount of data and the actual volume being transmitted by users’ phones
and received by the servers. Since virtual checkpoints are sparsely placed along roads, the
amount of storage and data transmission involved in the normal operation of the application is
minimized.
As users drive around, their smartphones send and receive data to and from the regional
server closest to the driver. These packets of information are minimized in content to conserve
bandwidth, and in addition, the frequency of transmission is smartly managed to only send
information when it is actually necessary. These optimizations ensure the timeliness of
LAB I
Team Blue
8
communication, a vital need for the effectiveness of the project.
Figure 1: Prototype system data flow.
As Figure 1 shows, users’ data passes through satellites, towers, and network cables
before finally arriving at the server. Once in the server, it runs through several algorithms that
sample, aggregate, and store it in the database, and is ready to be used by the server to update
other users. With all these exchanges of data, optimizing at every step of the way is paramount to
Traffic Wizards success.
Several concurrent algorithms perform pattern finding and real-time traffic status
determination. They work with database values for their inputs and write back to the databases
with new data when appropriate. This concurrent access means that the algorithms themselves
need synchronized implementations, and also that the database can aptly manage large amounts
of atomic transactions.
LAB I
Team Blue
9
Analyses can be initiated for a variety of reasons. A sudden and drastic enough change in
the speed of a checkpoint calls the attention of the blockage finder. A general change across a
series of neighboring Virtual Checkpoints triggers the Checkpoint Reallocator. Requests from
client devices initiate travel time and delay estimation routines.
The personalized features of Traffic Wizard mean that some information about the users
needs to be stored. A value indicating subscription level must be stored for authentication to
enable different feature sets on client devices. More importantly, the preprogrammed routes
drivers have created must be stored. In the interest of user privacy and safety, this information is
stored locally on client devices and transmitted to servers when appropriate.
Some other information such as email addresses, names, and other contact information is
stored in server databases. However, for privacy’s sake, no information that may link them to a
location is ever stored on the servers. Instead, computational methods determine user information
like subscription levels and checkpoint passage.
2.2 Major Components
The overall Traffic Wizard system is comprised of a network of servers that each draw
information from and send it to client devices—smartphones—belonging to populations of users
in their coverage area. Both the client and server sides of this system have their own unique
function and composition. Traffic Wizard uses some other components that already exist, such as
GPS networks. Others, and perhaps the most important, are the media that connect the client and
server together: the cellular satellites and Internet connections. While these external components
do not allow much control, inadequacies and interruptions in their service must be accounted for
with a robust implementation. Figure 2 shows the relationships of the major components and the
subsystems that are used in each.
LAB I
Team Blue
10
Figure 2: Major functional components of the final product.
The client-side application is implemented on a variety of operating systems, but must
retain a cross-platform continuity in aesthetics and functionality. It is responsible for storing
privacy-sensitive information about the user regarding payment information (where it is not
required by a platforms’ administrating body, such as the Apple App Store) and travel data.
Since it saves the times and dates of stored trip information, it also needs to send queries to the
server automatically to obtain pre-travel statuses.
While driving, the application needs to regularly check for updates to the status of
upcoming checkpoints along a route. The frequency of these checks is determined the
Checkpoint ETA algorithm, which estimates time of arrival at the next checkpoint and pauses
part of the program execution until this time has elapsed. At the end of each pause, the estimated
time of arrival to the next checkpoint is reassessed.
LAB I
Team Blue
11
Aside from presenting data to the user, the client smartphone application performs the
data gathering and transmission vital to the operation of the whole system. The aggregation of
data from all users in an area gives a snapshot of the traffic conditions at any given time. When a
user arrives at or passes a checkpoint within a certain distance, the application sends a data
packet to the server containing a user id number, the checkpoint ID number, and the speed and
heading (in degrees) of the car.
The servers store the majority of the data that pertains to the entire Traffic Wizard
system, as opposed to individuals’ private data. Each regional server stores all data pertaining to
the Virtual Checkpoints for the associated coverage area. Additionally, the servers are networked
together for communication and redundancy in the event of hardware failure. They are all
enabled with connections to a central database that holds necessary user information, as well as
third party databases with speed limits or other data mining input and output.
Besides storage of data, each server utilizes several algorithms to analyze the constant
steam of input data being provided from client devices. Dynamic checkpoint allocation, route
analysis and alignment, and input aggregation take place in the servers’ faster processing centers.
Some of these algorithms are constantly running across the databases’ ever-changing values and
others are only initiated by requests from users.
When a new coverage area is being set up for Traffic Wizard, an initial set of checkpoints
is generated to begin operation. The generating algorithm uses existing coordinate information
and cartographic analysis of area maps to determine the location and direction of roads, and then
distribute checkpoints across them according to a set of rules. Once this set is generated, the
Virtual Checkpoint database is populated with the values, and that regional server is ready to
start receiving, analyzing input data and comparing it to the known speed limits.
LAB I
Team Blue
12
Once generated, the set of Virtual Checkpoints in a given coverage area constantly
changes to minimize the total data transfer needs for any particular state of traffic across the
whole region. On a road with optimal flow at or above the posted speed limit, only a
geographically sparse collection of checkpoints is needed, because the denser the allocation
along the road and the faster users are driving, the more data transfers from smartphone to server
takes place in a given amount of time. However, once the aggregated speed from one or more
checkpoints along that road drastically changes, the segments closest to the likely blockage
location can be subdivided to provide a higher resolution picture of what is happening, and more
importantly, how other drivers can avoid the situation.
Reallocation could take place for other reasons, as well. It could be initiated in
conjunction with periodic traffic congestion. Using historical analysis on stored information,
more checkpoints could be allocated slightly before predicted periods of high volume on a given
roadway. It could also be cross-referenced with construction or event schedules for a given road
or location to prepare for increased traffic volumes.
If and when the server receives a data packet from a client, it is pooled with other
readings for that checkpoint with the same heading. The aggregating algorithm uses a Monte
Carlo method of sampling from these pools, and after normalizing the samples, incorporates all
values within a determined standard deviation. To actually merge the selected samples’
information, the new data are weighted according to their associated timestamps and averaged
with the existing aggregated speed.
Aggregating the weighted inputs into one value eliminates the need to remember a
history of inputs and deciding at what age data should be discarded. Instead, the history of all
inputs is intrinsically stored into the aggregated value through timestamp weighting. The impact
LAB I
Team Blue
13
of older inputs diminishes as time goes on and new input is received.
One of Traffic Wizard’s most helpful features is that before a driver travels, it analyzes
the trip they are about to take by comparing the preprogrammed routes they chose to make the
trip. For each route, all the checkpoints are queried for their aggregated speed values, which are
divided by the distances of each pair to get segment times. The times for all of a route’s
segments are then summed to produce an estimated travel time, which is used to determine
whether flow along this route is optimal or delayed. Finally, all the routes for a trip are ranked by
travel time to present the best option to the user.
Similar comparisons can be made for routes while the user is driving, although several
other variables are factored in for realistic results. Instead of comparing all the checkpoints the
routes contain, only those checkpoints not yet passed need to be analyzed. A combination of
GPS data and planar geometry determines the checkpoints from other routes to include in the
comparison. Also, the travel times to get from one route to another are considered—if the time
for inter-route travel increases the total travel time for a possible alternative route to be higher
than that of the current route, the candidate is discarded from the comparison.
As checkpoints are reallocated, routes that are stored on client devices become
deprecated and must be aligned with the current collection of checkpoints that describes the same
route. To collect all of the current checkpoints, a query would be run for each old checkpoint on
the Virtual Checkpoint database to search for checkpoints within certain distances. To ensure
that only checkpoints on the same route are selected—in a city, checkpoints on different roads
would still be very close together—additional analysis on latitude, longitude, heading, and data
from nearby checkpoints is performed.
In the interest of minimizing data transmission, server input volume and smartphone GPS
LAB I
Team Blue
14
usage (which drastically reduces battery life), the client application needs to send and receive as
little information as possible to the servers. To minimize GPS usage, the application uses the
speed and distance to the next checkpoint to estimate the time interval until encountering the
next checkpoint. This way, the smartphone does not need to continuously monitor its location,
using a small fraction of the battery charge that would be expended to constantly use the GPS
radio.
As a convenience to the user, a simple tracking tool can trace a route from indicated start
and stop points as a series of GPS readings and save it as a custom trip. With two button pushes,
users may avoid needing to type cumbersome addresses and trip times. Drivers do not
necessarily know where they are going—for instance, when they are following another person in
front of them—and so could not program an arrival location in the first place.
From the moment that Virtual Checkpoints are initially allocated to a coverage area, they
must be stored in a database to keep track of the data associated with each one for analysis. Each
checkpoint entity in the database shall have records containing attributes for latitude and
longitude, heading (direction of traffic flow—north, south, east, or west) and aggregated speed.
The fact that a checkpoint entity has an associated direction implies that for roadways with both
directions of travel, there are two checkpoints for every location along the route.
By far, this database is the largest compared to the others, as well as the most heavily
accessed. As checkpoint analysis and reallocation go on, both reads and writes can occur in high
volumes. To account for this, each server center must have equipment and database
implementations able to handle the task.
Despite storing most users’ location-sensitive information on the client devices, some
things must be stored on the servers: email addresses, subscription levels and login credentials.
LAB I
Team Blue
15
To ensure that this data does not provide a pathway to more private information, algorithms and
transmissions must not handle and correlate user data in obvious ways. Best practices shall be
observed in implementing any routine that accesses user data, including proper data
encapsulation and memory management.
The speed limit database for each region is constructed alongside the initial allocation of
checkpoints. Its data remain largely static compared to the checkpoint and driver databases, and
only really changes when speed limits are changed or new roads are built. Because mostly read
operations are performed on this database, an implementation and server optimized for fast read
access times shall be used.
2.3 Target Market Customer Base
Although the problem of traffic congestion potentially affects any person who takes the
wheel, the target customer base for Traffic Wizard is limited to those drivers who own a fully
functioning smartphone device with one of the supported operating systems. If they do not have
wireless Internet connectivity, they cannot access the servers. If they do not have a device with a
supported operating system, they cannot run the client application.
The initial target base is the greater Hampton Roads area. During this initial phase,
research on other U.S. cities is conducted to decide which may harbor implementations of Traffic
Wizard the best. Smartphone sales are certainly not constrained to American borders, and so a
potential worldwide market exists for Traffic Wizard.
Many secondary markets exist not only for the application itself but also for the data that
can be produced by mining the data in the servers’ databases. Both commercial and
governmental applications can benefit from the raw, pervasive data that Traffic Wizard
accumulates. The way that secondary customers can use this mined data adds to the return on
LAB I
Team Blue
16
investment for the primary customer base—drivers with smartphones—by bettering their
services to many of the same people.
Population densities always increase nearer to urban areas, and if an even distribution of
smartphones among populations is assumed, then smartphones are also more concentrated in
urban areas. Targeting only drivers who own smartphones and live in metropolitan areas
provides several benefits. Only a fraction of the roads in a country, or even continent, are stored.
At first, rural intercity roads are not covered, although wherever a cell signal exists, so does
potential to use the application. Not storing every road between cities saves a huge amount of
database storage and server processing. Only using smartphones located in major cities also
virtually guarantees the availability of a cellular signal.
One example of a possible secondary market for Traffic Wizard is commercial ground
shipping. FedEx, UPS, and even pizza delivery can enjoy the same amount of time saved by
everyday drivers avoiding traffic delays. In turn, the time saved by these companies provides
better services to their customers. This trickle-down effect can provide marginal returns on
investment several times over to Traffic Wizard customers.
3 Traffic Wizard Product Prototype Description
To prove the concepts behind Traffic Wizard and verify their feasibility in real world
systems, prototypes of both the server and client applications are constructed, tested and
executed using a test harness with various test scenarios. Visualizations show how the server
algorithms are performing their jobs and how data is flowing between different clients and
servers. Generated data is used to test the prototype server’s ability to handle real-world volumes
of input. Testing the system under extreme conditions of user sparsity and technical failures
helps to devise appropriate countermeasures and demonstrate the mitigation of these risks.
LAB I
Team Blue
17
3.1 Prototype Functional Goals and Objectives
The prototype must show that the algorithms have been designed correctly, the system can
handle the expected volume of input, and that latency can be minimized enough to keep the
application relevant. Since the algorithms appearing in the final product also appear in the
prototype, their effectiveness and logistics can be optimized through experimentation. The final
product must be able to handle large amounts of data in the real world, so the upper boundary on
throughput must be rigorously tested on the algorithms, databases and physical hardware. In
addition to finding the limit to the system’s input, bounds on the latency must also be thoroughly
tested. By establishing these measures in the prototype phase, the concept of the project is
proven and opportunities for further optimization are exposed for final product development.
A simulation driver application generates artificial data and allows a human presenter to
control variables and switch use cases during execution. To change use cases, the databases are
wiped and replaced with a seed data set tailored to the given scenario, but the algorithms
continue to execute in the same way. After the seed data is set, new data is continuously
generated based on the thresholds in the simulation variables to represent the constant flow of
traffic on any given road.
The prototype implements most of the underlying mechanisms that carry out the crucial
analyses. The algorithms and databases housed in the servers in the final product are fully
implemented. Instead of operating on a full-scale city’s data sets, however, the scope is greatly
reduced to a small area within a city. For special use cases, an artificially generated set of roads
may be used to prove the robustness of the algorithm.
In addition to demonstrating the abilities of the servers and server applications, the
prototype must show that the users’ application is easy and safe to use. The client application is
LAB I
Team Blue
18
developed on a single operating system, Apple’s iOS 5. Each functional part is developed to
show the pathways between views and the composition and layout of each view. Interface
features regarding subscriptions are not implemented.
Most importantly, the user must not be placed in danger as a result of using the
application while driving. Text-to-speech and voice recognition technologies are used for all
user-application interaction during drive mode. By allowing the user to interact solely with their
voice, they can keep their eyes on the road and hands on the wheel.
The user interface must be intuitive for still-mode, and especially for drive-mode, so the
driver can respond without a loss of concentration on the road. The small initial feature set
means that the collection of views in the user interface is minimally connected. Placement of
components must be common throughout the application to allow for rapid navigation and input.
In drive mode, speech output from the smartphone to the user must be clear, concise, and
must elicit the simplest possible answers. Yes or no questions shall be implied whenever possible
to not only simplify user interaction, but also application programming. Application behaviors
are implemented discourage the user from interacting with the smartphone by either visual
inspection or touch.
Simulating the real world operation of a prototype allows for experimental analysis of
server abilities. To see how the system handles different volumes of data, test cases are built
using input levels both within and beyond expected real-world amounts. This allows for
tweaking of algorithms and data structures to account for any shortcomings found from the initial
development of all server components.
Use cases defining traffic scenarios are implemented by creating seed data sets and value
sets for simulation variables. Once the simulation driver is executing, the values in these
LAB I
Team Blue
19
variables control the generation of new data. Unit tests are created out of each use case to ensure
the algorithms can cope with any incident or combination of occurrences. Test cases developed
for individual algorithms are run on the system, as well as those designed to test the system as a
whole.
3.2 Prototype Architecture
The prototype is built to mimic the server for the Hampton Roads area upon launch of the
final product. It includes a remote networked virtual machine to mimic the physical mainframes
of the final product’s servers. An additional machine acts as a console to drive the simulation and
visualize data in its environment. At least one Apple iPad or iPhone acts as a user’s client device
to complement the dummy drivers generated by the simulator during the demonstration. Figure 3
shows how the server implementation will interact with the simulation driver and client devices.
LAB I
Team Blue
20
Figure 3: Functional components of the prototype.
All algorithms dealing with traffic analysis implemented in the final product appear in the
prototype. Algorithms or families of algorithms include: speed aggregation, route analysis, route
tracing, checkpoint eta estimation, blockage finding and checkpoint allocation are all
implemented in the prototype. Because the prototype is experimental in nature, the algorithms
may be tweaked as determined by results from benchmarking data throughput and latency.
The prototype is implemented on an Apple iPhone running iOS 5. All features pertaining
to travel are implemented, so again subscription-based behaviors are excluded from the
prototype. The main goals of taking GPS readings, performing cartographic operations,
communicating with the server, and using voice and speech technology are all demonstrated in
the prototype. The checkpoint E.T.A. estimation and route tracing algorithms are both
LAB I
Team Blue
21
implemented as in the final product.
The server prototype is implemented on a virtual machine hosted by Old Dominion
University’s Computer Science department running Ubuntu Linux. It contains the
implementations of all traffic related algorithms. All databases are implemented, but subscription
related records, attributes, and tables do not appear in the driver database.
3.3 Prototype Features and Capabilities
The prototype exists to prove the concepts needed for Traffic Wizard to work as intended
and to experimentally define the limits of its abilities. The console allows a human controller to
alter the state of the simulation. In this way, all devised test cases, algorithms, and data flows are
testable and can be varied to provide more well rounded testing.
The most basic algorithm in Traffic Wizard also provides the most pertinent data: route
analysis. Due to its importance, it is implemented in the prototype to prove the concept and allow
for limit testing and tweaking. Functionality and impact for both server and client applications
are measured in prototype development and testing.
One of the more challenging algorithms is checkpoint allocation and dynamic
reallocation, and so it must be thoroughly tested before final product development. The console
provides a visualization of the behavior and effects of the reallocation. Again, experimental
results and statistical analysis determines the ultimate behavior of the Reallocator.
Another integral part of the entire Traffic Wizard system is the communications system
that connects the clients to the servers. It is essential for operation, but also poses potential risks
for high latency, rendering data old and unusable. The prototype must demonstrate that network
communication does not impede the flow of information to this point.
Table 1 below summarizes the features from the final product that are implemented in the
LAB I
Team Blue
22
prototype. Notice that some features are reduced in scope—these are implemented only to prove
a concept, such as user login. Other features, mostly payment- and subscription- related, are not
implemented in the prototype.
Features
Data Miner
Final Product
Prototype
It will retrieve real-time travel
information from drivers using the app.
Simulated driver metadata to use in
analysis.
Login
Allows user entry of authentication
credentials.
Restricted to specific test users.
New User
Allows a user to create an account and
select a membership.
Not implemented because of scope.
Settings
Allows user to alter application settings
and options.
Not implemented because of scope.
Trip Editing
Allows user to specify a new route to be
saved or modify an existing route.
Restricted to limited test area.
Route Tracer
Program function to track a route to be
saved as it is driven by the user.
Not implemented because of scope.
Travel Map
Non-interactive screen that displays
current traffic conditions while driving.
This is implemented.
End of Trip
Presents statistics about last trip and any
appropriate options to edit the stored
route.
This is implemented.
Simulation Console
Virtual Checkpoints
GPS
Latitude/Longitude
Coordinates
Not implemented in Final Product.
Demonstration interface for
simulated driving scenarios.
Associates GPS coordinates along roads
with checkpoints.
Simulated coordinates for handselected checkpoints.
Driver
Acknowledgement
Recognizes drivers passing GPS location
(checkpoint) as an event.
Upload user velocity at checkpoint being
passed / Download necessary traffic
updates for checkpoints along the route.
This is implemented on simulated
checkpoints.
Traffic Conditions
GUI
Data Exchange
Database
This is implemented on simulated
checkpoints.
Driver Profile
Database
Stores customer account information,
credentials, and payment method.
This is implemented with test users.
Virtual Checkpoint
Database
Stores checkpoint coordinates, current
traffic status, and historical statistics.
This is implemented with simulated
checkpoints.
Speed Limit Database
Stores static information on speed limits
for public access.
This is implemented.
LAB I
Team Blue
Features
Algorithms
Final Product
23
Prototype
Speed Aggregator
Analyzes and filters driver inputs to
determine current traffic speed.
This is implemented.
Checkpoint Allocator
Initial assignment of GPS coordinates to
initialize checkpoints.
Not implemented because of scope.
Checkpoint
Reallocator
Redistribution of checkpoints along roads
as determined by current checkpoint
statuses and historical patterns.
Only implemented on specific
driving scenarios.
Route Analyzer
Calculate delays, outputs alternate route
suggestions
This is implemented.
Next Checkpoint
Estimator
Estimates time to arrival at next
checkpoint from client side for
GPS/Data/Battery management.
This is implemented.
Route Matcher
Determines the closest Virtual Checkpoint
or set of checkpoints to a given GPS
coordinate or set of coordinates.
This is implemented.
Blockage Finder
Determines points on roads where traffic
flow is completely blocked.
This is implemented.
Driver Generator
Not implemented in Final Product.
Randomly generates virtual drivers
with speeds for testing purposes.
Table 1: Prototype and final product features.
3.4 Prototype Development Challenges
Many challenges face a project of this scale. Huge data volumes, network latency and
algorithm efficiency all play a large role in the success or failure of Traffic Wizard. Developing
the prototype provides an environment to experiment with different methods and ultimately
arrive at optimal solutions to the problems it faces.
The data that arrives at users’ smartphones must be accurate, otherwise trust is lost in the
application and they may end their participation. Reduction in user base means fewer traffic
sensors at the disposal of the system, and a negative feedback loop of dysfunction may occur. To
ensure that data is accurate and timely, multiple methods must be employed to test and regulate
the accuracy of data. Checkpoint reallocation, statistical analysis, normalization of input, and
prototype experimentation must all be used to work around corrupt data and find new ways to do
LAB I
Team Blue
24
so.
One goal of Traffic Wizard is to provide drivers timely information while minimizing the
data bandwidth on their smartphones, which translates directly into monetary cost. On the server
side, less data means faster execution and fewer necessary resources. Therefore, determining the
least possible amount of data needed to accurately gather traffic information must be determined
in the prototype phase, and test cases shall prove or disprove methods for optimizing data
conveyance.
The amount of data that will be received by any coverage area’s server will be immense The
prototype must provide a proof of concept as well as a testing environment to improve results as
much as possible. By analyzing a server’s input capacity through experimentation, the optimum
number of servers per coverage can be determined according to area square mileage or
population. It may also be found that different types of servers are needed to serve special needs
of a particular coverage area.
4 Glossary
Alpha testing – the initial testing phase for the development of the final product, which lasts 30
days and be closed to the public.
Beta testing – the second and final testing phase for the final product’s development, lasting 90
days and using the public to provide test data.
Blockage Finder – algorithm that determines whether traffic flow has completely stopped
at Virtual Checkpoints.
Checkpoint Allocator -- the algorithm that generates the initial set of Virtual Checkpoints
for a new coverage area.
Checkpoint Reallocator – the algorithm that continuously add and subtracts Virtual
Checkpoints from the database to optimize performance.
Distraction – any stimulus originating from the application that could cause the driver to divert
either their listening or visual attention from driving to the phone.
LAB I
Team Blue
25
Drive Mode – the collection of algorithms, processes and event listeners that operate while
the user is driving.
Driver Generator – simulation algorithm that creates artificial driver objects to send and
receive simulated data in the prototype demonstration.
Driver Profile Database – stores all information about users regarding subscriptions.
Driver – a person driving a car, but not necessarily using Traffic Wizard.
End User – anyone who has the application on their smartphone and uses it, therefore providing
the system with data.
Driver Profile – the collection of trips (and alternatives for each route) for a specific user.
Google Maps API – may be required to be purchased for an android version of the client
application due to the volume of queries.
GPS – a satellite powered high precision location tracking system.
Incidental Traffic Congestion – congestion due to usually unforeseeable circumstances, like
construction (foreseeable) or accidents (unforeseeable).
Next Checkpoint Estimator – smartphone algorithm that determines how long until the
user encounters the next checkpoint on their trip; used to optimized performance.
Periodic Traffic Congestion – traffic due to the patterned rise and fall in volume of cars
travelling on a road at certain times of day.
Pre-travel Analysis – a check that is performed before a user’s programmed trip’s departure
time to decide an initial route to take.
Pre-weighting System – the functions that affect how speed input is weighted against the
current aggregate speed.
Road Segment – a length of a road whose endpoints are Virtual Checkpoints.
Route – one of several alternative paths from a starting location to a destination.
Route Analyzer – the algorithm that estimates travel times for a given trip, examining multiple
alternate routes between the start and end points.
Route Matcher – algorithm that accepts a list of latitude/longitude coordinates and
returns a list of Virtual Checkpoints that defines the same route.
LAB I
Team Blue
26
Simulation Console – a graphical interface that visualizes the simulation’s datasets through
maps and tables, and provide for controls to change variables, begin new scenarios, and
manage execution of algorithms.
Speed Aggregator – the algorithm that takes raw input data and combines it into weighted
averages per checkpoint.
Speed Limit Database – holds speed limit information for roads in a given coverage area
for use by the Route Analyzer.
Still Mode – the state of the smartphone app while a user is not driving according to a
preprogrammed route.
Traffic Avoidance – any attempt to circumvent traffic, whether by altering travel times or
geographical routes.
Traffic Scenario – any possible state of flow of all the roads in a network.
Traffic Wizard – the combination of central processing servers and smartphone clients that
make up a monitored mobile sensor network to monitor traffic statuses and inform users.
Travel Data Collection – an anonymized system to gather speed, location, and heading data as
users travel.
Trip – a start location and destination with one or more ways to go between them.
Virtual Checkpoints – locations along roads stored as latitude-longitude coordinate pairs which
can have associated data and statistics, whose populations dynamically grow and shrink
according to existing checkpoints’ values.
Virtual Checkpoint Database – server database that holds the collection of Virtual
Checkpoints for a given coverage area.
LAB I
Team Blue
27
5 References
Chitu, Alex. “Google Maps Mobile Users Send Traffic Data.” Google Operating System. (25
August 2009). Retrieved from http://googlesystem.blogspot.com/2009/08/google-mapsmobile-users-send-traffic.html
“Licensed Drivers, Vehicle Registrations and Resident Population.” (2004). U.S. Department of
Transportation Federal Highway Administration. Retrieved from
http://www.fhwa.dot.gov/policy/ohim/hs04/htm/dlchrt.htm
Lomax, Tim, David Schrank and Shawn Turner. Texas Transportation Institute.
(2011). Annual Urban Mobility Report. College Station, TX. Retrieved from
http://mobility.tamu.edu/ums/
Martin, James. “1679 to 1681. Trolley Steam RP Verbiest.” (2005). History of the Automobile:
Origins to 1900. Retrieved from
http://users.skynet.be/tintinpassion/VOIRSAVOIR/Auto/Pages_auto/Auto_001.html&sa=
X&oi=translate