Lab 2 – Traffic Wizard Prototype Specification1

Running Head: Lab 2 – Traffic Wizard Prototype Specification

Lab 2 – Traffic Wizard Prototype Product Specification

Traffic Wizard – Blue Team

Old Dominion University

CS 411 - Brunelle

Author: Andrew Crossman

Last Modified: March 8, 2012

Version: 2.0

Table of Contents1.Introduction41.1.Purpose51.2.Scope101.3.Definitions and Acronyms131.4.References161.5.Overview162.General Description162.1.Prototype Architecture Description172.2.Prototype Functional Description192.3.External Interfaces212.3.1.Hardware Interfaces222.3.2.Software Interfaces222.3.3.User Interfaces222.3.4.Communication Protocols / Interfaces233.Specific Requirements243.1.Functional Requirements243.1.1.Databases (Kennedy)243.1.2.Algorithms293.1.3.Simulation Console (Crossman)383.1.4.GUI443.2.Performance Requirements553.2.1.Database Read/Write Speed (MacLeod)553.2.2.Smartphone Resource Management (Godavarthi)563.2.3.Wireless Data Transmission/Fidelity (Dong)573.2.4.Algorithm Efficiency (McKnight)573.2.5.Simulation Demonstration (Crossman)583.3.Assumptions and Constraints593.4.Non-functional Requirements (Godavarthi)603.4.1.Security (Godavarthi)603.4.2.Maintainability (Godavarthi)613.4.3.Reliability (Godavarthi)613.4.4.Server Uptime/Redundancy (Godvarthi)61

List of Figures

Figure 1: Traffic Wizard Update Process7

Figure 2: Traffic Wizard Data Flow9

Figure 3: Prototype Major Functional Components19

Figure 4: Checkpoint Data Exchange21

Figure 5: Traffic Wizard Prototype App Site Map23

Figure 6: Driver Profile Database ERD25

Figure 7: Virtual Checkpoint Database ERD27

Figure 8: Speed Limit Database ERD28

Figure 9: Checkpoint Allocator Road Model31

Figure 10: Next Checkpoint Estimator Schematic37

Figure 11: Traffic Wizard Login and Main Screen46

Figure 12: New Trip Menu Screens47

Figure 13: Route Tracer Screen48

Figure 14: Current Trips Menu and Trip Details Screen49

Figure 15: End of Trip Screen49

Figure 16: Delay Notification Screen50

Figure 17: Simulation Console Site Map51

Figure 18: Simulation Console Main Menu52

Figure 19: Traffic Simulation Window55

Figure 20: Simulation Dashboard Expanded56

List of Tables

Table 1: Prototype Features Table11

Table 2: Driver Profile Database26

Table 3: Virtual Checkpoint Database27

Table 4: Speed Limit Database29

Table 5: Assumptions and Constraints61

Introduction

What could easily be considered as one of the world’s most inconvenient societal problems is that of heavy traffic in high population areas. In regions where population growth exceeds the road capacity, traffic flow often becomes congested, which delays many drivers on the way to their respective destinations. Americans suffer 4.8 billion hours of excess commute time every year while 1.9 billion gallons of excess fuel is consumed while waiting in traffic (Texas Transportation Institute, 2011). These costs tend to be incurred the most in very largely populated areas when the data is grouped and analyzed. The amount of traffic on the road is a time-sensitive statistic, which makes it difficult to accurately predict what traffic conditions will be like as a driver travels a specific route. There are many factors involved in the way we currently handle heavy traffic avoidance, each with their own liabilities.

Current methods for determining if heavy traffic lies ahead are not reliable enough to be considered effective. Visual cues are too dependent on environmental factors and are not timely enough to be considered practical in avoiding traffic. Information on traffic conditions through the media, traffic cameras, or a friend is simply not timely enough to be accurate and cannot always be accessed easily. GPS devices sometimes have a traffic monitoring feature, but these devices are prone to connectivity issues and errors when their software becomes outdated. Current mobile apps are a source of distraction and are known to promptly deplete a user’s battery level and put a burden on their network data usage. These risks with smartphone apps need to be mitigated through a means that puts less strain on a user’s smartphone battery and minimizes the amount of data usage needed, but still provide timely traffic information.

Traffic Wizard is a personalized smartphone app solution to help inform drivers of traffic conditions in real-time before and during their trip. The app will feature travel profiles that let drivers store their most frequent routes and set times for their route to be analyzed by the server prior to travel time. By advising alternate routes during a trip to avoid unfavorable traffic congestion, Traffic Wizard will reduce the amount of delay that a driver encounters on their trip.

Purpose

The goal of Traffic Wizard is to inform drivers of poor traffic conditions in real-time, meaning the information can be utilized in a timely enough manner for a driver to take an alternate route if they wish. Each registered user has their own driver profile that they can use to keep track of their most frequently travelled routes. These routes will have the capability to be manually entered by a user, or traced when a user drives to be stored on their phone. Through their driver profile, users can select a route (such as their drive from work to home) to be analyzed by the Traffic Wizard server at a slightly earlier time prior to the expected travel time. This allows the user to get a quick idea of what the current traffic conditions are before they go to drive the route.

The foundation of the Traffic Wizard user base will be drivers with smartphones who live in high population areas, since they are the ones most likely to experience traffic congestion. Areas with the largest population sizes tend to suffer the most significiant costs from traffic congestion. Very large population areas incur the highest aggregate cost, most hours delayed, and highest amount of fuel excess out of various population sizes ranging from large to small (Texas Transportation Institute, 2011). While the app will be accessible to drivers all over the United States, these more densely populated areas are the expected focus for Traffic Wizard operational activity. Users who live in these regions are recognized as having the largest potential to benefit from the Traffic Wizard system of updates.

The other main factor for determining the Traffic Wizard customer base is the accessibility of the software app. Only drivers who have access to a smartphone that runs an Android or iOS operating system will be able to download and use Traffic Wizard. While this may seem like a limiting factor in defining the scale of the customer base, studies have shown that smartphones are rapidly gaining popularity each year. With research proving that smartphones powered by Android and iOS operating systems are on the rise (Email Marketing Reports, 2011), the Traffic Wizard app can be released on this market with confidence and guaranteed accessibility.

Another prospective user base for gathering useful information for traffic patterns are commercial group vehicles, such as shipping vans. If a device running the Traffic Wizard software is present in a commercial vehicle, then any delays encountered can be assessed for statistics useful for determining traffic patterns at different times of the day or specific days of the year. These findings can be very beneficial in saving time and money for a business willing to incorporate the Traffic Wizard system.

The main feature of Traffic Wizard is the service of delivering real-time traffic updates to drivers within a specific geographic proximity. For this information to be assessed and delivered effectively, an innovative data collection system is used called the Virtual Checkpoint System. Using this system for mining traffic data from all phones on the road, the Traffic Wizard server can receive and analyze incoming data, which includes latitude and longitude coordinates, current speed, and heading. The server then returns information on the traffic status in real-time to other devices that request the updates. Data exchange that occurs between the driver’s app and the server triggers the analysis of upcoming roads, as seen in Figure 1. The added feature of a driver profile allows users to have their saved routes analyzed in an efficient manner.

Figure 1: Traffic Wizard Update Process

Virtual checkpoints are simulated entities that are associated with specific latitude and longitude coordinates and are strategically placed along roads. Each checkpoint is noted with a color-coded traffic status as well to represent the traffic conditions in that area. A green traffic status would notate that there is little to no congestion causing delay at that road segment, while a red status would indicate that traffic is very congested or halted in that area. These virtual GPS locations act as flags for the Traffic Wizard app to upload travel data for the driver and download necessary updates for upcoming roads as determined by the server. This travel data includes their location (the checkpoint they are passing), speed, and heading. Since virtual checkpoints have the functionality of roadside nodes and the benefit of being digitally defined, checkpoints can be reallocated on demand for special traffic conditions. Checkpoints could be allocated within a small area to help determine blockages, or could be moved around on a larger scale during times like rush hour to assist in bringing more accurate updates to users.

Data exchange is set to occur when a driver’s current GPS location matches the coordinates of a known virtual checkpoint. The app sends the information to the server and receives updates to the status of upcoming checkpoints if that status has changed since the last update. If checkpoints along the remainder of a driver’s route have a new traffic status, indicating that traffic conditions have changed there, the app will display the new status once it receives this update from the server. This feature of Traffic Wizard makes an effort to reduce the typical drain on a user’s data usage and battery life by using a caching system for the checkpoints along a user’s route. When a driver selects a route to be driven, the app performs an initial download of the list of checkpoints that occur on that route and any immediate alternative routes. With these coordinates downloaded, the app can do GPS comparisons locally to determine when it has passed a checkpoint, as opposed to always polling the server for the next location to send the travel data. The app will have the option to turn off the GPS entirely if determines that the time until the next checkpoint is a longer duration.

[Space intentionally left blank.]

Figure 2: Traffic Wizard Data Flow

Through this efficient method of data exchange, useful information for traffic analysis is uploaded to the Traffic Wizard server. When the server receives this metadata, it runs a set of algorithms on the travel information to determine if traffic flow is optimal at that checkpoint or if there is any congestion to identify. The output from these algorithms can return that the multiple speeds being uploaded at a specific checkpoint are all below the known speed limit, which would indicate that traffic is becoming increasingly congested in that area. Proper speed limits are determined through a speed limit database that is used to reference public information on posted speed limits for every road. The checkpoint that is associated with that status may be labeled as yellow to indicate the level of congestion. This system of using real-time travel data as it is being uploaded to properly analyze traffic conditions is an effective means of providing timely and accurate predictions on traffic.

Every user of Traffic Wizard is given a customizable driver profile – where they can save their favorite or most frequent routes for easy accessibility. Users are able to select a route and add the time periods that they typically have to drive that route or just enter the time they know they will be traveling that route next. By doing this, the app can send a request to the server with the preprogrammed route to download and cache a list of checkpoints for the route in advance. This assists in keeping data usage at a minimum for the user’s device and provides a quick way to know what the upcoming traffic status will be like for a regular trip.

Some traffic-monitoring features and guarantees will not be available through the Traffic Wizard system. Drivers who use the app are not guaranteed to see a decrease in delay for their trip since there are other factors that determine when a driver gets delayed on their trip. It is also not guaranteed that real-time traffic information will be available to drivers in certain areas depending on the number of Traffic Wizard users who drive that route. Traffic Wizard is not a utility that promises to prevent traffic congestion, but instead offers assistance in helping drivers reduce the delay they experience in their normal trip. Another limitation to Traffic Wizard information is that when a blockage is found during traffic analysis, that blockage cannot be fully identified as an accident, construction, or other event. Only the fact that a blockage exists and is delaying traffic is told to the user when this occurs. Other features not implemented in Traffic Wizard include detection of emergency response vehicles on the road and turn-by-turn directions to a destination.

Scope

Traffic Wizard, as a final product, will cover large geographic areas across the country and focus on metropolitan areas with higher population densities. This will ultimately be accomplished through Traffic Wizard regional centers for the necessary servers to cover these regions. As a prototype, the scope of Traffic Wizard must be decreased to accommodate testing and demonstrating the system on a smaller scale. The geographical area covered, driver data being used, driver profile routes, and server processes will all be affected by the reduced scope of the prototype. By demonstrating the Traffic Wizard systems on a smaller scale, and proving that the system is efficiently scalable, the innovative concepts of this system can be proven as effective. The various features of the Traffic Wizard prototype can be observed in Table 1.

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.

Features

Final Product

Prototype

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.

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 Features Table

The geographical scope will be reduced to cover areas within Hampton Roads, Virginia. Since the development team (Team Blue) for Traffic Wizard is localized in Norfolk, Virginia at Old Dominion University, the starting region will be the university and surrounding roads. A full set of the geographic regions to be used in the prototype are outlined in Section 3.1.3.1. Old Dominion University is being used as the smallest region, with larger areas in Norfolk and Portsmouth being used for the medium and largest regions of the demonstration. In the larger regions, highway corridors and interstates will be the focus to determine how the Traffic Wizard system handles traffic updates in that situation.

Data being used by the server to produce traffic statuses will be simulated information in the prototype. Since the final product relies on real-time information being uploaded from drivers using the app, the prototype will be unable to benefit from this stream of data. A specialized Driver Generator algorithm (Section 3.1.2.8.) will be used to simulate the event of a driver entering the region being monitored during the demonstration. The simulated data will be derived from real world coordinates obtained by Team Blue members using the Traffic Wizard Route Tracer feature to gather coordinates and speeds for various routes. This data will not be used directly in the simulation, but will act as a foundation for calculations in determining the rate of traffic flow.

Since the demonstration of Traffic Wizard’s systems will be a simulation, the data will be exchanged in a time-stepping manner. As the simulation time advances to represent real time, data will be exchanged between virtual driver entities in the simulation and the server based on a virtual clock. Events such as new drivers entering the region or reaching their destination are based on simulation time that must be incremented as the simulation runs. With supported animation in the Simulation Console (Section 3.1.3.), this process will make the movement of virtual drivers and data exchange seem as though it is occurring at real-time, which the final product will do.

Definitions and Acronyms

Alpha Testing – First testing phase for Traffic Wizard that will be available to select institutions (closed access) for a duration of 30 days.

Beta Testing – Second testing phase for Traffic Wizard that will be available to the public (open access) as a demo for a duration of 90 days.

Blockage Finder – The server algorithm that determines if a blockage exists that is slowing or stopping traffic flow.

Checkpoint Allocator – The server algorithm that associates virtual checkpoints to their initial latitude and longitude coordinates for a specific region.

Checkpoint Re-allocator – The server algorithm that continuously adds and removes virtual checkpoints from the Virtual Checkpoint Database to improve accuracy and performance when evaluating traffic conditions.

Custom Route – Any user-entered route (start and end location) that is saved to the phone to be driven later.

Driver Generator – The Simulation Console component that is responsible for creating and handling virtual driver entities during prototype simulation demonstrations.

Driver Profile – App feature that allows users to store their most frequent (or favorite) routes that they travel to be saved on their device. Stored routes can be pre-analyzed by the server.

Driver Profile Database – The Traffic Wizard secure database that contains login information and payment details for users that have purchased the app.

Google Maps API – Web mapping service provided by Google that is utilized by Traffic Wizard for route analysis.

Incidental Traffic Congestion – Traffic congestion caused by an unexpected event such as an accident or emergency situation.

Next Checkpoint Estimator – The client app algorithm that uses the list of known virtual checkpoints along a route to estimate when the next virtual checkpoint will be passed.

Periodic Traffic Congestion – Traffic congestion due to the patterned rise and fall in volume of cars travelling on a road at predictable times (such as rush hour).

Pre-travel Analysis – Route analysis report that is computed by the Traffic Wizard server prior to the time that the user expects to drive that route.

Road Segment – Any defined, unbroken partition of road that lies between intersections to be used in assembling custom routes.

Route – Particular set of road segments that a user drives to reach their destination.

Route Analyzer – Main app feature and server algorithm that focuses on the route that a user is currently driving on to be analyzed for traffic status and report to the user (and make alternate route suggestions if applicable).

Route Matcher – The server algorithm that determines the closest virtual checkpoint to a given set of GPS coordinates in order to define the route being driven.

Simulation Console – Application developed during prototype stage to be used as a demonstration platform for Traffic Wizard. This platform will hold data for multiple driving scenarios to be called for demonstration.

Speed Aggregator – The server algorithm that accepts raw driver speed data and calculates weighted averages per virtual checkpoint.

Speed Limit Database – The database that will be referenced by the server when determining the appropriate speed for drivers to be travelling at on a given road.

Traffic Scenario – A representation of a set of realistic and unique traffic conditions to be used in the Simulation Console demonstrations.

Traffic Wizard – Traffic-monitoring smartphone app and server system developed by the CS 411 Blue Team.

Trip – A specific instance of travel along a user’s custom route.

Virtual Checkpoints – Traffic Wizard system for labeling specific latitude and longitude coordinates along roads to act as representations the traffic status in that area and as flags to trigger data exchange for drivers.

Virtual Checkpoint Database – The database that holds metadata (ID, latitude and longitude coordinates, and traffic status) on all virtual checkpoints being used in traffic monitoring and analysis.

Virtual Driver – Entities used in the Simulation Console demonstrations that simulate real-world drivers using preset routes and destinations.

References

Lab 1 – Crossman, Andrew – Traffic Wizard Product Description. CS 411. Spring 2012.

Brownlow, M. (September 2011). Smartphone Statistics and Market Share. Email Marketing Reports. Retrieved from http://www.emailmarketing-reports.com/wireless-mobile/smartphonestatistics.htm

Lomax, T., & Schrank, D., & Turner, S. (2011). Annual Urban Mobility Report. Texas Transportation Institute. Retrieved from http://mobility.tamu.edu/ums/

Schroeder, S. (May 19, 2011). Smartphone Sales Up 85% Year-Over-Year. Mashable Tech. Retrieved from http://mashable.com/2011/05/19/smartphone-sales-q1-2011-gartner/

Overview (8 lines)

Specific requirements for the Traffic Wizard prototype are outlined in this document to provide a foundation for building the various components involved in the system. Specifications for the Traffic Wizard prototype include functional, non-functional, and performance requirements. These requirements define how the prototype system should operate within the assumptions and constraints as defined in Section 3.3. The purpose of this document is to guide a programmer who is assigned to build certain components of the Traffic Wizard prototype with exact requirements for each part of the system. The information in Sections 2 and 3 can be utilized to create the full prototype as designed by Team Blue.

General Description

The Traffic Wizard system offers features that require cooperation among software and hardware components in order to bring timely information to end users. In order to do this, the prototype must put the planned concepts and designs to be tested against simulated data to prove that the system works. Operation of these various components requires specific functionality in order to accomplish these features, such as smartphone app stability and server algorithm efficiency. This section describes how the prototype system for Traffic Wizard will be designed to prove the defined concepts.

Prototype Architecture Description

The major functional components of the Traffic Wizard prototype are shown in Figure 3. The prototype system is comprised of two main divisions – the client-side smartphone app and the server, which will reside on a virtual machine and consist of software to run algorithms and the prototype Traffic Wizard databases. The client app for the prototype will have all the functional GUI components described in the Prototype Features Table (Table 1) in Section 3.3 to be used in the simulation. The app will take server output as though the app were being used during a trip and display the appropriate information to inform of traffic conditions on the created checkpoints. The prototype server will be responsible for generating dynamic drivers virtually with specific parameters to match the real world input from drivers. Using these data sets, which are modeled according to the various scenarios, the server parses the data and runs the necessary algorithms to return a traffic status for the data’s associated virtual checkpoint.

Figure 3: Prototype Major Functional Components

The simulated data that the server generates to represent drivers on the road is passed through the appropriate algorithms and stored in the virtual checkpoint database. The virtual checkpoint database in the prototype holds a subset of the data that the full real world product database would hold. Each virtual checkpoint’s designated coordinates are stored within the database, along with a determined traffic status. These resulting traffic statuses can be viewed in the simulation at the coordinates where that virtual checkpoint is located. The prototype will feature a scaled-down version of the driver profile database as well by allowing a user to create a profile and start adding routes. Their profile is stored on the database as a registered user. To run the Traffic Wizard algorithms, a reference to a public speed limit database will also be used when the algorithm needs to determine the proper speed limit of certain roads during analysis. The Traffic Wizard virtual machine server will require some software packages to become functional and work with the other components of the system. This mainly consists of Apache, MySQL, and PHP MyAdmin.

Prototype Functional Description

The prototype of the Traffic Wizard system involves three main components: the smartphone app, server, and Simulation Console. The Traffic Wizard prototype app, while not available for public users to download and experience, will be designed to support most of the functionality of the final product app. Along with transitioning GUI menus properly, the app must be stable enough during operation to not terminate due to a software bug.

The prototype server will contain most of the elements that the final product server will, but on a reduced scale to handle the simulated driver data that is being used. This server will still have a Driver Profile Database and Virtual Checkpoint Database to be used in the simulations. The prototype versions of driver profiles will still support creating and editing custom routes along with setting pre-analysis times for the route by the server. These profiles will be manually created templates for information and will not be actual user profiles as expected in the final product.

Virtual checkpoints used in the prototype will still function as they would in the final product. Instead of having a virtual checkpoint’s GPS location compared to an actual driver’s coordinates, it would be compared with a simulated set of coordinates for a virtual driver. This data should not differ between the two scopes, so the checkpoints can be used as designed for the final product. Virtual checkpoints used in the prototype act as agents for sending virtual driver data (speed and heading) to the server to be processed and have resulting traffic updates sent back to the virtual driver. This process of exchanging data can be observed in Figure 4.

Figure 4: Checkpoint Data Exchange

The most physical part of the Traffic Wizard prototype is the communication between a smartphone running the app and the Traffic Wizard server. Since a prototype app will be developed for deployment on a mobile device, that app will have capabilities to send information to the Traffic Wizard server when necessary. In the prototype, the only information that will be sent from the device is a list of GPS coordinates that were polled on the device using its own GPS functionality. This is to prove the information can be sent to the server from the Traffic Wizard app, and not to demonstrate how the app will be utilized in the real world product. Since the prototype will not be available to be driven around, the data sent from a device running the prototype app will not be in the standard format for the data packet (checkpoint ID, speed, and heading).

The platform used to implement these features and demonstrate the prototype is the Simulation Console. This system will have the means to generate virtual drivers using a Driver Generator and display a simulation of the traffic monitoring process based on a selected traffic scenario and region size (Section 3.1.3.) The Simulation Console will need to interact with the server in order to call necessary algorithms for the simulation being executed. Simulations will need to be executed in a timely enough manner, including all calls to the server for computations, to accurately represent real-time traffic conditions.

External Interfaces

This section outlines the physical and logical interfaces used within the Traffic Wizard prototype. This includes hardware, software, and user interfaces, as well as the communication protocols involved. Interfaces for the client app and server will be described, as well as the prototype-exclusive Simulation Console.

Hardware Interfaces

The Traffic Wizard prototype consists of only a few hardware interfaces. Since a prototype smartphone app is being developed, the smartphone (Android and iOS) is the main hardware interface. A 3G Internet connection module and GPS module are integrated into smartphone hardware and will both be utilized in the prototype. As for the prototype simulations of the system, an Old Dominion University laptop will be running the Simulation Console (Section 3.1.3.) while a virtual machine hosted by the ODU Computer Science department will act as the Traffic Wizard server. These are the only hardware interfaces involved in the Traffic Wizard prototype.

Software Interfaces

Team Blue administrators will interface with the server and MySQL database using SQL queries and PHP scripts. Using PHP, results from the database can be formatted accordingly depending on what server component has called for the information. Server applications will be built in Java and Perl in order to run algorithms and interface with server operations. The Simulation Console interface, used for demonstrating the Traffic Wizard prototype, will be built using the .NET 4.0 platform and will contain functionality for displaying demonstrations and changing parameters for simulations.

User Interfaces

The only user interface involved in the Traffic Wizard prototype is for the smartphone app. This prototype app will contain the GUI screens as outlined in Section 3.1.4.1. This interface is not meant for public use but instead acts as a proof-of-concept for specific Traffic Wizard features, such as driver profiles and the Route Tracer utility. The site map for the prototype app is displayed in Figure 6.

[Space intentionally left blank.]

Figure 5: Traffic Wizard Prototype App Site Map

Functionality of the smartphone user interface will be limited for demonstration purposes. The Login screen will not support actual user credentials, since there will not be any real Traffic Wizard users to authenticate for this process. Test information will be used to authenticate a user and create a driver profile to be stored on the Driver Profile Database (Section 3.1.1.1.). Route creation and editing will be supported, as well as the Route Tracer utility, which will utilize the smartphone GPS system to record the latitude and longitude coordinates of the device.

Communication Protocols / Interfaces

Two main protocols are used in Traffic Wizard server operations, Transmission Control Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol (UDP). TCP/IP will be used by the Simulation Console to establish a connection with the Traffic Wizard server on the Old Dominion University network to be used as necessary during simulations. UDP will be used by the smartphone app to demonstrate pushing driver data (location, speed, and heading) to the server without the need to establish and acknowledge a connection.