Running  Head:  LAB  I     1  

Lab I

Author(s): Andrew McKnight Version: 2

For: CS411 Professor: Brunelle

Document Purpose: Describe and compare the prototype and final product.

Last updated: February 28, 2012

     LAB  I     Team  Blue      

   

2  

Table of Contents 1 Introduction ............................................................................................................................... 3 2 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   Final  Product   Prototype  Data  Miner          

Traffic  Conditions  It  will  retrieve  real-­‐time  travel  information  from  drivers  using  the  app.  

Simulated  driver  metadata  to  use  in  analysis.  

GUI          

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   Not  implemented  in  Final  Product.  Demonstration  interface  for  simulated  driving  scenarios.  

Virtual  Checkpoints          GPS  Latitude/Longitude  Coordinates  

Associates  GPS  coordinates  along  roads  with  checkpoints.  

Simulated  coordinates  for  hand-­‐selected  checkpoints.  

Driver  Acknowledgement  

Recognizes  drivers  passing  GPS  location  (checkpoint)  as  an  event.  

This  is  implemented  on  simulated  checkpoints.  

Data  Exchange  

Upload  user  velocity  at  checkpoint  being  passed  /  Download  necessary  traffic  updates  for  checkpoints  along  the  route.  

This  is  implemented  on  simulated  checkpoints.  

Database          

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      

   

23  

Features   Final  Product   Prototype  Algorithms          

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-maps-mobile-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