Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Pilot Design, Execution & Evaluation

565 vues

Publié le

Andreas Menychtas - Bioassist

Publié dans : Logiciels
  • I went from getting $3 surveys to $500 surveys every day!! learn more... ▲▲▲ https://tinyurl.com/realmoneystreams2019
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Your opinions matter! get paid BIG $$$ for them! START NOW!!.. ●●● https://tinyurl.com/realmoneystreams2019
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Pilot Design, Execution & Evaluation

  1. 1. AGILE M18 Review, 20 October 2017, Brussels (Belgium) WP8 - Pilot Design, Execution & Evaluation ANDREAS MENYCHTAS - BIOASSIST - WP8 LEADER
  2. 2. Overview AGILE PilotsReal-time, drone based, multi- sensor emergency and maintenance support in port environments. Improved shopping experience for consumers and sustainable, attractive and differentiating solution for traders. UAV and ground based wildlife real-time monitoring and data collection in wide, inaccessible and wild areas. Quantified-self application for monitoring and analyzing biosignals and activity data IoT Testbed for experimenting with AGILE Components Low cost, high precision, multi- sensor, highly pervasive, sustainable air quality & pollution monitoring.
  3. 3. Methodology Pilots Implementation Pilots Evaluation Delivery of HW & SW components Integration Storylines Use Case Scenarios Project-level requirements Pilot-specific requirements Deployment of AGILE and collection of feedback Pilots Definition and Requirements Analysis Now
  4. 4. M18 Status / Work Done Design and Implementation of Pilots ◦ Definition of the architecture of each pilot ◦ Development of plan for integration with the AGILE components ◦ Continuous feedback to AGILE technical WPs (using the project tools: github, slack, teleconferences etc.) and interactive development of AGILE components ◦ Assessment of requirements fulfillment ◦ Implementation of Pilot Application Prototypes using AGILE Pilots Operation ◦ Definition of the operational plan of each pilot ◦ Procurement of equipment and sensors ◦ User recruitment ◦ Evaluation guidelines
  5. 5. AGILE Components and Pilots AGILE Components Pilot A Pilot B Pilot C Pilot D Pilot E Makers GW Industrial GW GW Management Device and Protocol Management Developers UI Data/Storage API Security API Cloud Integration Recommender/Configurator Integrated In progress HW SW
  7. 7. Overview Home / Daily use by non-experts Simplified Integration of ◦ Biosignal Sensors and Wearables ◦ Communication Protocols (BLE) Effective Data Exchange and Management Data Security and Privacy by Design Support of Cloud APIs for Activity and eHealth Data Synchronization Data Analysis in the Gateway Customization and Extensibility with Data- and Event-driven Workflows Pilot A: Quantified-Self
  8. 8. Implementation Agile Core Device Hooks AgileBLEnetworkcontainer Device Register Device Publish/Subscribe Device Stream Data Device Poll Data Device Driver Configure BLE GATT characteristics Connect and Run device init Map Device BLE notifications to Agile data endpoints Stream data Filter data ReadData AGILE Drivers for Activity Trackers and Biosignal Sensors Quantified-self Application UI Pilot A: Quantified-Self
  9. 9. Mapping to AGILE Architecture Pilot A: Quantified-Self
  10. 10. AGILE Components Used • Restful API is used for the accessing AGILE Services/Components • UI: • Device Management UI is used for the device discovery and setup. In future, the functionality of this UI will be embedded in the Quantified-self application and will be realized by communicating directly with the Device API. • IoT App Developers UI is used for implementing experimental data processing workflows for real-time and historical data. • IoT Gateway Management UI (OS.js) is used for integrating the web UI of the Quantified-self application. • Device API and Protocol API are used for the BLE communication with the activity trackers and biosignal measurement devices. • Data Management Cloud plugins are used for accessing users’ activity data from the cloud based APIs of app providers and devices manufactures such as Google Fit, Fitbit etc. • Security API is used for authentication to the Quantified-self application Pilot A: Quantified-Self
  11. 11. Innovation - KPIs • Holistic Approach • Beyond the limitations of a self-managed mobile application • Fully Automated • Suitable for people unfamiliar with technology such as seniors • Advanced Data Management • Support different approaches for data acquisition • Use of standards in the overall data lifecycle facilitating data import/export • Enhanced Security and Privacy • Local storage of data and sharing through policies • Extensibility and High Customization • Modular Hardware and Container-based Software Stack • Reduced Cost Added Value Minimum support of Devices • Four different types of devices (activity tracker, blood pressure monitor, pulse oximeter, weighing scale) are locally integrated Minimum support of Clouds • Two smartphone applications (Google Fit and FitBit) are supported via their Cloud Platforms KPIs Pilot A: Quantified-Self
  12. 12. Deployment and Operation Plan Location and user recruitment ◦ Recruitment from BioAssist’s user base (Athens) ◦ IMEC is also actively involved and users from the Living Labs will participate (Belgium). ◦ Crowdfunding Campaign Preparation of documents such as user consent, questionnaires, training material, etc. Equipment procurement is progressing Evaluation Cycles ◦ Involve only friendly users until the first stable release ◦ 1st Cycle: M23 – M27 ◦ 2nd Cycle: M27 – M36 Pilot A: Quantified-Self
  14. 14. Overview Pilot B: Open Field and Cattle Monitoring • Monitoring of sensor stations in areas beyond the established communication infrastructure in real time • No need for fixed gateway deployment and wireless network coverage • AGILE gateway will be deployed in UAVs manufactured by Sky-Watch and used for monitoring water quality through remote sensor stations
  15. 15. Implementation Pilot B: Open Field and Cattle Monitoring Ground Control Station (GCS) and UAV • Custom Flight Plans • Monitoring and supervision of the UAV during flight • IP based protocol between UAV and GCS to support AGILE
  16. 16. Implementation Pilot B: Open Field and Cattle Monitoring Sky-Watch AGILE Application • Node.js application deployed in docker container • Interfacing with AGILE API using agile-sdk • Interfacing with AGILE Node-RED using MQTT • Includes webserver for hosting frontend/UI • Currently communicating directly with LoRaWAN module for sensor input
  17. 17. Implementation Pilot B: Open Field and Cattle Monitoring Developers UI – AGILE Node-RED flow • Interfaces with Node.js Application using MQTT • Using AGILE Cloud components – currently ownCloud
  18. 18. Mapping to AGILE Architecture Pilot B: Open Field and Cattle Monitoring
  19. 19. AGILE Components Used Current Status ◦ AGILE REST API via agile-sdk for implementing the interface with AGILE microservices ◦ AGILE Node-RED Cloud Node for data upload to ownCloud ◦ Docker-based deployment infrastructure of AGILE Pilot B: Open Field and Cattle Monitoring Next Steps ◦ Device/Protocol API for communication with ground based sensors ◦ AGILE Data for retrieving stored sensor data ◦ AGILE Security for keeping collected data private ◦ AGILE UI components for configuration of users, devices, etc.
  20. 20. Innovation AGILE is intended to offer quick development and time-to-market for applications where secure data collection and cloud connectivity is of prime concern. Sky-Watch already specializes in data collection by UAV, and foresee increasing demand for cloud connectivity and data offloading in our UAV solutions. In this context, AGILE is considered as an important technology enabler for our future product range. Pilot B: Open Field and Cattle Monitoring
  21. 21. KPIs A1: Designated users will be allowed to log into a cloud storage and retrieve data ◦ An ownCloud server has been setup ◦ Users permissions will be granted during the Pilot deployment phase A2: Sensor data will be collected in flight by the AGILE Gateway ◦ Collection of sensor data from LoRaWAN ground stations is working ◦ The Sky-Watch application interfaces directly with a LoRaWAN module ◦ When LoRa/LoRaWAN support is added to the AGILE stack, Sky-Watch will switch to use the AGILE REST API/agile-sdk A3: Data from AGILE gateway is uploaded automatically to cloud storage upon connection to internet ◦ Data is already uploaded to ownCloud using the Agile Node-RED Cloud Node A4: UI must be viewable on the gateway’s Ethernet interface ◦ The UI is currently displaying live/historical data. Remaining functionality will be added during the next phases A5: Data from more than one sensor shall be present ◦ Currently the setup includes a single station with multiple sensors attached. This will be extended to include more stations/sensors early in the deployment phase Pilot B: Open Field and Cattle Monitoring
  22. 22. Deployment and Operation Plan Pilot B: Open Field and Cattle Monitoring Demonstrator A: Local Air Field Test 1 (Nov 2017 – Feb 2018) ◦ In-flight sensor data collection via data link from UAV to multiple ground stations ◦ Data offloading to cloud using AGILE APIs ◦ Data visible on application UI Demonstrator B: Local Air Field Test 2 (Feb – Jul 2018) ◦ Includes Demonstrator A items ◦ Integration with remaining AGILE core components - Data/Device/Security APIs Demonstrator C: Long Range Field Test (Jul – Dec 2018) ◦ Includes Demonstrator A and B items ◦ UAV needs to travel to move into sensor-range ◦ Final Test & Evaluation
  23. 23. Demo Components Pilot B: Open Field and Cattle Monitoring UAV containing AGILE Gateway, flight controller, and LoRa receiver Sensor element with LoRa transmitter Ground Station consisting of a Linksys Router (for demo) PC for displaying the UI
  24. 24. Demo Pilot B: Open Field and Cattle Monitoring
  26. 26. Overview • Provide a low cost/high quality solution for pollution monitoring based on: • pervasive/IoT philosophy; • Agile platform (both HW & SW); • small, low cost and high precision monitoring stations. • Demonstrate the reduction of the time to market for the development of a vertical solution based on Agile-IoT approach. • Adopt Design for Modularity approach for the design of the hardware platform. • Design and develop a set of prototypes of: • the monitoring station; • the device-to-cloud infrastructure; • a mobile application for the final user. Pilot C: Air Quality and Pollution Monitoring
  27. 27. The monitoring station GW + The user can select up to 10 sensors from a library of sensorsConfigurable sensing through modularity Pilot C: Air Quality and Pollution Monitoring Consolidated design of the AGILE Industrial Gateway hardware reference design. Main board Configurable sensing through modularity Connectivity & maintenance panel
  28. 28. Mapping to AGILE Architecture Pilot C: Air Quality and Pollution Monitoring
  29. 29. Innovation - KPIs The adoption of the DFM design methodology introduces a new sustainable and certified solution in the market of air quality and pollution monitoring: ◦ solution tailored on customer requirements (thanks to DFM and configurator); ◦ cheap solution: ◦ cert. sys.: 200K€ for installation and 200k€/year for maintenance; ◦ 5K€-7K€ device cost, <2K€ for installation and 3K€/year for maintenance (Bosh-Intel solution is not certified and certifiable!). ◦ small dimension and high territorial coverage (180 x 360 x 150 mm vs 1-3 m3); ◦ easy to integrate, install and maintain; open and easy to extend; ◦ fully remotely controlled. The platform allows managing heterogeneity and diversity: more than 150 sensors can be plugged in the monitoring station, depending on the specific application context. Time to market reduction: just 6 months to develop the monitoring station hardware, starting from the industrial gateway reference design. Pilot C: Air Quality and Pollution Monitoring
  30. 30. Deployment and Operation Plan Phase 1 (M12-M18) - basic use cases setup and laboratory tests: concluded. Phase 2 (M18-M26) - industrial and private demonstrator setup and test: ◦ hardware design and development (first release available); ◦ AGILE software stack porting and integration (ongoing); ◦ focused on the first test and evaluation of the AGILE hardware & software solution (ongoing). Phase 3 (M18-M36) - small rural town setup and test: ◦ Amaro (IT) and Martignacco (IT), plan ongoing. Pilot C: Air Quality and Pollution Monitoring Phase 4 (M24-M36) - metropolitan areas setup and test: Udine, Milano (already agreed) and Dubay (under discussion). Phase 5 (M30-M36) - final pervasive demonstrator setup and test: still to be defined. Martignacco, Udine, IT
  32. 32. Overview Objective: IoT technology can help optimize the shop operation and management by monitoring the machines in order to provide a good service to the clients. Pilot D: Enhanced Retail Services Temperature Electricity Distance Light Presence
  33. 33. Overview Deploy a set of sensors to monitor and gather service KPIs to guarantee the quality. Pilot D: Enhanced Retail Services Cold chain Cold Chain maintenance Follow up and temperature alerts Stock Management Alerts and stock replenishment Business continuity Power consumption and availability alerts Opening hours Shutter opening/closing detection Availability Alert when there are clients in the check-out point Temperature Sensors Distance sensors Electricity sensors Light sensors Presence sensors
  34. 34. 34 Pilot D: Enhanced Retail Services
  35. 35. Mapping to AGILE Architecture Pilot D: Enhanced Retail Services
  36. 36. AGILE Components Used Agile-core ◦ ProtocolManager: To register and manage Zigbee protocol. ◦ DeviceManager: To register all devices used by the pilot. ◦ DeviceFactory: Used by the DeviceManager. HTTP, api REST to interact with AGILE components. Agile-OSJS, development and monitoring environment. Agile-node-red, Development of monitoring flows. Agile-protocol-zb, communication between devices. Agile-sdk, library to access the AGILE API from NodeJS. Pilot D: Enhanced Retail Services
  37. 37. Advantages of using AGILE Facilitate the orchestration of all the events generated by the different devices. Facilitate the connection of different systems with the nodes offered by node-red. Standardize the implementation of applications to manage data obtained by a different kind of devices. Remote system management with all functions provided by RESIN.IO. Pilot D: Enhanced Retail Services
  38. 38. Innovation benefits AGILE can help our customer by: ◦ Improving customer experience ◦ Enabling real-time decisions through live monitoring ◦ Reducing cost through process automation ◦ Improving the brand image as being innovative by using IoT technologies ◦ In the future monitoring all the shops from a central console that displays real-time information Pilot D: Enhanced Retail Services
  39. 39. KPIs Minimum support of Devices: Eight different types of devices to be deployed and connected: Light sensor, Stock sensor, Proximity sensor, Electricity sensor, Temperature sensor, Light alarm in the store, Beacon detector, IoT display). ◦ The pilot D will use the 8 types of devices. ◦ For the demo we will use 4: Stock sensor, Proximity sensor, Temperature sensor and IoT display. Minimum development of applications: One AGILE application to visualize the monitoring of the different sensors. ◦ We will develop: ◦ The node-red flow for monitoring ◦ TENTO AGILE Application in Node-JS using AGILE SDK.
  40. 40. Deployment and Operation Plan Pilot Preparation: Define strategy to run the pilot (Oct 2017) ◦ Agree on physical scenario ◦ Define activities needed by employees to support operations. ◦ Agree on the physical devices to be deployed. Venue Set-up (Jan 2018) ◦ Prepare the shop for the pilot, deploying and configuring the AGILE Gateway and the IoT devices. ◦ Train employees. Pilot Monitoring (Feb-Sep 2018) ◦ Monitor the execution of the Pilot in the shop. ◦ Gather data and KPIs to allow measuring the impact of the Pilot in the business. Pilot Evaluation (Oct-Dec 2018) ◦ Evaluate the impact of the pilot based on the data gathered during monitoring phase. Pilot A: Quantified-Self
  41. 41. Demo Pilot D: Enhanced Retail Services
  43. 43. Port Area Monitoring We will examine how drones can be deployed in the event of a fire, explosion or other incident and get a good view on the situation even before the emergency services arrive at the spot. Time is crucial in these situations. Other applications around safety and the environment are within reach. The incidents would be specific to emergency situations for the fire department. Pilot E: Port Area Monitoring
  44. 44. Mapping to AGILE Architecture Pilot E: Port Area Monitoring
  45. 45. AGILE Components Used Components used ◦ agile-rest, ◦ agile-dbus, ◦ agile-core, ◦ agile-ble, ◦ agile-dronekit (own dronekit) Integration: Interfaces used/implemented ◦ BLE -> read sensortag ◦ WIFI -> read drone flightcontroller ◦ LTE/4G -> Long Distance Remote Connection to the GW Pilot E: Port Area Monitoring
  46. 46. Innovation Extensibility ◦ Multiple sensors can be added to the drone depending on the needs. ◦ Standardize the implementation of applications to manage data obtained by a different kind of devices. ◦ Enhanced connection possibilities (4G, 3G, wifi, ble,…). ◦ Multiple communication protocols available. Pilot E: Port Area Monitoring
  47. 47. KPIs Stability ◦ Feedback is provided to the development team for the implementation of the latest version of the AGILE Stack Latency & reactivity ◦ Latency is ok for viewing cameras. ◦ Over 4G reactivity of the drone is not good enough. With drone legislation it is not allowed since the drone has to be in line of sight all the time and has to react immediately to the commands of the pilot. Power consumption ◦ Not yet evaluated since the drone market evolves constantly. Pilot E: Port Area Monitoring
  48. 48. Deployment and Operation Plan Pilot Preparation: Define strategy to run the pilot (Oct 2017) ◦ Prepare PoC. ◦ Integrate Agile. Pilot Integration(Jan-Sep 2018) ◦ Integration and use in other projects. ◦ The drone & Agile will be used in another project, results from the PoC will be integrated there. Pilot Evaluation (Oct-Dec 2018) ◦ Evaluate the impact of the pilot based on the data gathered during test phase. Pilot E: Port Area Monitoring
  49. 49. Demo Pilot E: Port Area Monitoring
  51. 51. Approach 51 • Goal: pre-field tests to validate AGILE software before actual deployments • Approach: Building upon the IoT-lab testbed • Bare-metal access to 2700+ IoT devices • Multiple deployments & heterogeneous nodes • Single managing interface, common tools • See www.iot-lab.info AGILE IoT Testbed
  52. 52. Operation in AGILE Usefulness: the IoT testbed is useful to experiment interplay of AGILE gateway hardware/software with ”arbitrary” numbers of IoT devices Advantage: lowering the bar of entry with remote access, hence no need for local hardware deployment to test/experiment/debug an AGILE deployment Targets: ◦ Prior: testbed used daily by constrained IoT application/stack developers & researchers ◦ In a 1st phase: extended testbed open to AGILE partners ◦ In a 2nd phase: extended testbed open to AGILE Open-Call winners ◦ Beyond: extended testbed open to other external developers/users of AGILE AGILE IoT Testbed
  53. 53. Work Done Added hardware: several prototype AGILE gateways (Makers version) are now permanently deployed on IoT-Lab Backend extension: The backend now enables AGILE partners to securely & remotely access to AGILE gateways deployed on IoT-Lab, via CLI (with SSH) and via a web browser Added software: the AGILE gateways run the latest version of AGILE OS on Raspbian Documentation: we have documented how AGILE partners can use the testbed in a tutorial available online AGILE IoT Testbed
  54. 54. IoT-Lab IoT-LAB sensor (public frontend) Web SSH User AGILE IoT Testbed
  55. 55. IoT-Lab AGILE Extension 1 IoT-LAB server (AGILE frontend) Gateway IoT-LAB sensor (public frontend) Sensortag Web SSH User AGILE IoT Testbed
  56. 56. IoT-Lab AGILE Extension 2 IoT-LAB server (AGILE frontend) IoT-LAB sensor (public frontend) Web SSH User Gateway AGILE IoT Testbed
  57. 57. M19-M36 Planning AGILE stack: further integration with AGILE stack, once it supports IEEE 802.15.4 Access: enable access/usage for 3rd party users such as AGILE Open-Call winners Hardware: deploy additional AGILE hardware on the IoT testbed, including PiHat + shields for Xbee, LoRa Software: on the AGILE gateways deployed in the IoT testbed, switch from Raspbian to ResinOS End-to-end mode of operation: enable use of AGILE hardware as IPv6 border router to enable secure end-to-end transport of data from IoT devices to arbitrary remote location on the Internet AGILE IoT Testbed
  58. 58. Demo AGILE IoT Testbed
  59. 59. Demo IoT-LAB server (AGILE frontend) Gateway IoT-LAB sensor (public frontend) Sensortag Web SSH User Gateway AGILE IoT Testbed
  60. 60. NEXT STEPS
  61. 61. Pilots Evaluation Each pilot has developed a pilot execution scenario and an evaluation plan, including timing and milestones Alignment with Crowdfunding Campaign and Open Call KPIs have been identified and will be evaluated Monitoring of pilots technical and operational risks Apply the evaluation methodology and instruments of each pilot and provide feedback to the technical WPs. ◦ Analytics ◦ Surveys ◦ Questionnaires
  62. 62. THANK YOU