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