Building the Environment for the Things as a Service Concertation Meeting “Software&Service, Cloud Computing” Bruxelles, 12 th May 2013

March 11, Brussels Concertation Meeting2 It is an IoT platform to execute M2M applications within a local cloud of gateways, focusing on context and abstracting from devices though an ontology definition. It adapts to several device technologies, including ETSI standards. Features: Things Services Semantic-based access Context and Resource awareness ETSI adaptation Quality of Service (QoS) management Big Data Virtualization The BETaaS platform

March 11, Brussels Concertation Meeting3Motivations State of the artCritical Issues M2M applications use proprietary systems in a vertical approach Not possible to use generic functions due to closeness of current solutions. Inefficient use of resources. M2M applications are defined from the device or the service point of view. Split between things and the contents they provide. Current approaches for M2M applications are centralized. M2M networks are formed by heterogeneous devices with different needs that can be affected by the context that surrounds them Heterogeneous things and different ways to represent the information Integration and discovery of data is a complex task in M2M networks QoS mostly target on high-level domains of workflow and information management. More elaborated QoS requirements need to be considered to accommodate the variety of scenarios. IoT based platforms do not offer virtualization in the local environment, exploiting some devices capabilities. Virtualization in devices is very new and it is still under development, but it is possible to start exploiting some hypervisors

March 11, Brussels Concertation Meeting4 Functional Model ServiceThings-as-a-ServiceAdaptationPhysical GW S S S

March 11, Brussels Concertation Meeting5 Functional model instance GW 5 GW 2 GW 1 BETaaS Instance GW 3 GW 4 TaaS Adaptation PHY AnAn PnPn A1A1 P1P1 Local Component Service SYSTEM 1 SYSTEM 2 Local Component SYSTEM 3 Local Component Service Local Component Service BETaaS-UnawareBETaaS-Aware

March 11, Brussels Concertation Meeting6 Basic Services generated by the platform and associated to the content and context surrounding the thing. They are managed by the TaaS level and are not visible to Application Layer. They are distributed among the GWs. Equivalent things services are selected accordingly to performance-needs requested by the application Things Services

March 11, Brussels Concertation Meeting7 Access to the Platform ON the FLY Application provides the platform with a manifest file containing: Semantic service description Context QoS parameters Credentials Platform identifies Things Service and how to combine them to serve the request. Dinamic process EXTENDED Service It is installed on diretly on the GW. It offers the application with specific service based on things services.

March 11, Brussels Concertation Meeting8 Model the Knowledge – build a network of ontologies  BETaaS Things Ontology – model different aspects of the 2 BETaaS scenarios: Home Automation and Smart City. Model the Context – The location of the things (Home Automation: floor, room) – The functionality of the things: – Type of thing (sensor/actuator). – Type of measurement (e.g. humidity, temperature, presence, irrigation, etc) – Communication protocol(e.g. ZigBee) – Build a network of ontologies to model the context  BETaaS Context Ontology. Content Awareness A thing behaves differently depending on the context and so depending on the things located in its surroundings.

March 11, Brussels Concertation Meeting9 Goal: to infer information which is not explicitly reflected in the ontologies. How: using learning algorithms that bring self-management features into BETaaS: – Semantic reasoner + semantic rules Rule to detect Equivalent Thing Services Rule to detect the need to combine Thing Services Rule to calculate the operator to combine Thing Services Learning Algorithms

March 11, Brussels Concertation Meeting10 Quality of Services QoS Negotiation Resource reservation Optimized allocation Different classes QoS MonitoringTrust Security Mechanisms QoS Fulfilment Dependability Performance Performance Scalability Battery Load Stability in Provided DataDependability Self-healing Diagnosis Recovery Actions

March 11, Brussels Concertation Meeting11 Local Cloud Operations Big Data Gather data from source Storage Distributed computational Background Task execution Virtualization Start simple VM To balance the load between GWs To provide a turnkey commercial solution with specific services and application To increase the isolation level and platform reliability OCCI for remote cloud interactions

March 11, Brussels Concertation Meeting12 Add one plugin for each M2M technology to take care of the corresponding communication protocols. Focus on M2M ETSI – Most promising M2M solution – Great architectural flexibility M2M Adaptation - ETSI Sensor Capabilities GIP Protocol adaptation END DEVICE GSCL Resource Container Command Container BETaaS ETSI Plugin Upper Layers Proprietary Protocol UDP Sensor Data Command UDP Discovery GetData Register Set

March 11, Brussels Concertation Meeting13 EDI System (Electronic Devices for Illumination). EDI System (Electronic Devices for Illumination). Passive InfraRed PIR Sensors. Passive InfraRed PIR Sensors. Car modules. Car modules. Trial: Smart City Scenario Use Case – Lamp dimmering when presence detected. – Nearest car discovery – Automatically and dinamically lamp illumination according to user position – Statistical analysis on lamp status Goal – Interoperability between three pre-existing services managed by a GW each. – Distribution of services – Content access & Context awareness – Big Data

March 11, Brussels Concertation Meeting14 Proprietary software acting as an Alarm system together with the required presence sensors. Proprietary Domotics System accompanied with the appropriate sensors. BETaaS Application specifically created for Water Gardening Systems. Trial: Home Automation

March 11, Brussels Concertation Meeting15 Motivations vs Solutions State of the artCritical Issues M2M applications use proprietary systems in a vertical approach Not possible to use generic functions due to closeness of current solutions. Inefficient use of resources. BETaaS will allow the definition of new M2M applications whose scope spans across different domains.

March 11, Brussels Concertation Meeting16 Motivations vs Solutions State of the artCritical Issues M2M applications are defined from the device or the service point of view. Split between things and the contents they provide. BETaaS runtime platform will ease the development and execution of content centric user applications. Data and resources would be defined from the content point of view, regardless of the physical location in the local cloud..

March 11, Brussels Concertation Meeting17 Motivations vs Solutions State of the artCritical Issues Current approaches for M2M applications are centralized. M2M networks are formed by heterogeneous devices with different needs that can be affected by the context that surrounds them BETaaS platform stays close to the M2M nodes, through the creation of local clouds among nodes in concrete contexts Better reliability Better control over the location of data Better scalability A reduction of the overall energy consumption by reducing the transmission costs

March 11, Brussels Concertation Meeting18 Motivations vs Solutions State of the artCritical Issues Heterogeneous things and different ways to represent the information Integration and discovery of data is a complex task in M2M networks BETaaS platform will use semantic technologies in M2M networks in order to: – filter and unify the information that comes form sources of very different nature; – discover services or things; – model the behaviour of the things so they can react to unexpected circumstances or to changing conditions.

March 11, Brussels Concertation Meeting19 Motivations vs Solutions State of the artCritical Issues QoS mostly target on high-level domains of workflow and information management. More elaborated QoS requirements need to be considered to accommodate the variety of scenarios. Optimized resource reservation and allocation to services. New QoS measures will be considered, like, e.g., energy consumption rates in battery-operated devices

March 11, Brussels Concertation Meeting20 Motivations vs Solutions State of the artCritical Issues IoT based platforms do not offer virtualization in the local environment, exploiting some devices capabilities. Virtualization in devices is very new and it is still under development, but it is possible to start exploiting some hypervisors BETaaS enables virtualization in ARM-based devices, so it is possible to perform more complex tasks in the local environment (i.e. Big Data analysis). BETaaS proposes a resources management mechanism, which benefits the BETaaS platform itself and the applications.

T2.5 - Intecs Thank you