649849 ENTROPY Design of an Innovative Energy-Aware IT ......18/05/2017 – v1.0 Page 3 of 32 Executive Summary The vision of the ENTROPY project is to design and deploy an innovative

ENTROPY Consortium

Title: Document Version:

D1.4. Entropy Reference Architecture 1.0

Project Number: Project Acronym: Project Title:

649849 ENTROPY Design of an Innovative Energy-Aware IT Ecosystem for Motivating

Behavioural Changes Towards the Adoption of Energy Efficient Lifestyles

Contractual Delivery Date: Actual Delivery Date: Deliverable Type* - Security**:

01/06/2016 31/05/2016 R – PU * Type: P – Prototype, R – Report, D – Demonstrator, O – Other

** Security Class: PU- Public, PP – Restricted to other programme participants (including the Commission), RE – Restricted to a group

defined by the consortium (including the Commission), CO – Confidential, only for members of the consortium (including the Commission)

Responsible and Editor/Author: Organization: Contributing WP:

UBITECH WP1

Authors (organizations):

Anastasios Zafeiropoulos, Eleni Fotopoulou, Paris Liapis (UBITECH)

Keywords:

Technical, requirements, Semantic Web Technologies, Reasoning, Gamification, Data Aggregation,

IoT

Abstract:

Documentation of the overall Reference Architecture describing the main components of ENTROPY,

their functionalities and the defined communication interfaces.

649849 ENTROPY D1.4 ENTROPY Reference Architecture

18/05/2017 – v1.0 Page 2 of 32

Revision History

The following table describes the main changes done in the document since created.

Revision Date Description Author (Organization)

V 0.1 25/04/2016 Table of Contents and First version of the document Anastasios Zafeiropoulos, Eleni

Fotopoulou, Paris Liapis,

Thanassis Bouras (UBITECH)

V 0.2 05/05/2016 Contribution to Section 2 Stavros Lounis, Cleopatra

Bardaki (AUEBLTRN), Maja

Pokric (DNET), Antonio

Skarmeta, Fernando Terroso-

Saenz (UMU), Umutcan

Simsek, Anna Fensel (UIBK),

Anastasios Zafeiropoulos, Eleni


Thanassis Bouras (UBITECH),

Angeliki Bousiou, Vassilis

Nikolopoulos (INTELEN),

Norma Zanetti (HYPER)

V 0.3 20/05/2016 Contribution to Section 3 Stavros Lounis (AUEBLTRN),

Maja Pokric (DNET), Fernando

Terroso-Saenz (UMU),

Umutcan Simsek, Anna Fensel

(UIBK), Eleni Fotopoulou, Paris

Liapis, (UBITECH), Angeliki

Bousiou (INTELEN), Norma

Zanetti (HYPER)

V 0.4 23/05/2016 Editing of Section 1 and 4 Anastasios Zafeiropoulos

(UBITECH)

V 0.5 27/05/2016 Review performed by HES-SO Antonio Jara (HES-SO)

V 0.6 30/05/2016 Internal review Umutcan Simsek, Anna Fensel

(UIBK)

V 31/05/2016 Final version Anastasios Zafeiropoulos , Eleni


(UBITECH)


18/05/2017 – v1.0 Page 3 of 32

Executive Summary

The vision of the ENTROPY project is to design and deploy an innovative IT ecosystem for

motivating end-users’ behavioural changes towards the adoption of energy efficient lifestyles,

building upon the evolvements in the Internet of Things, Data Modeling and Analysis and

Recommendation and Gamification technologies. In the current document, the ENTROPY

Reference Architecture is detailed. The proposed architecture aims to exploit the advances made

available from the aforementioned technologies and provide an integrated platform, supporting

the fulfilment of the project objectives. In the proposed architecture, Internet of Things

technologies are exploited for the proper interconnection of a heterogeneous set of sensor nodes,

the collection of data based on Mobile Crowdsensing Mechanisms exploiting the power of the

collection of data from a critical mass of interested people and the application of proper

communication networking schemes with regards to data collection. Advanced Data Modelling

and Analysis techniques are applied for the modelling of the collected data and the extraction of

advanced knowledge by exploiting the power of Semantic Web techniques, Linked Data and

Data Analytics. Focus is given on the development of personalized mobile applications and

games targeted at providing energy related information to end users, increasing their awareness

with regards to ways to achieve energy consumption savings in their daily activities and adopt

energy efficient lifestyles based on a set of recommendations targeted to their culture. The

proposed architecture is targeting to be an open and fully extensible architecture that can be

deployed based on open-source tools and open APIs and be easily instantiable in diverse

environments.

Disclaimer

This project has received funding from the European Union’s Horizon 2020 research and

innovation programme under grant agreement No 649849, but this document only reflects the

consortium’s view. The European Commission is not responsible for any use that may be made

of the information it contains.


18/05/2017 – v1.0 Page 4 of 32

Table of Contents

1. Introduction ........................................................................................................................ 5

2. Entropy Reference Architecture ........................................................................................ 6

2.1 Communication Layer .................................................................................................. 7 2.1.1 IoT Nodes Data Aggregation ...................................................................................... 7 2.1.2 Crowdsensing Data Aggregation .............................................................................. 10

2.2 Data Fusion Layer ....................................................................................................... 12 2.2.1 Semantic Enrichment Component ............................................................................. 12

2.2.2 Big Data Repository .................................................................................................. 13 2.2.3 Triplestore ................................................................................................................. 13

2.3 Analysis Layer ............................................................................................................. 13 2.3.1 Analytics Tool ........................................................................................................... 13

2.3.2 Recommendation Engine .......................................................................................... 15 2.3.3 Gamification Framework and Gaming Engine ......................................................... 16

2.4 Application Layer ........................................................................................................ 19

2.5 ENTROPY Integrated Platform ................................................................................ 22

3. Mapping with Technical and Energy Efficiency Requirements .................................... 23

4. Conclusions ...................................................................................................................... 32


18/05/2017 – v1.0 Page 5 of 32

1. INTRODUCTION

In this document, detailed description is provided regarding the ENTROPY reference

architecture and the fulfilment of the requirements defined in D1.2 – “ENTROPY Technical

Requirements” and D1.3 – “ENTROPY Energy Efficiency Requirements”.

The outcome of this deliverable is provided as input to the ENTROPY technical WPs and is

going to be the starting point for the design and the implementation of the various mechanisms

and components developed in the project. Namely, based on the ENTROPY reference

architecture, in WP2 – “Energy Data Modelling, Fusion and Analytics”, the data aggregation and

fusion mechanisms as well as the data analytics production mechanisms are going to be fully

specified and implemented. Similarly, in WP3 – “Behavioural Recommendation and

Gamification Framework”, the recommendation framework for providing suggestions to end

users and building administrators as well as the gamification framework guiding the

implementation of serious games and personalized applications are going to be fully specified

and implemented. Finally, the overall components of the reference architecture along with their

interfaces and interconnection APIs are going to lead the implementation of the integrated

ENTROPY platform in WP4.

It should be noted that the design of the ENTROPY reference architecture has well defined and

separated layers that are composed by open source widely used frameworks including but not

limited to FIWARE, R-language, Drools, Virtuoso, mongoDB, Spring. Within ENTROPY all the

adopted open source technologies are customized, further developed and integrated in order to

come up with a final software paradigm that can get easily adopted by any third party

organization, interested in augmenting the energy efficiency habits of its end users.

The structure of the document is as follows. In section two, the overall reference architecture is

described on a per layer basis. The components identified per layer along with their description,

the internal architecture of each component and the interconnection interfaces with the rest of the

components are detailed. In section three, a mapping is provided between the identified

requirements in D1.2 and D1.3 and their priority with the architectural components, ensuring the

support of all the required functionalities in the project. Section four concludes the document

with a short summary of the presented work and a process for exploiting the provided

specifications in the various technical WPs.


18/05/2017 – v1.0 Page 6 of 32

2. ENTROPY REFERENCE ARCHITECTURE

The ENTROPY architecture consists of four Layers. Following a bottom up approach, the basis

of the architecture is the Communication Layer that is responsible for collecting the data coming

from sensors, mobiles and social media. The Data Aggregation Component, including IoT nodes

data aggregation and crowdsensing data aggregation is included in the Communication Layer, as

depicted with yellow colour at Figure 1. The Data Aggregation Component facilitates the

registration of the Sensor Devices and collects the measurements that come from the registered

devices (IoT nodes). Furthermore, it is responsible for communicating with ENTROPY serious

games and personalized applications as well as social media API’s in order to collect end users’

information as well as data that come from users mobile specific applications.

After collecting all the necessary data from all the ENTROPY data sources, the Communication

Layer forwards these data to the Data Fusion Layer and specifically to the Semantic Enrichment

Component. As the name indicates, the specific component realises the mapping between the

collected data and two specific ENTROPY semantic models: the Behavioural Semantic Model

(to be defined in Task 3.1) and the Energy Efficiency Semantic Model (to be defined in Task

2.1). The semantic enrichment of the collected data augments the expressivity of the information

and makes possible the realization of semantic reasoning upon them. The Semantic Enrichment

Component feeds the core big data repository of ENTROPY with the enriched information. The

big data repository keeps tracking of all data and updates upon request the ENTROPY

Triplestore where the data reside in a graph format and are available for semantic queries. The

big data repository cannot be semantically queried but supports high performance in terms of

simple querying, sharding, quick response times of read/write operations and unlimited capacity

in terms of storing data.

Following, the analysis layer resides on top of the Data Fusion Layer and performs queries to the

ENTROPY Big Data Repository in order to feed the Analytics Tool, the Recommendation

Engine and the Gaming Engine. The analytics tools aim to realize Behavioural and Energy

Analytics. The results of the analysis help the ENTROPY administrators better understand the

habits, patterns and preferences of the consumers as well as detect the positive-negative-neutral

effect of the gaming and recommendation components upon the behaviour of the consumers. The

Gaming Engine retrieves data from the Big Data Repository in order to parameterize the set of

serious Games that augment energy efficiency awareness of the pilot end users. The

recommendation engine also works towards the same direction but in a more personalised and

direct way also employing gamification principles. The recommendation engine, queries the

ENTROPY Triplestore and provides personalized recommendations to the consumers. It should

be noted that the interaction between the various analysis layer tools and the support of the

design as well as implementation of serious games and personalized applications is based on the

specification of the ENTROPY gamification framework.

Finally in the Application layer, ENTROPY personalized applications and serious games are

available to the ENTROPY end users. They receive input from the recommendation engine and

the Big Data Repository, while providing output to the end user via the games and applications.


18/05/2017 – v1.0 Page 7 of 32

The conceptual ENTROPY architecture is depicted in Figure 1:

Figure 1. ENTROPY Reference Architecture

2.1 Communication Layer

2.1.1 IoT Nodes Data Aggregation

This Data Aggregation Component of the Communication Layer is responsible for managing the

IoT nodes deployed in the buildings as part of the infrastructure. Furthermore, it also pre-

processes the raw sensor data coming from these agents so as to provide a uniform access to this

data. Then, the uncovered interface of this component will be used by the rest of the architecture

to access the data from these nodes. To do so, this component comprises three different sub-

modules as depicted in Figure 2 and described in the following paragraphs.


18/05/2017 – v1.0 Page 8 of 32

Figure 2. Data Aggregation Component sub-architecture

IoT Data Broker This repository is the key element of the whole component. In particular, it is in charge of the

storage of the historical data from the target IoT nodes. Furthermore, it also keeps the

management details of each of these nodes.

For its development, the Orion Context Broker1 will be used. This broker is part of the FIWARE

architecture that provides storage capabilities and a lightweight interface to define and update

data entities based on NGSI92 & 103. In that sense, it makes use of a Non-SQL mongoDB4 as

underlying database and a RESTful interface to access it. As a result, it is a suitable solution

when it is necessary to keep the current state of a set of entities of interest, in this case, the IoT

nodes. Furthermore, in conjunction with the FIWARE enabler COMET5 it is capable to store the

history of the measurements returned by the nodes. For the sake of clarity, this broker will be

integrated in the Big Data Repository (MongoDB) described in Section 2.2.2.

IoT nodes API This sub-component centralizes all the direct access to the IoT nodes. It delivers the appropriate

sequence of commands to these nodes during their bootstrapping stage for their proper

configuration. For that goal, it relies to a palette of policies. Once the IoT nodes are running, this

module also supports the automatic connection and disconnection of the nodes to the platform in

real time. In addition to that, it is the element that directly receives the raw sensor measurements

from the nodes. However, the processing of this data is carried out by the Data Stream Collection

as we will see later.

1 http://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker 2 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-

9_Open_RESTful_API_Specification 3 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-

10_Open_RESTful_API_Specification 4 https://www.mongodb.org 5 https://github.com/telefonicaid/fiware-sth-comet

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-9_Open_RESTful_API_Specification




https://github.com/telefonicaid/fiware-sth-comet


18/05/2017 – v1.0 Page 9 of 32

We leverage the FIWARE IoT Agent enabler to develop this component6. This enabler allows the

direct connection with hardware devices so as configure them, check their status and receive

their measurements. More specifically, this IoT agent supports several communication protocols

to connect with resource-constrained electronic devices, namely COAP7, MQTT8 and

Lightweight M2M (LWM2M)9. Moreover, it can be easily connected with the IoT data broker by

means of the NGSI interface so that any change in the configuration of the nodes (e.g. a new

type of measurement attribute captured by a node, or its report frequency) can be easily notified

to the broker.

Data Stream Processor

This component is in charge of the pre-processing of the raw measurements coming from the IoT

nodes. To do so, the IoT nodes API redirects all the measurements to this module.

Every type of collected data either by the device sensors deployed to sense the variables

identified as affecting the considered outputs or obtained by other sources should be pre-

processed in order to avoid incompleteness, noise and inconsistencies. Therefore, the data stream

processor splits this process in three steps: data cleaning, data transformation and data reduction.

1. Data cleaning: In the cleaning step the module focuses on filling in missing values by

predicting them using a learning algorithm: the attribute with the missing value is

considered as dependent variable and the module runs a learning algorithm (decision tree,

k-nearest neighbour) to predict it. Also, this component identifies outliers in the outputs

and tries to explain them through the inputs. If it is not possible, it simply removes them.

2. Data transformation: Dealing with categorical data implies some limitations, so the

module, groups some categories and also transform them into numeric because there are

many algorithms that require it. Later, in order to avoid that variables measured at

different scales contribute unequally to further analysis, it is necessary to transform the

data using normalization, standardization, box-cox transformation or other techniques,

depending on the algorithms that are going to be used.

xminxmax

xminx=x' i

i

3. Data reduction: Looking for irrelevant attributes which the module uses to compute

correlations. The attributes whose correlation efficient with the output is not statistically

significant are rejected. Also, it is common to transform the data space using the so called

Principal Components Analysis. PCA is a widely used technique for reducing

dimensionality, identifying the directions in which the variance of the observations is

accumulated.

Finally, in order to deal with the huge amount of data coming from the sensors, the present sub-

module will be developed by following the Complex Event Processing (CEP) approach. CEP is a

software paradigm to come up with real time solutions. In a nutshell, a CEP system comprises a

set of reactive rules in charge of detecting certain situations of interest by means of the

correlation, aggregation and pattern matching over a set of data streams. Hence, a CEP approach

will be used in order to orchestrate, by means of event-based rules, the aforementioned data pre-

processing steps. More in detail, these types of rules include several mechanisms to perform data

pre-processing. Among these tools, time or count-based sliding windows, that keep the last

measurements of set sensors, are instrumental resources. They allow aggregating and detecting

outliers of irrelevant measurements by only considering the data in such windows. Therefore, it

6 https://github.com/telefonicaid/lightweightm2m-iotagent 7 http://coap.technology 8 http://mqtt.org 9 http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-

registry


18/05/2017 – v1.0 Page 10 of 32

is possible to carry out most of the data pre-processing stage in almost real time. Finally, CEP

commodities like Esper10 are suitable solutions for a full-blown implementation.

IoT Data API

Once the data generated by the IoT nodes is stored in the IoT data broker after data stream

processor pre-processes it, the IoT Data API exposes such data to the rest of the components of

the architecture and specifically the Data Fusion Layer. To do so, it defines new high-level

entities stored in such a broker that are based on the data from the IoT nodes. For example, it can

define an entity “room” aggregating the values of all the IoT nodes located in the same room or

spatial area within a building. As a result, this sub-component provides a higher-level and

uniform access layer to the platform with respect the raw data stored in the broker.

Consequently, other modules of the platform access it by means of the NGSI protocol and

RESTful approach.

2.1.2 Crowdsensing Data Aggregation

Due to the inherent spread nature of the data capture with the crowdsensing approach, it is

necessary to develop appropriate aggregation techniques so as to deal with such largely

distributed data. More in detail, in the ENTROPY scope, the crowdsensing approach will allow

capturing a huge amount of data from target users within the pilots. More specifically, two

meaningful crowdsensing sources are devised:

• The implicit or explicit feedback of users when they use games and personalized

applications.

• The documents shared by these users in different social networking sites that might be

related with their involvement in energy-related or other activities of interest.

Figure 3. Inner architecture of the Crowdsensing Data Aggregation Part.

The module architecture in Figure 3 deals with these two types of crowdsensing-oriented flows.

It should be noted that -upon handling the data from this module- the aggregation of

crowdsensing data will be realized based on the same architectural approach as that for the IoT

nodes data.

10 http://www.espertech.com/products/esper.php


18/05/2017 – v1.0 Page 11 of 32

To start with, the incoming data should be filtered so as to discard redundant, inaccurate or

useless information. This is done by the crowdsensing data filter component. For instance, this

module is in charge of discarding the documents of users in the micro-blogging site Twitter, that

are just copies of previously written documents (i.e. re-tweets) as they do not provide actual

information of the current state of a user.

Once a cleaned stream of data has been composed, it is necessary to use tools able to correlate

and aggregate both types of streams. The final goal in this case is to extract useful information

about the behaviour and preferences of users in each pilot. In that sense, the crowdsensing data

reported by users will generally comprise two kinds of attributes.

Firstly, text content directly or indirectly written by the users. This includes the content of posts

and other documents share by the users in social network or micro-blogging sites or content

directly provided through the developed personalized applications. In this case, it is necessary to

apply techniques of feature extraction on this content. In this frame, the latent dirichlet

allocation11 or latent semantic indexing12 are two well-known algorithms that allow to 1)

automatically uncover the topics of a set of documents and 2) measure the pair-wise cosine

similarity of textual documents.

These two features are of great help to generate clusters of documents referring to particular

topics or activities of interest for the platform. However, they have an important downside in

terms of performance as they require rather complex matrix-based computation, so they might

not be completely reliable approaches in time-demanding domains. As an alternative, the

classification of documents using a bag of words solution is more appropriate when text

documents must be handled in a rapid manner. In this case, a document is classified in a certain

way if a direct match with a set of keywords occurs. Lastly, bearing in mind Figure 3, this task is

performed by the topic/activity extractor component.

Secondly, the data coming from the aforementioned crowd-based sources might also include

certain meta-attributes, like timestamps and, above all, geo-location features. These features

allow to spatially allocate users when they generate either feedback from the games and

applications or documents in social networks. In that sense, such spatial data can be used to

establish relationships among users in terms of common regions of interest. Hence, the regions

of interest extractor component in Figure 3 is responsible for this task. To do so, grill and

density-based clustering algorithms13 are prominent solutions to detect meaningful spatial

regions among a group of users.

Next, the textual and spatial clusters can be combined together so as to compose semantically-

enriched groups (clusters) of users that not only share common interests, preferences or activities

but also common spatial regions of interest. These groups of users are detected by the groups of

users detector (see Figure 3) on the basis of the aforementioned spatial regions of interest and

topic clusters. Then, the different groups of users can be exposed to other modules of the

platform.

To do so, the context broker, acting as big data repository, registers two type of sensors to deal

with the generated data. Firstly, a sensor entity “user” representing a particular user/contributor

11 Blei, D. M., Ng, A. Y., & Jordan, M. I. (2003). Latent dirichlet allocation. the Journal of machine Learning research,

3, 993-1022. 12 Dumais, S. T. (2004). Latent semantic analysis. Annual review of information science and technology, 38(1), 188-

230. 13 Birant, D., & Kut, A. (2007). ST-DBSCAN: An algorithm for clustering spatial–temporal data. Data & Knowledge

Engineering, 60(1), 208-221.


18/05/2017 – v1.0 Page 12 of 32

of the platform. This entity includes different attributes comprising individual aspects of interest

of the user, like hours spend in a game or its current or most frequently-visited locations. In

addition to that, an entity “group of users” will be also defined in the repository. In this case, the

entity comprises information about the generated clusters of users defined in this section. In that

sense, this entity will comprise aggregate information of the users like average age and common

activities or regions of interest.

Finally, in order to achieve a lightweight interconnection between all the components, the CEP

paradigm provides a suitable solution. Its design based on reactive event-condition-action rules

allows to rapidly launch the different algorithms and methods as soon as either a social-

networking document or a feedback report is received.

2.2 Data Fusion Layer

2.2.1 Semantic Enrichment Component The Semantic Enrichment Component (see Figure 4) is responsible for mapping the collected

information in the defined ENTROPY Semantic Models, and thus making possible its usage

based on common representation schemas. The continuous evolution of the semantic models, in

order to be able to map the collected information in specific entities, along with the appropriate

categorization of the available information is considered crucial. Specifically, the two models,

namely the behavioural semantic model and the energy efficiency semantic model, developed in

WP3 and WP2 respectively, are going to be used during the mapping process. The produced

output of data is going to be in JSON-LD format.

JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is

based on the already successful JSON format and provides a way to help JSON data to

interoperate at Web-scale. JSON-LD is an ideal data format for programming environments,

REST Web services, and unstructured databases such as MongoDB. JSON-LD is designed

around the concept of a "context" to provide additional mappings from JSON to an RDF model.

The context links object properties in a JSON document to concepts of an ontology (ENTROPY

Semantic Models). In order to map the JSON-LD syntax to RDF, JSON-LD allows values to be

coerced to a specified type or to be tagged with a language. A context can be embedded directly

in a JSON-LD document or put into a separate file and referenced from different documents

(from traditional JSON documents via an HTTP Link header).

Figure 4. Semantic Enrichment Component.

The produced JSON-LD data is made available in the Big Data Repository (as explained in the

following subsection) and can be used by the ENTROPY Analysis Layer tools or used for

interlinking purposed with available public or private data. Interlinking of data and production of

linked data is going to be realized based on the usage of the open-source workbench produced

through the LinDA FP7 project, available at http://linda.epu.ntua.gr/.

http://linda.epu.ntua.gr/


18/05/2017 – v1.0 Page 13 of 32

2.2.2 Big Data Repository This component regards the main repository of ENTROPY where data coming from the

ENTROPY components are going to be stored and made available for further processing. Such

data regard on one hand data coming from the IoT Data Aggregation Component, semantically

mapped data based on the ENTROPY semantic models, as well as data collected from the

Analysis Engine, the Recommendation Engine and the ENTROPY Games and Personalized

Applications.

The implementation of the Big Data Repository is going to be based on MongoDB that is a free

and open-source cross-platform document-oriented database. Classified as a NoSQL database,

MongoDB avoids the traditional table-based relational database structure in favour of JSON-like

documents with dynamic schemas, making the integration of data in certain types of applications

easier and faster. MongoDB supports a set of scaling and high performance assurance

characteristics, constituting it suitable for big data storage solutions.

A set of collections is going to be implemented for the storage of the data coming from the

various components/layers along with the appropriate interfaces for providing access to these

data from the associated tools (see Figure 4). Data coming from the data aggregation component

will be stored in the raw data collections, while semantically mapped data and data coming from

the analytics tool, the recommendation engine and the gaming engine will be stored at the

semantically mapped data collections.

2.2.3 Triplestore The Triplestore or RDF store regards a purpose-built database for the storage and retrieval of

triples through semantic queries. Unlike a relational database, a triple store is optimized for the

storage and retrieval of triples. In addition to queries, triples can usually be imported/exported

using Resource Description Framework (RDF) and other formats.

Import of data from the ENTROPY Big Data Repository is going to be supported, based on a set

of views defined by the Recommendation Framework (as detailed in section 2.3). Import of data

is going to be realized based on triggers initiated from the recommendation engine, while the

related data is going to regard a specific time window. We utilize the Triplestore as a repository

where semantic queries that lead to reasoning and recommendations are supported.

The implementation of the Triplestore will be based on the Virtuoso Open-Source Edition14

which supports SPARQL queries, access control and built-in semantic reasoning.

2.3 Analysis Layer

2.3.1 Analytics Tool Big data challenges can be understood through the lens of 7 V's: volume, velocity, variety,

veracity, validity, volatility and value. The traditional tools struggle with this paradigm so in

order to face with it we propose two analytic tools: R as statistical software and Pentaho Data

Integration (or Kettle) for extracting data in real time automatically.

In ENTROPY, these tools are going to be used for supporting energy and behavioural analytics,

as depicted in Figure 5. Input data for analysis are going to be provided from the ENTROPY Big

Data Repository, while the analysis results are also going to be stored in the same repository and

made available to the rest of the analysis tools as well as made available for consumption by the

ENTROPY Dashboard and the developed personalized applications.

14 http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/


18/05/2017 – v1.0 Page 14 of 32

Figure 5. Analytics tool internal architecture.

R is both an open source statistical software and a programming language, that although it was

initially created to provide a user-friendly way to do data analysis, has gained competitiveness

thanks to its community philosophy. It has available CRAN which is a huge repository of

curated R packages to which users can easily contribute. These packages are a collection of R

functions and data that make it easy to immediately get access to the latest techniques and

functionalities without needing to develop everything from scratch. R is the lingua franca of data

science. It is used in the academics, research and increasingly in business because faces perfectly

several challenges of Big Data through its functionalities: statistical analysis, data visualization,

and predictive modelling.

The main package that we are going to use is caret, because it provides a set of functions that

attempt to streamline the process for creating predictive models. Caret draws from the source

code of many other packages. Among the many utilities that it eases focused on data analytics:

data splitting, pre-processing, feature selection, model tuning using resampling. It is worth to

mention that it allows parallel computing by means of the doMC package. Parallel computing is

used to distribute the tuning parameters search for optimizing the predictive models. Although

parallel processing using doMC does not work on Windows, there are other possibilities such as

doParallel in case Linux based machines are not available.

The algorithms that we propose to implement by means of this package are those that have

already been successfully applied when facing energy efficiency problems: artificial neural

networks (both feed-forward and feedback), random forest, support vector machines and

Gaussian processes. The same algorithms can be also utilized when it comes to behaviour

modelling and inference of behavioural insights. Thus, multiple machine learning algorithms

supported by R packages will enable the deployment of behavioural analytics application.

These algorithms are fed with pre-processed data, made available in the ENTROPY Big Data

Repository.


18/05/2017 – v1.0 Page 15 of 32

Alternatively, the pre-processing step can be done with an R script, however, in this case the

Pentaho BI suite has to be used. The Pentaho BI suite consists of a set of applications that

generate business intelligence. It has two offerings, an enterprise and community edition. The

community edition includes the desktop application that we are interested in: the Pentaho Data

Integration (PDI), codenamed Kettle, consists of a core data integration (ETL) engine, and GUI

applications that allow the user to define data integration jobs and transformations.

Basically, Pentaho can be used in order to create a .ktr file that connects to the database and

query the variables. Also, it can support some very basic pre-processing steps (e.g. cleaning

repetitions, aggregations) in order not to feed R with excessive and redundant data.

2.3.2 Recommendation Engine

In this section, we explain the internal mechanism of the recommendation engine component

(Figure 6) and its communication interfaces. The component consists of three subcomponents,

namely the Context Listener and the Rule Engine from the Analysis Layer and the Triplestore

from the Data Fusion layer.

Context Listener

This subcomponent runs a background job to detect contextual changes (e.g. changes in location,

time and environmental measurements) by sending periodic requests containing pre-defined

queries to the Big Data Repository via its RESTful API. The context listener notifies the rule

engine whenever a change occurs. Naturally, the tracked contextual changes are not atomic, but

pre-defined high level changes. For instance, a small change in a single sensor measurement

might be irrelevant, meanwhile a temperature change between morning and noon can trigger a

recommendation.

Rule Engine

The rule engine subcomponent may be triggered by two mechanisms: notification of context

listener or a direct request from the application layer. The rule engine accesses to the Triplestore

via a RESTful API in order the retrieve SPARQL rules15 and run them on the RDF knowledge

base. After the execution of the rules, the rule engine transfers the suitable recommendations in

JSON-LD format to the Big Data Repository through its RESTful API. The recommendations

are stored in the repository and then streamed to the application layer. The feedback given by

user to a recommendation is also stored in the Big Data repository for further processing.

It should be noted that, additional to the SPARQL rules, we will also experiment a Drools16

based implementation of the rule engine to compare the performance and the impact of both

implementations on the creation of recommendations.

Interconnection with Triplestore

Even though, the Triplestore subcomponent resides in the data fusion layer from an architectural

point of view, it also plays an important role in the recommendation lifecycle. This

subcomponent serves as an intermediary storage where relevant aggregated context information

is stored. The relevant context information is extracted from the big data store based on pre-

defined business rules. The semantic rules and operations run on this context information.

Additionally, the subcomponent also serves as a rule base for SPARQL rules.

15 https://www.w3.org/Submission/2011/SUBM-spin-overview-20110222/ 16 http://www.drools.org/


18/05/2017 – v1.0 Page 16 of 32

Figure 6. Recommendation Engine Internal Architecture

Several technologies cooperate for the implementation of the component. We adopt the Java

programming language with OSGi17 architectural paradigm for software development and JSON-

LD format with RESTful APIs for inter-layer communication.

2.3.3 Gamification Framework and Gaming Engine

ENTROPY games and personalized applications are going to be developed taking into account

the defined gamification framework.

The ENTROPY Gamification Framework guides the logic behind the allocation of different

game elements and game setups to different identified groups of participants, based on the prior

analysis of their demographics, psychographics, organizational structure position, as well as

subsequent game behaviour. Respectively, the development of serious games is going to be

realized through the use of the Gaming Engine, while development of the personalized

applications will be based on custom development. Both of them are going to be provided for a

multi-platform environment, namely compatible to Android devices, Windows/Linux devices,

iOS operating system etc.

17 https://www.osgi.org/


18/05/2017 – v1.0 Page 17 of 32

ENTROPY Gamification Framework

More specifically, the ENTROPY Gamification Framework facilitates the introduction and

allocation of game elements to the respective end user contact points (Personalized application

and Serious Games) in order to enhance them with playful affordances. The overall goal is to

provide to the users/players the ‘right’ games that ensure their engagement towards energy

reduction and encourage an energy efficient behaviour, whilst raising their awareness on the

impact of their everyday activities.

It resides upon the theoretical foundations of the Mechanics Dynamics Aesthetics (MDA)

Framework that governs the game design from the designer and player perspective, in parallel

with the application of the Octalysis Gamification Framework that constitutes a collection of

game elements eligible for introduction. Figure 7 illustrates the internal architecture of the

instantiation of the aforementioned frameworks to the new ENTROPY Gamification Framework.

Figure 7. ENTROPY Gamification Framework

MDA Framework is the principal Gamification Framework that utilizes the extant game-

elements, as well as their application in the various deployments in the scope of each

deployment. Through the Mechanics part of the Framework, the extant game-elements (extant in

the Octalysis Framework) are instantiated based on the available information on participants as

well as extant resources available for the theoretical formation of the games. Based on a set of

predefined modes of game-element interactions for each available game-element, the system

proposes the currently optimal setup.

In terms of Game Elements, the Octalysis Gamification Framework acts as a basis that provides

the available Game Elements as described in D1.3 (i.e. Points, Achievements, Rewards in Good

Settings, Mission Settings for Energy reduction Goals, Avatars and Leaderboards for Social

Comparison) among others. In combination with the MDA Module, a set of game-elements and

the way the players interact with each element is defined and implemented by the personalized

application and serious game for delivery / application to the respective end-user or group of

users.

Lastly, the Aesthetics part of the MDA module receives the results of the application of game

elements to the different end-users and benchmarks their effect to a set of predefined goals. In

cases where the goals are not met, the dynamics part is adjusted for the game-elements to meet

the new attainable goals. Additionally, a set of predefined feedback for each game element is

provided to the end-user to assist him/her/them on how to proceed to achieve his/her/their

currently set goals.


18/05/2017 – v1.0 Page 18 of 32

ENTROPY Gaming Engine

Taking into account the provided Gamification Framework, a set of serious games are going to

be developed through the ENTROPY Gaming Engine. We have selected Unity3D Game Engine

(see Σφάλμα! Το αρχείο προέλευσης της αναφοράς δεν βρέθηκε. and Figure 8) because it

enables creation of 2D or 3D games. It is also a multiplatform game engine, which allows us to

target more devices easily. With Unity, you also get the capacity to deploy for the full range of

mobile, VR, desktop, Web, Console and TV platforms, in order to enable end-users to participate

in a device-agnostic way.

Figure 8. General Game Components Diagram

Unity3D provides a useful API that is accessible through C# scripts and JavaScript for basic

game engine functionality. More advanced API components, such as a VR library, a physics

engine or a multiuser library may also be used, resulting in a compact, functional API for fast

application development.


18/05/2017 – v1.0 Page 19 of 32

Figure 9. Serious Game Platform with general Unity3D functionality

Unity3D scripts permits a connection from within the Unity game environment with the

ENTROPY Big Data Repository. When connected with this repository, any possible query can

be sent through over HTTP. The query results received by the script can be processed or

visualised as wished or required in the virtual world.

2.4 Application Layer

The ENTROPY application layer concerns the set of developed serious games, the personalized

applications as well as the ENTROPY Dashboard.

Figure 10 shows in more detail what components are required in order to develop both serious

game and personalized application for a multiplatform deployment. Due to Augmented Reality

(AR) components in personalized application, and potentially as part of triggering mechanisms

in serious game, the AR library has to be added into Unity3D and XCode projects. This will

enable image/marker recognition for AR components which will be integrated with other

existing components of Unity3D.


18/05/2017 – v1.0 Page 20 of 32

Serious Game/ Personalized Application

Platforms

Gaming Engine Unity3D

Graphics Physics Scripting Multiplayer

Audio Animation UI VR…

Augmented Reality Library (e.g. Vuforia)

Add AR Lib to Unity3D project

Add AR Lib to XCode project

Add AR Markers Add ArCameraPrefab to scene

Add 3D Object and light

Set Load Dataset DEPLOY!

APIs

Social APIs (user profiles, friends list,achievements, statistics/leaderboards)

JSON Serialization (interacting with webservices or data exchange)

FeedbackInput Data

HTTP

Windows Android iOS Desktop, VR, Web…

Figure 10. ENTROPY Game Components Diagram

Figure 11 provides an example of different gamification techniques that might be implemented.

Figure 11. Gamification modes and techniques

The following sub-sections give brief descriptions of the serious games and personalized

application, while detailed Gamification design and specification will result from work in Task

3.3.

Indicative Game Description:

Develop Serious Games that combine the digital and the physical worlds and provide educational

content with respect to energy efficiency - energy consuming activities as well as best practices

for increasing energy efficiency and energy savings in the building sector.


18/05/2017 – v1.0 Page 21 of 32

Functionality:

Input data:

o Results from the analysis tool

o Real-time data from sensors in buildings

o User specific data

o Data triggered through AR app

o Recommendations

Output data:

o Game related data (scores, levels, rewards etc.)

o User behaviour data

o User specific data

Core Gameplay Mechanics:

o Define rules or methods for interaction, hence providing gameplay

o Allow people playing a game to have an engaging and fun experience

o Allow multiplayer interaction and assigning budget

o Include learning elements through actions

o Define game modes etc.

It should be noted that in order to deliver relevant information to their end-users, more and more

applications are using personalization techniques. Such methods require web providers to

manage and store user profiles. The most common architectures for personalized web

applications are to store the user profiles either at the server or at the client (browser). Therefore

an intermediate user profile management agent should exist. This agent should be responsible to

manage and store the user profiles and facilitate the communications between the game engine

and the personalization rules. This not only relieves the personalized servers from the tasks of

user profile management but also makes it possible to provide support for advanced

personalization techniques.

The ultimate objective is to determine the rules and the technologies that will allow personalized

training content, personalized feedback and personalized incentives to reach end-users that

match their profile, preferences and needs.

Indicative App Description:

Use markers around the building to access real-time and historical measurements through

Augmented Reality (AR) application. Educational content with respect to energy efficiency -

energy consuming activities as well as best practices for increasing energy efficiency and energy

savings in the building sector will be presented to the end user of the app.

Functionality:

Input data:

o results from the analysis tool

o measurement data

o user specific data

o smart recommendations

Output data:

o game related data (scores, levels, rewards etc.)

o user behaviour data

o user specific data

Core Mechanics:

o Define rules or methods for interaction


18/05/2017 – v1.0 Page 22 of 32

o Allow people playing using personalized application to have an engaging

and fun experience

o Allow multiplayer interaction

o Include learning elements through actions

2.5 ENTROPY Integrated Platform

ENTROPY components are going to be implemented as separate modules of the same platform.

In order to facilitate the dissemination of the final product as well as the easy installation and

adoption of the proposed solution on behalf of third party institutions, it is really important to

follow the same development paradigm and principles, while exposing a common user interface

where the ENTROPY administrator -without special IT knowledge of the combined

technologies- will be able to customize, monitor and plan behavioural interventions destinated to

the end users.

The ENTROPY Dashboard is going to be the unified common UI of the ENTROPY platform. It

is going to be developed and targeted at buildings administrators for providing information

regarding various functionalities such as the energy consumption and efficiency achieved in the

considered building, results of customized analytics processes (e.g. for forecasting or clustering

purposes), information about the registered sensors and IoT devices. Also, it will give the

possibility to administrators to graphically create and run analytic processes, while sending

specific recommendation to clusters of users depending on the interpretation of the analytics

results.

All components are going to get developed using a state of the art stack of backend and frontend

technologies. Regarding the frontend, ‘thymeleaf’ is planned to be used while backend is going

to be implemented in Java making use of the Maven build automation tool. Maven addresses two

aspects of building software: first, it describes how software is built, and second, it describes its

dependencies. From a technical point of view all components are going to expose their exposed

functions to centralized and common defined interfaces. Concerning the API, all public methods

of the ENTROPY recommendation, analytics and sensors registration components should be

present in the API module. Each module will expose its public interface in the API module

making use of Spring stereotypes (@Service). At the backend, it will mostly take place the

definition of models, exception handling and exposed API definitions. In addition, for every new

developed feature, a corresponding unit test will be implemented. Concerning the data storage,

as already mentioned, a common NoSQL database is adopted, to which all components will have

access via a common defined REST API.


18/05/2017 – v1.0 Page 23 of 32

3. MAPPING WITH TECHNICAL AND ENERGY EFFICIENCY

REQUIREMENTS

In this section, the mapping of the set of requirements detailed in D1.2 and D1.3 with the

components of the ENTROPY Reference architecture is realized, aiming at assuring the support

of the defined requirements as well as their association with specific components. The list of

technical and energy efficient requirements is provided in Table 1 and Table 2 accordingly.

Table 1. Mapping of Technical Requirements with ENTROPY Reference Architecture

ID Title Priority Component Fulfilled Comment

COM.1 Collection of

measurements

from various

sensor nodes

Top Data Aggregation

/ IoT nodes

Yes Data is going to be

collected and filtered / pre-

processed from the set of

the registered nodes in the

Data Aggregation

Component.

COM.2 Support of

standardized

communication

Protocol


/ IoT nodes

Yes A set of communication

protocols including MQTT,

OMA LWM2M (IPv4 and

IPv6) is supported in the

Data Aggregation

Component.

COM.3 Configuration of

data sampling

period

Medium Data Aggregation Yes A set of filtering / pre-

processing options are

made available at the Data

Aggregation Component.

COM.4 Social Media

API

Medium Data Aggregation

/ Crowdsensing

Yes Data collection from social

media feeds is supported

through crowdsensing data

aggregation mechanisms.

COM.5 Mobile Apps

Data Integration

Medium Data Aggregation

/ Crowdsensing

Yes Data collection from

mobile apps is supported

through crowdsensing data

aggregation mechanisms.

COM.6 Sensors

registration


/ IoT nodes

Yes Sensors registration is

supported at the Data


Specific configuration has

to be provided based on the

sensor type.

COM.7 Sensors

bootstrapping

Top Data Aggregation Yes Sensors management is

going to be supported at

the Data Aggregation

Component.

COM.8 Crowdsensing

filtering

Top Data Aggregation Yes Data collection and

filtering from smartphones

is supported at the Data



18/05/2017 – v1.0 Page 24 of 32

COM.9 Crowdsensing

user registration

Medium Data Aggregation Yes Crowdsensing data per

ENTROPY user is going to

be collected via the Data

Aggregation Component

(by including feeds from

the serious games and

personalized applications).

COM.10 Social Media

Stream Periodic

collection

Medium Data Aggregation Yes Social media streams are

going to be collected via

the Data Aggregation

Component, based on

topics of interest.

COM.11 Data Stream

Distributed

Engine

Medium Data Aggregation Yes Collection of data from

distributed data sources.

COM.12 Data Stream

General Event

Model

Top Semantic

Mapping

Yes All aggregated data is

going to be mapped in the

ENTROPY Semantic

models.

DATA.1 Design of

Behavioural

Semantic Model

Top Behavioural

Semantic Model

Yes To be provided by WP3.

DATA.2 Design of

Energy

Efficiency

Semantic Model

Top Energy Efficiency

Model

Yes To be provided by WP2.

DATA.3 Interlinking of

Entropy

Semantic

Models

Top Semantic Models Yes To be provided by WP2

and WP3. The target is a

interconnected and fully

extensible model.

DATA.4 Adopt (reuse)

existing

semantic models

Medium Semantic Models Yes Open and extensible

models. Reuse part of

existing ontologies.

DATA.5 Use of open

source

frameworks for

modelling

ontologies

Medium Semantic Models Yes Use of open-source tools

such as Protégé.

DATA.6 Data Storage

Scalability

Top Big Data

Repository

Yes Implementation based on

MongoDB that is

horizontally scalable.

DATA.7 Scalable triple

store

Top Triplestore Yes Implementation based on

Virtuoso Triple Store.

DATA.8 Reasoning

support at least

to RDFS /

OWL-Lite

reasoning.

Top Triplestore Yes Reasoning based on

SPARQL queries and

RDFS / OWL semantics


18/05/2017 – v1.0 Page 25 of 32

DATA.9 Definition and

implementation

of a data

management

policy

Top Big Data

Repository,

Triplestore

Yes Data management policy in

the MongoDB.

DATA.10 Support

Authentication

mechanisms for

access to data

Top Big Data

Repository,

Triplestore

Yes Authentication

mechanisms for accessing

the Big Data Repository.

DATA.11 Support

interlinking of

ENTROPY

triplestore with

LOD

Medium Triplestore Yes Interlinking via usage of

the LinDA FP7 project

workbench.

DATA.12 RESTful based

communication

between

ENTROPY

components

Top Big Data

Repository,

Triplestore

Yes Specification of interfaces

for communication

among the components,

based on the work that is

going to be realised

within WP2, WP3 and

WP4.

DATA.13 SPARQL

Endpoint

provision

Top Triplestore Yes SPARQL endpoint over the

Triplestore.

DATA.14 Data mapping to

Semantic models

Top Semantic

Enrichment

Yes Data mapping through the

Semantic Enrichment

Component.

DATA.15 Pull of

aggregated data

from

Aggregation

Components in a

Common Format

Medium Semantic

Enrichment

Yes Storage of data in a JSON-

LD format.

DATA.16 Fast detection of

modified data

Top Context Handler Yes Detection of changes by

the Context Handler and

triggering of associated

rules.

ANALYSIS.1 Support a set of

robust

algorithms and

visualizations

Top Analytics Yes Set of algorithms supported

through R in the analytics

tool.

ANALYSIS.2 Use of open

source

frameworks for

machine

learning

algorithms

Top Analytics Yes Implementation based on

R, Python and Java.

ANALYSIS.3 Provide

Analytics &

Visualization

Top Analytics Yes Design and development of

the ENTROPY Dashboard.


18/05/2017 – v1.0 Page 26 of 32

Dashboard

ANALYSIS.4 Development of

mechanisms able

to process both

static and mobile

data

Top Analytics Yes Supported since the data

aggregation component

supports both static and

mobile data.

ANALYSIS.5 Fast analysis of

meaningful

changes of data

related to

entities of

interest (e.g.

buildings,

groups of

people, etc.)

Top Analytics Yes Set of supported

analytics.

ANALYSIS.6 Real-time

analysis support

Top Analytics Yes Real time feeds and

analysis based on

predefined processes.

ANALYSIS.7 Recommender

System-

Application

Layer Interface

Top Recommendation

Engine

Yes Storage of data in the

ENTROPY Big Data

Repository and

consumption of data by the

Analysis and Application

Layer components.

ANALYSIS.8 Recommender

System Rule

Engine

Medium Recommendation

Engine

Yes The interoperability of

state of the art open source

rule engines (e.g. Drools)

and SPARQL rules must be

investigated. SPIN API and

Apache Jena will be

utilized for running the

rules.

ANALYSIS.9 Rule

Registration

Top Recommendation

Engine

Yes Definition at the Rule

Engine

ANALYSIS.10 Implicit and

Explicit

Recommender

Engine Tuning

Top Recommendation

Engine

Yes All relevant data is going

to be available at the

ENTROPY Big Data

Repository.

ANALYSIS.11 Data-To-

Behaviours

mapping rules

Top Analytics,

Recommendation

Engine,

Gamification

Framework

Yes Produce set of

behavioural analytics,

map them with rules and

recommendations.

APP.1 Provide different

Versions based

on Users clusters

Top Personalized

Apps, Serious

Games

Yes Personalized apps and

games based on the

profile of the user.

APP.2 Provide

Interfaces that

support the use

of game

mechanics

Top Personalized

Apps, Serious

Games,

Gamification

Framework

Yes Adoption of game

mechanics as defined in

the gamification

framework.


18/05/2017 – v1.0 Page 27 of 32

APP.3 Provide Push

Notifications

Top Personalized

Apps, Serious

Games

Yes Provide notifications to

end users in the

personalized applications

and serious games.

APP.4 Provide Content

and Games

Administration

panel

Top Application Layer Yes This feature will be

supported via the

ENTROPY Admin

Dashboard

APP.5 Provide Games

KPIs tracking

Top Personalized

Apps, Serious

Games, Big Data

Repository

Yes Support KPIs tracking at

the ENTROPY Big Data

Repository.

Table 2. Mapping of Energy Efficiency Requirements with ENTROPY Reference Architecture

ID Title Priority Component Fulfilled Comment

BEHAVIOURAL.1 Behavioural

Profile

representation to

the Behavioural

Semantic Model

Top Behavioural

Semantic Model,

Semantic

Enrichment

Component

Yes Representation of

concepts in the

behavioural semantic

model and mapping of

data based on this

model via the Semantic

Enrichment

Component.

BEHAVIOURAL.2 Interconnection

with Social

Media

Medium Personalized

Applications,

Serious Games

Yes To be defined in detail

during the development

of the personalized

applications and the

serious games.

BEHAVIOURAL.3 Rules creation

based on actions

related with

behavioural

profile


Engine

Yes Definition of set of

relevant rules and

recommendations in the

recommendation

engine.

BEHAVIOURAL.4 Provide energy

consumption

rates in an easily

interpretable

format to

cause/increase

awareness

Medium Personalized

Applications,

Serious Games

Yes Provision of relevant

information at the

personalized

applications and serious

games.

BEHAVIOURAL.5 Provide energy

consumption

information

easily

comparable with

real world

examples or

relevant cost

Medium Personalized

Applications,

Serious Games


information at the

personalized


games.

BEHAVIOURAL.6 Provide

personalized

information

Medium Analytics Tool,

Personalized

Applications

Provision of relevant

information at the

personalized


18/05/2017 – v1.0 Page 28 of 32

regarding the

consumption

patterns

applications taking into

account feedback from

the analytics tools.

BEHAVIOURAL.7 Support

awareness

campaigns

Medium Personalized

Applications

- Not applicable in the

architectural design

BEHAVIOURAL.8 Define and

measure

behavioural

change indicators

(i.e. the

behavioural

metrics defined

in section 3.3.7

among others)


Personalized

Applications

Yes Extraction of

behavioural analytics,

storage in the big data

repository and

consumption of such

data in the personalized

applications.

BEHAVIOURAL.9 Prioritization of

recommendations


Engine

Yes Inclusion of priority

indicators in the

provided

recommendations.

BEHAVIOURAL.10 Provide

information

regarding energy

consumption per

set of indicators

(e.g. per capita,

KWh, m2,

KWh/m2)


Personalized

Applications


information at the

personalized

applications taking into

account feedback from

the analytics tools.

BEHAVIOURAL.11 Provide learning

material to end

users

Medium Personalized

Applications,

Serious Games

Yes Provision of learning

material at the

personalized


games.

BEHAVIOURAL.12 Allow the

realization of

challenges with

certain goals

Top Personalized

Applications,

Serious Games

Yes Inclusion of challenges

in the business logic of

the personalized


games.

BEHAVIOURAL.13 Support real-time

recommendations

through the

personalized

applications


Engine,

Personalized

Applications

Yes Consume the provided

recommendations in

real time by the

personalized

applications.

BEHAVIOURAL.14 Support non real-

time

recommendations

through the

personalized

applications


Engine,

Personalized

Applications

Yes Consume the provided

recommendations, as

stored in the big data

repository, by the

personalized

applications.

BEHAVIOURAL.15 Support direct

(real-time)

feedback


Engine,

Personalized

Applications,

Gamification

Yes Collection of feedback

through crowdsensing

mechanisms. Provision

of recommendations to

end users.


18/05/2017 – v1.0 Page 29 of 32

BEHAVIOURAL.16 Support indirect

feedback


Engine,

Personalized

Applications,

Feedback

Mechanism,

Challenges,

Serious Games,

Gamification

Yes Collection of feedback

through crowdsensing

mechanisms.

BEHAVIOURAL.17 Leaderboard &

Loss aversion

Medium Gamification,

Serious Games,

Personalized

apps

Yes Business logic of the

personalized


games.

BEHAVIOURAL.18 Default options Medium Gamification,

Serious Games,

Feedback

Mechanism


personalized


games.

BEHAVIOURAL.19 Integrate

pictograms,

emoticons,

colours and

sounds as

indicators for

accepted actions

or inefficient

behaviours

Medium Personalized

Applications,

Serious Games,

Feedback

Mechanism


personalized


games.

BEHAVIOURAL.20 Selection of

peers – Team

formation

Medium Personalized

Applications,

Serious Games,

Feedback

Mechanism,

Gamification


personalized


games.

BEHAVIOURAL.21 Real and Virtual

prizes as a

reward for high

energy efficient

users (concerns

end-user with

above threshold

intrinsic motives

towards energy

efficiency)

Medium Personalized

Applications,

gamification


personalized


games.

BEHAVIOURAL.22 Real prizes &

goals (concerns

end-user with

below threshold

intrinsic motives

towards energy

efficiency)

Medium Personalized

Applications,

Challenges


personalized


games.

BEHAVIOURAL.23 Real and Virtual

prizes & point

system (all end-

users are

rewarded based

Medium Personalized

Applications,

Serious Games,

Point System


personalized


games.


18/05/2017 – v1.0 Page 30 of 32

on their

engagement &

commitment with

ENTROPY

intervention)

BEHAVIOURAL.24 Conceptualise

the effect of

certain actions

within a virtual

world.

Medium Serious Games Yes Virtual reality serious

games.

BEHAVIOURAL.25 Educate end-user

through games

Medium Serious Games Yes Provision of educational

content through the

serious games.

BEHAVIOURAL.26 Improve end-

users decision-

making

Medium Serious Games,

Personalized

Applications,

“News”

Yes Through tips,

recommendations,

educational content in

the personalized


games.

BEHAVIOURAL.27 Summary of

effort progress

Medium Personalized

Applications,

“Profile” or

weekly report


personalized


games.

BEHAVIOURAL.28 Enable Points

allocation

Medium Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.29 Enable and

Evaluate

Achievements

Medium Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.30 Availability of

Roles within

teams

Medium Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.31 Availability and

evaluation of

missions

Medium Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.32 Availability of

self representing

avatars

Medium Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.33 Support and

evaluate

narrative context

in terms of

energy efficiency

Personalized

Applications,

Serious games,

Gamification


personalized


games.

BEHAVIOURAL.34 Enable the

allocation of end-

Personalized

Applications,


personalized


18/05/2017 – v1.0 Page 31 of 32

users to different

visual versions of

the app

Serious games,

Gamification


games.

BEHAVIOURAL.35 Most effective

actions

Medium Feedback

mechanism


personalized


games.

BEHAVIOURAL.36 Evaluate

interventions

Medium Personalized

Applications


personalized

applications.

BEHAVIOURAL.37 Creation and

dissemination of

questionnaires

Medium Personalized

Applications


personalized

applications.


18/05/2017 – v1.0 Page 32 of 32

4. CONCLUSIONS

In this document, the ENTROPY Reference Architecture has been described. Details are

provided regarding the functionalities and the components per layer of the architecture, as well

as the interconnection interfaces among the components.

The ENTROPY Reference Architecture is going to lead the overall deployment of the

ENTROPY components, mechanisms and integrated platform in WP2, WP3 and WP4 while it be

also adopted in the pilots’ execution and evaluation phase in WP5.

Thus, more detailed descriptions of the individual ENTROPY components, interfaces and APIs

will be provided within the lifetime of the project, based on the technical work realized in the

other WPs.

Documents

649849 ENTROPY Design of an Innovative Energy-Aware IT ......18/05/2017 – v1.0 Page 3 of 32 Executive Summary The vision of the ENTROPY project is to design and deploy an innovative