Running Head: Lab 2 – Prototype Requirements
1
Lab 2 – Prototype Requirements
Author(s):
Version:
For:
Professor:
Document Purpose:
Andrew McKnight
2
CS411
Brunelle
Outline requirements for prototype
development.
Last updated: March 28, 2012
Lab 2 - Prototype Requirements
Team Blue
2
Table of Contents
1
Introduction ............................................................................................................................... 3
1.1 Purpose.................................................................................................................................. 4
1.2 Scope ..................................................................................................................................... 4
1.3 Definitions and Acronyms .................................................................................................... 6
1.4 References ............................................................................................................................. 8
1.5 Overview ............................................................................................................................... 8
2
General Description .................................................................................................................. 9
2.1 Prototype Architecture Description ...................................................................................... 9
2.2 Prototype Functional Description ....................................................................................... 11
2.3 External Interfaces .............................................................................................................. 14
2.3.1 Hardware Interfaces ................................................................................................... 14
2.3.2 Software Interfaces .................................................................................................... 15
2.3.3 User Interfaces ........................................................................................................... 15
2.3.4 Communication Protocols/Interfaces ........................................................................ 16
List of Figures
Figure 1: Traffic Wizard system process flow. ............................................................................. 13
Figure 2: Data flow in Traffic Wizard, including prototype components. ................................... 14
Figure 3: Smartphone application GUI sitemap. .......................................................................... 15
List of Tables
Table 1: Prototype features. ............................................................................................................ 5
Lab 2 - Prototype Requirements
Team Blue
3
1 Introduction
Traffic Wizard uses smartphone capabilities to gather traffic information and provide
drivers with opportunities to make the best possible travel decisions before they leave and 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
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.
Traffic Wizard is a personalized traffic assistant 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. Ultimately, individuals
Lab 2 - Prototype Requirements
Team Blue
4
will know of every possible opportunity to avoid traffic and get where they are going faster.
1.1
Purpose
The Traffic Wizard ecosystem involves several interdependent parts. All must be fully
functional, including communication capability. Risks do exist, from availability of user base
from which to gather data, to hardware malfunction, to cellular signal strength. The prototype
serves several purposes with respect to risk mitigation. It helps find the bounds of normal
operation of a given server configuration by experimentation. Algorithms can be troubleshot and
fine tuned to the actual amount of input they will receive in the real world. The prototype also
provides a test plan that serves as the foundation to building an automated testing framework.
Finally, the prototype shall serve as a demonstration of the capability of the system in its own
right, and as a realization of a small but significant societal tool.
1.2
Scope
The prototype implements most of the underlying mechanisms that carry out the crucial
analyses. As Table 1 shows, 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. The Old Dominion
campus and select highway corridors will be used for most of the prototype presentation.
Much of the data used for the prototype will be compiled ahead of time. Seed data for test
case startup will be manually created. Available routes for users to choose will be
preprogrammed using actual GPS data obtained by Team Blue staff. All realistic combinations of
seed data and variables will be tested to demonstrate the robustness of the algorithms.
Lab 2 - Prototype Requirements
Features
Data Miner
Team Blue
5
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.
Table 1: Prototype features.
Lab 2 - Prototype Requirements
Features
Algorithms
Team Blue
6
Final Product
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 features (continued).
1.3
Definitions and Acronyms
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.
Drive Mode – the collection of algorithms, processes and event listeners that operate while the
Lab 2 - Prototype Requirements
Team Blue
7
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.
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.
Lab 2 - Prototype Requirements
Team Blue
8
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.
1.4
References
“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/
McKnight, Andrew. “Lab 1 – Product Description.” CS411. February 8, 2012.
1.5
Overview
This document provides a general description of how the Traffic Wizard environment works
along with a description of each component. Hardware and software components will be
Lab 2 - Prototype Requirements
Team Blue
9
explained, as well as the interfaces between them. Requirements for the major algorithms,
databases and user interfaces of the prototype are set. Nonfunctional requirements regarding
security, performance and reliability are also outlined.
2
General 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 will inform the mitigation of risks like
user sparsity and technical failures.
2.1
Prototype Architecture Description
Figure 4: Functional components of the prototype.
Lab 2 - Prototype Requirements
Team Blue
10
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 4
shows how the server implementation will interact with the simulation driver and client devices.
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
algorithms are implemented on a virtual machine running Ubuntu Linux, which will include
installations of Apache, MySQL and PHPMyAdmin to facilitate networking and data storage.
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. A list of actual algorithms implemented in the prototype can be found in Table 1.
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.
Lab 2 - Prototype Requirements
2.2
Team Blue
11
Prototype Functional Description
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.
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
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
Lab 2 - Prototype Requirements
Team Blue
12
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
that are implemented discourage the user from interacting with the smartphone by either visual
inspection or touch.
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
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.
Execution of the simulation is controlled by a console residing on a separate machine,
outside the software system of Traffic Wizard itself. The console provides a user with start, stop
and reset controls, as well as a way to change environment variable for different traffic scenarios.
A map screen draws Virtual Checkpoints along the roads at their actual location with
visualizations depicting their speed values and timestamps.
Lab 2 - Prototype Requirements
Team Blue
13
Figure 1: Traffic Wizard system process flow.
Figure 1 details the order of events for sending and receiving data in the Traffic Wizard
environment. On a high level, data is sent from one user to the system, which sends data to many
users. Figure 2 elaborates on which kinds of data are send at different steps of the process.
[Space intentionally left blank.]
Lab 2 - Prototype Requirements
Team Blue
14
Figure 2: Data flow in Traffic Wizard, including prototype components.
2.3
External Interfaces
Both the prototype and real world product are systems of software and hardware
components. Some of these components exist in the world already, and all Traffic Wizard needs
is to work with it and use it functionality. Following are descriptions of some of the interfaces
used in the prototype.
2.3.1 Hardware Interfaces
Virtually all hardware interfaces needed for the Traffic Wizard system involve
components of the smartphone, except for necessary overhead like server mainframes or
workstations. The Objective-C CFStream library is used to interface with the smartphone’s
cellular connection. To get speed and location data, the CLLocation library is used to interface
with the GPS radio.
Lab 2 - Prototype Requirements
Team Blue
15
2.3.2 Software Interfaces
Several different software systems will communicate with one another during prototype
demonstration. The software layer providing access to the databases must be implemented in the
server code, which in Java will be the ConnectorJ API library for MySQL. The simulation
console will be implemented in C# on a separate machine, so it must communicate with the
server via network.
2.3.3 User Interfaces
Human users of the prototype application will be able to use the basic functions: creating
and editing trips, tracing routes, viewing delay notifications and trip begin and end routines. The
logical layout of the smartphone interface is outlined in Figure 3. The login screen is displayed
upon opening the application, after which the main menu appears providing access to other areas.
Figure 3: Smartphone application GUI sitemap.
Lab 2 - Prototype Requirements
Team Blue
16
2.3.4 Communication Protocols/Interfaces
In order for the Traffic Wizard system to work, the smartphones must be able to make
frequent connections to a server. The prototype will use the TCP protocol to send data to the
server and to receive it. In the prototype, it is essential that the few drivers involved all reliably
send their data. In the real world, UDP would be sufficient due to the large volume of users.
[Space intentionally left blank.]