-
Notifications
You must be signed in to change notification settings - Fork 3
Project Proposal
- [Introduction](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#introduction)
- [Background Information](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#background-information)
- [Objectives](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#objectives)
- [Methods](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#methods)
- [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.
- 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
###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
- 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
- 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)
All sensors will be interfaced using a single board computer. These computers are well suited for do-it-yourself (DIY), educational, and prototyping projects due to their low cost and the wide variety of available sensors. The boards considered for the project are the Raspberry Pi and the Arduino Uno. Although they are similar in size and cost, their intended purposes differ slightly. The Raspberry Pi is a fully operational computer running a Linux operating system [11]. Having a full OS gives the Raspberry Pi the luxury of communicating with higher level devices such as a USB WiFi dongle or sensors with digital output. Conversely, the Arduino Uno is a micro-controller designed for embedded applications, meaning there is no operating system [12]. The Arduino is well suited to communicating with low level sensors which give either analog or digital signals.
Below we have listed some of the advantages of each of the boards.
Raspberry Pi:
• Internet connectivity: The Raspberry Pi includes a full GNU/Linux OS and therefore includes advanced networking capabilities. It provides an Ethernet port as well as plug and play support for some USB Wifi & 3G dongles. • Performance: While the Raspberry Pi does have the overhead of running an OS, it boasts a 750 MHz processor which can be overclocked up to 1GHz with either 256 MB or 512 MB (shared with GPU) of RAM available. The flash memory is also larger (depending on the size of SD card used). • Cost: While the board itself is comparable to the Arduino, being able to use a standard USB WiFi dongle is a great advantage over the Arduino WiFi shield (~$10 vs $70). • Output: If the sensor needs to be controlled in-situ, common video and audio output formats will help accomplish this. • Programming Flexibility: With a full GNU/Linux OS, any language that compiles on ARMv6 architecture can be used. This opens up the possibility of using many languages or a mix of languages.
Arduino Uno:
• Power requirements: If the application requires batteries as the power source, the Arduino uses significantly less power than the Raspberry Pi. • Sensor compatibility: The Arduino offers more ports to interface with sensors outputting both digital and analog signals. Comparatively the Raspberry Pi cannot communicate with analog output sensors. • Large development community: The Arduino development community is more mature than the Raspberry Pi’s with a large number of tutorial and example projects [13]. While other computer boards may be considered depending on the application we decide upon, many are comparable to these two boards, and as such only these boards will be explored for the remainder of this report.
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. Adding a GPS receiver will increase project cost by means of the receiver as well as its power supply. • If the sensor is designed to gather spatial data (i.e. image based) from a discrete location, it could be possible to avoid including a GPS receiver if the location of the sensors does not have to be known to a high precision. The other sensors to be included on the device depend on the application chosen. There are a wide variety of sensors available, many of which are inexpensive. Examples of other sensors that could be include are: image, video, sound, temperature, pressure, humidity, altitude, distance, magnetometer, accelerometer, force sensitive resistor, tilt, infrared, luminosity, motion, radiation, liquid flow, stretch and more [14].
The sensor assembly will have network access of some kind, with which it will send sensor data to a database designed specifically for IoT applications. This server is maintained by the Sensor Web Interface for IoT Standard working group [15]. The sensor assembly will require a library or set of libraries to interface with the database's OGC RESTful API, which will be developed to adhere to the upcoming OGC Standard Sensor Web interface for IOT (SWIOT) [16] standard. This project will likely be one of the first to use the SWIOT standard, and it is hoped that the project helps the standard get recognized and used by other developers.
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 its 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++ [17]. The Arduino offers its own integrated development environment (IDE) where the device can be programmed using the Arduino Programming Language, based on C/C++. It also has many libraries available by default for connecting to standard sensors [18].
The project will be managed through Github which will serve as a means to plan & document the project during its evolution. Github has many tools to aid projects along their development and is a good choice for the project due to its open source nature. The Github tools that will be used throughout the project's lifetime are:
Milestones: For any deliverables required or goals set during the project, a milestone will be created. A milestone can be given a due date, and will include one or more tasks that need to be accomplished.
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 can be associated with a milestone. 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 issue’s 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 Github wiki will serve as the main repository for all the knowledge amassed throughout the project. It is readable by anyone but only project collaborators (our group) can add to it for the time being. By compiling all data in one place all team members can stay current with the project's evolution without needing to consult multiple sources.
Pulling/Forking: Github uses the content tracking system git to track changes to files (usually code), often by means of forking and pulling. A user can fork (or copy) a repository (collection of files) and then subsequently create a local copy on their machine. From here they can make any edits they desire, and if they want to commit the changes, they create a pull request. This pull request is reviewed by other teammates, specifically the group leader, and if accepted then these changes are merged into the master branch of the main repository. The group will likely only work on the master branch for the duration of the project, but if necessary other branches might be developed and explored. By utilizing these tools the group hopes to manage the project in an open, detailed, and organized manner in which all group members are accountable and progress is maintained.
See issue #5
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.