WP2 - T2.1 - Automatic configuration based on hardware modules
•
1 j'aime•608 vues
AGILE 2nd F2F MEETING, 14-15 April 2016, Athens, GR
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à WP2 - T2.1 - Automatic configuration based on hardware modules
Similaire à WP2 - T2.1 - Automatic configuration based on hardware modules (20)
Plus de AGILE IoT
Plus de AGILE IoT (7)
Dernier
Dernier (20)
WP2 - T2.1 - Automatic configuration based on hardware modules
- 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. ◦ …
- 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).
- 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.
- 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.
- 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.
- 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?
- 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.