Creating a Sensor Services Platform
|has title::A Sensor Service Platform for Centralized Data Collection & Sharing|
|Master:||project within::Software Engineering|
|Student name:||student name::Vlant Iordanou|
|Second supervisor:||Martijn Onderwater (CWI)|
|Second reader:||has second reader::Natalia Silvis-Cividjian|
|Company:||has company::Centrum Wiskunde en Informatica (CWI)|
Sensors are small devices that measure some physical phenomenon, such as temperature or CO2 level. Within the RRR project we research methods to make this data available for users. A key element is the platform that gathers the sensor data and shows it in an appropriate form to the users. This could be a graph with temperature values of the previous day, a quarterly report on the indoor climate of an office or a SMS-alert about rising CO2 levels.
Within this project we would like to explore architectural options for creating such a sensor services platform. The IT landscape is illustrated in figure 2 below. Typically, the WSN reports sensed information to a database, where it is available for the services platform. The platform makes the data available to applications in the desired form, for instance as an alarm or a graph.
In this project we are particularly interested in the use of webservices to expose the sensor data and/or services to third party service providers. Webservices are well-known in modern IT environments and are expected to play a large role in the adaptation of WSNs into every-day life and the development of new applications. The key questions to be answered in this internship are:
- Which webservice interfaces should be chosen?
Various definitions exist in literature and in practice, and at the moment it is unclear which of these is the best choice.
- How should these interfaces be connected to form the Sensor Service Platform?</br> They can be, for instance, converted to regular interfaces in source code and programmatically connected. Alternatively, a message bus could be used to provide mutual communications. Or perhaps using an OSGi container is a better option.
Role of the Student
The student will answer the questions above by (1) providing an overview of existing webservice interfaces for exposing sensor data and (2) discussing the pros and cons of the various architectural setups. Finally, a prototype platform will be implemented. To motivate the choice of webservices and architectural setup for the prototype, the student can make use of the output of a recent requirements elicitation phase within the RRR project. Industry partners are also available for additional discussions and brainstorm sessions.
Initiative by the student to incorporate personal ideas and interests is greatly appreciated. Data is available from Munisense, a partner in the RRR project. Besides this, data can be obtained from public data sources and simulations. There is also the possibility to create a live sensor network for testing purposes.
Goal and deliverables
The main goal of the project is to answer the key questions mentioned before. The deliverables are:
- A review of existing webservice standards.
- An overview and discussion of the possible architectural setups.
- A prototype sensor services platform.
- A thesis describing the results from the internship.