Short URL

CSR: Small Self-Sustainable Solar-Powered Emergency Mesh Design

 

Other areas:

Loading, please wait...

Introduction

Natural emergency and disaster scenarios are common occurrences. However hard humans try, we are helpless when it comes to facing the wrath of nature. In 2009 alone, there were at least fifteen disjoint events of natural disasters in the United States. Earthquakes, floods, and hurricanes are common examples. In addition to human casualties, natural calamities can destroy the power grid, telephone networks, and mobile phone towers leaving survivors stranded without any viable mode of communication. There is no alternative for disseminating critical updates such as disease and safety alerts, location, and direction to survivors.

This problem is an outcome of the lack of network systems that are designed to survive and serve during natural disasters. While the research community spends its time designing efficient systems for day-to-day communication – DSL, cable, and mobile phone systems – we often ignore the uncommon case when the power grid is non-operational and the Internet is unreachable. However, with concerns related to greenhouse carbon emissions and global warming, disaster scenarios are poised to become a common case rather than an outlier.

To help find solutions to fill this need, CAST and the Department of Computer Science and Computer Engineering (CSCE) of the University of Arkansas have received NSF funding to make fundamental advancements in the design of fallback infrastructure that can serve critical information to survivors during the aftermath of a natural calamity. Designing a robust fallback data dissemination mesh during disasters is non-trivial and challenging. First, energy consumption is a fundamental design pillar. Our team is developing a mesh architecture that is energy efficient, self-sustainable, and available. In the absence of the power grid, an operational mesh must rely on renewable energy sources such as solar and should have near-perpetual lifetime while serving critical updates. Since renewable energy scavenging is notoriously unpredictable, such a system requires a clean-slate low power hardware and software systems design. Second, self-stabilization is a fundamental property of fallback mesh architecture. The variability inherent in renewable energy scavenging and extreme environmental conditions during the aftermath of a natural calamity will inevitably lead to permanent and transient node failures. In the event of a failure, nodes in the mesh will be designed to automatically redistribute their data to maintain high levels of redundancy and fault tolerance. Third, the mesh design will be general and compatible with off-the-shelf laptops, mobile phones, and PDAs. While ultra-low power systems can be designed using custom hardware, such systems cannot serve popular mobile devices. Hence, we rely on common wireless technology such as Wi-Fi and simple web-based services for information dissemination.

 

Process

A key goal of the initial part  of the project was to configure a very robust low power low cost computer, and identify and assemble a software stack that would create a complete system to provide a map to the user that would route them from their current location to an emergency shelter while avoiding dangerous areas.  The computer system selected for this phase of the project is the Gumstick Overo Air. It was selected for two reasons. One, the Gumstick Overo is a very low power computer.  And two, the Gumstick Overo Air has an integrated WiFi module

necessary for conducting the proper tests.

The software stack was assembled from open source tools. The stack is composed of OpenLayers, Mapsever, Mapnik, Apache 2, PostgreSQL, PostGIS, and pgRouting with a few custom bits of code written in Java, JavaScript, Python, and PHP. The figure on the right shows how the system currently looks.  The red area represents a danger zone. The green circle represent the users current location. The black and white shelter icon represent a safety location. The green line from the users current location to the safety location represent the shortest route that avoids the danger zone.

The Gumstix computer is setup with an ad-hoc network to allow WiFi enabled computers such as smart phones to connect and access the services on the Gumstix. This needs to be changed to an access point as soon as the necessary drivers become available. The reason for this is that Android OS enabled systems do not connect to ad-hoc networks by default, but will connect to access points.  A DHCP server is set up on the Gumstix to provide connecting computers with an address in the same subnet space as the Gumstix.  A domain name service is set up so that every request for any computer name always returns the address of the single Gumstix on which the name servers is running on. The reason for this is that the user of the system needs to see the emergency information. Whatever computer the user tries to contact, google.com for example, needs to instead contact the Gumstix and retrieve the emergency information rather than displaying a “server not found” message.

An application written using the OpenLayers JavaScript library draws the map. The map drawn is pulled from three sources. The base layer of the map is made from a call to MapServer. The current location of the map user is retrieved from the some HTML 5 JavaScript. A route from the user’s current location to the safety location is retrieved from a GCI-bin PHP script. Apache 2 was selected to serve as the HTML server. All the requests for data flow through the HTML server.  One nice feature of Apache 2 is that it allows the server to specify the error pages. The “404 page not found” message has been set to return the top index.html page. This works with the domain name server to assure that no matter where the user tries to go on the web the user is presented with the emergency information instead of an error message.

MapServer provides the base layer map to the OpenLayers based client. It reads the map tiles and integrates safely location and danger zone information from the PostgreSQL database to produce new tiles with the integrated information that are then sent to the client. To make the map tiles for MapServer to serve, Mapnik was chosen. Mapnik can make very nice looking maps. The source street data that was used to feed Mapnik comes from the Census Bureau’s TIGRE Line data in Shape file format. As currently configured, the system serves street data for Washington County Arkansas. A python script that used the Mapnik library was written to read the shape files and produce map tiles as well as a text file with the tile boundaries.  A Java program was written to take the text file of boundaries and create a Shape file of the tile boundaries. The tile boundaries Shape file is needed by MapServer to locate the tiles it serves.

A PostgreSQL database is set up to store information. The utility of a database such as PostgreSQL makes it an easy choice over using straight files to store the data.   To enable the PostgreSQL database to store spatial data the PostGIS extension was installed. Not only does PostGIS allow for the storage of spatial data, but it can represent that data to the user in many useful formats. Specifically useful to this project is the ability to create JSON formatted spatial data that can be injected straight into OpenLayers for visualization.

The pgRouting plugin was added to the database to allow the database to calculate routes.  The pgRouting routines work on networks that are not necessarily spatial networks. So any connectivity graph with weighted edges can be used as source. This unfortunately is not ideal for this application because the routes retuned contain only node and edge identification numbers which then have to be used to retrieve the geospatial coordinates of the edge nodes. This slows the process down somewhat. Still, routes can generally be found in less than 10 seconds, which is acceptable.

A PHP application responds to request from OpenLayers for the route information.  The program queries the route from the data base in a JSON format which it can send directly to the OpenLayers map. Every attempt to integrate the PHP seamlessly into Apache caused Apache to crash. As a result the PHP program was set up as a CGI-bin application.

Year 2 Update