Evaluation of the usability of low-cost sensors for public air quality information

From its-wiki.no
Jump to: navigation, search

Evaluation of the usability of low-cost sensors for public air quality information

by Rozina Dongol
Supervisor(s) Josef Noll, Nuria Castell Balaguer
Due date 2015/12/01
Status Finished
Problem description: The Norwegian Institute for Air Pollution monitoring has initiated the project CITI-SENSE-MOB on Mobile Air Pollution measurements. Mobile sensor platforms are going to be installed on buses, cars and bicycles to achieve a wider distribution of measurements, as compared to the limited number of fixed stations.

The goal of this thesis is to establish the semantic framework for sensor integration on a global scale. GEOS, the framework for creating a community-driven interoperable geoscience-wide geoinformatics infrastructure, is seen as one of the key candidates for sensor integration and sensor fusion. The expected outcome of the thesis is an integration framework for mobile sensor data, based on semantic technologies. A semantic rule system is envisaged to control the reliability of the sensor system, either as a stand-alone evaluation on the sensor platform, or as a fusion of sensor. Such a fusion might consist of mobile data together with sensor data from other sources, e.g. the fixed air quality stations in order to establish models for reliability.

Methods and Tools: The tools and methods in this thesis are based on
  • A set of scenario, describing the challenges
  • A list of requirements being extracted from the scenarios
  • A description and evaluation of technologies and tools being candidates for solutions
  • A functional architecture/description of the envisaged system
  • An implementation of the core concepts
  • A demonstration of the solution
  • An evaluation of the solution, including a critical review of the descisions taken earlier
  • Conclusions
  • References
Time schedule The envisaged time schedule (for a long thesis/60 ECTS) is:
T0 0 starting month, T0+m denotes the month where the contribution to a certain chapter shalle be finalized
T0+2 months: create an initial page describing the scenario
T0+3: Provide a list of technologies which you think are necessary for the thesis
T0+4: Establish the table of content (TOC) of the envisaged thesis. Each section shall contain 3-10 keywords describing the content of that section
T0+7: Provide a draft of section 2 (scenario) and 3 (technologies)
T0+10: Establish a draft on what to implement/architecture
T0+11: Set-up an implementation, testing and evaluation plan
T0+15: Evaluate your solution based on a set of parameters, keep in mind there is no such thing as a free lunch
T0+17: Deliver the thesis
Pre-Knowledge This thesis includes a reasonable amount of programming. The envisaged thesis is based on radio communications, thus expects the user to have followed at least two radio-related courses
Approved Approved by Kirsti Dalseth
Keywords CITI-SENSE-MOB, Sensor Networks, Air quality, Air pollution, Reliability, Semantic Technologies, GEOS, Rules
Depiction File:Evaluation of the Usability of Low-cost Sensors for Public Air Quality Information.pdf

this page was created by Special:FormEdit/Thesis, and can be edited by Special:FormEdit/Thesis/Evaluation of the usability of low-cost sensors for public air quality information

Submission of Master's thesis:
Available here - Media:Evaluation_of_the_Usability_of_Low-cost_Sensors_for_Public_Air_Quality_Information.pdf

Next steps

  • decide on long or short thesis
  • learn about semantic technologies (e.g. UNIK4710, Logic group, ...)
  • start writing a scenario: think about an idea on how sensors can deliver reliable results
  • GEOS (Arne J Berre and the other Sintef students)
  • ...

Notes from meeting 11Nov2013

Media:201311NotesRozina.pdf

This page provides hints on what to include in your master thesis.

TOC

Title page, abstract, ...

1. Introduction, containing: short intro into the area, what is happening
1.1 Motivation, containing: what triggered me to write about what I'm writing about
1.2 Methods, containing: which methods are you using, how do you apply them
2. Scenario, optional chapter for explaining some use cases
2.1 user scenario, (bad name, needs something bedre)
2.2 Requirements/Technological challenges
3. State-of-the art/Analysis of technology, structure your content after hardware/SW (or other domains). Describe which technologies might be used to answer the challenges, and how they can answer the challenges
3.1 technology A
3.2 technology B
4. Implementation
4.1 Architecture, functionality
4.2
5. Evaluation
6. Conclusions
References

Comments

Red line

Your thesis should have a "red line", which is visible throughout the whole thesis. This means you should mention in the beginning of each chapter how the chapter contributes to the "goals of the thesis".

Use of scientific methods

A thesis follows a standard method:

  • describe the problem (problemstilling)
  • extract the challenges. These challenges should be measurable, e.g. method is too slow to be useful to voice handover.
  • Analyse technology with respect to challenges. Don't write & repeat "everything" from a certain technology, concentrate on those parts (e.g. protocols) which are of importance for your problem

References

  • Wikipedia is good to use to get an overview on what is happening. But there is not scientific verification of Wikipedia, thus you should use wikipedia only in the introduction of a chapter (if you use text from wikipedia). Use scientific literature for your thesis.
  • Scientific library is "at your hand", you can get there directly from UiO: [[How to get access to IEEE, Springer and other scientific literature -> Unik/UiOLibrary]]
  • I suggest that references to web pages, e.g. OASIS, W3C standards, are given in a footnote. Only if you find white papers or other .pdf documents on a web page then you refer to them in the reference section.

Evaluation of own work

Perform an evaluation of your own work. Revisit the challenges and discuss in how you fulfilled them. Provide alternative solution and discuss what should be done (or what could have been done).