Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IoT and Cloud services interactions


Published on

Román Sosa (Atos)

Published in: Software
  • Be the first to comment

IoT and Cloud services interactions

  1. 1. AGILE M18 Review, 20 October 2017, Brussels (Belgium) IoT and Cloud services interactions ROMÁN SOSA/ ATOS / WP4 LEADER 1
  2. 2. Outline 1. Architecture mapping 2. Introduction 3. IoT services 4. Storage services 5. PaaS services 6. Next steps 7. Summary
  3. 3. Mapping to AGILE Architecture – Development View
  4. 4. Intro - Objectives Objectives ◦ Sharing of sensor data with cloud services ◦ Deployment of AGILE workflows on cloud Benefits ◦ Performance ◦ Ex: Complex data processing is needed ◦ Availability ◦ Ex: Data or processing need to be available 24x7 ◦ Accessibility ◦ Ex: Many users need to access the data 4
  5. 5. Intro - Classification of clouds Classification of cloud services ◦ IoT services. Specifically intended for IoT usage (e.g. Xively) ◦ Closed devices services. These devices directly push sensor data to cloud (e.g. Misfit) ◦ Storage services (e.g. Dropbox) ◦ Deployment services (e.g. Heroku) 5
  6. 6. Application exports data ◦ IoT services ◦ Storage services Application imports data ◦ Closed-device services Intro - Use cases (I) 6 <X,Y> <X,Y>
  7. 7. Intro - Use cases (II) AGILE Applications Runtime deployed on cloud Push an AGILE application to a remote runtime 7
  8. 8. Intro - Use cases (III) Export sensor data to cloud ◦ Storage services Get PaaS Recommendation 8 <X,Y,t> Local Storage Cloud Recommender INPUT OUTPUTGW profile
  9. 9. Intro - Approach Node-RED ◦ Rapid prototyping ◦ IoT services and Storage services: Nodes to share data ◦ Reusing if possible!! Kura Wires ◦ Industrial-oriented ◦ Access to Kura supported services PaaS providers ◦ Deployment of Node-RED workflows 9
  10. 10. IoT services (I) Supported services ◦ Xively ◦ FIWARE ◦ ThingSpeak ◦ Using Kura ◦ AWS IoT, Azure IoT, Kapua ◦ Using Shimmer ◦ Fitbit, Google Fit, Misfit… Issues ◦ Domain translation ◦ A single sensor datum is expected to be sent to service when it occurs. ◦ Very different behaviour and interface 10
  11. 11. IoT services (II) Xively (LogMeIn) ◦ Pushes sensor data ◦ Automatic creation of a device ◦ FIWARE ◦ Pushes sensor data ◦ ThingSpeak (MathWorks) ◦ Pushes sensor data ◦ Allows automatic creation of a channel ◦ ◦ Fork of existent node. 11
  12. 12. IoT services (III) Health services ◦ Pulls sensor data from cloud service ◦ Integrating Shimmer: ◦ Supported services: Fitbit, Google Fit, Misfit… ◦ Open MHealth ◦ Kura Wires ◦ Pushes sensor data ◦ Integrating the Kura AGILE component ◦ Supported services: AWS IoT, Azure IoT, Kapua ◦ Pending integration with Kura REST API ◦ It will allow services to be supported from Node-RED 12
  13. 13. Storage services (I) Supported services ◦ Dropbox ◦ Google Drive ◦ OwnCloud ◦ SOLID servers Issues ◦ Appending to files not possible ◦ OAuth2 → IDM 13
  14. 14. Storage services (II) Dropbox ◦ Uploads files ◦ ◦ Fork of existent node Google Drive ◦ Uploads files ◦ OwnCloud ◦ Uploads files ◦ SOLID servers ◦ Pushes sensor data ◦ Adds semantic information ◦ 14
  15. 15. Storage services (III) Cloud Data Management UI ◦ Allows uploading sensor data stored in Local Storage to a supported Storage service ◦ Backend pending 15
  16. 16. Storage services - Demo Upload sensor data to Owncloud The workflow reads values from the dummy device (each 10s). The values are buffered. Each 30s, the contents of the buffer are uploaded to an ownCloud repository. Goal: demonstrate easy file uploading to a storage service 16
  17. 17. PaaS services Node-RED deployment ◦ Offers uniform API for deployment of applications ◦ Not limited to Node-RED ◦ Supported services ◦ CloudFoundry v2 compatible ◦ Heroku ◦ OpenShift v2 (discontinued) ◦ OpenShift v3 (in progress) ◦ Workflow to cloud ◦ Move workflow to cloud ◦ Forwards incoming data to remote workflow ◦ 17
  18. 18. PaaS services - Demo Deploy AGILE workflows to cloud Three workflows ◦ Local: Read from dummy device ◦ Remote: Send to a FIWARE IoT endpoint ◦ Chart: Get values from FIWARE Context Broker and plot Two workflows to push to cloud. ◦ Remote workflow is pushed to cloud → The local chart still being updated. ◦ Chart workflow is pushed to cloud → The chart data is public on Internet. Goals: ◦ offload computational processing ◦ easy public release of data 18 FW IoT FW Ctx Broker LOCAL REMOTE GRAPH LOCAL REMOTE GRAPH FW IoT FW Ctx Broker
  19. 19. Security IDM Token ◦ Retrieves token from user authenticated with AGILE ◦ Attribute ◦ Gets attribute for a particular entity ◦ 19
  20. 20. Next steps Implementation of the Cloud Storage backend Integration of the PaaS Deployer in the AGILE software stack Integration of “moving a workflow to the cloud” functionality Finalize support of OpenShift v3 on PaaS Deployer Optional aspects, useful for pilots, that improve the functionality of the implemented Node-RED nodes Integration with pilots 20
  21. 21. Next steps – Pilots Pilot A ◦ Current: Integration with Google Fit is used ◦ Export data to Dropbox or Google Drive ◦ Execution of workflows on remote Node-REDs Pilot B ◦ Export data to a storage service (currently OwnCloud) Pilot C ◦ Use of Kura WIRES and Kapua Cloud Pilot D ◦ Deployment of a back-office application Pilot E ◦ No integration expected 21
  22. 22. Summary Objective ◦ Provide the essential connectors for allowing AGILE users to extend the capabilities of the gateway by managing data and deploying apps in existing cloud services. Achievements ◦ Applications are able to share data with IoT and Storage services ◦ Applications are able to retrieve data from cloud services associated to health devices ◦ Users are able to deploy Node-RED runtimes onto a PaaS service ◦ Users are able to move functionality of local AGILE workflows to remote Node-REDs ◦ Users will be able to share data with Storage services 22
  23. 23. THANK YOU