Air Quality Monitoring

The majority of in-depth work in environmental IoT has been done here. For the most part, research in this area covers sensor networks used to measure and report air quality metrics for a given area. Air quality is typically measured in one of two ways; using a reactive component in a sensor to calculate the parts per million in a volume of air (ppm/v), or by measuring light wavelengths over a period of time and detecting particles in the air [1]. One of the objectives of monitoring air quality in this manner is to provide information about the air to the population that was previously not available. It has been suggested that air quality sensor networks measuring information like this could produce “ozone alerts”, like traffic alerts, and commuters could use this information when planning a route [2].

A few academic studies have been performed in this area. One of them out of Lancaster University (UK), used consumer-grade “maker” electronics to perform a study on how pollution levels impact individual commuters. They developed wearable sensors using Arduino boards that they gave to study participants to wear as they commuted to and from campus. The information was reported back to a central instance using an application on a smart phone. The results did not agree on exact concentrations of pollution at given times, but using data plotted on a map, the researchers were able to identify “high” and “low” areas of pollution during peak travel times. The data inconsistencies were attributed to the low-quality sensors used, a requirement of both the cost and power requirements of a wearable device. The research team did propose doing a follow-up study where they performed an exit interview with the participants. Many participants reported feeling like they had traveled through an area with “bad pollution”, only to find the data did not back that up. This seems to indicated there is difference between perceived and measurable levels of air pollution in our environment [3].

Another system to measure pollution was set up in Cape Town, South Africa. This system was established to be a proof-of-concept “WaspNet” for sensor networks. The idea here being that with a central system many types of metrics for different environmental factors could be collected centrally and be made available for use. The system was designed to address several of the problems surrounding deployments of this kind; namely poor network connectivity and power. The central technology used for data collection and reporting was Zygbee which is a low-power network communication protocol. The author of the study stressed the importance of well documented standards and open-source sensors as a strategy for building a robust and sustainable solution. The centralized and open nature of such a system also lowers the barrier of entry for developing nations, meaning organizations that could not afford to build this from the ground up could purchase a few sensors and participate, gathering valuable information. At the time of this writing, the data collected by the system was not available for public consumption, but there are plans to offer that in the future [4].

I was surprised that I did not find many city-scale projects like this in my research. I did, however, find quite a number of smaller grassroots efforts. Many of these had similar approaches and scope, some even using the same technology. The end goal was developing a network that private citizens could afford to tap into and get useful data. The Air Quality Egg provides a $185 boxed kit, and has a website with a real-time map showing data collected from participants [5]. The AirPi project was featured on the Raspberry Pi homepage and features a set of do-it-yourself instructions, parts, and code to build an air quality ground station. It also has a map-based reporting interface [6]. The AirCasting project allows for a number of different sensors to connect to an Android OS application and upload data to a central location that way [7]. One of the projects to use this delivery method is CitiSense, which provides a wearable sensor about the size of a wallet intended to be clipped to a backpack. The sensor uploads data to the CitiSense reporting page using AirCasting as the passthrough [8]. HabitatMap also uses AirCasting for delivery, but instead uses it’s own “AirBeam” sensor, which is an Arduino board, intended to be carried. The site also has information and activities related to pollution awareness at the local level [9].

Environmental IoT: The Internet and Our Natural World

The following few posts comprise the write-up for my topic research this semester. Overall, I found the environmental science uses of IoT technology to be in a very early stage, with more expected to occur in the near future than has already happened. More detail on each section I investigated will be in each section. Links will be provided to each section below.

When investigating the areas of study in environmental Internet of Things, that is IoT technologies as they react and act upon the natural world, I was surprised to find this is a young concept within a field that is itself new. Computer applications that monitor events in the environment have been around for decades, but many of them rely on older technologies to function. The overwhelming majority of applications that touch the natural world use proprietary communication protocols to talk to closed systems, and very rarely do anything over the commodity Internet. The majority of IoT research seems to be devoted to home automation, shipping and delivery; things that make money. That said, there is interest here, mostly from small start-up businesses and community grassroots organizations. The primary areas of research are Pollution Monitoring (air and water quality) and Early Alert Systems (forest fires, earthquakes).

So who is doing this work? Currently, it seems to be mostly research organizations and startups. The latter seem to be focused largely on products they can bring to market, pollution sensor wearables and the like. The former are working on larger projects to see how Internet connected systems can help us understand and react to our natural world. Traditionally, this sort of work has been performed by governments and large organizations, largely for reasons of legal compliance. It is expensive to set up these systems, smaller organizations do not have access to the scale or quality of equipment to match the older systems, which is why you see more networks set up using older protocols and not leveraging the Internet as much. However, local community interest and maker culture are filling in some of these perceived gaps using IoT concepts [1].

I have broken up the coverage of this topic into a few posts, covering the sub-sections of the sort of work taking place, as well as perceived challenges and my conclusions about the field.

1. Air Quality Monitoring
2. Forest Fire Detection
3. Earthquake Detection
4. Challenges and Conclusions
5. References
6. Slides

Final Project: Service Specifications and IOT level

Here are all of the high-level overviews of the services I intend to create for my air quality monitor. There are a total of 4.

• GasReadingService runs on a schedule on each node (10 seconds), gets a reading from the sensor and sends the value to ReadingSendingService for delivery.
• ReadingSendingService sends the timestamped reading from GasSendingService, along with a unique identifier for the node the reading originated on. This contacts a RESTful endpoint on the central control node.
• CentralDataCollectionService runs on the central control node and accepts the GasLevelReading values as POST data from the ReadingSendingService. If everything checks out, it stores the values in a database. The service also provides an interface to get a series of GasLevelReading objects back out of the database given a node identifier and a timestamp series.
• CentralDataDisplayService runs an HTTP front-end that users interact with. Through the interface, users supply a set of nodes they are interested in and a timestamp range, and the CentralDataCollectionService is contacted to get these values. The display service then renders a graph to give the user the data requested.

Finally, this system will be operating at IoT Level 4. This is because there are more than 1 nodes collecting data, running independent of one another, which send the values to a central location for storage and analysis.

GasReadingService

ReadingSendingService

CentralDataCollectionService

CentralDataDisplayService

Final Project: Domain Model and Information Model Specs

Here are some diagrams of my proposed Domain Model (how all the pieces of the system interact) and Information Model (what data looks like) for my final project; an air quality monitor. Because of the complexity of measuring "air quality", I have decided to focus on monitoring a single gas (Carbon Monoxide, or CO). Monitoring additional gasses and environmental readings would have similar Domain and Information models.

Domain Model

Information Model

Django RESTful Example

The other topic covered in homework this week was setting up a RESTful service using Django. The example provided in the book is a Weather Station mock-up. I have implemented this example and made a few changes of my own to make it work. I did not use MySQL as the database back-end, which is not a hard requirement since Django's data representation libraries let you change the back-end without modifying the object structure. Code is here.

Setup Instructions

1. Install Python 2.7 with Virtualenv extension
2. 'virtualenv weatherstation' to create a new blank "weatherstation" Virtualenv container
3. 'source weatherstation/bin/activate' to turn on Virtualenv container
4. 'pip install -r requirements.txt' to install all the required packages for the Django setup
5. 'python mange.py syncdb' to create a new database
6. When prompted to add a new user, say 'yes' and use 'username' and 'password'

Running Instructions

1. Activate the weatherstation Virtualenv container
2. 'python manage.py runserver'
3. Add at least one piece of data and browse to 'http://127.0.0.1:8000/home'

Adding Data

Modify the following line to as needed.

curl -i -H "Content-Type: application/json" -X POST -d '{"name":"TestCity", "timestamp": "123456", "temperature": "46", "lat": "30.123456", "lon": "76.123456"}' http://127.0.0.1:8000/station/ -u username:password

What's Happening Here?

The URI endpoint "/station" allows people with the correct permissions (username:password) to create new "Station" objects in Django using a POST request and a JSON object in the POST data. These objects contain a name along with some temperature and location information. When the /home URL is loaded, the "requests" Python library makes a GET request and displays the information from the last update using the "index.html" template. The values passed to the template from the view replace the {{ values }} of the same name.

WAMP Publisher / Subscriber Example

One of the topics covered in our homework this week was setting up an asynchronous WAMP publisher / subscriber example using Python. WAMP stands for "Web Application Messaging Protocol", which is a sub-protocol which leverages Websockets (which in turn leverage HTTP) to set up asynchronous communication models. The Python implementation uses AutobahnPython (WAMP implemented on the Twisted network library) to do this. The example code in the book and the procedures used to do this are unfortunately out of date, so the code needed to be modified to get this to work. I had to modify each code sample to clean up some spelling / syntax, and add a "main" function at the bottom to start an ApplicationRunner using the ApplicationSession defined above. Code is available here.

Setup Instructions

1. Install Python 2.7 with Virtualenv extension
2. 'virtualenv wamp' to create a new blank "wamp" Virtualenv container
3. 'source wamp/bin/activate' to turn on Virtualenv container
4. 'pip install crossbar' to install Crossbar.io WAMP router, will get AutobahnPython as a dependancy
5. Create a new blank Crossbar.io server to use as a WAMP router
1. 'mkdir server'
2. 'cd server'
3. 'crossbar init'

Usage Instructions

1. Start the WAMP router
1. 'cd server'
2. 'crossbar start'
2. Start the Subscriber (./subscriberApp.py)
3. Start the Publisher (./publisherApp.py)

What's Going On Here

When the server is started, it is accepting all new topics published to 'realm1' without any authentication. When the subscriber joins, it is telling the server "please send me any new updates to com.example.test-topic". When the publisher joins, it starts an infinate loop of taking the current time and updating the topic 'com.example.test-topic' with that value. The server then sends those updates to the subscriber client, which prints them out.

Planning Final Project

This week, we were asked to start planning our final projects in more detail by completing the Purpose / Requirement Specification and Process Specification. The project I would like to complete would be a sensor network for monitoring air quality over a wide area. Because I do not have the time or finances to set up an actual network, I will create a single "node" as proof-of-concept, then simulate others to create the effect of multiple nodes reporting data.

Purpose / Requirement Specification

Purpose

The purpose of this project is to provide an assessment of air quality over an area. This is accomplished by setting up a network of air quality nodes that all report data back to a centralized instance on regular intervals. The central instance is accessible using a dashboard, in which a graph of sensor readings from nodes is visible. Individual nodes report back information about air quality around them. This data can be viewed in an aggregate for an area and used to provide an assessment of the air quality in the areas being watched by the sensor network. The intended users of this system will be people interested in measuring the air quality of an area, such as health officials or environmental scientists.

Behavior

The nodes participating in the sensor network will take reading on regular intervals and send them to the central instance. Air quality is generally measured by the following readings;

- CO levels (carbon monixide)

- CO2 levels (carbon dioxide)

- NO2 levels (nitrogen monoxide)

- O3 (ozone)

- particulate matter

Note: For the purposes of this class, only data readings from the CO sensor will be implemented because of time and cost constraints. Additionally, only a single physical node will be created. Additional nodes will be simulated using simple random number generators reporting manufactured data to the central instance.

System Management Requirement

The system will have a single central instance responsible or information processing, storage and display. One or more sensor nodes will report data to the central instance. Each sensor node knows how to find the central instance, and any information about the location of any given node is stored on the central instance. This way, sensor nodes can join and drop off the system as needed.

Data Analysis Requirement

Data will be stored and graphed using an interface on the central instance. The primary purpose of the interface will be to display real-time information over a user specified region. The information gathered by the network could be used to automate reports about so-called "bad-air" days, make predictions about air quality trends, or chart the change of air quality over time / space. However, that may be outside the scope of the work achievable in this class.

Application Deployment Requirement

The central instance for data collection and display will need to be "always on" and accessible, so it will be hosted on a cloud service provider like Amazon A2 or similar. The sensor nodes are physical entities running a limited software load for collecting data and transmitting it to the central instance, so they will need to be located where they are collecting the readings.

Security Requirement

The central instance will have 2 views; a general "read-only" view that users interested in consuming the data can view, and a administrative view responsible for accepting new nodes into the network and managing those already participating. The administrative back-end is separated so that the general users can not introduce data providers into the network or remove existing ones, insuring the data is collected from authorized participants only.

Process Specification

Process Diagram for Sensor Readings

Process Diagram for User Interface Interactions