Adaptive Gateways for Diverse Multiple Environments

Transcription

1 Adaptive Gateways for diverse multiple Environments D2.3 Final version of gateway self-configuration, IoT Device discovery & Remote gateway management Project Acronym AGILE Project Title Adaptive Gateways for Diverse Multiple Environments Project Number Work Package WP2 Core Module Integration & Gateway SW framework development Lead Beneficiary RN Editor Georgios Michalakidis Resinio Ltd Reviewer 1 Alexander Felfernig TU Graz Reviewer 2 Csaba Kiraly FBK Dissemination Level PU Contractual Delivery Date 30/06/2017 Actual Delivery Date 18/07/2017 Version V1.0 D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 1 of 57

2 Abstract This report forms the second iteration, and final deliverable, of Work Package 2 Core Module Integration & Gateway SW framework development part of the AGILE EC-funded Horizon 2020 project. We report on functionality of the gateway and orchestration components such as the Operating System selected and being further developed, the underlying AGILE stack components (e.g. SDKs and APIs), the accompanying systems for configuration and recommendations as well as device provisioning and discovery subsystems. Finally, we include the original review of requirements incl. assessment of IoT Protocols and Standards to facilitate use-case and pilot development. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 2 of 57

3 Document History Version Date Comments V0.1 17/05/2017 Initial Draft, Sections V0.2 22/05/2017 Intro, Requirements V0.3 31/05/2017 Inclusion of initial report D2.2 components V0.4 15/06/2017 Internal Review, Additions V0.5 26/06/2017 Update to OS work, Configuration components V0.6 29/06/2017 Review V0.7 03/07/2017 Inclusion of sections from beneficiaries V0.8 05/07/2017 Review V /07/2017 Review comments of Prof. Felfernig on Section 4 applied by Seda Polat Erdeniz V /07/2017 KURA UIs for recommender outputs are added in Section 4 V /07/2017 Descriptive text about KURA UIs for recommender outputs are added in Section 4 V /07/2017 Review by Csaba v /07/2017 Corrections in Section 3 V /07/2017 Added content to section V0.9 14/07/2017 Reviewed version to be proof-read V1.0 16/07/2017 Ready for submission D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 3 of 57

4 Table of Contents Document History... 3 Table of Contents... 4 Table of Figures... 6 Table of Tables Summary Operating System and Container Technology ResinOS as Operating System all-in-one option for AGILE Container technology AGILE gateway software architecture... Error! Bookmark not defined. 2.4 Updating the underlying OS and AGILE stack Applying the container paradigm to the embedded world Interoperability and Communication Protocols (IoT) Communication and Device Discovery Kura framework integration and functionalities Recommender and Configurator The AGILE Recommender service The App Recommender The Workflow Recommender The Device Recommender The Cloud Recommender The AGILE Configurator service The Ramp-up Configurator (for Pilot-C) The Resource Optimisation Configurator Publications Gateway Management D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 4 of 57

5 5.1 Accessing the AGILE gateways Provisioning AGILE gateways Report Conclusion D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 5 of 57

6 Table of Figures Figure 1 Core components of ResinOS which has been adapted for AGILE Figure 2 The Resin.io stack that is being adopted by AGILE for device management purposes... Error! Bookmark not defined. Figure 3 Deployment flow using "git repository" management logic Figure 4 AGILE Kura container on the OS.js interface Figure 5 WIRES workflow example Figure 6 The Recommender configuration page Figure 7 Recommender and Configurator Service runs on the AGILE gateway locally. Recommender operations and Ramp-up Configurator need to connect to the Recommender Server. The Resource Optimization Configurator can run totally offline Figure 8 Online Recommender and Configurator Services are shown in yellow boxes in the AGILE Cloud Services Architecture Figure 9 Configurator Service is shown as the yellow box in the AGILE Gateway Architecture. 30 Figure 10 An example use-case of the App Recommender is shown in an illustration of the App Manager UI Figure 11 Outputs of app recommender (on KURA UI) Figure 12 An example use-case of the Workflow Recommender is shown in an illustration of the Node-Red Workflow Development Environment UI Figure 13 Outputs of workflow recommender (on KURA UI)... Error! Bookmark not defined. Figure 14 An example use-case of Device Recommender is shown as an illustration of the Device Manager UI Figure 15 Outputs of device recommender (on KURA UI)... Error! Bookmark not defined. Figure 16 An example use-case of Cloud Recommender is shown as an illustration on the Node- Red Workflow Development Environment UI Figure 18 An example use-case of Resource Optimisation Configurator is shown as an illustration on the App Manager UI Figure 19 Outputs of resource optimization configurator (KURA UI )... Error! Bookmark not defined. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 6 of 57

7 Figure 20 Device management dashboard with fleet details and device logs Table of Tables Table 1 - Sample fragments of an ASP-based configuration knowledge base of the Pollution Monitoring System of Pilot-C Table 2 - Features of protocols a and b such as their performance, reliability and costs Table 3 - Requirements of Users u1 and u2, with respect to performance, reliability and costs D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 7 of 57

8 Acronyms Acronym Meaning H2020 Horizon 2020 EC AGILE IoT WP RN CN API VPN NAT SDK IP HTTP(/S) URL PU OS Tx.x Dx.x European Commission Adaptive Gateways for diverse multiple Environments Internet-of-Things Work Package Resinio Limited CREATE-NET Application Programming Interface Virtual Private Network Network Address Translation Software Development Kit Internet Protocol Hypertext Transfer Protocol (/Secure) Uniform Resource Locator Public Dissemination Operating System Task (No.) Deliverable (No.) D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 8 of 57

9 1 Summary The report builds on the initial version of the similar deliverable (D2.2) and further defines mechanisms in development for the following components of the AGILE gateway: Operating System and container technology (Raspbian and ResinOS as two available options based on end-developer preference and availability of features), which enables the makers and industrial versions of the gateway to realise features defined in AGILE Frameworks and software modules enabling interoperability and communications (related to IoT standards) Upon input on the configuration/setup requirements from users (e.g. installation of hardware modules for modular support of network protocols), auto-configure any required libraries for module support as well as provide extensions (in the form of APIs, DBUS etc.) for access to those modules from WP3 items, including a summary of the Eclipse Kura Open Source framework for IoT TU Graz configuration and recommendation components that support (1) ramp-up and optimization of IoT hardware and software components and (2) different scenarios related to the identification of relevant items, for example, applications and services Device discovery mechanisms on the AGILE gateway for integration of popular network and IoT protocols incl. associated connectivity protocols (e.g. for message exchange) Current gateway management features (local and remote) through a summary of the Resin platform which is adopted and integrated with AGILE Following the analysis and initial integration of IoT standards for the creation of the makers gateway as reported on deliverable D2.1 after work on tasks T2.1 (Automatic configuration based on hardware modules) and T2.2 (Analysis and Integration of IoT Standards), the second work package WP2 concentrated on device discovery mechanisms (T2.3), as well as remote management of the gateway (T2.4). Work on both T2.3 and T2.4 is reported here, with its current status pending any modifications as part of the final, maintenance task T2.5 in this WP. We also set out the final components D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 9 of 57

10 selected to be applied to the gateway in terms of resource optimisation (auto-configuration), IoT device discovery, and remote gateway management including the decision to support an Open Source Operating System currently in active development by project partners. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 10 of 57

11 2 Operating System and Container Technology AGILE will provide the ability for the consortium members (and potentially the end makers) to deploy, update, and maintain code running on remote gateways. Development and deployment of AGILE-specific software (for example, management daemons running on the gateway) will be developed using tools like git and Docker to allow you to seamlessly update of remote devices. For a quick route to the various releases of the makers version of the AGILE gateway, we chose Raspbian ( and ResinOS as the two compatible Operating Systems that the AGILE stack can be installed and operating on. It is worth noting that we do not rely on OSspecific features, but rather, we have chosen this distribution due to the community support on the makers edition. In fact, the only underlying requirements for the AGILE stack to operate are: Linux Operating System with kernel version 3.10 or higher Appropriate configuration for docker+docker environments (most desktop distros support this out of the box on installation of docker) By adding Docker ( as the container technology on top of Raspbian we can ensure benefits (over traditional virtualisation, for example) such as easier compilation (builds), modularity and environment consistency. In the case of ResinOS, we can additionally support embedded devices where kernels are often outdated and/or impossible to recompile with docker-specific configurations (due to lack of source availability or buildchain complexity). Additionally, ResinOS ( and the underlying service Resin.io will be used as a more complete solution for this purpose, essentially allowing the AGILE stack to run on 2 Operating Systems depending on users and use-cases requirements. The ResinOS option features span cross-compilation, device monitoring, VPNs, to log collection, all out of the box and ready for IoT. This was deemed the fastest route to delivery of the required OS features and AGILE-required services after departure of the original partner who would provide the container-based OS component for AGILE. By adopting ResinOS for use by the AGILE gateway, our aim is for the AGILE partners, as well as makers of applications, pilots and other use-cases, to focus on the product and IoT applications, and not infrastructure. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 11 of 57

12 It is important to note that the Operating System is being adapted for use by AGILE, but is an existing Open Source project by Resinio Ltd. 2.1 ResinOS as Operating System all-in-one option for AGILE The all-in-one Operating System, ResinOS, is tailored for containers and designed for the unique realities of the embedded world. ResinOS supports almost 20 distinct device types, has a robust networking and provisioning story, emphasises reliability over long periods of operation, and enables a productive developer workflow. The partner behind the OS has been developing and using ResinOS as part of the resin.io platform for years and have recently released it as an independent and Open Source Operating System, so that others can benefit and contribute to running containers on connected devices. ResinOS packages the following essential parts of an OS: a kernel optimised for each device type, systemd, a networking stack optimised for diverse network conditions, and Docker Figure 1 Core components of ResinOS which has been adapted for AGILE D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 12 of 57

13 By using a Command Line Interface (CLI) developers (makers and industrial customers alike) can develop on the AGILE gateway technically from any machine, with an efficient workflow that gets out of the way of building projects. 2.2 Why containerisation Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries anything that can be installed on a server. This guarantees that it will always run the same, regardless of the environment it is running in. On AGILE, we will use a git-like flow for development and deployment of AGILE components. Additional benefits to this (other than a simpler deployment flow) include security (crosscontainer) and integration capabilities (with services across containers communicating with one another). 2.3 Updating the underlying OS and AGILE stack With one of AGILE s goals being 100% updateability, while the agent and the developers /users application container are easy to switch out, this doesn t extend to the kernel or the host OS. To deal with this, we create an additional small boot partition. An upcoming version of our agent will be able to download a new OS version, and make the device boot from the alternative boot partition. In this way we can ensure that the new version of the OS is downloaded and installed correctly before rebooting the device to the new version. Even if the new version fails to boot for some reason, our system is built in such a way that the next boot will bring the device back to the original working version of the host OS, operating and ready to download the corrected new version. It is important to note that all gateway devices, both those in production and development, will have the ability to have their host OS updated. When the update capability is complete serverside, the project partners who have control over the fundamental (and in most cases, managed) D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 13 of 57

14 parts of the AGILE stack will be able to bring the entire AGILE gateway fleet up to date. This is particularly important, for example, in the case of security update installation when required. Figure 2 Deployment flow using "git" repository logic A light deployment ensures that software running on the gateway devices leverages a number of powerful components to provide great functionality at a minimal performance cost. 2.4 Applying the container paradigm to the embedded world The combined approach to deploy an OS that utilises container technology for embedded devices such as the AGILE gateway shares a lot with Cloud Operating Systems for containers. We share the focus on minimalism, getting out of the makers way and letting their container do the heavy lifting, and using Docker, which is the standard way of running containers, and well understood by a large developer community. We apply the same principles to a different domain, that of embedded Linux devices, sometimes called connected devices, Internet of Things or Industrial Internet, depending on the use case. While some of the cloud operating D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 14 of 57

15 systems have been made to run on particular embedded devices, their architecture is geared towards the cloud, where they shine. By applying the container paradigm to the embedded world, the OS development partner, Resinio, have faced and solved a unique set of challenges that are not common in the Cloud and datacentre world, such as: The extreme heterogeneity of device types found in the wild; Severely restricted resource envelopes in terms of storage, CPU, and networking; Devices that are difficult to reach or re-provision upon failure, where power is unstable and may be turned off at any time, or with custom hardware attached. Because it is built from scratch on top of the proven Linux Yocto implementation, our deepest architectural and feature choices have been made exclusively with embedded devices in mind. Although Raspbian, combined with Docker, delivers the project s key objectives, ResinOS is built for embedded devices, and this focus drives architectural objectives. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 15 of 57

16 3 Interoperability and Communication Protocols (IoT) 3.1 Communication and Device Discovery As was initially explored in deliverable D2.1, the consortium has shortlisted protocols for implementation including some that provide IoT Device Discovery features. Considering also the commercial availability of devices and the needs of AGILE Pilots, the following protocols had been selected for implementation in the first phase: BLE, ZigBee, , LoRa, LoRaWAN, and OCF Core Framework. At the same time, and later during the implementation of said protocols, work had been carried out to refine the architectural concepts in order to allow the adaptation of a wide range of protocols and enable, as much as possible reuse of existing libraries independent of their implementation language and software dependencies. All the mentioned protocols had been implemented according to plan, while part of the integration work is still on-going in T2.5 and T3.4. Table 1 summarizes the current status for each protocol. As the table shows, we have achieved our goal of allowing code-reuse in protocol implementation through a language-agnostic framework. During the implementation of the OCF Core protocol (which provides a higher layer protocol abstraction than the others) need for an updated Protocol API arose. We are in the process of updating the implementation of individual modules to reflect this change. As for the integration, BLE was the first protocol implemented and as such, it is fully integrated in the architecture. Other protocols have been tested in isolation, but full integration is still on-going in T3.4. Table 1: Protocol and Discovery implementation status Protocol Discovery language Implementation Protocol Integration status support status API version BLE Yes Java Finalized v1 Fully integrated D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 16 of 57

17 OCF Core Yes C++ Finalized v2 Tested individually, to be integrated in the stack ZigBee HW does not support discovery Python Finalized v1 Tested individually, to be integrated in the stack No Python Finalized v1 Tested individually, to be integrated in the stack LoRa / LoRaWAN No Python Finalized v1 Tested individually, to be integrated in the stack Besides the above-mentioned protocols, and in-line with the architectural goals, reuse of Kura components for connecting devices through industrial IoT protocols had been explored. AGILE adapts a two-layer approach for abstracting Things, providing a Protocol API (with optional discovery features when supported) and a Device API. The APIs are documented at As mentioned earlier, v1 of the API was used until recently, while we are in the process of updating modules to v2. The Protocol API allows low-level (i.e. not specific to the actual device, only to the protocol itself) access to the features of the device. It provides unified syntax and semantics for some of the common operations that, if supported by the underlying protocol, could be interpreted the same way over all the supported protocols. Such is, for example the discovery part of the API, which provides the following functionalities: - Properties: o String DiscoveryStatus: show the discovery status of the protocol [STOPPED/RUNNING/FAILURE] o Array[DeviceOverview] Devices: list of discovered devices - Methods: D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 17 of 57

18 o Void StartDiscovery(Integer duration) : initiate a discovery operation. Discovery automatically stops after duration seconds. Discovery continues until StopDiscovery if duration is equal to 0 o Void StopDiscovery() : stops a discovery operation - Signals: o FoundNewDeviceSignal: fired when a new device is discovered. It carries a DeviceOverview object Such common parts of the API allow us to build common protocol-agnostic functionality on top, such as the discovery functionality in the Device Management UI. The AGILE Device API, instead, provides a higher-level abstraction of things, mapping them to a conceptual model in which devices contain components that could be read, written, or subscribed, and commands could be executed. The drawback of this abstraction is that with most protocols, the semantical information required to map between the two APIs is not available, neither through reflection (i.e. by querying the device), nor through standard registries. In these cases, a device implementation is required. The advantage of providing these two APIs is that the developer can choose whether to implement a specific device type or to register the device only as a generic device and handle it at a lower level, directly using the Protocol API. More details on how these can be used from the Developer UI will be documented in the next WP3 deliverable BLE As highlighted in D2.1, protocol implementations build upon existing protocol libraries and include an adaptation layer that exposes the AGILE Protocol API. In the case of BLE, only a few libraries are available (BlueZ, Android BT, and PayPal GATT), of which BlueZ is the most prominent one. Our implementation is based on BlueZ and uses the Intel TinyB library to interface to it. The code repository is at Discovery features BLE supports discovery. After enabling discovery by calling the StartDiscovery function of the Protocol API, the BLE adapter is placed in scanning mode. BLE provides two types of scanning: D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 18 of 57

19 passive scan which is listening for device advertisements (discoverable BLE devices send out so called advertisement frames periodically) and active scanning, where additional information is requested by the scanning device after an advertisement message is received. (Note that in some other protocols active scanning has another meaning: it means that the scanner would broadcast a scan request triggering immediate action from neighbouring devices. However, in the case of BLE, devices keep their receivers off most of the time, therefore this kind of active scan would not make sense.) Our current implementation uses the scanning mode supported by BlueZ, which is active scanning for Linux kernels before 3.17 and passive scanning for newer kernels 1. As soon as devices are found, a FoundNewDeviceSignal is launched, containing the Protocol specific unique device ID and other metadata, most importantly the BLE device name. In the case of BLE, we use the MAC address as device ID. All the information in the signal can be used by the system to find matching device implementations. Device communication Our BLE protocol implementation models device communication at the standard GATT (Generic Attributes) level. GATT models devices as collections of services, which are themselves collections of characteristics, which can be read, written, or subscribed. The Protocol API directly exposes these characteristics with similar operations. Since the Device API has a relatively straightforward mapping to these characteristics, implementing a new device type is also simplified. However, even if standardised libraries of service and characteristic identifiers exist (Bluetooth SIG Assigned Numbers), device manufacturers are free to define their own services and characteristics. Thus, in some cases implementations of device types can provide a simplified component list through the Device API by hiding some of the complexities in the GATT mapping. Such is the case of the TI Sensortag, in which reading a sensor value involves three GATT operations: writing to a characteristic to turn on the sensor, reading another GATT characteristic to get the actual value, and finally turning off the sensor. 1 D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 19 of 57

20 3.1.2 OCF (Open Connectivity Foundation) Core Framework OCF, formerly known as OIC (Open Interconnect Consortium) defines specifications for device interoperability in the IoT context. Their Core Framework specification, which has been release in its finalized 1.0 version at the time of writing of this deliverable (June 28, 2017), defines the architecture, resource models, and RESTful APIs for interacting with OCF compliant devices. IoTivity is the open source reference implementation of the OCF specifications. On the Client side, which is the role of the Gateway in OCF terminology, IoTivity provides a C library, C++ bindings, and a separate Node.js implementation. Our implementation uses The C++ binding and implements the AGILE Protocol API on top of that. The implementation is available at Discovery features OCF and its IoTivity implementation supports discovery. In OCF, devices hold various resources. Resources are identified by URIs, and encapsulate a set of properties (key=value pairs). Both devices and resources can be target of discovery procedures. While in theory OCF and IoTivity can support various underlying protocol stacks, in practice it is used mainly over a CoAP+UDP+6LowPAN protocol stack. In this case, discovery is implemented through IPv6 multicast messages reaching registered devices which then respond with unicast messages sent to the initiator. Our implementation uses this discovery feature to search for nearby devices. After StartDiscovery is called, the Gateway periodically sends out multicast messages, both because the underlying multicast mechanism is not reliable and because new devices might be joining the network during the discovery period. When a unicast response is received from a device, our implementation constructs the device descriptor, and fires a FoundNewDeviceSignal for the device discovered. Device communication Read, Write, and Subscribe operations on the Protocol API are mapped to their corresponding operations on the IoTivity API (get, put, and observe). Since the IoTivity API is exposing D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 20 of 57

21 asynchronous operations with callbacks even for get and put operations, mutexes are used in the code to wait for the respective callback and implement synchronous blocking read/write operations ZibBee, , LoRa / LoRaWAN ZigBee, , LoRa, and LoRaWAN all use the AGILE Shield with various XBee compatible wireless modules, as documented in D1.2. The software for all these protocols is implemented in Python3, and can be found at Discovery features With the exception of ZigBee, these protocols are at a level of the protocol stack where discovery is not available as a protocol feature. We note that e.g is the most common MAC PHY/MAC used in the OCF Core (Iotivity) protocol stack, and discovery is supported at that level. ZigBee, as a protocol, would allow for some discovery features, however on the used (and most common) XBee module this feature turned out to be not implemented reliably. Device communication The code implements these protocols by providing a generic Python3 mapping from an internal API to the AGILE API, and by providing separate implementations for the following protocols: XBee XBee ZigBee LoRaWAN/LoRa (using the Microchip RN2483 transciever) Each protocol might implement the following methods: Connected () -> string Driver () -> string Name () -> string Connect () -> void Disconnect () -> void Discover (a{sv}) -> void Exec (sa{sv}) -> void Setup (a{sv}) -> void Send (a{sv}) -> void Receive () -> a{sv} Subscribe (a{sv}) -> void D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 21 of 57

22 Usage The order of execution for any module is: Setup Connect Send / Receive Disconnect. The Setup method only applies when the Connect method is called. If no setup parameters are defined, the Connect method may use default parameters. For a detailed description of each of these methods, we refer the reader to: Kura framework integration and functionality AGILE Kura integration provides all the advantages and functionalities of the Kura IoT Framework to the AGILE Gateway Software Platform. The main functionalities introduced by Kura include: 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. AGILE Kura is available as a standard docker AGILE container. The containerisation of Kura has been performed following the AGILE procedure and is currently focused on the no-network version with Oracle JDK. This version of the JVM provides good performance, with respect to the Open JDK, but it is affected by some licensing issues that prevent its free redistribution. For this reason, we identified an alternative Java JVM, Zulu. Partner FBK identified huge performance gains over other redistributions as well as clearer licensing terms that allow distribution as part of AGILE, with Kura and through ResinOS; it is now being assessed as a viable alternative. AGILE Kura container can be downloaded at the following link: The following figure illustrates the Kura interface in the OS.js environment. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 22 of 57

23 Figure 3 AGILE Kura container on the OS.js interface. AGILE Kura provides support for widely used industrial protocols. The hardware abstraction layer simplifies the use of the protocols and reduce the complexity of application development. The support for industrial protocols is available with two approaches: AGILE REST API: the approach based on the AGILE REST API is the standard way to access and use the industrial protocols. Being REST oriented and programming languages agnostic, this approach is potentially available for any kind of application. Kura native services: this solution is suggested when developing Kura-based Java application, that doesn t require a further level of abstraction but can directly take advantage of Kura native services. AGILE Kura provides support for the following industrial protocols: MQTT, MQTTS, Modbus, CAN Bus, RS-485, OPC-UA, PROFINET. The first approach based on the REST API could be implemented with two different solutions: the integration with the AGILE Protocol Object or the extension of the AGILE API with new specific functionalities for industrial protocols. The design and development activities are currently focusing on the first solution, because it would not require modifications of the API. However, considering the intrinsic characteristic of industrial protocols, it could be possible that the current AGILE Protocol Object is not suitable for the integration of these protocols. In this case, an extension of the AGILE API that will capture D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 23 of 57

24 the peculiarities of the industrial protocols will be required. The analysis of this issue will continue in the second part of the project. AGILE Kura supports different cloud platforms for data storage oriented to telemetry application. Currently, it is possible to publish data through a common cloud connector on the following cloud platforms: Eclipse Kapua, Azure IoT, AWS IoT. Kura cloud connectors are available as standard Kura services and will be also integrated in the AGILE REST API. More details have been included in deliverables D4.1/D4.2. Kura WIRES offers a native workflow programming tool, which represents an alternative to NodeRED, specifically oriented to industrial application. WIRES support all of Kura s functionality offering a simple and reliable way to define end-to-end workflows for data acquisition, local processing and cloud storage. A complete example is available in deliverable D4.1/D4.2, where a step-by-step how to illustrates how to collect data from industrial appliances through an industrial protocol and publish the data on the cloud. Figure 4 WIRES workflow example Use of Kura as a GUI for application configuration interfaces AGILE Kura offers a uniform and automatic solution to generate the GUI for application configuration. The solution provides a graphical interface that is homogeneous across different AGILE application, which is natively integrated in the Kura web interface. The process of automatic generation is based on the description of the configuration form through a XML file D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 24 of 57

25 called metatype. In this file, the developer provides a simple description of all the fields required to configure every single parameter of the AGILE application that can be configured by the user at runtime. When the application is deployed, a specific Kura bundle is responsible to generate, integrate and publish the configuration page into the Kura Web interface. At runtime, the bundle retrieve and set the application configuration directly from the set and get configuration API of the application itself. More details will be provided in WP3 deliverables. The following figure illustrates the configuration interface automatically generated for the Recommender. Figure 5 The Recommender configuration page Finally, AGILE Kura provides a set of features that extend the OSGi native capabilities for application life-cycle management: application in the form of bundles can be started, stopped, updated and removed at run time, without turning off the gateway and directly from the Kura web interface, locally or remotely. This is one of the advanced features available for Java application in the AGILE Kura container. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 25 of 57

26 4 Recommender and Configurator The AGILE configuration services provide an interface that can be used by other AGILE services and AGILE users to determine consistent settings (configurations) that make the overall gateway environment operable. Examples of configuration scenarios and the recommendation features of this service are discussed in the following paragraphs. Related TUGraz scientific publications are enlisted in the 4.3 Publications section. Differentiation between the terms recommender and configurator : Recommendation functionalities are used to recommend specific items (e.g., apps, devices, and cloud services) to users of the AGILE environment (e.g., a user of a smarthome environment based on AGILE can receive recommendations regarding interesting apps that could be additionally installed, a user of health tracking devices can receive recommendations regarding step tracker or pulse/blood pressure monitoring applications). The determination of recommendations is based on recommendation algorithms such as collaborative and contentbased filtering. Configuration functionalities are used to determine configurations, i.e., combinations of items that satisfy a given set of constraints. For example, gateway hardware configurations for a specific application domain or gateway profile configurations some related examples will be provided in the following paragraphs. Two types of configurators (ramp-up configurator and resource optimization): The ramp-up configurator is based on Answer Set Programming technologies and supports the configuration of IoT infrastructures (in the context of AGILE, the major related showcases are the ramp-up of a pollution monitoring environment and the ramp-up of a smarthome environment). The same technology can be exploited for the other AGILE pilots. Answer Set Programming (ASP) technology is used primarily for reasons of an intuitive knowledge representation. ASP allows definition of complex product structures and related constraints in a component-oriented fashion which makes the technology extremely flexible w.r.t. the applicability in different IoT application domains. In AGILE we exploit the Potassco/Clingo library for the definition and execution of configuration tasks ( Related developments by TU Graz are mechanisms to D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 26 of 57

27 increase the efficiency of search and related diagnosis components that proactively support users in situations where no solution could be found. The ramp-up configurator service is designed for usage as a Cloud service, for reasons of efficiency and scalability explained by the potential size and complexity of configuration knowledge bases. In many scenarios, the solution space is extremely large and efficiently determining configurations requires reasonable hardware resources not provided by gateway infrastructures. Furthermore, ramp-up configuration typically takes place before gateway installation. The ramp-up configurator is currently deployed on the following server: The resource optimization configurator is based on constraint satisfaction technologies (CSP); within AGILE, the Choco Java library is used ( Contrary to the ramp-up configurator which is running as a cloud service, the resource optimization configurator is a Dockerized AGILE service running on the gateway ( This service works completely offline, i.e., can be executed directly on the gateway. Implemented Recommender Technologies: Recommender service is using two recommendation technologies: Content Based Filtering and Collaborative Filtering. Content-based filtering recommends items based on a comparison between the content of the items and a user profile. The content of each item is represented as a set of descriptors or terms, typically the words that occur in a document. The user profile is represented with the same terms and built up by analysing the content of items which have been seen by the user. Collaborative filtering also referred to as social filtering, filters information by using the recommendations of other people. It is based on the idea that people who agreed in their evaluation of certain items in the past are likely to agree again in the future. A person who wants to see a movie for example, might ask for recommendations from friends. The recommendations of some friends who have similar interests are trusted more than recommendations from others. This information is used in the decision on which movie to see. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 27 of 57

28 These technologies can be generally memory and CPU consuming. Besides, in collaborative filtering a central database is required. Therefore, we run our recommender backend as a cloud service (currently deployed on a server at TUGraz). The recommenderandconfigurator micro-service runs on the agile gateway but needs to connect to this server to be able to get recommendations (note that the configurator part of the service, which is not used in the WP4 context, can work completely offline without interacting with a cloud backend). Content Based Filtering uses the gateway profile information, which comprises location, price preferences and required services. This gateway profile information is taken from the gateway profile information file of the recommenderandconfigurator service. After taking the profile information, the recommender checks the available cloud services and recommends the best fitting ones in the beginning of the output list where up to 10 recommendation results can be found. Collaborative Filtering uses similarities in gateway profiles. This means that other similar gateway users cloud preferences are recommended by the service. Recommender and Configurator relations with WP2 tasks: T2.3 (IoT Device Discovery and Gateway Management). The Resource Optimisation Configurator can be utilised by AGILE Services (such as Device Manager or Component Manager to provide a configuration for gateway settings (e.g., selection of specific data transfer protocols depending on a given set of optimization parameters) based on information related, for example, to the gateway profile and preferences which are provided as an input to the configurator service. Resource Optimisation Configurator is designed to work as a local restful service on AGILE gateways. T2.4 (Remote Gateway Management) similar to gateway management, recommender functionalities are provided and can be used in terms of, for example, showing apps, devices and cloud services recommendations to users. T2.5 (Gateway SW Maintenance) is responsible for supporting the AGILE pilot users and Open Call participants with regard WP2 products. WP2 includes the Management UI (that utilises recommendation services) and AGILE Services (that utilise the Resource Optimisation Configurator). D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 28 of 57

29 Figure 6 Recommender and Configurator Service runs on the AGILE gateway locally. Recommender operations and Ramp-up Configurator need to connect to the Recommender Server. The Resource Optimization Configurator can run offline. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 29 of 57

30 Figure 7 Online Recommender and Configurator Services are shown in yellow boxes in the AGILE Cloud Services Architecture Figure 8 Configurator Service is shown as the yellow box in the AGILE Gateway Architecture 4.1 The AGILE Recommender service The recommender (and configurator) service runs on the AGILE Gateway and it needs to connect to the recommender backend server online (except for the Resource Optimization Configurator, it works offline). Recommendable items are stored on the Recommender Server. These items are retrieved online from specific marketplaces (dockerhub for apps, amazon.com for devices, D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 30 of 57

31 node-red for workflows and a local file for cloud services). The Recommender Server also holds requests history to be able to identify similarities between new requests. Services and Restful API: There are four recommendation services (app/workflow/device/cloud service) and two configuration services (ramp-up and resource optimisation). All these services are collected on one docker micro service (except the ramp-up configurator) and are running on the gateway which is accessible by the other gateway services. Ramp-up configurator runs itself on the server side and accessible via its web UI. The recommender and configurator docker micro services can be downloaded to the AGILE gateways from dockerhub: The recommender backend server is located here: The ramp-up configurator is located here: The recommender and configurator service can be used by other gateway services via its restful API: Source code: Recommender and configurator gateway service: Recommender backend: Rampup Configurator backend: Recommendable Items stored on the Recommender Server: Recommender Server holds the recommendable items for each type of recommendations (app, device, etc.). These items are retrieved from the online marketplaces by the Recommender Server whenever the update repository service is called. This service is called when the recommender server is deployed. Update repository service can be also triggered periodically to keep the items storage up-to- D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 31 of 57

32 date. Currently, the following amount of the items is provided on the Recommender Server: Apps: 781 docker micro services (for IoT) o from the online marketplace: o One sample recommendable item from this marketplace: IoT Sensor Simulator: Workflows/Nodes: 1593 workflows/nodes o from the online marketplace: o One sample recommendable item from this marketplace: LG TV Remote Controller Workflow: e73 Devices: 2951 (raspberry-pi compatible) devices o from the online marketplace: o One sample recommendable item from this marketplace: Raspberry-Pi Camera Module: Megapixel/dp/B01ER2SKFS/ref=sr_1_1?ie=UTF8&qid= &sr=8-1&keywords=raspberry+pi+camera Cloud Services: 8 (node.js compatible) cloud services o from the online marketplace: o One sample recommendable item from this marketplace: Heroku Cloud Services: In the next versions, we can increase the varietyvariety of the marketplaces for these recommendable items. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 32 of 57

33 4.1.1 The App Recommender The App recommender (see below) can be used (get app recommendation) by the AGILE gateway services using its API: GetAppRecommendation. App Recommender is working on the gateway and also uses the backend recommender server (due to the mentioned performance reasons); consequently, it needs an internet connection on the gateway. On the recommender server, recommendable apps are stored which are taken from the docker-hub by the server itself. Recommendation items (apps) can be updated by taking the available items from Docker-Hub website using the API: For calculating recommendations, content-based and collaborative filtering is used. For contentbased recommendation, App Recommender uses information about installed apps, workflows/nodes and plugged devices (gateway profile data) to make a recommendation to the user. For collaborative filtering based recommendation, recommendation requests (on the basis of gateway profiles) of other gateways are used. Outputs of the App Recommender are the names and links of the apps which can be downloaded from Docker-Hub website. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 33 of 57

34 Figure 9 An example use-case of the App Recommender is shown in an illustration of the App Manager UI D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 34 of 57

35 Figure 10 Outputs of app recommender (on KURA UI) KURA user interface (UI) of the App Recommender: This UI always shows the most relevant recommendation to the user; the app can be downloaded by the user (by clicking the "apply" button). If not relevant, further recommendations can be shown. The same approach to display recommendation results in KURA is also implemented for the Workflow Recommender, Device Recommender, Cloud Recommender, and Resource Optimization Configurator. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 35 of 57

36 4.1.2 The Workflow Recommender The Workflow Recommender can be used by the AGILE Gateway Services using its API: Workflow Recommender is working on the gateway and also uses the backend recommender server. Consequently, it needs an internet connection on the gateway. On the recommender server, recommendable workflows and nodes are stored which are taken from the Node-Red website by the server itself. Recommendation items (workflows/nodes) can be updated by taking the available items from Node-Red website using the API: For calculating recommendations, content-based and collaborative filtering is used. For contentbased recommendation, Workflow Recommender uses information about installed apps, workflows/nodes and plugged devices (the data of gateway profile) to make a recommendation to the user. For collaborative filtering based recommendation, recommendation requests (on the basis of gateway profiles) of other gateways are used. Outputs of the Workflow Recommender are the names and links of the workflows or nodes which can be downloaded from Node-Red website. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 36 of 57

37 Figure 11 An example use-case of the Workflow Recommender is shown in an illustration of the Node-Red Workflow Development Environment UI D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 37 of 57

38 4.1.3 The Device Recommender The Device recommender can be used by AGILE gateway services using its API: Device Recommender is working on the gateway and also uses the backend recommender server consequently, it needs an internet connection on the gateway. On the recommender server, recommendable devices (devices compatible with raspberry-pi) are stored which are taken from the amazon.com by the server itself. Recommendation items (devices) can be updated by taking the available items from Amazon.com using the API: For calculating recommendations, content-based and collaborative filtering is used. For contentbased recommendation, Device Recommender uses information about installed apps, workflows/nodes and plugged devices (the data of gateway profile) to make a recommendation to the user. For collaborative filtering based recommendation, recommendation requests (on the basis of gateway profiles) of other gateways are used. Outputs of the Device Recommender are the names and links of the devices which can be ordered from Amazon.com website. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 38 of 57

39 Figure 12 An example use-case of Device Recommender is shown as an illustration of the Device Manager UI D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 39 of 57

40 4.1.4 The Cloud Recommender The Cloud Recommender can be used (get cloud recommendation) by AGILE gateway services using its API: GetCloudRecommendation Cloud Recommender is working on the gateway and also uses the backend recommender server consequently, it needs an internet connection on the gateway. On the recommender server, recommendable cloud services are stored which are decided with the WP4 partners to include in our recommendable list. These services can support node.js which is required for workflow deployments on cloud servers by the AGILE developers. For calculating recommendations, content-based and collaborative filtering are used by the Cloud Recommender. For content-based recommendation, Cloud Recommender uses information location, price preferences and required services (information is retrieved from the gateway by the recommender service) to make a recommendation to the user or developer. For collaborative filtering based recommendation, recommendation requests of other gateways are used. Outputs are the names and links of the cloud services which can be accessed via the provided link to register and start to use. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 40 of 57

41 Figure 13 An example use-case of Cloud Recommender is shown as an illustration on the Node-Red Workflow Development Environment UI D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 41 of 57

42 4.2 The AGILE Configurator service The Ramp-up Configurator works on the server side and can be used via its web UI. The Resource Optimisation Configurator works on the gateway. Details of the AGILE Configurators were also explained in deliverable D2.1 under Section The Ramp-up Configurator (for Pilot-C) The Ramp-up Configurator works on the server side and can be used via its web UI ( Its application is shown in the context of Pilot-C as Monitoring Station Configurator as shown in the screenshots below. Monitoring Station Configurator is designed to help the installation technicians. The technicians can use this tool to see the suitable installation configuration for the deployment environment. The technician provides the details about the installation environment (indoor, outdoor, wall types, school or industry place, etc,) via the UI of the configurator. Then, the configurator starts calculating consistent solutions for the given input and the predefined constraints about the sensors and pollution metering. Finally, the configurator displays possible solutions to the technician who should use one of these solutions for the installation. A configuration includes all needed hardware and software components including a corresponding overall price for the configuration. This way, we are able to guarantee the correctness of IoT infrastructure configurations and contribute to significant cost savings in related installations and maintenance processes. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 42 of 57

43 Step.1- Accept environmental data as input from installer D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 43 of 57

44 Step.2- Search for configuration D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 44 of 57

45 Step.3- Show the configuration options to the techni D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 45 of 57

46 We have used an open source library Clingo as an ASP (Answer Set Programming) Configurator ( A ramp-up configurator implementation for Pilot-C has been developed by TU Graz. OOur target in this context is to provide a generic interface to the configurator than can be exploited by different (AGILE) configuration scenarios. The ASP knowledge representation is useful especially in complex domains where the number and type of different needed components are not known beforehand. The idea of ramp-up configuration is that engineers specify the properties of the given application domain (e.g., pollution monitoring requirements or the structure of a specific house in the context of smarthome configuration) and the configurator automatically determines the corresponding set of sensors, apps and further components needed to make the gateway operable. Where needed, pricing information related to the overall configuration can be included. The AGILE configurator also provides support in situations where no solution can be identified, for example, in a pollution monitoring scenario, the technician responsible for the configuration could have specified requirements that are inconsistent with the underlying knowledge base. In this context, TU Graz is providing diagnosis and repair techniques that proavtively support configurator users in getting out from no solution could be found situations. A special focus is given on the efficiency and prediction quality of the underlying algorithms. In Table.1, some parts of an Pollution Monitoring knowledge base (based on ASP) are shown. % configuration for 1 station type_monitoringstation(1). % 1 station has many deployment environments : max 1 #const max_deploymentenvironments = 1. #const number_deploymentenvironments = max_deploymentenvironments. potentialinstance_deploymentenvironment(2..number_deploymentenvironments+1). D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 46 of 57

47 0{type_deploymentenvironment(X)}1 :- potentialinstance_deploymentenvironment(x).. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ATTRIBUTE DEFINITIONS (DOMAINS:attributedomain and VALUES:attributevalue) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Class: type_monitoringstation(x) % Attribute Domains attributedomain_type_monitoringstation_communication(wired;wireless). attributedomain_type_monitoringstation_localstorage(yes;no). attributedomain_type_monitoringstation_cloudstorage(yes;no). attributedomain_type_monitoringstation_enclosure(strugged;standard). % Attribute Values 1{attributevalue_type_monitoringstation_communication(X,Y): attributedomain_type_monitoringstation_communication(y)}1 :- type_monitoringstation(x). 1{attributevalue_type_monitoringstation_localstorage(X,Y): attributedomain_type_monitoringstation_localstorage(y)}1 :- type_monitoringstation(x). 1{attributevalue_type_monitoringstation_cloudstorage(X,Y): attributedomain_type_monitoringstation_cloudstorage(y)}1 :- type_monitoringstation(x). 1{attributevalue_type_monitoringstation_enclosure(X,Y): attributedomain_type_monitoringstation_enclosure(y)}1 :- type_monitoringstation(x). %%%%%%%%%. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ASSOCIATIONS %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % ASSOC1: monitoringstation - deploymentenvironment 1{assoc_type_monitoringstation_and_type_deploymentenvironment(X,Y): type_deploymentenvironment(y)} max_deploymentenvironments :- type_monitoringstation(x). 1{assoc_type_monitoringstation_and_type_deploymentenvironment(Y,X): type_monitoringstation(y)} 1 :- type_deploymentenvironment(x).. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%% % CONSTRAINTS %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%% % C1: DeploymentEnvironment.locationType= Urban CONFLICTS Area.Category= Countryfield :-attributevalue_type_deploymentenvironment_locationtype(e,urban), attributevalue_type_area_category(a,countryfield), assoc_type_deploymentenvironment_and_type_area(e,a).. Table 2 - Sample fragments of an ASP-based configuration knowledge base of the Pollution Monitoring System of Pilot-C D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 47 of 57

48 4.2.2 The Resource Optimisation Configurator The Resource Optimisation Configurator works on the gateway inside the recommenderandconfigurator docker micro service. This service can be downloaded to the gateway from dockerhub: The Resource Optimisation Configurator service can be used via its restful API. The related API description can be seen online here: GetResourceOptimization. The user preferences are defined in a system file and are used as an input to the configurator besides the gateway profile information. Target of this configurator is to provide appropriate settings for the devices or applications to the gateway. This configurator can be triggered by the gateway services (Device Manager, Component Manager, etc.). Before operable, corresponding parameters, domain values, and constraints have to be defined in terms of a constraint satisfaction problem (CSP). After receiving the optimum settings for apps and devices, AGILE Services are responsible to apply those settings. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 48 of 57

49 Figure 14 An example use-case of Resource Optimisation Configurator is shown as an illustration on the App Manager UI D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 49 of 57

50 We implemented the Resource Optimisation Configurator focusing on the configuration/optimization of data exchange protocol usage in Java based on the Choco CSP solver ( Our implementation is placed under The tables below show a very simple example of Resource Optimisation (see also Deliverable 2.1). According to the user preferences (Table.3), the Configurator can select the best protocol appropriate for the user/device. User preferences are represented in terms of utility with regard to interest dimensions, (see Table.3). The given set of different protocols is included in Table 2. The currently implemented basic approach is flexible in the sense that optimisation criteria can be redefined/extended depending on the requirements of the applications scenario. Table 3 - Features of protocols a and b such as their performance, reliability and costs Table 4 - Requirements of Users u1 and u2, with respect to performance, reliability and costs 4.3 Publications TUGraz has below publications related to AGILE project: ACCEPTED: «Towards Configuration Technologies for IoT Gateways» CP2016 Workshop on Configuration, ACCEPTED: «Constraint-Based and SAT-Based Diagnosis of Automotive Configuration Problems» Journal of Intelligent Information Systems (JIIS), val/journal/10844 D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 50 of 57

51 ACCEPTED : «Human Computation for Constraint-based Recommenders» Journal of Intelligent Information Systems (JIIS), ACCEPTED: «Cluster-Specific Heuristics for Constraint Solving» International Conference on Industrial, Engineering, Other Applications of Applied Intelligent Systems, ACCEPTED : «Recommendation Technologies for IoT Edge Devices» The Third International Workshop on Internet of Things: Networking Applications and Technologies, ACCEPTED: «Constraint Ordering Heuristics for Direct Diagnosis Algorithms» Configuration Workshop, 2017 (30 March, 18 May 2017). ACCEPTED: «ASP-based Knowledge Representations for IoT Configuration ScenariosScenarios» Configuration Workshop, 2017 (30 March, 18 May 2017) / SUBMITTED: «An Overview of Recommender Systems in the Internet of Things» Journal of Intelligent Information Systems (JIIS), val/journal/10844 WILL BE SUBMITTED: «Configuration Technologies in Sports Monitoring» Configuration Workshop, 2017 (30 March, 18 May 2017) / WILL BE SUBMITTED: «Overview of IoT sports monitoring and big data» Journal of Intelligent Information Systems (JIIS), val/journal/10844 WILL BE SUBMITTED: «Application of AGILE in sports monitoring» International Sports Engineering Association, ISEA 2018 (1 May 2017) WILL BE SUBMITTED: «Ramp-up Configuration for Environmental Pollution Monitoring Stations» Venues to be selected WILL BE SUBMITTED: «An Overview of Workflow RRecommendation in IoT» CAISE or SEKE or ICSE D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 51 of 57

52 5 Gateway Management This component of the report, which documents local and remote management features of the AGILE gateway, refers to work in progress. Although we refer below to integration of the resin.io device management platform (certain features are provided via an interface locally to the gateway and others via remote access for fleet-management purposes) the software implementation of APIs and underlying parts of the AGILE stack that realise the above is still ongoing and as per the documented task durations in the description of work. 5.1 Accessing the AGILE gateways AGILE will contain Docker images with all the dependencies to run projects. The core container is stored in a Resin.io container index/registry and a separate agent on the gateways is alerted that a new version any makers app is ready. If a gateway device is offline at the time, it will become aware of this when it obtains internet connectivity again. Having a device behind a NAT is not a problem as AGILE will employ a VPN setup for the devices. This is a good point to note that all communication between AGILE, Resin.io as the intermediary of the open-source solution, and the end gateway devices is encrypted, either via the VPN or through HTTPS. The agent then downloads the changed layers of the core AGILE application container image, stops the old version of the application, and starts the new one. Different update strategies will also be supported, depending on the cases identified in the pilots. Delta updates is also a separate development that the partner is undertaking, that should be much more efficient in terms of bandwidth. The applications themselves can make use of update locking to block updates from happening during critical times (e.g. a medical device is updating data on the gateway, or an industrial machine is in the middle of an operation). As the process is ongoing, makers will be able to see the overall progress of the download in an AGILE dashboard. Clicking on specific devices exposes more detailed information about the gateway, such as logs. D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 52 of 57

53 Figure 15 Device management dashboard with fleet details and device logs At every step of the process, each part of the back-end reports back to an API server which makes the information available to the user interface. But the management UI will just be another API client. CLI or node.js and Python SDKs can be used (virtually anything that consumes an API), and AGILE will be accompanied by a full API documentation. One of the key aims of AGILE is to facilitate rich experiences, combining device-level data provided by AGILE s management interface, with higher-level application-specific data that lives in other data domains. 5.2 Provisioning AGILE gateways A key feature of the AGILE fleet management stack is in provisioning keys for application which are embedded in the image download. These are used to make first contact with the AGILEgateway-specific-endpoint and server and authenticating the devices as having been flashed with an authorised image. Unless someone downloads the OS or other software components from the AGILE dashboard (or via the CLI), the devices cannot enter an application. The details of the provisioning differ depending on the device type (for example the type of hardware the gateway supports). In summary, the following steps occur: D2.3 Final version of self-configuration, IoT Device discovery & Remote management Page 53 of 57