Re-configurable Ad-hoc Network to Track Points of Interest

Transcription

1 Re-configurable Ad-hoc Network to Track Points of Interest Project Plan May September 28, 2011 Project Client: Jessica Miller Lockheed Martin, Advanced Development Programs Members: Benjamin J. Wiemers Robert D. Lourens Adrian S. Jagdeo Faculty Advisor: Dr. Ahmed Kamal

2 Table of Contents i. List of Figures ii. List of Tables iii. List of Definitions 1 Introduction 1.1 Executive Summary 1.2 Problem Statement 1.3 Acknowledgments 1.4 Operating Environment 1.5 Intended Users and Uses 1.6 Assumptions 1.7 Limitations 2 Expected End Product and Deliverables 2.1 Functional Requirements 2.2 Non-Functional Requirements 2.3 Security Design Considerations 2.4 Solution Approach Ad-hoc Network and Reconnecting Algorithm Hardware Interface and Information Sharing User Interface 2.5 Documentation 2.6 Possible Risks and Risk Management 3 Resources and Schedules 3.1 Work Plan 3.2 Financial Resources 3.3 Time Schedule 4 Closure Material 4.1 Project Team Information 4.2 Closing Summary 1

3 i. List of Figures Figure 1 System sketch, page 6 Figure 2 Node in system sketch, page 7 Figure 3 Time Spent on Components by Team Member, page 10 Figure 4 Project Gantt Chart, page 11 ii. List of Tables Figure 1 Project Phase Hours Breakdown, page 10 iii. List of Definitions Ad-Hoc - A type of network between various nodes. A ad-hoc network does not require a central controlling entity on the network. GPS - Global Positioning System determines the latitude and longitude of a sensor by means of radio signals. GUI - A Graphical User Interface allows system to graphically present information to a user and retrieve information from the user. Wi-Fi - Allows devices to communicate to one another with the use of radio signals. 2

4 1 Introduction 1.1 Executive Summary Performing wireless communication in radio-unfriendly environments is a problem with many diverse applications. Signal range can be significantly less than in optimal environments due to radio absorption, reflection, or interference. This is a unfortunate for anyone wishing to take advantage of wireless networking in these environments. When the network nodes are mobile, there is the added complication of needing to manage and monitor the network dynamically to ensure constant connectivity. One approach to this problem is to create an intelligent ad-hoc network. This would be a decentralized network of nodes where rather than sending traffic through a central router, all nodes act as routers for all other nodes. Where the size of a traditional network would be limited by the range from each node to the central router, the size of an ad-hoc network would be limited by the area that could be covered by a connected graph of network nodes, so it could cover a much larger area. Also, if any node is disconnected, the ad-hoc network could either route around it or physically rearrange its nodes to reestablish full connectivity. This problem fits well into Lockheed Martin s areas of research, as the applications of such a system could include military missions, police surveillance and search and rescue activities. They would like us to research, design, and implement a solution. 1.2 Problem Statement The goal of the project is to build a mobile ad-hoc network that will be able to facilitate cooperative missions between vehicles in complex urban environment. Each vehicle will share information such as speed, direction, location, fuel, and any other sensor output available, with the other nodes in the network. Each will receive this information from the other nodes and make it available to the user. If a node goes down and causes the network to become disconnected, the nodes will attempt to repair the network by making a recommendation to the user of what position to move to, based on previous GPS locations of the other nodes. 1.3 Acknowledgments Lockheed Martin will supply the necessary funding to complete this project. They will assist with any technical expertise when necessary. 1.4 Operating Environment The environment consists of an urban or wooded environment which will severely limit the transmission distance of Wi-Fi. The ad-hoc network will cover a much smaller area in this environment than it could in an optimal environment. The network will also likely split frequently, and nodes or groups of nodes will be isolated from the rest. This will have to be considered at 3

5 every step in the design and implementation of the network algorithms. This project will consider the Iowa State University Campus as the typical terrain. 1.5 Intended Users and Uses This project is intended to be used by persons in the military, police, and search and rescue to assist in making their job less strenuous. The network would facilitate the cooperative missions between vehicles in complex urban environment. By having more information readily available, decision can be made faster and with a higher grade of certainty. This is due to the fact that they would be able to have continuous communication with each other to allow for collaborative planning and tracking while completing complex tasks. They could share information such as speed, direction, location, fuel, etc. which can be useful in a hostile environment. Having the other nodes information readily available can provide a key advantage to the mission. 1.6 Assumptions The client has made many assumptions for us to simplify the scope of the project, and we have made some ourselves as well. The client informed us that we can assume that our network will not need to support more than 255 nodes, which will simplify the network and the network management algorithms. They also made the assumption that the network will not span more than one square mile, so our nodes will not have to communicate wirelessly over excessive distances. We have assumed that the system will only be operated in typical environmental conditions. Temperatures will not be extreme and water will not be an issue. This will make selection of the hardware much easier. We have also assumed that radio interference in the area where the system is operating will be minimal. This will also allow us to use typical consumer-grade hardware with little low-level modification. Regarding hardware selection, we have assumed that the system will only be run on the hardware selected by us. Targeting only hardware we have on hand will allow us to ignore idiosyncrasies of other hardware setups and focus on perfect compatibility with what we support. 1.7 Limitations Our two biggest limitations are time and money. We can only afford hardware for a few nodes, while our client has assumed we will support up to 255. We won t be able to test on nearly that many, so we will need to carefully consider this during the design, or find a way to simulate having more nodes in our system. The last limitation is our experience. Our team has collective experience building software and working with hardware, and some experience with networks, but none on the specific topic of ad-hoc networks. Designing this system will take significant research on our part, and the advice of our advisor. 4

6 2 Expected End Product and Deliverables 2.1 Functional Requirements The client provided us with functional requirements organized into three priority levels. High priority requirements relate to communication of the network nodes. They must be continuously connected via Wi-Fi, and if a node drops out of the network, each node must inform the user where to move to repair the network. This should be inferred based on the previously recorded GPS coordinates of the other nodes. The network must be an ad-hoc network and not require a central base station. All nodes are equal peers, and messages will be passed throughout the network. Any two nodes in the mesh network will be able to communicate, even if they don t have direct line-of-sight communication. Medium priority requirements involve tracking. Each node will continuously share data about itself with all other nodes, including position, speed, and output of any other sensors available. Each node track information about all other nodes. Low priority requirements involve tasking. Each node may have different capabilities, such as varying sensors or tools, and the nodes in the network will work together to complete mission objectives. Routes may be planned and re-planned dynamically. 2.2 Non-Functional Requirements The client also provided us with other non-functional requirements. The first of such nonfunctional requirements involves the existence of a user interface to allow interaction with a user. The user interface should possess some sort of graphical element. The second nonfunctional requirement is the integration of mobile devices such as tablets or cell phones. The devices will allow for more practical test cases. The third non-functional requirement is to integrate with the Smartphone-controlled Mission Platform. 2.3 Security Design Considerations For this particular project, security will be given little consideration. Security implementation can be included as a final extra step but is not required at this time. However, simple security measures are encouraged if practical and straightforward to include. We will hold security considerations on a low priority. However, this project will be designed with the understanding that future development of this project will include and require strict security measures. 5

7 2.4 Solution Approach The following is a system sketch of general solution for the project. The nodes will communicate and share their GPS and sensor information with one another. They will be connected via an ad-hoc network. Figure 1. System Sketch 6

8 The following is a block diagram of a single node in the network. The nodes will take inputs from the user interface and also output information to the user interface. The nodes will also read from the sensors and GPS. It will also communicate with the network and have a network algorithm module for repairing the network when needed. Figure 2. Node in System Sketch The project will be approached as three modules. The first module will focus on the network and reconnecting algorithm. The second will focus on the hardware interface and information sharing. The third algorithm will focus on the user interface. These three modules will develop together to complete the entire project. 7

9 2.4.1 Ad-hoc Network and Reconnecting Algorithm The network module will create and maintain an ad-hoc network between all the nodes involved. Instances may arise that causes certain nodes to become disconnect from the network. An algorithm will be developed to correct for these actions. The algorithm will direct nodes to locations determined to have the best chance of network recovery Hardware Interface and Information Sharing The hardware interface and information sharing module will work between the higher-level logic and the hardware to translate commands and data. It will interface with the chosen networking hardware to pass data from the networking logic component to the network, using the selected protocol Detect when a new device has come within range Transform received data from the networking protocol to an internal data format, pass it up to the networking logic component Receive data from the sensors, transform it into an internal data format, pass it to the networking component Do basic consistency faults to detect hardware or networking faults User Interface The user interface module will contain a GUI to provide a friendly interaction for the user. It will have an interface similar to Google maps which would display each nodes as an item on a map. The map would be click-able that when a node is selected, it will display the different information of the node which includes speed, direction, GPS coordinate, health. It will also feature a gesture interface for the GUI which allows zooming in and out using fingers. It would also be equipped with a report tab to query the different item and sensors a personnel is carrying. 2.5 Documentation The following documentation must be completed during this project: Software Development Plan - This document describes the problem the goals of the project and how this project will obtain those goals. System and Software Requirements Spec - This document defines all the requirements of the project. Project Plan - This document outlines the work and direction the group will take to accomplish the goal. This document also details functional requirements and a tentative schedule of the project. System and Software Architecture - This document the required structure of the system and how the system components must work together. 8

10 Preliminary Design Review - This document discusses the possible option for completing the project. Critical Design Review - This document identifies the options chosen from the Preliminary Design Review document. Software Test Description and Report - This document reviews the actions taken to test the system and discusses the findings from the tests. Final Report - This document details and discusses the completed project. 2.6 Possible Risks and Risk Management There are several risks associated with this project. We have identified some possible risks and how they will be mitigated. Purchased hardware may not have the desired range. Hardware will be evaluated as carefully as possible before purchase. Wireless adapter range may be increased by increasing the power. Team members may be unfamiliar with the networking techniques required. Ad-hoc networking will be carefully researched before designing the system. Team members may be unfamiliar with the low-level coding techniques required to closely integrate with the networking hardware. Windows APIs and other libraries will be researched to determine suitability for replacing custom low-level code. The team will plan carefully during the design process to determine what is known and unknown, and learn as necessary. The team will also make use of the professors knowledge to plan the best course of action. There may not be any libraries supporting ad-hoc networking on Android devices, or it may be difficult to implement. Ad-hoc networking on Android will be researched carefully to determine whether this will be a feasible goal before hardware is purchased. Design or implementation tasks may take longer than planned. Design and research tasks will be started proactively to ensure that they are complete by the end of the Fall semester, and that implementation can begin over Winter break or immediately in the Spring. Time estimates for all tasks will be overestimated, accounting for Hofstadter s Law. 9

11 Designing Developing Testing Totals 3 Resources and Schedules Following is our plan for the number of hours that each phase of the process will take, a description of our financial resources, and our anticipated schedule. 3.1 Work Plan This table explains the estimated amount of hours required to complete the project. The table breaks down the hours for each member of the group on the projects. Adrian Jagdeo Robert Lourens Benjamin Wiemers Totals Table 1. Project Phase Hours Breakdown This chart details the areas the group members are expect to focus their time on. GUI Networking Adrian Jagdeo Robert Lourens Benjamin Wiemers Information Sharing 0% 20% 40% 60% 80% 100% 120% Figure 3. Time Spent on Components by Team Member 10

12 3.2 Financial Resources A budget will be provided from Lockheed Martin, Advance Development Programs to fund the project. This budget is estimated to be $3000 which will be used to buy the resources. These resources include 4 Laptops, 4 GPSs, 1 Wireless Router, Infrared and TV Cameras. 3.3 Time Schedule Following is the tentative schedule for completing this project. 9/1/ /21/ /10/2011 1/29/2012 3/19/2012 Fall Semester Winter Break Spring Semester DESIGN PHASE Identify Ad Hoc Protocols Research APIs Design Architecture Research Hardware Develop GUI Design DEVELOPING PHASE Build Ad Hoc Network Add Repairing Ability Develop Software to share information TESTING PHASE Test Connectivity Test Repairing Test Information Sharing Test GUI Functionality DOCUMENTATION AND REPORTING Weekly Reports Software Development Plan System and Software Requirements Spec Project Plan Preliminary Design Review System and Software Architecture Hardware List Design Document Critical Design Review Software Test Description and Report Project Poster Final Report Demonstrations Figure 4. Project Gantt Chart 11

13 4 Closure Material 4.1 Project Team Information Client: Jessica Miller Lockheed Martin, Advanced Development Programs Members: Adrian Jagdeo Software Engineering Rob Lourens Software Engineering Benjamin Wiemers Computer Engineering Faculty Advisor: Dr. Ahmed Kamal Department of Electrical & Computer Engineering 4.2 Closing Summary This project focuses on developing an ad-hoc network to track points of interest in an urban environment. These could be used in many environments such as in a search and rescue situation or a combat situation. The project will result in an ad-hoc network that works to repair itself when issues arise. This project will contain a GUI that will help track points of interest. The project will also develop a means of sharing information between the nodes. By following the proposed schedule and work plan, we will develop a product that fills the requirements. 12