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.

AGILE software, devices and wider ecosystem


Published on


Published in: Software
  • Be the first to comment

  • Be the first to like this

AGILE software, devices and wider ecosystem

  1. 1. AGILE M18 Review, 20 October 2017, Brussels (Belgium) AGILE software, devices and wider ecosystem CSABA KIRALY / FBK / TECHNICAL COORDINATOR, WP3 LEADER GEORGIOS MICHALAKIDIS / RESIN.IO / WP2 LEADER
  2. 2. Outline 1. A recap of what AGILE is (…and why we call it an ecosystem) 2. Mapping within overall WP structure 3. Mapping within the overall Architecture 4. The host Gateway 5. Software stack and OS 6. Support for devices and protocols 7. Overview of the UI 8. Extendibility – managing fleets of devices and updates 2
  4. 4. Industrial & makers’ HW, complete SW stack, diverse services and pilots 4
  5. 5. AGILE SW– Main Objectives AGILE SW as an Enabler: who should benefit from AGILE? ◦ DIY and Makers: tinker with gadgets, integrate, keep data private ◦ Startups: Prototype IoT application, scale with business ◦ Enterprise: build robust IoT solutions, reduce development and maintenance costs Main AGILE Technical Objective Build a modular, reconfigurable software stack for the IoT gateway by going beyond the state of the art technology currently used to build IoT gateways and by leveraging on open source solutions and communities. 5
  7. 7. Mapping to AGILE overall Work Package structure 7
  8. 8. Mapping to AGILE Architecture (Development View) 8 Legend: WP2 WP3 Hybrid
  9. 9. Tasks and Milestones (Gantt) 9 Key points: ◦ Final Component Integration ongoing (T3.4) ◦ Maintenance tasks (T2.5 and T3.5) tracking further requirements from pilots
  10. 10. WP2-specific Objective Overview ID Name Notes 1 Select, Develop, Integrate Software Components • Software component development to accommodate pilots • Simple deployment process (partners & users alike) • Compatibility and interoperability key aims achieved 2 Operating System Integration • Allow users a choice (multiple OS and arch. support) • Cater IoT market with an OS further implemented in parallel, to cover emerging IoT industry needs 3 Configuration, Protocol Integration, User-space Apps • Development of protocol base repos/classes • Expandability key aim (instructions provided) • Allow to simply develop real-world use-cases (API provided) • Familiar tools (Node-RED, OS.js, Dataviz out-of-the-box) 4 Framework for local and remote gateway management • Services & UI enabling local management of the gateway • Fleet management through partner’s service ( incl. security updates to Stack, Apps & remote monitoring 10
  11. 11. WP3-specific Objective Overview ID Name Notes 1 Open source component evaluation • Initial selection documented in D 3.1 • Developed framework to allow for the use of these components 2 Gateway and data management Interfaces • Developed UI Framework and Management UI • Developed local data storage component 3 Developers’ visual environment and recommender • Integrated Node-RED & developed AGILE-specific extensions • Developed recommender and its UI integration 4 Integration of SW components (ongoing till M24) • Stack already includes most AGILE components • Pending: integration of further protocol adapters 11
  13. 13. Achievements ◦ GW HW and Operating System support ◦ Software stack: modular language-agnostic micro-services ◦ Interoperability with typical IoT devices and protocols ◦ Local data storage ◦ UI framework, management, and rapid prototyping UI ◦GW Management features (fleet, etc.) ◦ Recommendation services (separate presentation) ◦Integration of security features (WP5) ◦ IoT (and generic) cloud interoperability (WP4) 13 Software framework for the IoT GW OS instances, protocol adapters, cloud adapters (WP4) etc.
  15. 15. GW hardware platform support Goal: ◦ Support for popular DIY platforms ◦ Support co-deployment with other SW for the DIY segment ◦ Broad industrial grade support for IoT GW platforms Approach: ◦ Common layer on top of OS: Docker based containerisation Achievements: ... 15
  16. 16. Architecture and host gateway device support 1. Stack fully compatible with the following architectures ◦ ARM v7 ◦ X86_64 2. Stack compatible with mainstream and IoT Operating Systems ◦ resinOS (partner’s-own Open Source OS implementation) ◦ Raspbian ◦ Others possible/straightforward w/ docker (e.g. barebone Yocto) 3. Gateway device support ◦ Custom-made AGILE Gateway for industrial use (per WP1) and station ◦ Raspberry Pi (v3 recommended due to resources and out-of-box connectivity) ◦ Up Board (fully compatible - x86_64) ◦ Others in progress (testing - e.g. ARM v8 64-bit) 16
  17. 17. Allow choice of underlying HW to the developers UP Squared Up Board (x86_64) 17 Raspberry Pi (with GPIO HAT custom for AGILE) Industrial AGILE Gateway (custom) AGILE Monitoring Station (custom)
  19. 19. AGILE Stack modular, language- ,and architecture-agnostic Goal: ◦ Enable customisation of GW for different use cases ◦ Enable software reuse, independent of language and dependencies ◦ Support different CPU micro-architectures ◦ Simplify SW deployment and component development Approach: ◦ Containerised micro-services, connected by internal DBus and REST APIs ◦Each service has its own GIT repository, following conventions ◦Docker images are automatically generated per-service, for each CPU architecture ◦ Lean management of deployed components using Docker Compose 19
  20. 20. AGILE Stack components: container based modularity 20 Service Name (agile-) language Internal bus dbus - REST API endpoints core java Datastore data node.js Security and IDM security node.js ● Identity Management Component idm-core node.js ● Policy decision point policies node.js Recommender recommender java GUI framework osjs node.js ● Management GUI ui node.js ● Developer GUI & runtime nodered node.js Protocol registry protocolmanager Java ● BLE support ble Java ● Shield support shield-software Python ● OCF Core support iotivity C++ Device registry devicemanager Java ● Java device engine devicefactory Java
  22. 22. Thing/Protocol Support Goal: ◦Capture the complexity of the IoT device ecosystem, without bidding on “the next standard” ◦Support southband protocols at different levels of abstraction ◦BLE, OCF Core, ZigBee, LoRa, Modbus, etc. ◦Enable device type specific code deployment Approach: ◦Differentiate between Protocol abstraction and Device abstraction ◦Protocols: Simple common protocol API, supporting device discovery and communication features ◦Devices: higher-level abstraction mapping to components and commands ◦Containerized protocol adapters to simplify code reuse ◦Containerized device engine with pluggable device implementations 25
  23. 23. Thing/Protocol Support in practice Protocol implementations ◦BLE ◦based on Bluez and TinyB, in Java ◦OCF Core ◦based on Iotivity, in C++ ◦ZigBee, 802.15.4, LoRa (through Libelium’s custom-made HAT) ◦implemented in one container, in Python ◦Other protocols developed by project based on Protocol API Device implementations ◦Device engine with pluggable device classes ◦Java (and Python) base classes for device implementation ◦Reference implementations: SensorTag (Java), Lamp (ZigBee) ◦Pilots developing device support ◦Device API can also be implemented and deployed as a standalone container 26
  25. 25. UI Framework & Rapid Prototyping Environment 28 Goal: ◦ Integrated development and Dataviz environment ◦ Out-of-the-box tools to kickstart development ◦ Examples (Apps and services) Approach: ◦Popular UI modules (e.g. OS.js) ◦Websockets (real-time data) Achievements: ◦Per screenshots (across AGILE components)
  26. 26. 29
  27. 27. Introducing Kura to the mix Goals: • a “privileged” container for Java and OSGi-based application; • full support and easy access to widely adopted industrial protocols; • a unified simple connector to cloud platforms; • a workflow programming tool oriented to industrial application; • an automatically generated and unified GUI for application configuration; • life-cycle management of AGILE Kura and Java application. 30
  28. 28. Configuration (TU Graz) through Kura (Eurotech/Eclipse) 31
  29. 29. Goal: • Offer a development and deployment framework (Linux and containers) designed for on-device environment control, device provisioning, and management of “fleets” of systems, as well as automate operations. 32 Remote management (& fleets)
  30. 30. 33
  31. 31. 34
  32. 32. DEMO
  33. 33. While you wait… guide on how to Get Started 36 ● SW Requirements (host machine): Docker, Resin CLI, Node.js ● Gateway HW Requirements: RPi 3 (or RPi2 or Up board x86_64 w/ WiFi + Bluetooth)
  34. 34. Integrating an OS built for the embedded world (Getting Started) Stack & User-space 37
  35. 35. 38
  36. 36. THANK YOU
  37. 37. AGENDA 9.00 Start 9.00 (15min) Brief intro (recap of previous episodes, main architecture/achievements in a nutshell) — Raffaele 9.15 (30min) IoT Hardware innovation: the Industrial and Maker's hardware gateway (roughly WP1) — Paolo, David R. 9.45 (45min) Enabling rapid prototyping: AGILE gateway, device, protocol mgmt, software release, packaged components (roughly WP2+WP3) — Georgios, Csaba 10.30 (10min) Coffee Break 10.40 (20min) AGILE Development Environment, demo — Csaba (WP3) 11.00 (30min) AGILE Research, brief results overview: recommender and configuration + security — Alexander/Seda + Juan David (recommender and WP5) 11.30 (60min) IoT and Cloud services interactions (including demo) — Roman (WP4) 12.30 lunch (1.5hr - can be shortened in case of time constraints) 14.00 restart 14.00 (90min) AGILE Pilots (focus on use of AGILE architecture in pilots and on what innovation potential came out of those) — Andreas (+ Pilot leaders) (WP8) 15.30 (20min) innovations radar — Jonas 15.50 (10min) Coffee Break 16.00 (20min) impact, open calls and external collaboration — Johnny (WP6) 16.20 (20min) partnership and dissemination — Philippe (WP7) 16.40 (30min) Administrative / financial — Margherita (WP9) 17.10 (35min) reviewers / PO debriefing 17.45 (15min) PO to present main conclusions / first feedback 18.00 end (might be extended to 18.30 at the latest in case of overrunning the schedule) 40