OpenIoT
Soldatos, John
The aim of this talk is to introduce OpenIoT, a FOSS project for developing/integrating Internet-of-Things (IoT) applications and services. OpenIoT is developing a platform and a range of tools for developing and deploying non-trivial IoT solutions. The introduction of the project will be made in the form of a lecture/presentation/lighening talk, yet it will also include practical examples and demonstrations of IoT applications based on the OpenIoT platform. Furthermore, a short programming tutorial could be provided. The aim of the presentation will be to attract interested developers/contributors to the project, thereby boosting OpenIoT's community building efforts. The main goal of the OpenIoT project (openiot.eu) is to develop a bluepring middleware infrastructure for implementing/integrating Internet-of-Things solutions. OpenIoT is supported (co-funded) by the European Commission as part of the FP7 programme. It is a joint effort of several developer teams around Europe, including open source enthousiasts and developers of other prominent open source IoT platforms such as Global Sensor Networks (GSN) and AspireRfid. OpenIoT is a java-based IoT project, which features unique properties. In particular, it provides the means for: 1.Collecting and processing data from virtually any sensor/ data stream, including physical devices, sensor processing algorithms, social media processing algorithms and more. In OpenIoT the term sensor refers to any components that can provide observations. OpenIoT will facilitate the integration of the above sensors with only minimal effort (i.e. few man days effort) for implementing an appropriate access driver. 2. Semantically annotating sensor data, according to the W3C Semantic Sensor Networks (SSN) specifications. 3. Streaming data of the various sensors to a cloud computing infrastructure. 4. Dynamically discovering/querying sensors and their data. 5 Composing and delivering IoT services that comprise data from multiple sensors based on minimal programming and through the use of visual tools. 6. Visualizing IoT data based on appropriate mashups (charts, graphs, maps etc.) 7. Optimizing resources within the T middleware and cloud computing infrastructure. The above features make the project innovative and differentiate it from other/similar IoT middleware projects. The OpenIoT founders and developers aspire to gradually engage open source developers in the OpenIoT community, as users, developers and contributors. The development and expansion of an open source community is deemed as a critical step for improving the project and boosting its wide adoption. The project's presentation during FOSDEM could comprise: 1. An overview presentation of the project. 2. An anatomy of the open source components comprising the FOSS project on Github. 3. Short/targeted demonstrations of IoT applications build based on the project. 4. Short tutorials on downloading/using/deploying OpenIoT 5. Q&A sessions aiming at resolving key questions and issues.
 So thank you for coming to the Dev Room of Internet of Things. I'd like to present our next speaker, who's Nikos Keflakis from Greece. Nikos is a researcher in a number of areas, especially European projects for RFID and Open IoT, which is the project for the Internet of Things, one of many projects. Nikos, we have 15 minutes for presentations, 10 minutes for discussions, and then we cut. And if people ask questions, please repeat the questions, because we are streaming live to the whole world, and it's through the microphone here that we're here. So if you're talking, we want to hear you. Keep your questions short, clean. Nikos will repeat them for the camera, for the audience. Thank you very much. Thank you very much for the introduction. So thank you for joining this session. So in this session, I'm going to present you the Open IoT project, which is a joint effort of seven European partners, universities, and industry, and it is part of an EU project. So what can Open IoT do? First of all, Open IoT is a means to capture data from various sensors. And when we say sensors, we mean virtually anything. So this room could be a sensor that has some observation as attributes. So, for example, the number of people that are here now attending this meeting could be an observation item that could be captured from this platform. Then after pushing this data to the cloud, this sensor data to the cloud, we are able to discover the available sensor types that consist this data. And these types then can be used with an appropriate user interface that we have built to create easily and without considering the complexity of the middle world platform and the technologies, services that could be used later on from a user, simple or more complex. Then we can visualize these services that have been built and create mass-ups and provide them either to the public or for private use. And finally, we can manage these resources and we can, the modules resources and our platform deployment, and we can apply optimization in various stages of this platform. So what can you see here is a high-level description of the Open IoT architecture. So as I have described before, we have our sensor middleware platform, which is in fact our legacy from another open source project called Global Sensor Middleware, the GSN project, which we have extended to support the cloud storage and semantics to semantically annotate the data and store them to a cloud platform. So then we have our cloud platform which can run either locally, inside a campus, inside a company, or be public. So for the example I will give you next for the demonstration is run to the EC2 Amazon cloud. Then it is consisted from the scheduler which is responsible to discover available sensors and help request definition tool to build and store a service description to the data cloud. And then we have the service delivery utility manager which then undertakes the task to retrieve these descriptions and visualize them at the request presentation module. So as I have already mentioned, with our platform we can create a virtual sensor out of anything in our everyday lives, physical or virtual one, and it doesn't take more than one or two month dates to create it because we have implemented a special interface, we have created a special interface that someone has to implement and use all the available features provided by the global sensor and mid-ware platform. So then we have the ability to annotate this data and semantically annotate this data and store them to the cloud. And of course we have tools to facilitate this deployment. So another thing that we can do as already mentioned is the sensor discovery and the ability to use these sensors to create new services and store them back to the cloud. These services are described with Sparkle queries, so we are using the Sparkle query language to store and retrieve this kind of data. So and then of course we have visual tools to help this service description. We are with a toolbox and just the dragging and dropping modules. It is possible to automatically create and transparently from the user to create the required Sparkle queries to be used later in our service visualization. And of course we have the tools, we already have created some widgets, line charts, pie charts, gauge meters or maps that the data that are retrieved from our platform can be visualized, but it is also easy as we are using open source libraries to do that to create new widgets that can apply to other, compare the wind chill temperature versus the actual air temperature in Brussels area for the last three weeks. And so this service will be done on the fly and without having to prior set up anything else. And of course this is going to present it with the widgets available in the request presentation tool. Okay, sorry. So as you can see here we have integrated all our tools in a simple point of entrance, so the Open IoT ID tool. And now we have started creating our application. So we just enter a new name, a new application name and we start configuring our scenario. So the first thing we have to do is go to the Brussels area and check for the available sensors. So we pinpoint an area and we set a radius of 15 kilometers. So our point of interest is this specific area. And now we have discovered two available sensor types and one of them is the weather station. So we need to apply a filtering mechanism from our toolbox to define the dates that are of interest of us. So we define the three last weeks, actually the three last weeks when this video was taken, so from 7th till the 28th of January. So you are going to see the actual temperature of Brussels area for these three weeks. The next thing we apply a group modules so as to group the wind chill and the air temperature by year, month and date. So after we have set up the group mechanisms, we choose the average from our toolbox as an aggregator. So because we want to get the average for every day. And we are going to use a line chart as a sink. So at the line chart we choose to provide two lines because we are going to have two inputs. And at the X axis we are going to set up the date, so a date observation and at the Y axis we are going to set up the Celsius value. So after setting up the line chart, we just connecting the appropriate outputs and inputs to the line chart so we connect the dates at the X axis and the average output at the Y axis. So the next thing that we have to do is we can validate this design. So we actually can automatically generate the sparkle curies that are involved in this design. So if you take this sparkle query and execute them at the sparkle interface of an RDF data store, we can produce the output that we are going to visualize later. So all this information together with what kind of widget we are using, some constraints that we are using and the structure of the service are sent to the scheduler and stored to the cloud. And so now by logging in at the request presentation tool, we are retrieving this information. So now it loads the application setup that we have already done and now we are going to visualize it. So after refreshing the tool, we can see at the widget the actual temperature value. So I guess it was a little bit hotter in the three weeks of January than now. So the question was you were showing a weather capability and on the filter on the input, you put a date. How did I know for example that was a date capability and not for example altitude or a geographic area. What talks about the capabilities there? For this specific tool, this specific box module if you noticed, it's referring specifically about date. So it wasn't something else. So currently at the filtering part we support dates but later on we can extend it for other metadata of sensors. For example, the depth that a sensor is put in the ground if we want to count the ground humidity or other values that have been supported. So I will explain with a relatively new project. Okay so to go to the open source part of the thing, we are using LTPL license version 3. Our project was first released at September of 2013. All the modules provide main event management and we have documentation available in our wiki for Eclipse and NetBeans IDs. We have the open source project portal which is available at the JIT Hub. So it's the OpenIoT project. We have provided the wiki again from JIT Hub, the documentation. Inside you can find the documentation inside the wiki. We have download links and also you can find the project stats in the OLO. So we are using for our project other open source libraries, containers and frameworks. So we are using the Apache Maven already mentioned. Our preference integrated development environment is Eclipse. We are using Jboss REST easy for the web services. We are using JSF prime phases and the JS plan for the user interface that have been demonstrated and you have already saw. JMX and Java melody for the management and monitoring. Our web container application platform container is Jboss. For the RDF database we are using the open source version of virtuoso. Cessami and general libraries for accessing the Sparkling interface that we have implemented. Jaseek has the authentication system implementation that we are going to have been already implemented in our project but it's to be integrated to it and we are using log back for processing logging events. So these are some of the open source libraries and platforms that we are our project is using. Although we are a new, relatively new project we have so far 13 contributors, dedicated contributors to it. Our project is mostly written in Java and although it is a new project, it is one of the best new projects for the year 2013. As given from the BlackDuck organization which is the organization behind OLOCH. So our project can be also accessed from our European project link where you can go to the Open IoT EU and we have a more generic view of our site and a more dedicated for academics that you can find the link inside the main site. So if you have any questions, this time I'm going to give some pens to the ones that already have questions. Thank you. So you've talked mainly about logging sensor data. Is your project also about actuating actuators for example, could it be used in an industrial environment to monitor a process and even control parts of it? Okay. Actually our project is already been used in industrial scenarios because there are five scenarios that implement in the specific project and actually one is in industry where it is, so the example was only provided as an example. You can have as input anything you like. The one that you cannot do is provide control over the sensor because we decided that okay, someone may allow access to his sensors but most of the people won't allow, so they won't just push data to the cloud and not allow someone else to log into their systems and have control over their sensors. So we're only pushing data up but we're not pushing data down. We have another solution about this which is actually for the sensor, the sensor millware to check in a stable time interval if something have changed, if I'm not using a sensor anymore so it can stop producing data and so on and so forth. So this is the solution that we have designed and implementing. Can you justify the fact that you use RDF triple store for storing the data because if I had to load a lot of data and then having a lot of throughput and afterwards letting application writing some kind of craze but the mining machine learning of the data, well I'm not sure triple store would be the best choice. Can you explain why did you go in that way? Thank you. So the reason that we have used RDF is that we are using a special ontology that we call OpenAoT ontology which is actually an extension of the sensor network ontology and this is used to model all the available sensors and sensor types in a manner that we can homogenously access. So for example at XIVELY you push data without some specific control so all the sensors cannot be grouped. So by using this specific platform without the user has to bother on annotating this data with the OpenAoT ontology or bothering about RDF triple store they can produce their data in a way that can be used from other services and other users. So this is mainly the reason that we have followed the RDF triple store and the specific ontology. I think the reason of using RDF is more obvious because at the moment we are not working only with hardware, we are also working with virtual sensors. So at the time that we have Twitter we have streams collecting from the internet so that data is coming in a specific format which is HML. So the reason is already the format is there, the standard is there, WTC standard is the format RDF so why not use this standard to break all the data from Arduino cards or interconnected devices into that format. Then in that way we can combine both. It's true that RDF give us a little bit of headache when you want to access database but it's true as well that MySQL is a relational database and if you have multiple devices, thousands of devices will have a headache as well. So what we have done and we are doing at the moment in this project is extending to stream data processing which is one of the areas that we are researching and we are inviting people to do research on that or work with us on that. Because stream processing means we can do queries into streams in real time so means we can get information more easily. So we have run experiments and stream processing queries or stream processing is more efficient than even relational database so it's a trade off essentially in real time. If you want to look at them you should sort of, I work with a number of things in finance where they are doing real time data processing things like KDB and so on and it might just be worth looking at those tools because they do it all the time already, sub-micro second response right now. That's not research, that's everyday business as usual. We finished five minutes before half hour. We have time this afternoon for participant driven discussions so if you have questions about such things as storing data in load and see situations come back with that. Thank you very much. We have a five minute break. Then we start on the hour with the next topic. Put that down. you you
 So thank you for coming to the Dev Room of Internet of Things. I'd like to present our  next speaker, who's Nikos Keflakis from Greece. Nikos is a researcher in a number of areas,  especially European projects for RFID and Open IoT, which is the project for the Internet  of Things, one of many projects. Nikos, we have 15 minutes for presentations, 10 minutes  for discussions, and then we cut. And if people ask questions, please repeat the questions,  because we are streaming live to the whole world, and it's through the microphone here  that we're here. So if you're talking, we want to hear you. Keep your questions short,  clean. Nikos will repeat them for the camera, for the audience. Thank you very much.  Thank you very much for the introduction. So thank you for joining this session. So in  this session, I'm going to present you the Open IoT project, which is a joint effort of  seven European partners, universities, and industry, and it is part of an EU project.  So what can Open IoT do? First of all, Open IoT is a means to capture data from various  sensors. And when we say sensors, we mean virtually anything. So this room could be  a sensor that has some observation as attributes. So, for example, the number of people that  are here now attending this meeting could be an observation item that could be captured  from this platform. Then after pushing this data to the cloud, this sensor data to the  cloud, we are able to discover the available sensor types that consist this data. And these  types then can be used with an appropriate user interface that we have built to create  easily and without considering the complexity of the middle world platform and the technologies,  services that could be used later on from a user, simple or more complex. Then we can  visualize these services that have been built and create mass-ups and provide them either  to the public or for private use. And finally, we can manage these resources and we can,  the modules resources and our platform deployment, and we can apply optimization in various stages  of this platform. So what can you see here is a high-level description of the Open IoT  architecture. So as I have described before, we have our sensor middleware platform, which  is in fact our legacy from another open source project called Global Sensor Middleware, the  GSN project, which we have extended to support the cloud storage and semantics to semantically  annotate the data and store them to a cloud platform. So then we have our cloud platform  which can run either locally, inside a campus, inside a company, or be public. So for the  example I will give you next for the demonstration is run to the EC2 Amazon cloud. Then it is  consisted from the scheduler which is responsible to discover available sensors and help request  definition tool to build and store a service description to the data cloud. And then we  have the service delivery utility manager which then undertakes the task to retrieve  these descriptions and visualize them at the request presentation module. So as I have  already mentioned, with our platform we can create a virtual sensor out of anything in  our everyday lives, physical or virtual one, and it doesn't take more than one or two  month dates to create it because we have implemented a special interface, we have created a special  interface that someone has to implement and use all the available features provided by  the global sensor and mid-ware platform. So then we have the ability to annotate this  data and semantically annotate this data and store them to the cloud. And of course we  have tools to facilitate this deployment. So another thing that we can do as already  mentioned is the sensor discovery and the ability to use these sensors to create new  services and store them back to the cloud. These services are described with Sparkle  queries, so we are using the Sparkle query language to store and retrieve this kind of  data. So and then of course we have visual tools to help this service description. We  are with a toolbox and just the dragging and dropping modules. It is possible to automatically  create and transparently from the user to create the required Sparkle queries to be  used later in our service visualization. And of course we have the tools, we already have  created some widgets, line charts, pie charts, gauge meters or maps that the data that are  retrieved from our platform can be visualized, but it is also easy as we are using open source  libraries to do that to create new widgets that can apply to other, compare the wind  chill temperature versus the actual air temperature in Brussels area for the last three weeks.  And so this service will be done on the fly and without having to prior set up anything  else. And of course this is going to present it with  the widgets available in the request presentation tool. Okay, sorry. So as you can see here we  have integrated all our tools in a simple point of entrance, so the Open IoT ID tool.  And now we have started creating our application. So we just enter a new name, a new application  name and we start configuring our scenario. So the first thing we have to do is go to  the Brussels area and check for the available sensors. So we pinpoint an area and we set  a radius of 15 kilometers. So our point of interest is this specific area. And now we  have discovered two available sensor types and one of them is the weather station.  So we need to apply a filtering mechanism from our toolbox to define the dates that  are of interest of us. So we define the three last weeks, actually the three last weeks  when this video was taken, so from 7th till the 28th of January. So you are going to see  the actual temperature of Brussels area for these three weeks. The next thing we apply  a group modules so as to group the wind chill and the air temperature by year, month and  date. So after we have set up the group mechanisms, we choose the average from our toolbox as  an aggregator. So because we want to get the average for every day. And we are going to  use a line chart as a sink. So at the line chart we choose to provide two lines because  we are going to have two inputs. And at the X axis we are going to set up the date, so  a date observation and at the Y axis we are going to set up the Celsius value. So after  setting up the line chart, we just connecting the appropriate outputs and inputs to the  line chart so we connect the dates at the X axis and the average output at the Y axis.  So the next thing that we have to do is we can validate this design. So we actually can  automatically generate the sparkle curies that are involved in this design. So if you  take this sparkle query and execute them at the sparkle interface of an RDF data store,  we can produce the output that we are going to visualize later. So all this information  together with what kind of widget we are using, some constraints that we are using and the  structure of the service are sent to the scheduler and stored to the cloud. And so now by logging  in at the request presentation tool, we are retrieving this information. So now it loads  the application setup that we have already done and now we are going to visualize it.  So after refreshing the tool, we can see at the widget the actual temperature value. So  I guess it was a little bit hotter in the three weeks of January than now.  So the question was you were showing a weather capability and on the filter on the input,  you put a date. How did I know for example that was a date capability and not for example  altitude or a geographic area. What talks about the capabilities there?  For this specific tool, this specific box module if you noticed, it's referring specifically  about date. So it wasn't something else. So currently at the filtering part we support  dates but later on we can extend it for other metadata of sensors. For example, the depth  that a sensor is put in the ground if we want to count the ground humidity or other values  that have been supported. So I will explain with a relatively new project.  Okay so to go to the open source part of the thing, we are using LTPL license version  3. Our project was first released at September of 2013. All the modules provide main event  management and we have documentation available in our wiki for Eclipse and NetBeans IDs.  We have the open source project portal which is available at the JIT Hub. So it's the OpenIoT  project. We have provided the wiki again from JIT Hub, the documentation. Inside you can  find the documentation inside the wiki. We have download links and also you can find  the project stats in the OLO. So we are using for our project other open source libraries,  containers and frameworks. So we are using the Apache Maven already mentioned. Our preference  integrated development environment is Eclipse. We are using Jboss REST easy for the web services.  We are using JSF prime phases and the JS plan for the user interface that have been demonstrated  and you have already saw. JMX and Java melody for the management and monitoring. Our web  container application platform container is Jboss. For the RDF database we are using  the open source version of virtuoso. Cessami and general libraries for accessing the Sparkling  interface that we have implemented. Jaseek has the authentication system implementation  that we are going to have been already implemented in our project but it's to be integrated to  it and we are using log back for processing logging events. So these are some of the open  source libraries and platforms that we are our project is using. Although we are a new,  relatively new project we have so far 13 contributors, dedicated contributors to it. Our project  is mostly written in Java and although it is a new project, it is one of the best new  projects for the year 2013. As given from the BlackDuck organization which is the organization  behind OLOCH. So our project can be also accessed from our European project link where you can  go to the Open IoT EU and we have a more generic view of our site and a more dedicated for  academics that you can find the link inside the main site. So if you have any questions,  this time I'm going to give some pens to the ones that already have questions. Thank you.  So you've talked mainly about logging sensor data. Is your project also about actuating  actuators for example, could it be used in an industrial environment to monitor a process  and even control parts of it? Okay. Actually our project is already been used in industrial  scenarios because there are five scenarios that implement in the specific project and  actually one is in industry where it is, so the example was only provided as an example.  You can have as input anything you like. The one that you cannot do is provide control  over the sensor because we decided that okay, someone may allow access to his sensors but  most of the people won't allow, so they won't just push data to the cloud and not allow  someone else to log into their systems and have control over their sensors. So we're  only pushing data up but we're not pushing data down. We have another solution about  this which is actually for the sensor, the sensor millware to check in a stable time  interval if something have changed, if I'm not using a sensor anymore so it can stop  producing data and so on and so forth. So this is the solution that we have designed  and implementing. Can you justify the fact that you use RDF triple store for storing  the data because if I had to load a lot of data and then having a lot of throughput and  afterwards letting application writing some kind of craze but the mining machine learning  of the data, well I'm not sure triple store would be the best choice. Can you explain  why did you go in that way? Thank you. So the reason that we have used RDF is that we  are using a special ontology that we call OpenAoT ontology which is actually an extension  of the sensor network ontology and this is used to model all the available sensors and  sensor types in a manner that we can homogenously access. So for example at XIVELY you push  data without some specific control so all the sensors cannot be grouped. So by using  this specific platform without the user has to bother on annotating this data with the  OpenAoT ontology or bothering about RDF triple store they can produce their data in a way  that can be used from other services and other users. So this is mainly the reason that we  have followed the RDF triple store and the specific ontology.  I think the reason of using RDF is more obvious because at the moment we are not working only  with hardware, we are also working with virtual sensors. So at the time that we have Twitter  we have streams collecting from the internet so that data is coming in a specific format  which is HML. So the reason is already the format is there, the standard is there, WTC  standard is the format RDF so why not use this standard to break all the data from Arduino  cards or interconnected devices into that format. Then in that way we can combine both.  It's true that RDF give us a little bit of headache when you want to access database  but it's true as well that MySQL is a relational database and if you have multiple devices,  thousands of devices will have a headache as well. So what we have done and we are doing  at the moment in this project is extending to stream data processing which is one of  the areas that we are researching and we are inviting people to do research on that or  work with us on that. Because stream processing means we can do queries into streams in real  time so means we can get information more easily. So we have run experiments and stream  processing queries or stream processing is more efficient than even relational database  so it's a trade off essentially in real time.  If you want to look at them you should sort of, I work with a number of things in finance  where they are doing real time data processing things like KDB and so on and it might just  be worth looking at those tools because they do it all the time already, sub-micro second  response right now. That's not research, that's everyday business as usual.  We finished five minutes before half hour. We have time this afternoon for participant  driven discussions so if you have questions about such things as storing data in load  and see situations come back with that.  Thank you very much. We have a five minute break. Then we start on the hour with the  next topic.  Put that down.  you  you
_FOSDEM_2014__OpenIoT_8ap0yOffaqU_0_251.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_252_1091.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_1092_1751.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_1752_8387.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_8388_10883.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_10884_11723.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_11724_12203.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_12204_12551.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_12552_12623.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_12624_12671.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_12672_19355.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_19356_19403.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_19404_19451.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_19452_20819.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_20820_20939.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_20940_21527.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_21528_22811.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_22812_23075.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_23076_24611.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_24612_25823.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_25824_26147.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_26148_27035.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_27036_27203.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_27204_27575.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_27576_28715.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_28716_28763.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_28764_31919.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_31920_31967.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_31968_32759.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_32760_32807.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_32808_33083.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_33084_34775.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_34776_34847.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_34848_36719.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_36720_36767.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_36768_36923.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_36924_37415.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_37416_37535.png _FOSDEM_2014__OpenIoT_8ap0yOffaqU_37536_37937.png
So thank you for coming to the Dev Room of Internet of Things. I'd like to present our next speaker, who's Nikos Keflakis from Greece. Nikos is a researcher in a number of areas, especially European projects for RFID and Open IoT, which is the project for the Internet of Things, one of many projects. Nikos, we have 15 minutes for presentations, 10 minutes for discussions, and then we cut. And if people ask questions, please repeat the questions, because we are streaming live to the whole world, and it's through the microphone here that we're here. So if you're talking, we want to hear you. Keep your questions short, clean. Nikos will repeat them for the camera, for the audience. Thank you very much. Thank you very much for the introduction. So thank you for joining this session. So in this session, I'm going to present you the Open IoT project, which is a joint effort of seven European partners, universities, and industry, and it is part of an EU project. So what can Open IoT do? First of all, Open IoT is a means to capture data from various sensors. And when we say sensors, we mean virtually anything. So this room could be a sensor that has some observation as attributes. So, for example, the number of people that are here now attending this meeting could be an observation item that could be captured from this platform. Then after pushing this data to the cloud, this sensor data to the cloud, we are able to discover the available sensor types that consist this data. And these types then can be used with an appropriate user interface that we have built to create easily and without considering the complexity of the middle world platform and the technologies, services that could be used later on from a user, simple or more complex. Then we can visualize these services that have been built and create mass-ups and provide them either to the public or for private use. And finally, we can manage these resources and we can, the modules resources and our platform deployment, and we can apply optimization in various stages of this platform. So what can you see here is a high-level description of the Open IoT architecture. So as I have described before, we have our sensor middleware platform, which is in fact our legacy from another open source project called Global Sensor Middleware, the GSN project, which we have extended to support the cloud storage and semantics to semantically annotate the data and store them to a cloud platform. So then we have our cloud platform which can run either locally, inside a campus, inside a company, or be public. So for the example I will give you next for the demonstration is run to the EC2 Amazon cloud. Then it is consisted from the scheduler which is responsible to discover available sensors and help request definition tool to build and store a service description to the data cloud. And then we have the service delivery utility manager which then undertakes the task to retrieve these descriptions and visualize them at the request presentation module. So as I have already mentioned, with our platform we can create a virtual sensor out of anything in our everyday lives, physical or virtual one, and it doesn't take more than one or two month dates to create it because we have implemented a special interface, we have created a special interface that someone has to implement and use all the available features provided by the global sensor and mid-ware platform. So then we have the ability to annotate this data and semantically annotate this data and store them to the cloud. And of course we have tools to facilitate this deployment. So another thing that we can do as already mentioned is the sensor discovery and the ability to use these sensors to create new services and store them back to the cloud. These services are described with Sparkle queries, so we are using the Sparkle query language to store and retrieve this kind of data. So and then of course we have visual tools to help this service description. We are with a toolbox and just the dragging and dropping modules. It is possible to automatically create and transparently from the user to create the required Sparkle queries to be used later in our service visualization. And of course we have the tools, we already have created some widgets, line charts, pie charts, gauge meters or maps that the data that are retrieved from our platform can be visualized, but it is also easy as we are using open source libraries to do that to create new widgets that can apply to other, compare the wind chill temperature versus the actual air temperature in Brussels area for the last three weeks. And so this service will be done on the fly and without having to prior set up anything else. And of course this is going to present it with the widgets available in the request presentation tool. Okay, sorry. So as you can see here we have integrated all our tools in a simple point of entrance, so the Open IoT ID tool. And now we have started creating our application. So we just enter a new name, a new application name and we start configuring our scenario. So the first thing we have to do is go to the Brussels area and check for the available sensors. So we pinpoint an area and we set a radius of 15 kilometers. So our point of interest is this specific area. And now we have discovered two available sensor types and one of them is the weather station. So we need to apply a filtering mechanism from our toolbox to define the dates that are of interest of us. So we define the three last weeks, actually the three last weeks when this video was taken, so from 7th till the 28th of January. So you are going to see the actual temperature of Brussels area for these three weeks. The next thing we apply a group modules so as to group the wind chill and the air temperature by year, month and date. So after we have set up the group mechanisms, we choose the average from our toolbox as an aggregator. So because we want to get the average for every day. And we are going to use a line chart as a sink. So at the line chart we choose to provide two lines because we are going to have two inputs. And at the X axis we are going to set up the date, so a date observation and at the Y axis we are going to set up the Celsius value. So after setting up the line chart, we just connecting the appropriate outputs and inputs to the line chart so we connect the dates at the X axis and the average output at the Y axis. So the next thing that we have to do is we can validate this design. So we actually can automatically generate the sparkle curies that are involved in this design. So if you take this sparkle query and execute them at the sparkle interface of an RDF data store, we can produce the output that we are going to visualize later. So all this information together with what kind of widget we are using, some constraints that we are using and the structure of the service are sent to the scheduler and stored to the cloud. And so now by logging in at the request presentation tool, we are retrieving this information. So now it loads the application setup that we have already done and now we are going to visualize it. So after refreshing the tool, we can see at the widget the actual temperature value. So I guess it was a little bit hotter in the three weeks of January than now. So the question was you were showing a weather capability and on the filter on the input, you put a date. How did I know for example that was a date capability and not for example altitude or a geographic area. What talks about the capabilities there? For this specific tool, this specific box module if you noticed, it's referring specifically about date. So it wasn't something else. So currently at the filtering part we support dates but later on we can extend it for other metadata of sensors. For example, the depth that a sensor is put in the ground if we want to count the ground humidity or other values that have been supported. So I will explain with a relatively new project. Okay so to go to the open source part of the thing, we are using LTPL license version 3. Our project was first released at September of 2013. All the modules provide main event management and we have documentation available in our wiki for Eclipse and NetBeans IDs. We have the open source project portal which is available at the JIT Hub. So it's the OpenIoT project. We have provided the wiki again from JIT Hub, the documentation. Inside you can find the documentation inside the wiki. We have download links and also you can find the project stats in the OLO. So we are using for our project other open source libraries, containers and frameworks. So we are using the Apache Maven already mentioned. Our preference integrated development environment is Eclipse. We are using Jboss REST easy for the web services. We are using JSF prime phases and the JS plan for the user interface that have been demonstrated and you have already saw. JMX and Java melody for the management and monitoring. Our web container application platform container is Jboss. For the RDF database we are using the open source version of virtuoso. Cessami and general libraries for accessing the Sparkling interface that we have implemented. Jaseek has the authentication system implementation that we are going to have been already implemented in our project but it's to be integrated to it and we are using log back for processing logging events. So these are some of the open source libraries and platforms that we are our project is using. Although we are a new, relatively new project we have so far 13 contributors, dedicated contributors to it. Our project is mostly written in Java and although it is a new project, it is one of the best new projects for the year 2013. As given from the BlackDuck organization which is the organization behind OLOCH. So our project can be also accessed from our European project link where you can go to the Open IoT EU and we have a more generic view of our site and a more dedicated for academics that you can find the link inside the main site. So if you have any questions, this time I'm going to give some pens to the ones that already have questions. Thank you. So you've talked mainly about logging sensor data. Is your project also about actuating actuators for example, could it be used in an industrial environment to monitor a process and even control parts of it? Okay. Actually our project is already been used in industrial scenarios because there are five scenarios that implement in the specific project and actually one is in industry where it is, so the example was only provided as an example. You can have as input anything you like. The one that you cannot do is provide control over the sensor because we decided that okay, someone may allow access to his sensors but most of the people won't allow, so they won't just push data to the cloud and not allow someone else to log into their systems and have control over their sensors. So we're only pushing data up but we're not pushing data down. We have another solution about this which is actually for the sensor, the sensor millware to check in a stable time interval if something have changed, if I'm not using a sensor anymore so it can stop producing data and so on and so forth. So this is the solution that we have designed and implementing. Can you justify the fact that you use RDF triple store for storing the data because if I had to load a lot of data and then having a lot of throughput and afterwards letting application writing some kind of craze but the mining machine learning of the data, well I'm not sure triple store would be the best choice. Can you explain why did you go in that way? Thank you. So the reason that we have used RDF is that we are using a special ontology that we call OpenAoT ontology which is actually an extension of the sensor network ontology and this is used to model all the available sensors and sensor types in a manner that we can homogenously access. So for example at XIVELY you push data without some specific control so all the sensors cannot be grouped. So by using this specific platform without the user has to bother on annotating this data with the OpenAoT ontology or bothering about RDF triple store they can produce their data in a way that can be used from other services and other users. So this is mainly the reason that we have followed the RDF triple store and the specific ontology. I think the reason of using RDF is more obvious because at the moment we are not working only with hardware, we are also working with virtual sensors. So at the time that we have Twitter we have streams collecting from the internet so that data is coming in a specific format which is HML. So the reason is already the format is there, the standard is there, WTC standard is the format RDF so why not use this standard to break all the data from Arduino cards or interconnected devices into that format. Then in that way we can combine both. It's true that RDF give us a little bit of headache when you want to access database but it's true as well that MySQL is a relational database and if you have multiple devices, thousands of devices will have a headache as well. So what we have done and we are doing at the moment in this project is extending to stream data processing which is one of the areas that we are researching and we are inviting people to do research on that or work with us on that. Because stream processing means we can do queries into streams in real time so means we can get information more easily. So we have run experiments and stream processing queries or stream processing is more efficient than even relational database so it's a trade off essentially in real time. If you want to look at them you should sort of, I work with a number of things in finance where they are doing real time data processing things like KDB and so on and it might just be worth looking at those tools because they do it all the time already, sub-micro second response right now. That's not research, that's everyday business as usual. We finished five minutes before half hour. We have time this afternoon for participant driven discussions so if you have questions about such things as storing data in load and see situations come back with that. Thank you very much. We have a five minute break. Then we start on the hour with the next topic. Put that down. you you
European projects for RFID and Open IoT, which is the project for the Internet of Things, one of live to the whole world, and it's through the short, clean. Nikos will repeat them for the Thank you very much for the introduction. So project, which is a joint effort of seven capture data from various sensors. And when we say sensors, we mean virtually anything. So this could be an observation item that could be this data to the cloud, this sensor data to the types then can be used with an appropriate user world platform and the technologies, services resources and we can, the modules resources and optimization in various stages of this platform. middleware platform, which is in fact our legacy from another open source project called Global Sensor Middleware, the GSN project, which we have store them to a cloud platform. So then we have responsible to discover available sensors and help request definition tool to build and store a available features provided by the global sensor And of course we have tools to facilitate this course we have visual tools to help this service dragging and dropping modules. It is possible to some widgets, line charts, pie charts, gauge meters or maps that the data that are retrieved also easy as we are using open source libraries service will be done on the fly and without widgets available in the request presentation And we are going to use a line chart as a sink. So at the line chart we choose to provide two go to the open source part of the thing, we are the OpenIoT project. We have provided the wiki development environment is Eclipse. We are using the open source libraries and platforms that we contributors, dedicated contributors to it. Our view of our site and a more dedicated for main site. So if you have any questions, this like. The one that you cannot do is provide implementing. Can you justify the fact that you annotating this data with the OpenAoT ontology or their data in a way that can be used from other services and other users. So this is mainly the we are not working only with hardware, we are database and if you have multiple devices, stream processing means we can do queries into discussions so if you have questions about such