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

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