AGILE software, devices and wider ecosystem

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

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

WHAT IS AGILE
(SW PERSPECTIVE)

Industrial & makers’ HW, complete
SW stack, diverse services and pilots
4

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

WORK PACKAGE AND
ARCHITECTURE MAPPING

Mapping to AGILE overall
Work Package structure
7

Mapping to AGILE Architecture
(Development View)
8
Legend:
WP2
WP3
Hybrid

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

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 (Resin.io) incl.
security updates to Stack, Apps & remote monitoring
10

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

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.

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

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

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)

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

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

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

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

RAPID PROTOTYPING,
MANAGEMENT OF FLEET

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)

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

Configuration (TU Graz) through Kura
(Eurotech/Eclipse)
31

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)

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)

Integrating an OS built for the embedded world
(Getting Started)
Stack & User-space
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

AGILE software, devices and wider ecosystem

More Related Content

What's hot (20)

Similar to AGILE software, devices and wider ecosystem (20)

More from AGILE IoT (17)

Recently uploaded (20)

AGILE software, devices and wider ecosystem