This document discusses the roles and design of an automatic configuration and recommender system for an IoT gateway. The system will configure the gateway and recommend software modules based on the hardware modules connected. It will include an autoconfig component that applies configurations and a recommender that suggests configurations. The roles, design options, and integration with the gateway software stack are debated, including supporting offline and online usage scenarios. Deadlines for initial prototype versions and integration are outlined.

1. WP1 - T2.1
LEADER: ETH
INVOLVED PARTNERS: CN, RULEMOTION, TUGRAZ,
LIBELIUM
AGILE ATHENS MEETING, 14-15 April 2016, ATHENS GR

2. Task Summary
T2.1 - Automatic configuration based on hardware modules
Duration: M0-M6
Objectives:
◦ implement the mechanisms that will allow the AGILE gateway to be auto-
configured based on the hardware modules activated by the user;
◦ collect requirements for the recommender based on the hardware modules to be
supported.
Status:
◦ concepts definition, architecture and functionalities: almost finished;
◦ requirements and knowledge identification: next step;
◦ D2.1 deliverable preparation: next step.
Deadlines:
◦ M9 - D2.1 Core requirements specification and IoT protocol integration -
Rulemotion - Report -Public
AGILE KICK-OFF MEETING, 12-14 January 2016, Trento IT

3. Automatic configuration and
recommender roles
Two main roles:
◦ manage HW modularity;
◦ contribute managing gateway deployment.
Manage HW modularity: depending on the HW modules connected to the
gateway automatically configure the drivers; select and configure the
corresponding AGILE modules.
Manage gateway deployment: the gateway can be deployed in different
contexts, both in terms of environment and vertical application. The
gateway provide to the recommender information about the deployment
context, the recommender select a configuration/s depending on the
context and send it/them to the autoconfigthat in turns applies the
configuration.
What is the relation between the autoconfig and the recommender?
◦ The recommender suggests a set of solutions to a configuration issue.
◦ The autoconfig selects one of the suggested solutions and applies it.

4. Roles of the recommender
Role of the recommender:
◦ recommends applications and workflows;
◦ recommends configurations;
◦ recommends peripherals (to be discussed).
Application:
◦ depending on the HW modules selects/suggests the AGILE Sw modules to be
downloaded, installed and started;
◦ depending on the specific context selects/suggests the AGILE Sw modules to
be downloaded, installed and started.
◦ depending on the GW profile and Workflow items, suggest a Workflow or
Node to developer.
Workflows: TDB

5. Roles of the recommender (2)
Configuration:
◦ depending on the HW modules selects/suggests the best configuration to be
adopted for drivers and SW modules;
◦ depending on the specific context selects/suggests the best configuration to
be adopted for drivers and Sw modules.
Recommender works after the boot phase, in user space.

6. Roles of the auto configuration
Auto-configuration support:
◦ at boot time;
◦ at run time.
At boot:
◦ for device drivers it is already provided by the OS;
◦ at the end of the boot process, after entering the user space, the AGILE SW
Modules are automatically configured by autoconfig. (this is done by
Configurator)
At runtime: configures drivers and AGILE Modules.
◦ Rpi Shields currently doesn’t support hot plug/swap. It is possible to support it
with specific hardware modification of the Shield (based on a buffer to manage
the signals during hot plug/swap), passing UART, I2C, etc. through the shield and
monitoring with a daemon a specific I/O line;
◦ always supported by peripherals based on enumerable interfaces (USB,
Bluetooth, etc..).
◦ Except for USB, the industrial gateway doesn’t need hot swap peripherals,
therefore it doesn’t need auto-configuration at runtime.

7. Drivers and AGILE modules
management
We refer to a model where any HW module is managed by a subsystem
logically composed by two components:
◦ a device driver (OS-Kernel level);
◦ a specific application (application level, user space, an AGILE module).
Two classes of peripherals:
◦ standard HW modules (hot plug not supported);
◦ HW modules based on enumerable interfaces (hot plug supported).
The recommender manages three different situations:
◦ peripheral type 1 -> 1 driver -> 1 AGILE Module;
◦ peripheral type 2 -> 1 driver -> 1 AGILE Module;
◦ peripheral type 2 -> 1 driver -> n AGILE Module.

8. Drivers and AGILE modules
management (2)
AGILE Platform
Operating System
HW Module Categories HW modules based on “enumerable” interfaces
Hot plug/hot swap
AGILE
Module
AGILE
Module
AGILE
Module
AGILE
Module
AGILE
Module
Device
driver
Device
driver
Device
driver
Standard HW Modules
SATA
drive
r
Storage
Module
WIFI
drive
r
Networking
Module
ComExpress, PCI, etc.. USB, Bluetooth, Zigbee, SATA(with backplane), etc..
Zigbe
edriv
er
WSN temp
module
WSN optic
meas.
module
WSN
pressure
module
E.g. interfaces/peripherals
WSN
coordinator
module
1 2 3

9. Drivers and AGILE modules
management (3)
Case 1:
◦ The HW module must be connected before boot, hot plug not supported.
◦ The HW module is supported by a specific driver available locally; the kernel
load the driver automatically with default configuration.
◦ Only an AGILE Module corresponds to the required driver. If not available
locally, the recommender simply identify it and communicate it to gateway.
Case 2:
◦ When the HW module is connected to the gateway the kernel manages it
with the driver already loaded (e.g. USB).
◦ Only an AGILE Module corresponds to the required driver. If not available
locally, the recommender simply identify it and communicate it to gateway.
◦ If not available locally the gateway downloads the module. The module is
started with default configuration.

10. Drivers and AGILE modules
management (4)
Case 3:
◦ When the HW module is connected to the gateway the kernel manages it with
the driver already loaded (e.g. Zigbee via USB).
◦ Depending on the HW module a set of AGILE modules are available. The
recommender identify the most suitable set of AGILE modules and inform the
gateway (e.g. a Zigbee coordinator and a Zigbee application).
◦ If not available locally the gateway downloads the modules suggested. The
modules are started with default configuration.
Case 1,2, 3):
◦ depending on the deployment context and the application, the recommender
might suggest a configuration for the driver (autoconfig) and for the AGILE
Module. These configuration are applied at end of the boot phase (for drivers)
and when the AGILE modules are running.
◦ At runtime, if the context changes, the recommender can suggest new
configurations of drivers or AGILE modules.
◦ At runtime, if the context changes, the recommender can suggest new AGILE
modules to be downloaded and started (do we support this?).

11. Autoconfig/recommender SW
characterization
How the autoconfig/recommender can be characterized from a
software point of view?
The automatic configuration:
◦ handled both by OS and Configurator
◦ locates at operating system level.
◦ It could be implemented as a OS daemon.
It runs on the gateway.
◦ The recommender:
◦ locates at application level.
◦ It runs on the gateway and it is an AGILE module.
◦ Could it be a server application running remotely? On the cloud?

12. Autoconfig/recommender SW
characterization (2)
Recommender:
◦ content based and collaborative algorithms can be applied depending on the
use cases and knowledgebase.
Configurator:
◦ the basic version can be based on a rule engine or Constraint Solver;
◦ depending on the use cases:
◦ we can adopt the basic version;
◦ we can extend the basic version with a more autonomous solution based on learning, semantic,
AI, … technologies.

13. Abstraction levels
HARDWARE
FIRMWARE
OS
APPLICATION
JAVA VM
OSGi Framework
Kura Framework
Kura Application
APP Container APP Container
…
Application Application
Kernel
HOT SWAP PERIPHERALS
PLUG & PLAY PERIPHERALS
(e.g. USB)
Drivers
Libraries AUTOCONFIG
RECOMMENDER

14. Gateway offline
AGILE Gateway
Conf.s &
Modules
Repository
Recommender
Autoconfig
Gateway connected to a LAN (1)
AGILE Gateway
AGILE Gateway
AGILE Gateway
AGILE Gateway
Gateway connected to a LAN (2)
Conf.s &
Modules
Repository
LAN LAN
Gateway connected to a LAN (3)
AGILE Gateway
AGILE Gateway
AGILE Gateway
Conf.s &
Modules
Repository
Recom
mender
LAN
AGILE Gateway
AGILE Gateway
AGILE Gateway
AGILE Gateway
Recommender usage
scenarios

15. Gateway online (1)
InternetAGILE Gateway
AGILE Gateway
AGILE Gateway
Gateway online (2)
InternetAGILE Gateway
AGILE Gateway
Conf.s &
Modules
Repository
Gateway online (3)
Internet
AGILE Gateway
AGILE Gateway
Conf.s &
Modules
Repository
Recom
mender
Recommender usage
scenarios (2)
Topology of the solution decided after use case description is available
◦ 1st version based on cloud recommender
◦ “Autonomous” version (autoconfig, recommender & knowledge base on the
gateway) is mandatory
◦ The best solution is probably: Gateway online (1) + gateway online (3):
◦ it covers both offline and online situations;
◦ it is scalable and flexible;
◦ it covers many potential requirements of use cases.

16. Recommender usage
scenarios (3)
When the gateway is offline, it should be as much autonomous as possible:
◦ the recommender runs on the gateway;
◦ a repository of configurations and modules is installed on the gateway.
When the gateway is connected to a LAN:
◦ it could be used as in an offline situation;
◦ alternatives:
◦ the recommender is a software running on a server on the LAN, or in a local private cloud;
◦ a single repository could be available on the LAN.
When the gateway is connected to the internet:
◦ it could be used as in an offline situation;
◦ alternatives:
◦ the recommender is a software running on the internet, or on the cloud;
◦ configurations and modules are stored in one or more remote repositories.

17. Recommender usage
scenarios (4)
Scenarios that justify a high level of autonomy for the gateway:
◦ In a transportation application, with different connectivity options (3G,
HSDPA, Wifi hot spots, etc..) the gateway should select autonomously,
depending on the geographical position and available connectivity, the best
communication channel (in terms of price, connection , etc.)
◦ On a cruise liner a set of gateways is connected to the ship LAN. The ship
sometimes is connected to the internet sometimes not. The gateways could
be fully autonomously or could rely on a shared local repository and a shared
recommender that, in turns, could run on a local cloud.
◦ …

18. Architecture for Offline
Recommender Engine

19. Architecture for Offline
Configurator Engine

20. Autoconfig/Recommender
footprint
Considering the hardware resources available on the two versions of the
gateway, there could be potential issues related to the footprint of the
autoconfig/recommender:
◦ the industrial gateway provides a Intel Atom class cpu, at least 1Gb of RAM
and at least 16 Gb of storage.
◦ The limitation and constraints of the Rpi have to be evaluated.
◦ According to the use cases(when and what to recommend/configure
according to what) and knowledge bases(size, how to update, owner,
location), Configurator and Recommender Engines location and working
principles can be decided.

21. Gateway profile
The profile contains:
◦ Installed Apps (Snappy applications)
◦ Installed and Developed Workflows and Nodes
◦ Plugged devices (sensors and comm. devices)
◦ Context information (gw use case: cruise, field, etc.)
The profile is stored:
◦ locally in the gateway;
◦ the gateway shares/publishes its profile with AGILE server to be used for
recommendations for other Gateways; (user consent can be asked)
◦ distributed/remote storage of profiles.

22. Requirements & Knowledge
base
Requirements and knowledge base will defined in collaboration with
WP8:
◦ T2.1 manages knowledge base and has the overall view of the requirements
and knowledge base definition:
◦ specifies horizontal technical, architectural and functional requirements;
◦ explains how knowledge base must be described and provide an example;
◦ overviews the knowledge base “creation”.
WP8 Use case owners have to define:
◦ identifies autoconfig & recommender requirements for specific use cases;
◦ the knowledge base for specific use cases (HW, SW, Context).
WP1&WP2 contribute creating the knowledge related to the gateway
HW and OS (horizontal aspects).

23. Deadlines & versions planning
M6: D2.1 “description of mechanisms developed/integrated that will
enable the automatic configuration of the gateway based on the
hardware modules attached every time”
M9: D2.2 “initial version of the mechanisms integrated and developed
for the self-cofinguration of the gateway”
M12: 1st autoconfig/recommender scenario, recommender is outside
the gateway or on a simulated gateway
M18: D2.3 “Final version of Gateway Self-configuration”
M24: (AGILE Full SW stack) sophisticated solution for recommender and
autoconfig
M30: version integrated with use case/s

24. Details on the recommender and
configurator…

25. Knowledge Bases
Proposal
In Phase-1, all knowledge bases are located on server. Recommender
and Configurator are also executed on server side. APIs of those
knowledge bases should be specified by the data owners.
Recommender on Gateway, operates on imported apps and
Workflows. If profiles of other users are included, recommendation
should be remote.
In Phase-2, some of the knowledge bases can be located locally on
the gateway. Some functionalities of Recommender and Configurator
can be also executed on the gateway locally. This Phase provides an
OFFLINE functionality of Recommender and Configurator. (Cruise
Gateways may require such offline usages)

26. Recommender Role -1
Recommend Apps (snaps)
Uses App knowledgebase, other Gw Profiles and own Gw Profile
Case: When a IoT user want to see recommended apps on the AGILE
Management Interface, Recommender should use the Gw profile (which
sensors are plugged? ,etc.), other people Gw profiles (which apps are
installed on similarly configured Gws? ,etc.) to suggest some apps to
install.
Case: When a new device plugged, Recommender can recommend a
related application to the user via Management Interface.

27. Knowledge Base for R.Role-1

28. Recommender Role -2
Recommend Workflows
Uses GW profile and workflow knowledge base
Case: When on AGILE Development Interface a developer is developing
a new workflow using Temperature Sensor, developer may want to see
the recommended nodes and flows. In that case, current GW Profile
(what are the other plugged devices?, etc.) and workflow knowledge
base (what are possible nodes and flows that use Temperature Sensor
and maybe also other plugged devices together) will be used by the
Recommender to suggest a Node or Flow to the developer.
Case: When a developer is developing a workflow using Sensor1,
recommender can recommend to plug and use Sensor2 that is widely
used with Sensor1 by other similar workflows.

29. Knowledge Base for R.Role-2

30. Recommender Role -3
Recommend Configurations
Uses other AGILE GW profiles
Case: When a wifi module is plugged, there may be also zigbee and BLE
modules plugged before. For some apps, all 3 options can be possible.
For best configuration, Configurator may ask Recommender to select an
appropriate one according to other GW configurations.

31. Knowledge Bases for R.Role-3

32. Configurator Role -1
Configure Drivers
Configurator comes into play when kernel fails to configure a driver of a
plugged device. OS requests for an appropriate driver for the new device
from the Configurator.
Uses the Features of Drivers and Gateway Profile
◦ Driver1 supports temperature sensors
◦ Gateway has Driver2.
Uses the Constraints of Drivers
◦ Driver1 is not compatible with Driver2.
Uses the Domains
◦ Drivers can be in states (Loaded, NotLoaded, Installed, NotInstalled).
When more than one solutions is found by Configurator, to be able to select
best solution Recommender is triggered. Recommender returns best
solution back to Configurator.

33. Knowledge Bases for C. Role-1

34. Configurator Role -2
Configure Apps
Uses the Features of Apps and Devices (features of the installed apps, which sensors or devices are compatible
or incompatible)
◦ App1 can use Wifi, Zigbeeor BLE.
◦ App1 has Temperature Measuring Feature.
◦ App1 has Pressure Measuring Feature.
◦ App2 can only use Wifi.
◦ Zigbee can not work if Wifi is in use.
◦ BLE can work together with Zigbee and Wifi.
◦ Temperature Sensor 1 does not work if Temperature Sensor2 is in use.
Uses the Constraints of Gateway (which action should be taken in which mode)
◦ When Normal Mode is enabled, then enable Wifi on apps.
◦ When Energy Saving Mode is enabled, then enable BLE on apps and disable other communication protocols.
◦ When Security Restriction Mode is enabled on the gateway, disable all connections on the installed apps.
◦ When Wifi hardware module is plugged, then enable the communication protocol as Wifion installed apps and disable current
protocol.
◦ When Temperature Sensor is plugged, then enable the Temperature Feature of related apps.
◦ When Wifi is unplugged, then enable Zigbee or BLE on related apps.
Uses the Domains
◦ A feature of an app can be (Disabled , Enabled).
◦ A hardware module can be (Plugged , Unplugged).
◦ Gateway can be in a (Normal, Energy Saving, Security Restricted) mode.

35. Knowledge Bases C. Role-2

36. Gateway Profiles
AGILE Gateway profiles can be shared with a centralized server to be used
by Recommender.
Profiles should be classified according to their similarities on the server.
There should be a Recommendation Algorithm running on the server to be
able to use these profiles and recommend solutions to the Gateways.
A profile contains:
◦ Installed Apps (Snappy applications)
◦ Installed and Developed Workflows and Nodes
◦ Plugged devices (sensors and comm. devices)
◦ Context information (gw use case: cruise, field, etc.)
A profile is stored:
◦ locally on the gateway;
◦ the gateway shares/publishes its profile with AGILE server to be used for
recommendations for other Gateways; (user consent can be asked)
◦ distributed/remote storage of profiles.

37. Open Question-1
Collection Gateway Profiles on Server
Can we collect Gw Profiles on a server?
Gw Profiles on server should be classified according to similarities. An
algorithm should be run on server. Will there a server available?
Should we ask consent of user to share own Gw Profile with server as
anonymous?
If user does not allow to share Gw Profile with server, should we still
support that user with recommendations using other Gw Profiles or
not?

38. Open Question-2
Workflow Knowledgebase
Where will it be located?
How to access it?
What kind of features are stored?
When can we have a sample knowledgebase?
Who is responsible with developing this knowledgebase?

39. Open Question-3
Snap Knowledgebase
Where will it be located?
How to access it?
What kind of features are stored?
When can we have a sample knowledgebase?
Who is responsible with developing this knowledgebase?

40. Open Question-4
Driver Constraints and Features
Where will it be located?
How to access it?
What kind of features are stored?
When can we have a sample data?
Who is responsible with developing this data?

41. Open Question-5
Apps Constraints and Features
Where will it be located?
How to access it?
What kind of features are stored?
When can we have a sample data?
Who is responsible with developing this data?

42. Open Question-6
Configuring Apps
How to configure an app? An app should be configurable by Agile SW.
This means an app should provide an API for Agile SW to configure it.
◦ Suggestion: This can be done by adding a Configuration Engine Node, during
a workflow development.
What kind of info can be requested from app developer in Configuration
Node?
◦ Suggestion: Optional devices to use. (one of given the communication
devices can be used according to the availability on the Gw and user
preferences: Wifi, zigbee or BLE.

43. Contact info
T2.1 Leader Eurotech
Paolo Azzoni
paolo.azzoni@eurotech.com
TU GRAZ
Institute of Software Technology
Prof. Alexander Felfernig: alexander.felfernig@ist.tugraz.at
Arda Akcay: aakcay@ist.tugraz.at
Seda Polat Erdeniz: spolater@ist.tugraz.at

44. Thanks for the attention.
That’s all folks.