icore Internet Connected Objects for Reconfigurable Ecosystem

(1)

iCore

Internet Connected Objects for Reconfigurable Ecosystem

Grant Agreement Nº 287708

D6.2 Final proof of concept prototype

for Smart Home: Living Assistant

Version: Due Date: Delivery Date: Nature: Dissemination Level: Lead partner: Authors: Internal reviewers: 1.0 31/03/2014 09/05/2014 Report Public UPRC

See contributors table

VTT, TNO

www.iot-icore.eu

The research leading to these results has received funding from the European Community's Seventh Framework Programme

(2)

D6.2. Final proof of concept prototype for Smart Home: Living Assistant

Date: 09/05/2014 Grant Agreement number: 287708 Page 2 of 63 Deliverable Title Final proof of concept prototype for Smart Home

Deliverable Number 6.2

Keywords: Smart Home Proof of Concept, Cognitive Mechanisms Specification, Communication Interfaces, Demonstration Scenarios.

Executive Summary: This deliverable describes the final prototype of the proof of concept for the Smart Home use case. The document starts from an overview of the various components and hardware used describing their functionalities, their implementation details as well as their added value to iCore. Then, the use case scenarios are described and the interactions between various components during each scenario is analysed. Finally, performance results for the iCore system are presented and the implemented interfaces between components are specified.

(3)

Date: 09/05/2014 Grant Agreement number: 287708 Page 3 of 63

Contributors

First Name Last Name Affiliation Email

Vera Stavroulaki UPRC [email protected]

Panagiotis Vlacheas UPRC [email protected]

Dimitris Kelaidonis UPRC [email protected]

Vassilis Foteinos UPRC [email protected]

Antonis Moustakos UPRC [email protected]

Panagiotis Demestichas UPRC [email protected]

Andrey Somov CNET [email protected]

Erik Mademann ZIGPOS [email protected]

(4)

List of Figures

Figure 1: Step 1 of the request process ... 13

Figure 2: Step 2 of the request process ... 13

Figure 3: NLP - SRA Process diagram ... 15

Figure 4: Generic RWK Model ... 16

Figure 5: Smart Home RWK Model ... 18

Figure 6: Generic SK Model ... 19

Figure 7: Smart Home SK Model ... 21

Figure 8: CVO Registry GUI - an indicative instance ... 22

Figure 9: CVO Composition Engine ... 23

Figure 10: CVO Dynamic Workflow ... 23

Figure 11: CVO Coordination GUI ... 25

Figure 12: VO Registry GUI ... 26

Figure 13: VO Creation Tool and associated processes ... 27

Figure 14: VO FE & VO BE ... 28

Figure 15: CVO Desktop Interface ... 29

Figure 16: Smart Car CVO... 30

Figure 17: Smart Traffic Light CVO ... 31

Figure 18: Smart Lighting CVO ... 32

Figure 19: Arduino MEGA with Ethernet Shield ... 32

Figure 20: Motion Sensor, Light Sensor, LED Light ... 33

Figure 21: Power Socket ... 33

Figure 22: Accerelometer, eeRTLS device ... 34

Figure 23: Temperature/Humidity sensor ... 34

Figure 24: Wireless Lamp ... 34

Figure 25: Light Sensor ... 34

Figure 26: WaspMote platform with sensors ... 35

Figure 27: FlyportIoT platform ... 36

Figure 28: Raspberry Pi without case... 37

Figure 29: Software architecture combining WSN to iCore system ... 37

Figure 30: Android Tablet ... 38

Figure 31: Android Phone ... 39

(8)

Figure 33: CVO Coordination Process ... 42

Figure 34: Integration architecture ... 43

Figure 35: Service Level execution time vs. Number of Available Service Templates ... 45

Figure 36: Approximation & Reuse Opportunity Detection execution time vs. Number of Available VOs ... 47

Figure 37: CVO Composition Engine execution time vs. Number of Available VOs ... 48

Figure 38: VO Discovery Process execution time vs. Number of Available VOs ... 49

Figure 39: Overall CVO Creation/Instantiation execution time vs. Number of Available VOs ... 50

(9)

List of Tables

Table 1: Generic RWK Model - description of concepts ... 17 Table 2: Generic SK Model - description of concepts ... 20

(10)

1 List of Acronyms and Abbreviations

Acronym Definition

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

AROD Approximation and Reuse Opportunity Detector

BN Bayesian Network

CCE CVO Composition Engine

CM Correlation Matrix

CPT Conditional Probability Table

cURL Client URL Request Library

CVO Composite Virtual Object

E2E End to End

HTML5 HyperText Markup Language 5

HTTP Hypertext Transfer Protocol

ICT Information and Communications Technology

JSON JavaScript Object Notation

MAP Maximum a Posteriori

NLP Natural Language Processing

PHP Hypertext Preprocessor

POS Part-of-Speech

RDF Resource Description Framework

RWK Real World Knowledge

SA Security Agent

SK System Knowledge

SoC System on Chip

SR GUI Service Requestor Graphical User Interface

SRA Service Request Analysis

URI Uniform resource identifier

VO Virtual Object

VO BE Virtual Object Back End

VO FE Virtual object Front End

(11)

2 Introduction

This document describes the Final Proof of Concept for the iCore Smart Home: Living Assistant Use Case. The Final Proof of Concept unifies the functionalities already implemented in the first Smart Home prototype while further extending the application of the iCore architecture and concepts. Listed below are the iCore architecture aspects that have been extended:

Service Requestor GUI: the users of the Smart Home Use Case have access to the service through this simple, web-based, interface.

User Preferences and Profiling: this component provides smart, personalized services to the users by means of saving certain information about the users (e.g. the services the user has requested and feedback provided for them) and using them to parameterise the service. Real World Knowledge and System Knowledge: In the context of the Smart Home PoC these components support the Dynamic Composite Virtual Object (CVO) Creation and Knowledge based Instantiation by providing past as well as current information (e.g. past CVOs).

VO Registry: this entity is used to hold and manage information regarding the Virtual Objects of the iCore System. Various components in the Smart Home Use Case use this registry to retrieve as well as change information about Virtual Objects (VOs).

VO Factory: this easy to use tool has been implemented to facilitate the creation of Virtual Objects. An end user as well as a domain expert can use this web-based tool to easily create and register VOs.

CVO Management Unit: CVO Coordination: this component is responsible for resolving conflicts that arise when two or more iCore entities both require access to a CVO and it can’t be granted at the same time.

The Prototype Architecture, Validation and Demonstration are described in detail in the following chapters.

(12)

3 Proof-of -concept prototype environment

3.1

Overview

The Smart Home environment aims to improve the quality of life for the disabled and the elderly as well as provide monitoring tools for both family members and healthcare professionals. Additional objectives of this proof of concept include: (a) easy integration of care taking, (b) remote health care, (c) home automation and (d) online medicine purchasing services. Additionally it creates possibilities of a new business eco-system among the elderly, the impaired, patients, family members, care takers, doctors, nurses and pharmacy stakeholders.

3.2

Components

3.2.1. Service Requestor GUI

This component is intended for the end-user/stakeholder. It has been created with “ease of use” in mind and its purpose is to receive a request in natural language and then, through interactions with other iCore components, create the Composite Virtual Object (CVO).

It has been implemented using a number of technologies; namely: (a) HTML 5, (b) PHP, (c) AJAX, (d) Javascript, (e) MYSQL, (f) Servlets (Java Web Services) as well as a (g) RESTful interface to facilitate the connection between the Servlets and the iCore infrastructure.

Firstly, the service requestor selects the area that the CVO will “cover” and clicks the “Fetch Functions” button (this is done in order to have the available Virtual Objects in the area). Then he selects the type of device (Desktop, Mobile or Tablet) he wants the CVO instantiated on and inserts a Service Request written in natural language as illustrated in Figure 1. He can also select any policies he wants (e.g. High performance, Low expenditure). Afterwards, the Service Execution Request is created for the service requestor and the selected Virtual Objects (VOs) are displayed for confirmation (Figure 2).

The Service Requestor GUI provides an iCore user with a simple to use interface with the iCore System thus allowing him to easily request a service.

(13)

Figure 1: Step 1 of the request process

Figure 2: Step 2 of the request process 3.2.2. Natural Language Processing (NLP)

The NLP component is used to perform lexicological analysis on requests expressed in natural language. For this purpose, the WordNet relational dictionary (http://wordnet.princeton.edu/) is being used. It executes Sentence Detection, Sentence Tokenization, Part-of-speech (POS) tagging tasks on service requests. This component outputs the words of the user request, the POS tags of

(14)

Date: 09/05/2014 Grant Agreement number: 287708 Page 14 of 63 the selected words and the syntactical dependencies between the selected words. This output serves as input to the Service Request Analysis component.

It therefore contributes to the automated analysis of the user requests by clarifying the useful information in them adding to the overall ease of use of the iCore System.

3.2.3. User Preferences and Profiling

This component is used to obtain user preference data as well as manage and represent this information (Indicative information includes: (a) the set of available service templates, (b) the set of services that have been requested/are being used and (c) an indication of the user preferences associated with a particular service and service template). In particular, it holds the Conditional Probability Tables (CPTs) of the iCore users. These CPTs are part of the Bayesian Networks (BNs) and they keep the probabilities for the variables of the BNs.

As mentioned in the iCore deliverable document 5.2 [2], a Bayesian Network (BN) is a compact expressive representation of uncertain relationships among variables of interest in a domain. A BN is a directed acyclic graph where nodes represent random variables. A lot of works on e.g. user modelling includes the use of BNs, as a method for evaluating, in a qualitative and quantitative manner, elements of the user behaviour and consequently updating the user profile.

Additionally, this component is responsible for updating the CPTs after the service execution by exploiting the user feedback.

This entity contributes to automated analysis and matching of user requirements for the dynamic creation and configuration of CVOs with the aim of providing smart, personalized services.

3.2.4. Service Request Analysis

This component is responsible for the selection of the optimal Service Template. This process is fulfilled either by exploiting the Maximum a Posteriori (MAP) inference algorithm and the user preferences of the Bayesian Networks or by selecting the Service Template with the greatest semantic similarity estimation. The first case is used when there is previous knowledge about the user request into the Bayesian Networks. Otherwise, the second case is used. The input to SRA has the format given by NLP and it consists of: (a) service request, (b) location, (c) user role and (d) user preferences. The user preferences are extracted via the User Preferences and Profiling component. The outcome of this process is a so called “Service Execution Request” that is used by Approximation and Reuse Opportunity Detector (AROD).

This entity contributes to automated analysis and matching of user requirements for the dynamic creation and configuration of CVOs with the aim of providing smart, personalized services.

(15)

Figure 3: NLP - SRA Process diagram 3.2.5. Service Template Repository

In this repository a collection of Service Templates, created by domain experts, is stored. This allows for the Dynamic CVO creation of a CVO.

A Service Template defines at a high-level the operations, dependencies, and intelligence needed for the automated deployment of a particular service/application. This includes the (generic) types of CVOs and VOs that will be required for realizing these operations and intelligence ([3]).

3.2.6. Real World Knowledge (RWK)

The RWK includes particular instantiations of a generic RWK model, which is used as the basis for the development of the RWK in a specific domain. The generic RWK model is depicted in Figure 4, while the Table 1 presents the description of the particular nodes that are included in the model. In general the model is comprised by different nodes that are considered as meta-data containers that include particular meta-data properties. Through the use of the meta-data properties, as well as the corresponding concepts, it is possible to structure a specific RWK model, which will be oriented to the Smart Home PoC. Consequently, by following the above approach, the RWK Model that is associated with the Smart Home PoC is depicted in Figure 5. The current model includes particular instantiations of the concepts that are included in the Smart Home PoC prototype, presenting them as instantiations of the Generic RWK Model concepts.

(16)

Figure 4: Generic RWK Model

RWK Model

Node Description

RWK Root Node The ‘RWK Root Node’ presents the root node of the iCore RWK Integrated Model that points to a domain specific RWK Model, such the Smart Home or the Smart Meeting RWK Model.

Domain The ‘Domain’ node presents the domain, on which the RWK model is referred and describes its concepts. Each domain can be described in terms of its type (e.g.: Smart Home, Smart meeting, etc), a name and a textual description in natural language.

Domain Parameter

Each domain may include one or more parameters, the ‘Domain Parameters’, which may describe domain specific concepts required for specific situations, such Date & Time, Indoor Location, Status of a process and/or situation, etc.

RW Concept The ‘RW Concept’ node can be used so as to present the potential Real World concepts that can be involved into a specific domain. In a general approach, it could be considered as the node that can describe the non-ICTs and

RWK Root Node hasURI :URI Domain hasURI :URI hasName :String hasType :URI hasDescription :String Domain Parameter hasURI :URI hasName :String hasFeatureType :URI hasFeatureValue :Literal Domain Service hasURI :URI hasName :String hasDesciption :String instantiates :URI RW Concept hasURI :URI hasName :String hasType :URI indicates hasRWConcept hasRWFeature hasDomainParameter hasDomainService RW Feature hasURI :URI hasName :String hasFeatureType :URI hasFeatureValue :Literal

(17)

Date: 09/05/2014 Grant Agreement number: 287708 Page 17 of 63 (potentially) the ICT objects, which are included in a specific domain (e.g. Smart Home:[Sensors & Actuators, Persons, Places, etc], Smart Meeting:[Places, Mobile Devices, QR Codes, etc]).

RW Feature The ‘RW Feature’ node works as assistant node to the ‘RW Concept’ node and it is considered as part of the RWK Model, in order to support the capability for further description of a RW concept, where it is required.

Domain Service The ‘Domain Service’ node presents a service as it is considered in iCore. Actually, it can describe either a domain specific or a generic (multi-applied/re-usable) service, which is developed under a specific concept so as to serve specific purposes. For instance, in the Smart Home PoC, a domain specific service refers to the Smart Health Monitoring, which actually can be re-used outside of the initial concept. The domain service it is described in terms of a URI as its unique identifier, a name and textual description in natural language, while it includes a link, as a URI, to the Service Template that has been used for its instantiation.

(18)

Figure 5: Smart Home RWK Model

Smart Environmental Monitoring<<Domain Service>>

+hasURI: URI +hasName: Stirng +hasDescription: String +instantiates: URI +MonitorEnvironmentalConditions() +AdjustEnvironmentalConditions()

Smart Health Monitoring<<Domain Service>>

+hasURI: URI +hasName: String +hasDescription: String +instantiates: URI +MonitorHealthStatus() +NotificationsOnHealthStatus() +RaiseAlarmInCaseOfEmergency() hasDomainService hasDomainService <Smart Home> +hasURI: URI +hasName: String +hasType: URI +hasDescription: String Home <<RW Concept>> hasRWConcept Actuator <<enumeration>> <<RWConcept>>+Heating System <<RWConcept>>+Airconditioning System <<RWConcept>>+Light <<RWConcept>>+Buzzer - Fire Alarm <<RWConcept>>+DoorLock Sensor <<enumeration>> <<RWConcept>>+Temperature Sensor <<RWConcept>>+Humidity Sensor <<RWConcept>>+Luminosity Sensor <<RWConcept>>+Accelerometer Sensor <<RWConcept>>+Move Detection Sensor <<RWConcept>>+Camera <<RWConcept>>+Body Pulse <<RWConcept>>+Body Temperature Outdoor Place <<enumeration>> <<RW Concept>>+Porch Room <<enumeration>> <<RW Concept>>+LivingRoom <<RW Concept>>+BedRoom <<RW Concept>>+BathRoom <<RW Concept>>+Kitchen consistsOf 1...* consistsOf 1..* hasRWConcept Control Feature <<RW Feature>> +hasURI: URI +hasName: String +hasFeatureType: URI +hasFeatureValue: Literal Sensing Feature <<RW Feature>> +hasURI: URI +hasName: String +hasFeatureType: URI +hasFeatureValue: Literal hasRWConcept hasRWFeature hasRWFeature Person <<RW Concept>> +personID: URI +personName: String hasRWConcept Person Feature <<enumeration>> +age :Integer +male :String

+role :String[ Elderly, Medical proffesional, Family Member ] +userPreferences :Literal

hasRWFeature

Smart Home Domain Parameter<<enumeration>>

<<DomainParameter>>+AreaOfInterest <<DomainParameter>>+Home GeoLocation hasDomainParameter uses 1...* uses 1...* monitors 1...1 monitors 1...* uses 1...* uses 1...*

(19)

Date: 09/05/2014 Grant Agreement number: 287708 Page 19 of 63 3.2.7. System Knowledge

In the Smart Home PoC, the System Knowledge (SK) is used for the dynamic selection of the most appropriate CVO Instance(s) that can fulfil a service request, by the corresponding CVO Management Unit functions. The SK is comprised by an information set that is associated with the CVO instance and presents various features. Further to that, a generic System Knowledge model has been developed and depicted in Figure 6, while the description of its particular nodes is provided in the Table 2. Similarly with RWK Model, the SK model is used so as to define a specific instantiation of the System Knowledge in the context of the Smart Home PoC prototype.

Figure 6: Generic SK Model

SK Model Node Description

SK Root Node The ‘SK Root Node’ presents the root node of the iCore SK Integrated Model that points to a domain specific SK Model, such the Smart Home or the Smart Meeting SK Model.

System Process The ‘Service Node’ node presents a service, which is executing in the system by consuming system capabilities. In particular, this service includes and is realized by a set of different system component that can be classified either as VOs or CVOs.

System Concept The ‘System Concept’ node can represent a wide variety of different system components that actually in our system, namely in the iCore platform could be summarized by their classification into VOs and CVOs. Since there will be an association with specific VOs and CVOs it will be possible to include system

SK Root Node hasURI :URI indicates System Process hasURI :URI hasName :String hasDescription :String System Resource hasURI :URI hasName :String hasFeatureType :URI hasFeatureValue :Literal includes consumes System Concept hasURI :URI hasName :String hasDescription :String

System Concept Feature hasURI :URI

hasName :String hasFeatureType :URI hasFeatureValue :Literal

(20)

Date: 09/05/2014 Grant Agreement number: 287708 Page 20 of 63 parameters that are associated with the (C)VOs.

System Concept Feature

The ‘System Concept Feature’ node is capable to present any specific feature / characteristic that is associated with a particular System concept. For instance, in case we have as a System Concept a VO, then the System Concept Feature node can be used so as to represent a set of different VO Parameters, etc.

System Resource The node ‘System Resource’ presents any system resource in terms of CPU, RAM, etc that is consumed during the execution of a System Concept. For instance, whether a CVO/VO is executed, it uses a set of different resources on the system that hosts it. Consequently, through this node it is possible to present such concepts.

Table 2: Generic SK Model - description of concepts

Moreover, Figure 7 presents a specific instance of the SK model for the Smart Home PoC that is implemented based on the generic SK model. As it can be observed, the particular SK model includes concepts such the CVO Parameters, the System Resources that are used, the System Concepts that are involved in the CVO, etc.

(21)

Figure 7: Smart Home SK Model

Smart Home Process

<<System Process>>

CVO Smart Home

<<System Concept>>

VO Heating System

<<System Concept>>

VO Temperature - Humidity DHT11 Sensor<<System Concept>>

VO Luminosity Sensor<<System Concept>> <<System Concept>>VO Camera

VO Body Temperature Sensor<<System Concept>> VO Airconditioning System<<System Concept>>

VO Move Detection Sensor<<System Concept>> VO Body Pulse Sensor<<System Concept>> VO Accelerometer Sensor<<System Concept>>

VitrualObject +hasURI: URI +hasStatus: String +hasType: URI CompositeVO +hasURI: URI +hasStatus: String +CVOOperation_1() +CVOOperation_2() +CVOOperation_n() implements implements implements implements implements implements implements implements VO Light <<System Concept>> implements +isComprisedBy 1..*

System Concept Feature

CVOSituationParameter +hasURI: URI +hasName: String +hasFeatureType: URI +hasFeatureValue: Literal CVORequestParameter +hasURI: URI +hasName: String +hasFeatureType: URI +hasFeatureValue: Literal +hasRequestParameter 1..* +hasSituationParameter 1..* Situation Parameter <<enumeration>> <<CVOSituationParameter>>+Area <<CVOSituationParameter>>+Time <<CVOSituationParameter>>+Available VOs Request Parameter <<enumeration>> <<CVORequestParameter>>+Policies <<CVORequestParameter>>+VO Functions implements implements implements System Concept +includes 1..* System Resource +consumes 1..* CPU <<System Resource>> RAM <<System Resource>> +hasConcepttFeature 1..*

(22)

Date: 09/05/2014 Grant Agreement number: 287708 Page 22 of 63 3.2.8. CVO Management Unit: Approximation and Reuse Opportunity Detection (AROD)

This component comprises the following tasks: (a) exploiting the information stored in the CVO Registry, (b) identifying past service requests that match closely enough the present incoming ones and the situations under which they were issued and (c) matching requested VO functions to approximate ones (in case the requested ones are not available) whenever possible. In this manner, the CVOs can be re-used and the task of CVO composition from scratch can be avoided under certain circumstances ([3]).

As per the identification and comparison of past and present situations and requests a set of parameters has been defined:

The situation parameters which consist of the time of day the request occurred, the area of interest (location), and the available VOs at that time

The request parameters that consist of the set of functions requested and corresponding related features to be maximized or minimized

Additionally, AROD will attempt, in the case the requested VO function(s) does not exist, find an approximate match that can, even partially, satisfy the request. To achieve this, a correlation matrix is used.

The use of the AROD component results in faster response times, better overall performance, higher reusability, smaller resource usage as well as higher stability.

3.2.9. CVO Registry

The CVO Registry component has been implemented by using openRDF Sesame API and Apache Jena API. It is implemented as an RDF Memory based Graph database, while it is complemented by a customized Java API (CVO Registry API), which supports the communication capabilities and the performance of actions against the CVO Registry. The Sesame API has been used for the development of the Graph Database as a Semantic Repository, whole the Apache Jena API for the development of the CVO Registry Endpoint that allows the performance of SPARQL Requests on RDF data. In the Smart Home PoC, the CVO Registry is used in order to store the created CVOs as well as to enable the direct instantiations of existing CVOs. The description of CVOs is supported by the CVO Model that includes the CVO Semantics that is stored in the CVO Registry as RDF data.

Figure 8: CVO Registry GUI - an indicative instance 3.2.10. CVO Management Unit: CVO Composition Engine (CCE)

This component is responsible for evaluating the virtual counterparts of real world objects, i.e. VOs and finding the most suitable composition of VOs that fulfils the service requirements (requested VO types, policies). Exploiting a heuristic algorithm, it achieves optimal compositions of VOs in minimum time. In addition, it allows the approximation of functions of VOs, in order to guarantee service provisioning. The CCE mechanism exploits a custom heuristic algorithm and is developed as a RESTful web service. Data is XML-formatted/encoded.

(23)

Figure 9: CVO Composition Engine 3.2.11. CVO Management Unit: CVO Dynamic Workflow (Planner)

This component is responsible for deciding the logical connection of the selected VOs. In particular, it provides a graph that describes how input/outputs of VOs are linked, in order to finally achieve a specific goal. Exploiting a well-known algorithm, namely Graphplan (open-source JAVA implementation), it achieves maximum performance in minimum time, enabling the dynamic composition of multiple, diverse VOs into one CVO. The Planner is developed as a RESTful web service. Data is XML-formatted/encoded.

(24)

Date: 09/05/2014 Grant Agreement number: 287708 Page 24 of 63 3.2.12. CVO Management Unit: CVO Coordination

The coordination component aims to support the coordination and E2E optimization process of the available CVOs in the CVO Level. In particular, the CVO Coordination process enables the dynamic management of the simultaneous access to and use of available CVOs from other entities, such as other CVOs. Specifically, the CVO Coordination component observes the use of available running CVOs by other entities and based on specific semantic priority indicators combined with the current situation, decides on the sequence for the use of the CVO from each extern entity.

Consequently, when more than one entity is simultaneously using and/or accessing the same CVO, this is monitored by the CVO Coordination entity, which collects the available information with respect to the current situation, as well as the semantic priority indicators for each entity, aiming to derive a priority list for the CVO use. In this way the best possible management of the concurrently running, inter-related CVOs is achieved, in terms of the avoidance of potential conflicts arising from their simultaneous access and use by other entities.

In general the specifications of the CVO Coordination are described below. Breaking the process in different phases, in the first phase we have the detection of a conflict caused by more than one incoming requests for access and use to a particular CVO. In the second phase the Coordination component, collects information about the CVOs that try to use the monitored CVO and notifies the CVO that is under coordination. The information includes the identifiers of the CVOs (CVO IDs) that performed the conflicted requests. Having the CVO IDs, in the third phase, the Coordination interacts with the CVO Registry so as to acquire the semantic priority indicators. Since the indicators have been acquired, the Coordination component performs data computation so as to calculate a priority rank for each CVO. Finally, a specific priority list is constructed and sent back to the CVO, phases 4 and 5 respectively, through a Conflict Resolution Response, so as to manipulate fairly the access of the external CVOs.

An example in the Smart Home PoC, constitutes the demonstration presented regarding the smart city domain where there are two different CVOs, the Smart Home CVO and the Smart Car CVO that try to access and use simultaneously the Smart Traffic Light CVO. The CVO Coordination component that is running in the background, detects the access requests conflict and it takes over to resolve the conflict, by giving priority to the Smart Home CVO. An indicative example regarding the use of the CVO Coordination in the Smart Home PoC for example (Figure 11) when movement is detected a command is sent to the Smart Traffic Light CVO that a pedestrian needs to cross the road. The Traffic Light CVO however is also getting a command that a car wants to cross. Since it cannot resolve this conflict the data is sent to the CVO Coordination which is responsible for making the decision. This component aims to create a priority list for the CVOs to use whenever there is a conflict between them. To achieve this, semantic priority indicators are used in combination with the current situation. It aims the best possible management of concurrently running, inter-related CVOs, in terms of the avoidance of potential conflicts arising from their simultaneous access and use by other entities. The latter constitutes the real added value of this component, since it comes as a solution for resource management in the IoT, and consequently leading to the improvement of IoT systems performance.

(25)

Figure 11: CVO Coordination GUI 3.2.13. VO Registry

The VO registry includes information about VOs that are available in the system. Various entities that are available in the framework can interact with the VO registry so as to perform semantic-based discovery and selection of VOs, as well as to retrieve and/or modify the corresponding information. The innovation of this component corresponds to the ability of the integration of existing ontologies in an abstract way, giving the ability to develop generic descriptions for the VOs, without the need to link with specific – predefined ontologies.

The VO Registry is implemented as a Semantic Repository that stores structured data with its meta-data in a form of Graph Data Models. For the development of the Graph Models, the RDF specifications are used, while the instantiated models are stored into RDF Databases (DBs), which constitute one of the sorts of the Semantic Repositories. For the implementation of the RDF DBs the openRDF Sesame Java API is used that provides both a Web Server to host the RDF DBs, as well as a well defined API to support the management of the repositories and their stored data. Further to that, the VO Registry is accessible over HTTP and it is hosted on the Sesame Web Server. Each RDF DB has its own SPARQL endpoint through which the end users (either human or software agents) can access VO data. A SPARQL endpoint is accessible over the internet by using a specific URI. Additionally, a cURL API that supports the interfacing between VO Registry and third party entities, has been developed, allowing requests and responses in XML and JSON formats.

Alternatively, a VO registry can be implemented using the commercial Xively service (https://xively.com/). This option is explained in details in iCore d6.1 in Sections 3.2.2. and 3.2.5. Xively, however, is not as powerful and multifunctional a registry as the iCore one.

It is worth noting that sensors used on hardware platforms generate raw data, i.e. measurement values without any context information. Data transformation chain raw data – RDF document is described in details in iCore D6.1 in Section 3.2.3.

The innovation of this component corresponds to the ability of the integration of existing ontologies in an abstract way, giving the ability to develop generic descriptions for the VOs, without the need to link with specific – predefined ontologies.

(26)

Figure 12: VO Registry GUI 3.2.14. VO Template Repository

This entity holds a collection of VO Templates. A VO Template can be used to create a particular VO and provides a generic structure for the semi-automatic implementation of various VO types. In the Smart Home PoC it has been used the GitHub API to support the development of the Software repository that will store the VO Template Software packages. In this case, the end-user, having the URI of a specific VO Template can send a request to access the repository and download the corresponding software packages. Since VO Software module is developed, by using the VO Template, it can be deployed to the VO container so as to start its execution. The required methods for the interaction between external entities and the repository will be included in the VO API. 3.2.15. VO Container

This component is the “middle-man” for connections to the Arduino/WaspMote/Flyport platform. It is the execution environment in which the VOs run and it’s designed for ease of use and it can allow a CVO to receive data from multiple Arduino platforms using a single IP.

The VOs can be deployed in the VO container through a user friendly GUI that allows the user to import and upload the VO in the cloud, so as to be accessible remotely, under a specific URI.

The VO Container component supports the dynamic deployment of java-based software directly in the cloud and its wrap-up under a Web Service Endpoint so as to be accessible by external users. 3.2.16. VO Factory (VO Creation Tool)

The VO Creation Tool constitutes a powerful tool that includes creation and registration mechanisms so as to allow the end-use to perform the creation and the registration of the VOs in an easy way. In addition the tool allows the user to manipulate the VO related data stored in the VO Template Repositories and the VO Registries. Figure 13, presents the overview of the VO Creation Tool functionality in a high-level approach. In particular, the tool offers a user friendly Graphical User Interface (GUI) that helps the end-user to add the description of VOs in a traditional way by completing data forms. The background functionality of the VO Creation Tool takes over the dynamic and automatic transformation of the information into meta-data properties, based on the VO Model, constructing thus the VO Semantics that in turn is stored in the VO Registry. In order

(27)

Date: 09/05/2014 Grant Agreement number: 287708 Page 27 of 63 somebody to use the VO Creation Tool, should have specific credentials that are associated with a specific user role and a specific unique API-Key. Depending on the user role, the end user has different and diverse rights in the system. Moreover, the system uses the API-Key so as to enable various algorithmic functionalities for the performance of different action in the system such the VO Registration.

Figure 13: VO Creation Tool and associated processes

The added value of the VO Creation tool corresponds to the advantage given by the Web-based GUI that allows the users to create in an easy way the description of their VOs, without the need to have IT knowledge or any skill for programming.

3.2.17. VO Front-End Software and Back-End REST Modules

The exploitation of the REST architecture principles constitutes the key concept for the implementation of the development of the VO Front-End (FE) and the VO Back-End (BE) in the Smart Home PoC. The VO FE corresponds to the part that is responsible for the communication between VO – CVO and the VO BE is the responsible part for the realization of the communication between VO - ICT. An indicative diagram of what is described above, is depicted in Figure 14. The figure is a simplification as it omits the VO FE interfaces to the VO management unit (and thus the cognitive management functionality). The VOs as SW agents is developed as Web Resources implemented as Web Services accessible over the Internet using REST protocol. By the development of an abstract communication interface for the VO FE it is allowed the accessibility of VOs by various and diverse entities, overcoming the technological heterogeneity.

In particular, the VO FE can be developed as one or a set of RESTful Web Services that implements specific functionalities of the VO, such as to provide the measurement data of a sensing process, to retrieve information about VO features, etc. Using a top-level URI that will constitute both the

(28)

Date: 09/05/2014 Grant Agreement number: 287708 Page 28 of 63 identifier for the VO, as well as the pointer of the VO as Web Resource that is available in the Internet, it is possible to provide access to external entities which wish to use the VO and its functionalities.

Figure 14: VO FE & VO BE

Through the exploitation of the information that is available in the VO registry, an external entity can be aware about the top-level VO URI, as well as about additional information regarding its provided functionalities features, etc. Specifically, the data that is associated with the VO are able to describe the VO as a SW entity, giving specific information about how the VO functions can be accessed (lower-level URIs – VO function URI) and consumed, which parameters and data-types are required by a function, which are function’s output results, etc. Consequently, an external entity can communicate with the VO FE, using the URIs that are associated with the VO and its functions. Under each URI different methods of the VO RESTful WS are implemented and executed in order to provide specific functionality to their consumers, while the instantiation of the VO Information Model, which correspond to this VO provides data for the description of RESTful WS.

On the other hand the VO BE exists in Arduino gateway that is used in the Smart Home PoC. Its purpose is to provide access to the functionalities provided by the ICT Objects connected on the Arduino platform.

3.2.18. VO Back-End Software REST Module for wireless sensor networks

The VO Back-End Software REST Module for wireless sensor networks handles functionalities and access of ICT objects connected through standardized and proprietary wireless sensor actor networks (WSAN) like ZigBee, LightweightMesh (LWMesh) and ZIGPOS eeRTLS systems.

3.2.19. Correlation Matrix

This component has been implemented as a RESTful web service. It provides correlations between various VO functions as well as the ability to manage them. More specifically, each correlation is a decimal number from 0.0 to 1.0 representing the satisfaction of one function towards another (e.g. “video” can fully satisfy “image” so the correlation between them is 1.0). The correlations are stored within a mysql database.

3.2.20. Security Agent

The Security Agent component is a RESTful web service and it has been implemented in order to ensure security in the VO level. Specifically, when a user is registered in the iCore System he is given

ICT Object

VO

Registry

VO URI

Front-end

Back-end

VO CVO

(29)

Date: 09/05/2014 Grant Agreement number: 287708 Page 29 of 63 certain “roles” (indicatively: VO_OWNER, SIMPLE_USER, PREMIUM_USER) that represent his access rights. The user roles are stored using a MYSQL database. These roles are then passed on to the VO Registry component whenever he issues a request. The VO Registry then checks, by means of the Security Agent, whether or not the user has access to each VO he requests.

This component therefore contributes to the overall security of iCore. 3.2.21. Smart Home CVO

This CVO implements the Smart Home Functionality. That includes automated temperature, lighting adjustment and automated alerting of medical centre as well as a self-healing feature to replace broken sensors.

Figure 15: CVO Desktop Interface 3.2.22. Smart Car CVO

In this CVO basic automated driving functionality is implemented. This is mainly used in conjunction with the Smart Traffic Light CVO to showcase the coordination mechanism.

(30)

Figure 16: Smart Car CVO 3.2.23. Smart Traffic Light CVO

This CVO is designed to be the controller of an automated traffic light in a Smart City. In the Smart Home context this CVO is used long with the Smart Car to showcase the coordination mechanism.

(31)

Figure 17: Smart Traffic Light CVO 3.2.24. Smart Lighting CVO – (iCore – BUTLER Integration)

The Smart Lighting CVO is a web-based application that is responsible for the sensing of ambient luminosity values, by using the corresponding VO, as well as the real time location of a human user who is moving around in a place, such as a room of a smart home. The CVO gets the above three measurement values and by using a specific formula, which constitutes its service logic, force decisions regarding the control of light that is available in the place where the user is moving. In particular, the end-user can provide its preferences regarding the light intensity in the room, as well as regarding the distance in which the light should be turned on, since the user is close to the light. The light is turned on if the user is going closer to it than the preferred distance and if the light intensity is lower than the current one that is measured. The CVO has been developed by using responsive website technology and therefore it is available either by PC or by Smart Mobile devices (Smart Phones Tablets, etc), just by using a web browser.

(32)

Figure 18: Smart Lighting CVO

3.3

Hardware

3.3.1. Arduino

For the interconnection of sensors-actuators in the Smart Home PoC the Arduino platform is used (Figure 19).

(33)

Date: 09/05/2014 Grant Agreement number: 287708 Page 33 of 63 3.3.2. Sensors– Actuators

For the demonstration of the Smart Home PoC features a number of sensors and actuators are used through multiple available hardware platforms (Arduino, WaspMote, RaspberryPi, Flyport etc…):

Motion Sensor Light Sensors Temperature-Humidity Sensor Accelerometer Sensor LED Lights Fan

Heater (an LED lamp inside a casing) Buzzer

PowerPlug

(34)

Figure 22: Accerelometer, eeRTLS device Figure 23: Temperature/Humidity sensor

Figure 24: Wireless Lamp Figure 25: Light Sensor

Various available sensors/actuators are distributed on several hardware platforms to demonstrate hardware independency of iCore architecture through use of VO representing ICT objects.

3.3.3. WaspMote

In contrast to Arduino platform with an Ethernet shield, we use WaspMote platform which enables wireless communication. WaspMote, similarly to Arduino, is capable of sensing temperature, humidity and light. However, its wireless connectivity allows Sarah to perform local monitoring of house conditions due to easy platform deployment which is free from connectivity and cabling that might cause some difficulties for her. Another reason to use different hardware platform with somewhat alike functionality is to address heterogeneity problem.

(35)

Figure 26: WaspMote platform with sensors

WaspMote platform can be easily adapted to a number of smart home applications by substituting an expansion board located on top of ‘mother board’. This is the main difference between Arduino where a user can add/remove single sensors/actuators and WaspMote where a user can connect the entire application specific board with all associated components at once.

3.3.4. Flyport

In contrast to Arduino and WaspMote platforms which focus on sensing and actuation of the house environmental conditions, FlyportIoT platform puts main emphasis on the monitoring of elderly people, i.e. Sarah, health status and house security.

The core element of the platform is a PIC microcontroller (MCU) by Microchip. Communication capability is realized by WiFi module by Microchip. Wireless communication makes Flyport easy for deployment platform, so that elderly persons can easily change their location without cabling. In our Smart Home use case we adapt Flyport for two scenarios:

Medical: monitoring of body temperature, pressure, and heart rate; in the case when of

monitored parameters exceeds a threshold the platform has actuation capabilities for local (visual and sound alarm) and remote (medical center notification via the Internet and WiFi) alarming.

Security: monitoring of gas leakage in the Sarah’s kitchen and door locking using fingerprint

sensor – this solution is especially convenient for elderly people and helps them to avoid undesirable situations when they lose an entrance key; similar to medical scenario Flyport performs local and remote notifications in the case of abnormality.

Humidity _Light Temperature Wireless connectivity Power supply

(36)

Figure 27: FlyportIoT platform

3.3.5. Raspberry Pi

The RaspberryPi is a credit-card-sized single board computer that gains a lot of interest in communities that use it mainly for development and teaching of basic computer science. Next to many GPIO´s that can be used to connect sensors and actuators it comes with Broadcom system on chip (SoC), which allow the use of various Linux distributions. ZIGPOS developed an IEEE802.15.4 (ZigBee) bridge that can be plugged on the Raspberry Pi.

In our Smart home use case the Raspberry Pi has been adapted with integrated IEEE802.15.4 device to act as a gateway for wireless sensor networks. ICT object associated in standardized networks (e.g. ZigBee, LWMesh) are automatically associated to the Gateway. Software components implement the VO Back-End Software REST Module for wireless sensor networks connecting automatically to the VO Registry.

Wi-Fi module

(37)

Figure 28: Raspberry Pi without case

Figure 29: Software architecture combining WSN to iCore system 3.3.6. Android Tablet

An android tablet is used to showcase the mobile app for the Smart Home CVO (Figure 30). The technical specifications of this tablet are:

Ram: 1 GB

(38)

Date: 09/05/2014 Grant Agreement number: 287708 Page 38 of 63 Screen: 10.1", 1024 x 600 pixels

Storage: 8 GB

Android version: 4.1 “Jelly Bean”

Figure 30: Android Tablet

3.3.7. Android Phone

For the demonstration of the mobile app for the Smart Home CVO an android phone is used (Figure 31). The technical specifications of this phone are:

Ram: 512 MB

Processor: 1 GHz single core Screen: 3.7", 480 x 800 pixels Storage: 4 GB

(39)

(40)

4 Demonstration scenarios

4.1

Dynamic CVO Creation

4.1.1. Scenario description

In this scenario the user has asked for a CVO that will check on the health of “Sarah”, the elderly inhabitant of the house in the Smart Home PoC, and that will be able to control the conditions of the room. The user is also able to pick between three devices to instantiate the CVO on (tablet, PC, phone). Furthermore, the user is given a choice of policies (i.e. Low Expenditure, High Quality, etc) and an area (the house in this case) to select where to search for available VOs. The process is better shown on the figure below.

4.1.2. Interactions between components

Initially the user selects the area of interest to him and clicks “Fetch Functions”. The Service Requestor GUI then sends a VO discovery request to the VO Registry so as to display the available VO functions in the area to the user. Afterwards, the user selects the device the CVO will be instantiated in, any policies he wishes (i.e. Low Expenditure, High Quality) and types a request in natural language to be sent to the NLP component (Natural Language Processing) which will, in turn, send an acknowledgement to the SR GUI and then perform a lexicological analysis on the request. The NLP component will then forward the analysed data to SRA (Service Request Analysis) which will select the optimal service template and forward it to the AROD component. At this point AROD will search for and return to SR GUI the VO functions that will be used in the CVO. The user can now inspect the VO functions that will be used and, if he chooses to continue, forward the completed request to AROD. The AROD component will then check for existing CVO instances that can fulfil the

(41)

Date: 09/05/2014 Grant Agreement number: 287708 Page 41 of 63 requested parameters. For this process the CVO Registry will be queried and the results (if any) will be checked one by one for compatibility with the current request and situation parameters. If a compatible enough result is found then that CVO will be re-instantiated [3.2], otherwise a request will be made to the CVO Composition Engine (CCE). The CCE component is responsible for finding the optimal configuration of VOs for the service that has been requested. When that has happened the CCE will send the configuration to the CVO Dynamic Workflow component (Planner) so that a scheme can be made concerning the communication and connection of the VOs. The Planner at this point will save the CVO composition to the CVO Registry and then initiate it.

4.2

Knowledge-based Instantiation

4.2.1. Scenario description

In this scenario a user requests, once more, a service as described in the Dynamic CVO creation scenario. In this case a CVO that can fulfil the requested service already exists in the CVO Registry. 4.2.2. Interactions between components

The process described in the Dynamic CVO creation is repeated as is until the AROD component is reached. That is, the user needs to select an area of interest, request a service from NLP and receive a set of VO functions. Afterwards the data are once more sent to the AROD component. AROD in this case will detect the previous CVO and initiate it once again without the need of going through the CCE and Planner components that are responsible for a large portion of the CVO creation time.

4.3

CVO Self-Healing

4.3.1. Scenario description

A light sensor in the Smart Home CVO is damaged and sending false readings. 4.3.2. Interactions between components

When the light sensor is detected as damaged (or when it is removed for demonstration purposes) the CVO will initially display a message with the information. It will then move on to send a replacement request to the AROD component which will in turn make the specific VO appear as “Unavailable” (since it is damaged) in the VO Registry and forward the information to the CCE component. The CVO Composition Engine will then look for an available VO (in the area that had been specified for the CVO creation) and assuming it finds one it will change the composition of the CVO that is saved in the CVO Registry and forward the information to AROD. AROD will then send the new sensor information to the CVO and, finally, the CVO will display a message that the process has been completed and start taking readings from the new sensor.

4.4

CVO Coordination

4.4.1. Scenario description

The Smart Home CVO, Traffic Light CVO, iCore Car CVO and the Coordination mechanism are active. Sarah, the inhabitant, tries to cross the road while traffic is inbound.

(42)

Figure 33: CVO Coordination Process 4.4.2. Interactions between components

When Sarah leaves the house a motion sensor will pick up her movement. The Smart Home CVO will then activate the porch light so she can see and also send a request to the Traffic Light CVO to stop any cars trying to pass. Meanwhile the iCore Car CVO is constantly sending requests to the Traffic Light to get a green light. That means that when Sarah tries to cross the street the Traffic Light will have received two requests that it cannot resolve at the same time. To solve this conflict the Traffic Light CVO will forward the information to the Coordination mechanism. The coordination mechanism then decides (through “weight” data that exists for each entity – car, human) which of the two requests has priority over the other. In this case Sarah has priority over the car so the Coordination mechanism sends the decision to the Traffic Light which will then turn green for pedestrians and red for cars.

4.5

iCore – BUTLER Integration

4.5.1. Scenario Description

This scenario is used for showing abilities to use cross communications between two different IoT based platforms named i-Core and BUTLER to fulfil requested services using advantages of both platforms. Here Sarah wants to automate the light control based on her preferred conditions and location inside her environment. Therefore, she requests a service able to check light intensity conditions and setting light via actuators inside her environment. In detail, the lights will be controlled and turned on, if the current light intensity is below her preferred threshold and if she is nearby the light itself. Otherwise the light will stay off for the purpose of energy saving.

4.5.2. Interaction between components

In this Demonstrator a BUTLER- system is running providing location based context from a BUTLER compliant Smart Server. Therefore an RTLS-system is connected to the Smart Gateway providing the BUTLER system location information of a mobile node connected to Sarah. In the BUTLER system a Smart Server is able to retrieve information from any associated ICT object through the Smart Gateway and use/forward it to other modules/components. This Smart Server is able to associate to an iCore architecture using the VO-registry method and register itself as a VO able to provide location based context to the system.

Smart Home CVO

Smart Traffic Light CVO Smart Car CVO CVO Management Unit Coordination Mechanism

Request for ‘Green Light’

Requests ‘Green Light’

Conflicting requests – Sends request for conflict resolution

Conflict Resolution Request

Resolves the conflict and sends the corresponding

decisions Decisions on Traffic Light management Response on ‘Green Light’ request

(43)

Date: 09/05/2014 Grant Agreement number: 287708 Page 43 of 63 The VO discovery request to the VO Registry results in the available VO functions that are in particular light actuators, light intensity sensors and location information VO. When the luminosity sensor recognize a value below the threshold the Smart Home CVO will then request the actual position of Sarah and compare it to the position of the light of interest. If the location matches the location of the lamp actuators the CVO will request the Lamp to turn on. Also, if the lamp is turned on and the Smart Home CVO recognizes that Sarah has left the Position and is out of scope of the lamp, it will request the device to turn off in order to save energy.

Figure 34: Integration architecture

4.6

Performance Results

This section presents some indicative results on the performance of the implemented cognitive management framework (as has already been written [3]) in terms of the time required and the bytes exchanged for the various entities of the framework to accomplish their task, including the time for the CVO instantiation. It should be noted that the presented results are mainly related to the Dynamic CVO Creation and Knowledge-based CVO instantiation processes as these are the most demanding among the four processes described in the previous section.

4.6.1. Prototype Implementation

A prototype of the proposed cognitive management framework has been implemented. The current corresponding implementation comprises, apart from software components for the various functional components presented in the previous chapter, a number of actual sensors and actuators. In terms of hardware aspects of the equipment that was used for the experiments, the NLP and SRA mechanisms, as well as the Service Template Repository were executed on a PC with:

CPU: Intel(R) Core(TM) i7-3632QM at 2.20GHz memory (RAM): 8.00 GB

In addition, the AROD and CCE mechanisms, as well as the CVO Registry were hosted on a PC with: CPU: Intel(R) Core(TM) i7-2630QM at 2.00GHz

(44)

Date: 09/05/2014 Grant Agreement number: 287708 Page 44 of 63 memory (RAM): 4.00 GB

The VO Registry was hosted in a server machine with: CPU: Intel(R) Xeon(R) E5520 at 2.27GHz memory (RAM): 16.0GB

The RWOs that were used and represented as VOs consisted of different types of sensors and actuators, such as temperature, humidity, luminosity sensors, lamps, fans, etc. Finally, the communication between the different machines was performed over a LAN and each machine was connected via Wi-Fi on a wireless network router.

4.6.2. Service level mechanisms performance

Figure 35, presents results on the performance of Service level mechanisms with and without prior knowledge about a given user request. In the case that no prior knowledge is available all available Service Templates have to be searched in order to select the most appropriate one and derive corresponding VO and CVO information. Thus, this approach is dominated by the amount of available Service Templates and the amount of nodes comprised in each of the Service Templates. Actually, the complexity of the Service template selection process is:

( )

which means that, as the amount of the Service Templates (i.e. w) and the amount of nodes (i.e. n) of each Service Template increase, the execution time increases too. In the case of available knowledge on a particular user request, Bayesian statistics are exploited for the derivation of the optimal Service Template, thus eliminating the need of looking into each node of each Service Template. Therefore, the overall process of selecting the most appropriate service template in this case depends only on the number of Service Templates. So, the complexity of this selection process is:

( )

As can be observed in Figure 35, when prior knowledge is available less than half the time is required for processing a user request by the Service level mechanisms. Generally, the goal of automated users’ requirements analysis and matching for the dynamic creation and configuration of CVOs with the aim of providing smart, personalized services through the selection of the most appropriate Service Template is fulfilled in a realistic time-frame considering that the Service level mechanisms execution take place during an initial, design-time phase. At this point it should be highlighted that the two lines on the diagram, will never intersect each other, since they have totally different increasing rate in proportion of the increasing number of available Service Templates. Further optimization of the Service level mechanisms execution, is scheduled for future work.

(45)

Figure 35: Service Level execution time vs. Number of Available Service Templates

4.6.3. CVO and VO level mechanisms performance

This sub-section focuses on results related to the performance of CVO and VO level mechanisms and processes. In particular, the time required for the execution of the AROD and the CCE entities as well as the VO discovery processes is presented. More specifically, results for eight different cases of the number of available VOs that could possibly be part of the created CVO are presented. In addition impact of the diversity of the structure/nature of each VO in terms of its representation data is investigated. The eight different cases correspond to increasing numbers of the available VOs ranging from 10 up to 80 and the diversity of the amount of information that correspond to each VO. The information for each VO is represented as a meta-data graph, which has a specific size, depending on the VO features. The graph includes associated meta-data containers with specific meta-data properties and each container corresponds to a specific VO feature, such as the VO functions, function inputs, outputs, etc. Each graph has its own size that is expressed in terms of the number of statements, where each statement represents a meta-data property. It should be noted that some of the VOs were emulated, i.e. did not correspond to the actual RWOs, while in each case, the average number of statements was between 130 and 150 statements per VO. The diversity of the VO information size and the different number of VOs, affect the overall execution time of the related processes in a linear increase of time. The experiments have been repeated five times for each case. Although the outcomes were quite similar in each case, the provided results

icore Internet Connected Objects for Reconfigurable Ecosystem

iCore

VTT, TNO

www.iot-icore.eu

Contributors

First Name Last Name Affiliation Email

Table of Contents

1 List of Acronyms and Abbreviations ... 10

4 Demonstration scenarios ... 40

5 Specification of interfaces ... 52

6 Conclusion ... 62 7 References ... 63

List of Figures

List of Tables

Acronym Definition

2 Introduction

3 Proof-of -concept prototype environment

Components

3.2.1. Service Requestor GUI

Figure 1: Step 1 of the request process

3.2.3. User Preferences and Profiling

3.2.4. Service Request Analysis

3.2.6. Real World Knowledge (RWK)

RWK Model

Figure 5: Smart Home RWK Model

Figure 6: Generic SK Model

Table 2: Generic SK Model - description of concepts

CVO Smart Home

System Concept Feature

3.2.9. CVO Registry

Figure 9: CVO Composition Engine 3.2.11. CVO Management Unit: CVO Dynamic Workflow (Planner)

Figure 11: CVO Coordination GUI 3.2.13. VO Registry

Figure 12: VO Registry GUI 3.2.14. VO Template Repository

Figure 13: VO Creation Tool and associated processes

Figure 14: VO FE & VO BE

3.2.19. Correlation Matrix

Registry

Figure 15: CVO Desktop Interface 3.2.22. Smart Car CVO

Figure 17: Smart Traffic Light CVO 3.2.24. Smart Lighting CVO – (iCore – BUTLER Integration)

Hardware

3.3.1. Arduino

Figure 22: Accerelometer, eeRTLS device Figure 23: Temperature/Humidity sensor

Figure 26: WaspMote platform with sensors

Figure 27: FlyportIoT platform

Figure 28: Raspberry Pi without case

Figure 30: Android Tablet

4 Demonstration scenarios

4.1.1. Scenario description

Knowledge-based Instantiation

4.2.1. Scenario description

CVO Self-Healing

4.3.1. Scenario description

CVO Coordination

4.4.1. Scenario description

iCore – BUTLER Integration

4.5.1. Scenario Description

Figure 34: Integration architecture

Performance Results

4.6.1. Prototype Implementation

4.6.2. Service level mechanisms performance

Figure 35: Service Level execution time vs. Number of Available Service Templates