Running Head: Lab 2 Prototype Requirements 1. Lab 2 Prototype Requirements

Transcription

1 Running Head: Lab 2 Prototype Requirements 1 Lab 2 Prototype Requirements Author(s): Andrew McKnight Version: 2 For: CS411 Professor: Brunelle Document Purpose: Outline requirements for prototype development. Last updated: March 28, 2012

2 Lab 2 - Prototype Requirements Team Blue 2 Table of Contents 1 Introduction Purpose Scope Definitions and Acronyms References Overview General Description Prototype Architecture Description Prototype Functional Description External Interfaces Hardware Interfaces Software Interfaces User Interfaces Communication Protocols/Interfaces List of Figures Figure 1: Traffic Wizard system process flow Figure 2: Data flow in Traffic Wizard, including prototype components Figure 3: Smartphone application GUI sitemap List of Tables Table 1: Prototype features.... 5

3 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

4 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.

5 Lab 2 - Prototype Requirements Team Blue 5 Data Miner Features Final Product Prototype Traffic Conditions GUI Login New User Settings Trip Editing Route Tracer Travel Map It will retrieve real-time travel information from drivers using the app. Allows user entry of authentication credentials. Allows a user to create an account and select a membership. Allows user to alter application settings and options. Allows user to specify a new route to be saved or modify an existing route. Program function to track a route to be saved as it is driven by the user. Non-interactive screen that displays current traffic conditions while driving. Simulated driver metadata to use in analysis. Restricted to specific test users. Not implemented because of scope. Not implemented because of scope. Restricted to limited test area. Not implemented because of scope. 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 Driver Acknowledgement Data Exchange Database Driver Profile Database Virtual Checkpoint Database Speed Limit Database Not implemented in Final Product. Associates GPS coordinates along roads with checkpoints. 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. Stores customer account information, credentials, and payment method. Stores checkpoint coordinates, current traffic status, and historical statistics. Stores static information on speed limits for public access. Table 1: Prototype features. Demonstration interface for simulated driving scenarios. Simulated coordinates for handselected checkpoints. This is implemented on simulated checkpoints. This is implemented on simulated checkpoints. This is implemented with test users. This is implemented with simulated checkpoints. This is implemented.

6 Lab 2 - Prototype Requirements Team Blue 6 Algorithms Features Final Product Prototype Speed Aggregator Checkpoint Allocator Analyzes and filters driver inputs to determine current traffic speed. Initial assignment of GPS coordinates to initialize checkpoints. This is implemented. Not implemented because of scope. Checkpoint Reallocator Route Analyzer Next Checkpoint Estimator Route Matcher Blockage Finder Redistribution of checkpoints along roads as determined by current checkpoint statuses and historical patterns. Calculate delays, outputs alternate route suggestions Estimates time to arrival at next checkpoint from client side for GPS/Data/Battery management. Determines the closest Virtual Checkpoint or set of checkpoints to a given GPS coordinate or set of coordinates. Determines points on roads where traffic flow is completely blocked. Only implemented on specific driving scenarios. This is implemented. This is implemented. This is implemented. This is implemented. Driver Generator Not implemented in Final Product. Table 1: Prototype features (continued). Randomly generates virtual drivers with speeds for testing purposes. 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

7 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.

8 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 Lomax, Tim, David Schrank and Shawn Turner. Texas Transportation Institute. (2011). Annual Urban Mobility Report. College Station, TX. Retrieved from McKnight, Andrew. Lab 1 Product Description. CS411. February 8, 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

9 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.

10 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.

11 Lab 2 - Prototype Requirements Team Blue 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

12 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.

13 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.]

14 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 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.

15 Lab 2 - Prototype Requirements Team Blue 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 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.

16 Lab 2 - Prototype Requirements Team Blue 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.]