Skip to content

Project Proposal

Jump to bottom
Harshini Nanduri edited this page Sep 24, 2013 · 13 revisions
  1. [Introduction](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#introduction)
  2. [Background Information](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#background-information)
  3. [Objectives](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#objectives)
  4. [Methods](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#methods)
  5. [Conclusion](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#conclusion)

Below are rough descriptions of what should go into each section of the report. See the relevant issues in the issue tracker for more details / discussion.

Introduction

  • Introducing the concept of the "Internet of Things (IoT)
  • Proposed benefits / reasons for the existence of IoT
  • Definition of the OGC specification for the IoT
  • Reason why we're using the OGC specification
  • Aims of the project
  • What we hope to accomplish

The revolution of the Internet changed the future of communication forever. As time went by, new technologies were developed which allowed us to move from the First Generation of the Internet to the Fourth Generation. In the 1970’s the First Generation of Internet began through APRAnet (Advanced Research Projects Agency Network). In the 1990’s the Second Generation of Internet was accompanied by AOL. In the 2000’s, the third generation began and we are still in it today. This generation is dominated by social media’s, such as Facebook, Twitter, MySpace, Flickr, etc. The society is now in the process of transitioning from the Third to Fourth Generation. The Fourth generation of Internet is represented by the Internet of Things (IoT). [1]

IoT is a new concept that involves the networking of all physical devices to function more cohesively as one unit to assist in everyday life. It connects everything to the internet “Virtually”. IoT will have huge impact on businesses all over the world as well as average household. Advantages of Internet of Things are; increase in household security, increase in energy conservation and also an increase in business sales. [1] This project involves using sensors in order to develop an Internet of Things application using the Open Geospatial Consortium (OGC) standard.

OGC is an international consortium with more than 445 companies, research organizations, government agencies, and universities that participate in a consensus process to develop geospatial standards that are available publicly. The OGC Standards allow technology developers to make geospatial information and services useful with any application that needs to be geospatially enabled. [2] "The standards coming out of this OGC process will make it possible for developers to ensure that sensors, the observations they produce and the systems they inform will be easy to reach and control with Web services, without compromising security and data integrity,” said Sensor Web for IoT convener, Steve Liang, who is director of the GeoSensorWeb Laboratory at the University of Calgary. [2]

See issue #2

Background Information

###Internet of Things One of the primary aims of our project is to develop an application of an Internet of Things. The term ‘Internet of Things’ (IoT) refers the resulting network formed between tangible objects and their virtual counterparts, and is the result of linking these two representations via an internet like structure. This is usually done by equipping or embedding objects with sensors, providing them with a unique identifier and thus the ability to communicate without requiring human interaction. [1] Objects used in an IoT may be anything from household appliances to living creatures. In each of these cases, data from the sensor assigned to an object is transferred over a network and may be accessed in real time, in order to gain insight on temperature, noise levels or other measurable conditions of the object being observed.

###Open Geospatial Consortium The Open Geospatial Consortium (OGC) is a non-profit international organization, and exists as a medium though which more than 400 organizations worldwide may collaborate to encourage development and implementation of open standards for geospatial services, data sharing and GIS data processing. [2] Founded in 1994, the main focus of the OCG is the creation of a set of technical documents known as OCG Standards. These documents detail encodings, which ensure complex spatial information remains available and relevant to various applications. OCG Standards are developed by a unique consensus process, which ultimately allow geoprocessing technologies to interoperate, thus guaranteeing compatibility between two or more separate products. [3]

RESTful API

There are two different types of Web Services: the first being Simple Object Access Protocol (SOAP) based, and the second being Representational State Transfer (REST) based. The latter Web Service is a CGI-based application that is similar to using an HTTP form – it was originally described in context of HTTP, but is not limited to it. [4] To implement our project, we are planning to use the RESTful Web API design model, or RESTful web service. This is an architectural style web API (see section 3 below), implemented using HTTP and REST principles. RESTful requires several necessary aspects, including the media type of the data supported by the Web API, and a set of operations (such as GET, PUT, or DELETE) using HTTP methods as mentioned above. In addition, these aspects should include a base URI for the Web API, and the API should be largely centered on hypertext. [5]

###Use of a Common API An API (Application Programming Interface) exists to aid developers in writing applications for Web Services such as SOAP or REST. It usually consists of a set of classes that can format and make requests from the Web Service, and thus simplifies the use of the Web Service. [4] When implementing our project, we will most likely be using multiple devices or sensors. While a unique API may be preferable for a single sensor, [6] this may cause problems when a project requires more than one sensor or dataset. Therefore, we have a need for such a thing as a single, standards-compliant API, common across the entirety of the project.
Linking everything through a common API will facilitate the project in a number of ways: it will centralize and ease the connection process to and from the sensors (this includes reducing connection and execution time of the application, as well as necessary power), it will simplify the code, and finally it will ease the task of maintaining security for one service rather than several. Furthermore, it will be easier for us as the developers to learn one API rather than several during implementation.

See issue #3

Objectives

  • Finding a sensor setup to add to the Internet of Things (IoT) / Sensor Network (SensorWeb) that can measure information relevant to us locally
  • Develop an intermediate library / interface for the sensors to the OGC RESTful API that is being hosted on Dr. Liang's servers
  • Develop some user interface (UI), such as a mobile application or web page, that uses sensor data in some fashion.

Expanded further (but still rough...)

This project is presented as one general umbrella goal, which is broken down into smaller objectives and sub-objectives. Overall goal: Use the Internet of Things to tangibly assist the citizens of the city of Calgary in a practical and user-friendly way.

Objective #1: Determine a location-based application of the IoT which is relevant to the city of Calgary. Further details: Define a problem relevant to Calgarians (or a particular sub-group of citizens, such as civil servants, university students, environmentalists, etc.); specifically identifying a component which can be measured and the importance of its spatial properties.

Objective #2: Design a sensor setup which can measure data suitable for the application determined in objective #1. Sub-objective:

  • Determine technical requirements necessary for data measurement (e.g. sensor(s) required, other periphery elements needed)
  • Create a working prototype of a sensor which could be deployed in the city
  • Test prototype in at least five different locations

Objective #3: Develop a library which links the sensor and the OGC RESTful API Sub-objective:

  • Learn necessary language(s) required for writing a library which will work with the chosen sensor setup
  • Collect test set of data with multiple sensors in a working/usable configuration in the city

Objective #4: Create a user interface (UI) such as a webpage or mobile application which makes use of the OGC RESTful API to display the sensor data. Sub-objective:

  • Design user-friendly graphical interface which is tested and found intuitive by at least 80% of test subjects
  • Represent collected data (in real time) using the created user interface

See issue #4

Methods

  • Sensors used / considered
  • How we plan on creating the library / interfacing with the database
  • Programming languages we may consider using for the task
  • Organization / management (project will be managed and tracked through github)

Computer board

All sensors will be interfaced using a single board computer. These computers are well suited for DIY, educational, and prototyping projects due to their low cost and the wide variety of available sensors. The board chosen for the the project is the Raspberry Pi. This was chosen over the Arduino Uno due to the following projected constraints:

Connectivity: The computer must be connected to the internet so that sensor data can be accessed. The Raspberry Pi includes an Ethernet port by default, and an external WiFi ($10) or 3G ($27) dongle can be attached. The Arduino has WiFi ($70) & GSM "shields" ($115) . It is likely that the sensor will be built to include WiFi capabilities in order to obtain a balance between cost and ease of use. In areas that are not near a WiFi network, a phone with 3G to WiFi capabilities may be utilized.

Performance: The Arduino board is built around a micro-controller with lower specs than the Raspberry Pi. The Arduino is clocked at 8-16 MHz processing speed with 2-8 kB of RAM available. The Raspberry Pi features separate CPU & RAM and boasts a 750 MHz processor which can be overclocked up to 1GHz with 512 MB (shared with GPU) of RAM available. Depending on the application, either could be suitable.

Power consumption: The computer & sensors will need to be powered by an external power source. The Arduino has much lower hardware specs than the Raspberry Pi, and as a result consumes less power. The sensors & network connection are likely to be the dictating factor in how much power is being used.

Cost: Costs of the boards themselves are similar, the Arduino Uno costing $30 and the Raspberry Pi costing $35. External sensors for the Arduino are generally more expensive than Raspberry Pi, as they must be built to work with the Arduino specifically. Sensors for the Raspberry Pi have the benefit of being able to connect via USB and as long as they are Linux compatible, it is likely they can be used.

//Add some details about Raspberry Pi, (OS we will be using (probably Debain derived Raspian)), how we will set up our development environment, how we plan on dealing with saving/transporting data, where we will be getting our raspberry pi (can we use steve's or do we need to order one?), how we plan on powering it (depends a lot on application)

Sensors considered

For the location of the device, the sensor set-up will likely be one of two situations:

  • If the hardware was designed to be used in an application where the sensor is moving, a GPS receiver will likely be included. //Add considerations for including a GPS sensor
  • If the sensor is to be placed in a location for long periods of time, and gathers spatial data of a different kind (ie image based) than the unit will likely not require a GPS receiver.

Other sensors that could be include are: Image (webcam or camera), Sound, Meteorological, Distance, Magnetometer, //some other stuff

Interfacing with the Database

The sensor assembly will have network access of some kind, with which it will be sending sensor data to a database designed specifically for IoT applications. This server is maintained by the Sensor Web Interface for IoT Standard working group. The sensor assembly will require a library which will be developed to adhere to the upcoming Open Geospatial Consortium (OGC) Sensor Web interface for IoT StandardSensor Web interface for IOT (SWIOT) standard. This project will likely be one of the first to use the SWIOT standard, and it is hoped that the project's deliverables will be used and adapted in the future to create a truly cohesive IoT.

Programming Language

The Raspberry Pi is configured to support Python by default, but it is easy to use other languages such as C/C++ or anything else that will compile on ARMv6 architecture. Advantages of using Python are that as high level programming language it allows for easy development and smaller source size. Due to it's interpreted nature, it is slower and uses more resources than C++. Advantages of using C/C++ are that as an intermediate programming language it is faster and more flexible than Python. Development of C++ programs is more complex, which takes more time and code is typically 5-10x larger in C++.

Organization / Planning

The project will be managed through Github which will serve as a means to plan & document the project during it's evolution. Github has many tools to aid project's along their development and is a good choice for the project due to it's open source nature. The tools that will be used throughout the projects lifetime are:

Issues: Any time there is a task that needs doing, an Issue will be created for it. The Issue's description will outline background information, objectives, and in most cases a due date. Issues can be assigned to users or users can volunteer by assigning an issue to themselves. Once an issue is assigned to a user, other user's know not to work on it without addressing the issues owner beforehand. Issues can be labeled and sorted in various ways to help manage the backlog, and will serve as the main organizational system for our day to day work.

Wiki: The wiki will serve as the main repository for all the knowledge amassed throughout the project. It is readable by anyone but only project contributors (our group) can add to it. By compiling all data in one place all team members can stay current with the projects evolution without consulting multiple sources.

Pulling: //Maybe Jeremy can flesh this section out as I only have a basic understanding and no experience yet

See issue #5

Conclusion

The Conclusion of the proposal will not be completed until all the other sections have been, so it is not entirely useful to mark down what will be inside of it now, but it is important to track that it should be done.

See issue #6

#Works Cited

[1] I. Wigmore, "Internet Of Things (IoT)," July 2013. [Online]. Available: http://whatis.techtarget.com/definition/Internet-of-Things. [Accessed 23 September 2013].

[2] "About OGC," Open Geospatial Consortium, 1994. [Online]. Available: http://www.opengeospatial.org/ogc. [Accessed 20 September 2013].

[3] "OGC Standards and Supporting Documents," Open Geospatial Consortium, 1994. [Online]. Available: http://www.opengeospatial.org/standards/. [Accessed 20 September 2013].

[4] R. Savage, "Stack Overflow Questions," 16 October 2009. [Online]. Available: http://stackoverflow.com/questions/1576072/what-is-api-web-services-how-do-you-create-them-and-why. [Accessed 23 September 2013].

[5] J. Black, "Stack Overflow Questions," 16 October 2009. [Online]. Available: http://stackoverflow.com/questions/1576072/what-is-api-web-services-how-do-you-create-them-and-why. [Accessed 23 September 2013].

[6] J. Steward, Interviewee, [Interview]. 23 September 2013.

Clone this wiki locally