Adaptive Gateways for Diverse Multiple Environments

Ref. Ares(2016)5698852-30/09/2016 H2020-688088 AGILE Adaptive Gateways for diverse multiple Environments D3.2 Application Interfaces (Gateway, Data Management & Developer s Interface) initial implementation Project Acronym Project Title AGILE Project Number 688088 Adaptive Gateways for Diverse Multiple Environments Work Package WP3 Device, Data Management & Developers Environment Development Lead Beneficiary CN Editor Charalampos Doukas (CN) Fabio Antonelli (CN) Reviewer Reviewer Dissemination Level Csaba Kiraly (CN) Georgios Michalakidis (RN) PU Contractual Delivery Date 30/09/2016 Actual Delivery Date 30/09/2016 Version V1.0 implementation Page 1 of 23

Abstract This deliverable presents the initial implementation of the core application interfaces of the AGILE gateway: The Gateway management Interface, the Data Management & the Developer s UI. implementation Page 2 of 23

Document History Version Date Comments V0.1 08/09/2016 Initial version, definition of ToC V0.2 16/09/2016 Initial content added for main interface, local gateway management and developer s interface V0.3 27/09/2016 Draft version delivered for preliminary review V0.4 29/09/2016 Draft with data management additions V1.0 30/09/2016 Final version integrated for submission implementation Page 3 of 23

Table of Contents 1 Introduction... 7 1.1 Technical Requirements & Features specification... 7 1.2 User experience Requirements... 8 1.3 Requirements from Pilots... 8 2 The AGILE Main User Interface... 8 3 AGILE Gateway Local Management Interface... 10 4 AGILE Data Management Interface... 16 4.1 Functionality... 16 4.2 Technology... 19 4.3 Scheme... 20 5 AGILE Developer s Interface... 20 5.1.1 Integration with AGILE software stack... 22 6 Future Work... 23 implementation Page 4 of 23

List of Figures Figure 1: Screenshot of OS.js with draft implementations of AGILE UI components... 9 Figure 2: Kura remote management web interface.... 13 Figure 3: Kura data services settings.... 13 Figure 4: Kura cloud services settings.... 14 Figure 5: Kura device configuration.... 15 Figure 6: The architecture of the Kura framework.... 16 Figure 7: List of identified devices upon discovery... 17 Figure 8: The Texas Instruments Sensor Tag being used as a testbed... 17 Figure 9: Selection of a device (more features will be added as we identify requirements)... 18 Figure 10: Viewing data from a device. The image presents the available data and units, with the last update. Aggregate data is then presented using the visualisation library... 18 Figure 11: Historically available data (currently part of the same session) is visualised 19 Figure 12: The Node-RED AGILE integrated developer s environment... 21 Figure 13: Sample of IoT Data visualisation using AGILE Developer s enviroment and data from connected wireless devices... 21 Figure 14: Sample of IoT Data visualisation using AGILE Developer s enviroment and data from connected wireless devices... 22 implementation Page 5 of 23

Acronyms Acronym AGILE IoT M2M API UI UX OS JS JSON USB HID MQTT HTTP NMEA GPS I/O GPIO PWM I2C SPI JNI OSGi WebDAV DB Meaning Internet of Things Machine to machine Application Programming Interface User Interface User Experience Operating System JavaScript JavaScript Object Notation Universal Serial Bus Human Interface Device MQ Telemetry Transport Hypertext Transfer Protocol National Marine Electronics Association Global Positioning System Input/Output General-purpose Input/Output Pulse-width Modulation Inter-integrated Circuit Serial Peripheral Interface Java Native Interface Open Service Gateway Initiative Web-distributed Authoring and Versioning Database implementation Page 6 of 23

1 Introduction AGILE implements a modular gateway for the communication and management of IoT devices. A great part of the design and development work of the project is dedicated to the software modules that the user interacts with. The core objective of D3.2 is to present the initial implementations of crucial user interfaces such as the gateway local management interface, the data management interface and the developers UI. In addition, it presents the initial integration of the main AGILE user interface (entry point for using the rest of visual interfaces). This initial delivery is part of the agile methodology the project is following for developing prototypes rapidly and releasing them to users for early testing, feedback and adoption. This document describes the component selection, main technical features and upcoming integration process with the overall AGILE software stack. It should be noted that this is the initial version of the requirements specification, design and development of the user interfaces. As the AGILE project progresses, additional requirements might arrive from the user community and the pilot execution. Thus, the selected components for integration or the current developments might change. The final developments will be presented in deliverable D3.3. 1.1 Technical Requirements & Features specification Before selecting the components to integrate and develop for the AGILE visual interfaces, we compiled a list of technical requirements and specifications that the interfaces need to meet in order to guarantee both the appropriate functionality and performance and also maximise the usability and optimise the user experience. These requirements and features are listed hereafter: Web-based user interface accessible from local area network: Any interaction between the AGILE users and the software components of the AGILE gateway should be done (not exclusively) from a web-based interface through the user s mobile device or personal computer. User authentication & access control through the web interface: The web interface must offer multiple user authentication functionality, enabling the access policy and user authentication to be transferred to the various AGILE interfaces and software components without the need for the user to re-authenticate. All AGILE technical functionality should be available through the user interfaces. Accessing the AGILE UIs should be done with minimum technical requirements on the client side: AGILE users should be able to use a basic web browser to access the AGILE interfaces without the need to install any special software (plugins, etc.). implementation Page 7 of 23

1.2 User experience Requirements One of the AGILE project expectations is to deliver a useful solution to the end users community (IoT developers, IoT device owners, etc.) and maximise the potential of adoption. This translates into various requirements that also reflect the design and development of the user interfaces. Thus, the UI components an AGILE user interacts with must meet criteria like: Intuitiveness Responsiveness 1.3 Requirements from Pilots The initial design of the aforementioned graphical interfaces takes into account also requirements from the AGILE piloting activities. Most of the latter have been described in D8.1 and will not be included in the current document. 2 The AGILE Main User Interface The AGILE gateway framework will consist of various software modules and interfaces (device management, data management, etc.) that user will interact with. However, there is the need for a single entry point for the user before authenticating to the framework and accessing the rest of the components. For this purpose, we have selected the integration of OS.js, an open source framework that emulates a desktop operating system inside a browser. OS.js is a JavaScript web desktop implementation for the web browser with a fullyfledged window manager, Application APIs, GUI toolkits and a filesystem abstraction. It has been built to feel like a traditional desktop, only with modern web technologies. Features a fully capable Window Manager and Desktop Environment that takes inspiration from Linux. It supports localisation, theme customisation, drag-and-drop, authentication and multi-user, group-based permissions, etc. OS.js comes with a default suite of applications for managing, viewing and editing of your files and out-of-the box support for WebDAV, Microsoft OneDrive, Google Drive and Dropbox. The main reason for selecting OS.js were (besides being open source and easy to integrate) the list of its main features: Works in any modern browser Server is deployable on any platform Can be built to run entirely in-browser without any server Dependency-free JavaScript frontend implementation Page 8 of 23

Easy to use APIs Customisable and easy to extend with custom code and modules etc. Supports multi-user environments and authentication Virtual File System - Store your files across many different storage/cloud providers Desktop and Window Manager built to feel familiar to most users Drag-and-drop support between applications Supports sessions so that the user can reload workspaces on any computer Localisation and translations support Comes with a small application suite Supports adding of packages via external repositories Comes with all the tools necessary to build custom applications Client is written in Strict Mode JavaScript and uses ECMAScript 5.1 standards Follows industry standard style guides Comes with Google API Javascript Support Comes with Windows Live API JavaScript Support Google Drive support Dropbox support OneDrive support We currently have integrated a version of the OS.js within AGILE creating a docker container for the integration/distribution of the module. The latter docker container can be found at the docker AGILE repository. The following screenshot illustrates how the OS.js environment looks inside the browser, with draft implementations of AGILE UI components. Figure 1: Screenshot of OS.js with draft implementations of AGILE UI components implementation Page 9 of 23

These components (basic Developer s interface, a data viewer, etc.) are web applications that are being displayed in the form of widgets inside OS.js. A great feature of this approach is that even if the consortium decides to select a different approach for the main AGILE user interface, all the of the developed UIs will be used without any major modifications. 3 AGILE Gateway Local Management Interface For the local gateway management of AGILE, the Kura framework has been selected. By local gateway management, we refer to functionality exposed to the AGILE user for performing features like: Managing & configuring the network interfaces of the gateway Monitoring the gateway resources (e.g., memory, cpu utilization, etc.) Performing gateway update operations (e.g., install new software modules or perform OS update operations) Managing devices directly connected to the gateway (e.g., devices communicating over Serial/SPI/I2C ports, etc.) The following section presents information about the framework itself. Eclipse Kura framework has been conceived to satisfy the increasing demand of Internet of Thing (IoT) service gateways running modern software stacks and operating on the edge of an IoT deployment as an aggregator and controller. Advanced software frameworks, which abstract and isolate the developer from the complexity of the hardware and the networking sub-systems, re-define the development and re-usability of integrated hardware and software solutions. Eclipse Kura (http://www.eclipse.org/kura/) is an Eclipse IoT project that provides a platform for building IoT gateways. It is a smart application container that enables remote management of such gateways and provides a wide range of APIs for allowing the developers to write, deploy and manage IoT application. Kura has three main objectives: simplify and improve the efficiency of IoT data collection and processing. Kura framework offers functionalities for data collection and storage oriented to telemetry and a policy-driven system to publish collected data on remote servers. These functionalities, which abstract from the complexity of data collection, network layer and publishing protocol, can be used to develop the IoT business logic running on the gateway. Simplify gateway lifecycle management. Kura framework offers web and API based remote management functionalities that simplify the management of the entire lifecycle of the gateway, from deployment to retirement. It allows also the remote management of the IoT applications installed in Kura including their deployment on the gateway, their upgrade and configuration. implementation Page 10 of 23

Provide a gateway software abstraction: Kura provides a service oriented, OSGi based API that abstracting the gateway hardware simplifies the development of IoT applications. The APIs offer easy and standard access to the underlying gateway hardware, including serial ports, GPS, watchdog, USB, GPIOs, I2C, etc. It also provides services to simplify the management of network configurations, the communication with IoT servers, and the remote management of the gateway. Kura runs on top of the Java Virtual Machine (JVM) and leverages OSGi (http://www.osgi.org), a dynamic component system for Java, to simplify the process of writing reusable software building blocks. Kura components are designed as configurable OSGi Declarative Service exposing service API and raising events. While several Kura components are in pure Java, others are invoked through JNI and have a dependency on the Linux operating system. Kura currently runs on two different OSGi implementations: Equinox, an open source implementation sustained by the Eclipse Foundation, and a second implementation known as Hitachi s SuperJ Engine Framework. The OSGi applications framework provides a programming model for developing, assembling, and deploying modular applications that use Java and OSGi technologies. OSGi application development tools provide a way to build enterprise applications that benefit from the modularity, dynamism, versioning, and third-party library integration provided by the OSGi applications framework. OSGi specifications are defined and maintained by the OSGi Alliance, an open standards organisation. The specification outlines open standards for the management of voice, data, and multimedia wireless and wired networks. The OSGi Service Platform Specification defines an open common architecture for service delivery and management using bundles, the basic building blocks of the OSGi environment. The core part of the OSGi Service Platform defines a secure and managed Java-based service platform that supports the deployment of extensible and downloadable applications, in the form of bundles. The specification defines a security model, an application life cycle management model, a service registry, an execution environment and modules. An OSGi bundle is a Java archive file that contains Java bytecode, resources and a manifest that describes the bundle and its dependencies. The bundle is the basic building block when developing and deploying an application. An OSGi application emerges from a set of bundles, of different types, to provide a coherent business logic. Following the OSGi development model, the services offered by Kura (including the monitoring related services) are provided on a per bundle/component basis. There isn t a one to one mapping between services and bundles: it can happen that more than one service is implemented by a bundle, but also there is the possibility to have two bundles that define a service in which a bundle specifies the service definition, while another manages the service implementation. The reason for this split is to provide the service definition to a third party without giving it the full implementation that, following the OSGi philosophy, is not required to develop an application. The binary version of bundle(s) and the service API are the only elements required for application development. Furthermore, in some cases, some services require multiple implementations. For implementation Page 11 of 23

example, the Kura Modem Service, the service that provides abstraction to the hardware of modems, is implemented by a set of bundles, one for each supported modem. Kura Framework provides the following services: I/O Services: o Serial port access through javax.comm 2.0 API or OSGi I/O connection. o USB access and events through javax.usb, HID API, custom extensions. o Bluetooth access through javax.bluetooth or OSGi I/O connection. o Position Service for GPS information from a NMEA stream. o Clock Service for the synchronisation of the system clock. o Kura API for GPIO/PWM/I2C/SPI access. Remote Management: allow for remote management of the IoT applications installed in Kura including their deployment, upgrade and configuration management. The Remote Management service relies on the Configuration Service and the Cloud Service. Web administration interface: offer a web-based management console running within the Kura container to manage the gateway. implementation Page 12 of 23

Data Services: Figure 2: Kura remote management web interface. o Store and forward functionality for the telemetry data collected by the gateway and published to remote servers. o Policy-driven publishing system, which abstracts the application developer from the complexity of the network layer and the publishing protocol used. Eclipse Paho and its MQTT client provides the default messaging library used. Figure 3: Kura data services settings. Cloud Services: easy to use API layer for IoT application to communicate with a remote server. In addition to simple publish/subscribe, the Cloud Service API simplifies the implementation of more complex interaction flows like request/response or remote resource management. Allow for a single connection to a remote server to be shared across more than one application in the gateway providing the necessary topic partitioning. implementation Page 13 of 23

Figure 4: Kura cloud services settings. Configuration Service: leverage the OSGi specifications ConfigurationAdmin and MetaType to provide a snapshot service to import/export the configuration of all registered services in the container. implementation Page 14 of 23

Figure 5: Kura device configuration. Networking: provide API for introspects and configure the network interfaces available in the gateway like Ethernet, Wifi, and Cellular modems. Watchdog Service: register critical components to the Watchdog Service, which will force a system reset through the hardware watchdog when a problem is detected. The next figure illustrates the full structure of the last version of Kura (ver. 2.0.1). implementation Page 15 of 23

Figure 6: The architecture of the Kura framework. The documentation of the API is available at the following address: http://eclipse.github.io/kura/ref/api-ref.html 4 AGILE Data Management Interface 4.1 Functionality This service is responsible for storing data produced by registered devices on the Agile API. It will do this by monitoring the Agile API for new registered device s and on registration setup up a websocket streaming the device data into a time series database. This timeseries database will expose a queryable HTTP API for other Agile applications as well as the data visualisation UI. The current state of the User Interface utilising the data management API is provided below. implementation Page 16 of 23

Figure 7: List of identified devices upon discovery Figure 8: The Texas Instruments Sensor Tag being used as a testbed implementation Page 17 of 23

Figure 9: Selection of a device (more features will be added as we identify requirements) Figure 10: Viewing data from a device. The image presents the available data and units, with the last update. Aggregate data is then presented using the visualisation library implementation Page 18 of 23

Figure 11: Historically available data (currently part of the same session) is visualised 4.2 Technology The service is built using influxdb, grafana and node.js. Influxdb was chosen firstly because it has a powerful sql like query language and secondly because makes these queries available via an http API. For instance, any service on the device could locally query the database like this: curl -G 'http://localhost:8086/query?pretty=true' --dataurlencode "db=mydb" --data-urlencode "q=select value FROM sensortag_1 WHERE region='us-west';select count(value) FROM sensortag_1 WHERE region='us-west'" implementation Page 19 of 23

Grafana is a popular visualisation library with native influxdb support. It also allows loading of visualisations via JSON configurations, which enables the data management service to automatically create dashboards for the user. 4.3 Scheme All the gateways device data is stored in a single time series DB, with its attributes saved as tags. This example we query a device and specific sensor for all data points recorded after 2014-01-01. select value from gateway where device = '<device_id>' and sensor = '<sensor_id>' and time > 1388534400s; We will expand with a full representation of the scheme in the deliverables to come. 5 AGILE Developer s Interface On of the core features of the AGILE gateway software stack is the ability for end users and developers to design and deploy their own application logic locally. While developers have always the option to deploy software applications and their dependencies (runtimes and libraries) by connecting to the gateway through terminal access (e.g., SSH), we wanted to provide this feature to the users through a graphical web-based interface. An interface that will be integrated together with the rest of the AGILE UI component and will also provide access to resources like stored data, recommendations, and communication with connected IoT devices. In addition, we wanted to provide a way for non developers to be able to design and deploy application logic without being coding experts. This is why we have selected to integrate the popular open-source Node-RED (http://nodered.org) workflow editor for the IoT. Node-RED is a powerful tool for building Internet of Things (IoT) applications with a focus on simplifying the wiring together of code blocks to perform application logic and carry out tasks. It uses a visual programming approach that allows developers to connect predefined code blocks, known as nodes, together to perform a task. The connected nodes, usually a combination of input nodes, processing nodes and output nodes, when wired together, make up a flows. Originally developed as an open source project at IBM in late 2013, to meet their need to quickly connect hardware and devices to web services and other software as a sort of glue for the IoT it has quickly evolved to be a general purpose IoT programming tool. Importantly, Node-RED has rapidly developed a significant and growing user base and an active developer community who are contributing new nodes that allow programmers to reuse Node-RED code for a wide variety of tasks. Although Node-RED was originally implementation Page 20 of 23

designed to work with the Internet of Things, i.e. devices that interact and control the real world, as it has evolved, it has become useful for a range of applications. The following screenshots depict the UI of Node-RED as integrated within AGILE and used to retrieve and visualize data from connected IoT devices. Figure 12: The Node-RED AGILE integrated developer s environment Figure 13: Sample of IoT Data visualisation using AGILE Developer s enviroment and data from connected wireless devices implementation Page 21 of 23

Figure 14: Sample of IoT Data visualisation using AGILE Developer s enviroment and data from connected wireless devices 5.1.1 Integration with AGILE software stack The Node-RED IoT workflow editor needs to be properly adapted for integration with the rest of the AGILE gateway software components. More specifically, the following adaptations have been envisioned and are being developed: A container with all the essential Node-RED runtime and dependencies AGILE nodes that provide direct access to the data coming from IoT devices that have been configured by the AGILE device manager and have been connected (paired) with the gateway AGILE nodes for interfacing with the local data store (performing data queries and storage operations) AGILE nodes that generate data visualisations (graphs) from IoT connected devices An initial docker container has been developed that contains all the essentials for running the AGILE Node-RED version inside the AGILE software stack. It can be found (among with the other component containers developed so far) in the AGILE docker repository: https://hub.docker.com/r/agileiot/ implementation Page 22 of 23

6 Future Work As already mentioned, D3.2 is the initial implementation of the main graphical interfaces for data management, local gateway management and application logic/workflow development. Until the next deliverable, D3.3, the software modules will have been finalised in terms of functionality and improved in stability including features requested potentially by the AGILE user community. Further integration will take place with components and features like trusted data sharing, device scanning, cloud application deployment and application and module recommendation. implementation Page 23 of 23