649849 ENTROPY Design of an Innovative Energy …...649849 ENTROPY D1.2 ENTROPY Technical Requirements 18/05/2017 – v0.1 Page 7 of 41 2. ENTROPY ROLES In ENTROPY, a set of roles

ENTROPY Consortium

Title: Document Version:

D1.2. Entropy Technical Requirements 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/03/2016 15/03/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:

Vassilis Nikolopoulos Intelen WP1

Authors (organizations):

Vassilis Nikolopoulos (INT)

Abstract:

This document provides an overview of the main technical requirements that will guide the

development of the ENTROPY Architecture. Upon a short description of the envisaged layered

architecture, a set of requirements is provided per layer, along with their prioritization. Furthermore,

short description of the technical infrastructure required for the setup of the ENTROPY pilots is

provided, aiming at extraction of technical requirements regarding their appropriate definition and

setup.

Keywords:

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

IoT

Disclaimer: The present report reflects only the authors’ view. The European Commission is not responsible for any use that may be made of the

information it contains.

649849 ENTROPY D1.2 ENTROPY Technical Requirements

18/05/2017 – v0.1 Page 2 of 41

Revision History

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

Revision Date Description Author (Organization)

V 0.1 1/02/2016 First version of the documenty INTELEN Vassilis Nikolopoulos,

Angeliki Bousiou (INT)

V 0.2 12/02/2016 Contribution in Sections 2 and 3 Anastasios Zafeiropoulos, Eleni

Fotopoulou, Paris Liapis,

Thanassis Bouras (UBITECH),

Norma Zanetti (HYPER), Anna

Fensel, Umutcan Simsek

(UIBK), Antonio Skarmeta,

Fernando Terroso-Saenz (UMU)

V 0.3 17/02/2016 Contribution in Section 4 Vassilis Nikolopoulos, Angeliki

Bousiou (INT), Anastasios

Zafeiropoulos, Eleni

Fotopoulou, Paris Liapis,

Thanassis Bouras (UBITECH),

Norma Zanetti (HYPER), Anna

Fensel, Umutcan Simsek

(UIBK), Antonio Skarmeta,

Fernando Terroso-Saenz (UMU)

V 0.4 22/02/2016 Contribution in Section 5 Piera Iorio, Paolo Alderigi,

Giulia Gori (POLO), Aristotelis

Agianniotis, Luc Dufour,

Mariam Barque, Dominique

Genoud (HES-SO), Antonio

Skarmeta, Fernando Terroso-

Saenz (UMU)

V 0.5 22/02/2016 Revised input from INTELEN and UBITECH,

Contribution in Sections 1 and 6

Vassilis Nikolopoulos (INT),

Anastasios Zafeiropoulos

(UBITECH)

V 0.6 01/03/2016 Internal review Stavros Lounis, Vassilis Stavrou

(AUEBELTR), Norma Zanetti (HYPER)

V 0.7 14/03/2016 Final version Vassilis Nikolopoulos (INT),

Anastasios Zafeiropoulos

(UBITECH)


18/05/2017 – v0.1 Page 3 of 41

Executive Summary

The document includes a full technical requirements specifications analysis for the ENTROPY

platform. The list of technical requirements aims to lead the design and implementation of the

ENTROPY architecture and thus all the developments realized within the project. The list of

technical requirements is going to be consolidated along with the list of energy efficiency

requirements identified in ENTROPY Deliverable D1.3 in order to support also the design and

implementation of the recommendation, analysis and gamification mechanisms of the

ENTROPY platform. The technical specifications document include also analytical H/W

information on the pilot sites, regarding the available AMR infrastructure (Sensors, meters,

installations procedures, cabling, tech specs, etc), the full AMI analysis, including the

connectivity and API architecture for data gathering and sensor data storage as well as the basic

technical information of the interconnected ENTROPY modules and the Meter Data

Management system

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 – v0.1 Page 4 of 41


18/05/2017 – v0.1 Page 5 of 41

Table of Contents

1. Introduction ........................................................................................................................ 6

2. Entropy Roles ..................................................................................................................... 7

3. ENTROPY Conceptual Architecture ................................................................................. 8

4. Technical Requirements per layer ................................................................................... 10

4.1 Communications Layer ............................................................................................... 10

4.2 Data Fusion Layer ....................................................................................................... 13

4.1 Analysis Layer ............................................................................................................. 18

4.2 Applications Layer ...................................................................................................... 21

5. ENTROPY PILOT SITES TECHNICAL REQUIREMENTS ....................................... 23

5.1 Navacchio Technology Park – Pilot A ....................................................................... 23 5.1.1 List of H/W IoT Sensors and AMR devices with Technical Specs ...................... 23

5.2 University of Murcia – Pilot B ................................................................................... 28 5.2.1 List of H/W IoT Sensors and AMR devices with Technical Specs ...................... 28

5.3 Technopole – Pilot C ................................................................................................... 34 5.3.1 List of H/W IoT Sensors and AMR devices with Technical Specs ...................... 34

6. Conclusions ...................................................................................................................... 41


18/05/2017 – v0.1 Page 6 of 41

1. INTRODUCTION

In this document, the set of technical requirements that have to be supported by the ENTROPY

platform are detailed. These requirements are going to provide –along with the energy efficiency

requirements detailed in D1.3-“ENTROPY Energy Efficiency Requirements” the starting point

for the design and specification of the ENTROPY conceptual architecture, as it is going to be

provided in deliverable D1.4- “ENTROPY Reference Architecture”.

In order to come up with a list of technical requirements, a set of steps are followed. Initially,

identification of the ENTROPY stakeholders is realized, aiming at presenting the main type of

users that interact with the ENTROPY platform and describing their role. Following, a short

description of the envisaged ENTROPY conceptual architecture is provided, including

information regarding the layers of the architecture and the main components per layer. The

description of the envisaged architecture is required in order to identify requirements per layer

and per component, as well as requirements for appropriate exchange of information across

layers. Then, a set of requirements is presented per layer following a specific template. For each

requirement, information regarding the involved stakeholders, the layer of the architecture, a

short description of the requirements, any associated constraints as well as indication regarding

the priority for supporting such a requirements is provided.

Finally, a short concluding section is provided, summarizing the overall requirements definition

as well as specifying how these are going to be used within the project in the future.


18/05/2017 – v0.1 Page 7 of 41

2. ENTROPY ROLES

In ENTROPY, a set of roles is identified based on the identification of different type of end users

interaction with the ENTROPY platform. The identified roles concern users of the provided

applications, games and platform interfaces, developers and administrators of the ENTROPY

components as well as technology and energy domain experts. Specifically, the following roles

are defined:

- End user: the user that participates to the energy efficiency campaign through the

personalized applications and serious games. It has access to the provided applications

and games through end user devices (e.g. smartphones, laptops, etc.) and provides also

feedback via crowd-sensing mechanisms.

- Platform administrator: the user responsible for providing the configuration, operation

and maintenance of the ENTROPY tools (e.g. sensors registration and configuration,

addition of rules in recommendation engine). It maintains the various modules and is

responsible for software upgrades.

- Building administrator: the user responsible for supervising the energy efficiency

campaigns in a specific building (monitoring of energy consumption, interpretation of

analysis results, and guidelines provision to end users). It usually have access to all the

available building energy monitoring infrastructure and is able to realise advanced

analysis regarding the energy usage profiling of the buildings. He is also responsible for

building energy certification processes.

- Software developer: the user responsible for developing and maintaining the ENTROPY

platform software components. It is responsible for software maintenance, updated and

software quality assurance aspects.

- Data scientist: the user responsible for interpreting analysis results (from the analytics

tools). It usually has consulting role, being able to propose the realization of set of

analysis focused on the end users’ needs, as well as extracting meaningful insights based

on the analysis results.

- Semantic web expert: the user responsible for designing and maintaining the ENTROPY

semantic models. The semantic models are going to be continuously evolved taking into

account novel concepts that have to represented as well as ongoing work in relevant

models. Based on the expressivity provided by the semantic models, a set of

recommendations will be supported.

- Gamification expert: the user responsible for designing and maintaining the ENTROPY

gamification architecture and operationalization of game elements in each launch.

- Energy domain expert: the user that has expertise in the energy domain and is able to

provide guidelines, recommendations and comments with regards to the functionalities

supported with the tools as well as the setup and operation of the pilots.


18/05/2017 – v0.1 Page 8 of 41

3. ENTROPY CONCEPTUAL 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 IoT Data Aggregation Component and

Crowdsensing Data Aggregation Component compose the Communication Layer and are

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

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

devices. On the other hand, the Crowdsensing Data Aggregation Component is responsible for

communicating with 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 realizes the mapping between the

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

and the Energy Efficiency Semantic Model. 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

constantly updates with the latest information the ENTROPY triplestore where the data reside in

a graph format and are ready to get semantically queried. 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 saving data. The

ENTROPY triplestore can be easily interlinked with external public Linked Open Data (LOD)

via the exposed SPARQL endpoint.

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

ENTROPY Big Data Repository and Triplestore in order to feed with data the Analytics Tool,

the Recommendation Engine and the Gaming Engine. The analytics tools aims to realize

Behavioral and Energy Analytics. The results of the analysis helps 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 gets data of the Big Data Repository in order to

parameterize the set of serious Games that augment energetic awareness of the pilot end users.

The recommendation engine also works towards the direction of augmenting the energetic

awareness but in a more personalized and direct way also employing gamification principles.

The recommendation engine realizes semantic queries to the ENTROPY triplestore taking

advantage of the RDFS+ reasoning of the ENTROPY triplestore and sends personalized

recommendations to the consumers.

Finally, in the Application layer reside the ENTROPY personalized applications and serious

games that are made available to the ENTROPY end users. They get input by information

available in the recommendation engine and the gaming engine, while they also provide input

collected via the end user through its interaction with the games and applications.

The conceptual ENTROPY architecture is depicted at Figure 1:


18/05/2017 – v0.1 Page 9 of 41

Figure 1: ENTROPY Conceptual Architecture


18/05/2017 – v0.1 Page 10 of 41

4. TECHNICAL REQUIREMENTS PER LAYER

In this section, a set of requirements are provided per layer of the envisaged ENTROPY

architecture. The full list of requirements, along with the energy efficiency ones identified in

D1.3, are going to be used towards the design and specification of the ENTROPY architecture in

D1.4.

4.1 Communications Layer

In the communications layer, most of the requirements stem from the need to support

mechanisms for establishment of network communication among the sensor nodes and the

aggregation and filtering of the monitored information. Network communication regards the

support of IoT-based network communication protocols along with specific aggregation

schemes. Data collection regards input from sensor nodes, input from building energy

management systems and input from end users devices (e.g. smart phones) and crowd-sensing

mechanisms. Sensors registration and management functionalities are also considered as part of

functionalities that have to be supported in the communications layer. The following

requirements are identified:

ID COM.1

Title Collection of measurements from various sensor nodes

Involved Roles Platform administrator, Software Developer

Description The platform should be able to collect measurements from a wide range of sensor devices (e.g. from water meters, energy meters, microgeneration, environmental conditions, air pollution).

Constraints -

Priority Top

Architectural Part IoT Data Aggregation Component

ID COM.2

Title Support of standardized communication Protocol

Involved Roles Software Developer

Description IoT Data Aggregation Component has to support a wide set of communication Protocols (e.g. OMA LWM2M, CoAP).

Constraints -

Priority Top



18/05/2017 – v0.1 Page 11 of 41

ID COM.3

Title Configuration of data sampling period

Involved Roles Platform Administrator, Software Developer

Description The platform should provide the capacity to configure the sampling period for the collection of data

Constraints IoT nodes should support such configuration option.

Priority Medium


ID COM.4

Title Social Media API

Involved Roles Software Developer, ENTROPY end user (student, teacher, resident)

Description The platform should provide the capacity to get data from a variety of social media feeds (e.g. based on specific tags in twitter or keywords in Facebook)

Constraints Personal information privacy issues, Request limits

Priority Medium

Architectural Part CrowdSensing Data Aggregation Component

ID COM.5

Title Mobile Apps Data Integration


Description The developed mobile applications should provide end user data feeds to the Crowdsensing Data Aggregation Component

Constraints Personal information privacy issues

Priority Medium

Architectural Part CrowdSensing Data Aggregation Component

ID COM.6

Title Sensors registration

Involved Roles Platform Administrator, Building Administrator, Software Developer

Description Support the registration of sensors in the ENTROPY platform along with their type, measurement units and details regarding the communication protocol supported as well as the data collection frequency.

Constraints Support of specific interconnection protocols

Priority Top

Architectural Part IoT nodes registration Component/IoT Data Aggregation Component

ID COM.7

Title Sensors bootstrapping


Description Support the automatic bootstrapping and configuration of different parameters of the sensors

Constraints Support of specific bootstrapping protocols

Priority Top

Architectural Part IoT nodes registration Component/Data Aggregation Component


18/05/2017 – v0.1 Page 12 of 41

ID COM.8

Title Crowdsensing filtering


Description Accept readings from different mobile sensors, like smartphones, restricted to a particular area or sets of user

Constraints Support of advance spatio-temporal rules for filtering incoming sensor data.

Priority Top

Architectural Part Crowdsensing Data Aggregation Component

ID COM.9

Title Crowdsensing user registration

Involved Roles Platform Administrator, Software Developer, End User

Description Allow the registration of different users so that they can send their mobile devices’ measurements to the Data Aggregation Component.

Constraints Support of a common interface that accepts the registration request coming from different mobile applications.

Priority Medium


ID COM.10

Title Social Media Stream Periodic collection


Description Periodically gather documents from social media sites that might be interesting for certain behaviors detection. This refers to temporal, spatial or topic criteria.

Constraints Support of a common interface that accepts the different APIs from a number of social media sites.

Priority Medium


ID COM.11

Title Data Stream Distributed Engine


Description Allow the processing of different data streams by means of a distributed event-based engine. This would allow a suitable scalability of the component.

Constraints

Priority Middle

Architectural Part Data Stream Processing / IoT Data Aggregation Component


18/05/2017 – v0.1 Page 13 of 41

ID COM.12

Title Data Stream General Event Model


Description Definition of a general event model in order to map raw data streams to a common and simple models. This formatted data will be enriched afterwards in the general repository

Constraints Event model depends on the specific data stream engine used for the collection and low-level processing of the data

Priority Top

Architectural Part Data Stream Collection / IoT Data Aggregation Component

4.2 Data Fusion Layer

In the data fusion layer, the collected data from the communication layer have to be processed and made

available to upper layers in order to support a set of analytics, recommendation and gaming

functionalities. Thus, the requirements that stem from this layer have to do with the support of

mechanisms for appropriate representation of the collected information, requirements for reliable and

scalable storage of the collected data as well as requirements regarding the support of interfaces for

fetching info from the analytics component, the recommendation engine and the gaming engine.

Appropriate representation is related with the design and specification of suitable semantic models as well

as the corresponding mapping mechanisms. Storage and querying interfaces are mostly related with the

efficient storage of information as well as the provision of endpoints for fetching of information from the

analysis layer.

The following requirements are identified:


18/05/2017 – v0.1 Page 14 of 41

ID DATA.1

Title Design of Behavioral Semantic Model

Involved Roles Software Developer, Semantic Web Expert

Description Design of Behavioral Semantic Model in order to:

represent the energy related behavioral aspects with high expressivity;

be able to take advantage of the reasoning techniques so as to come up with focused inferences upon the queried data;

use of standard formats like RDF for structuring and linking descriptions of things;

use of links to other related URIs in the exposed data to improve discovery of related information on the Web;

It is desirable to be able to support RDFS+ / OWL-Lite reasoning, depending on the capacity of the underlying reasoning engine of the proposed triplestore.

Constraints Capacity of the ENTROPY Semantic reasoner to infer logical consequences from a set of asserted facts or axioms (the capabilities of the reasoner depend on the selected open-source tool).

Priority Top

Architectural Part Behavioral Semantic Model

ID DATA.2

Title Design of Energy Efficiency Semantic Model


Description Design of Sensor Measurements Semantic Model in order to:

represent with high expressivity, the consumption of energy as measured by a set of monitored sensors and devices

be able to take advantage of the reasoning techniques so as to come up with focused inferences upon the queried data

Use of standard formats like RDF for structuring and linking descriptions of things

Use of links to other related URIs in the exposed data to improve discovery of related information on the Web

It is desirable to be able to support RDFS+ / OWL-Lite reasoning, depending on the capacity of the underlying reasoning engine of the proposed triplestore.

Constraints Capacity of the ENTROPY Semantic reasoner to infer logical consequences from a set of asserted facts or axioms (the capabilities of the reasoner depend on the selected open-source tool).

Priority Top

Architectural Part Energy Efficiency Semantic Model

ID DATA.3

Title Interlinking of Entropy Semantic Models


Description Interlink concepts in the developed ENTROPY semantic models, in order to be able to infer knowledge upon correlation energy consumption characteristics with end users behavioral aspects. Through interlinking, it will be possible to measure the effect of serious gaming activities and recommendations upon the end users behavior.

Constraints Existence of similar concepts between the DATA.1 and DATA.2 semantic models

Priority Top

Architectural Part Behavioral Semantic Model, Energy Efficiency Semantic Model

ID DATA.4

Title Adopt (reuse) existing semantic models


Description Reusing existing ontologies increase the quality of the applications using them, as these


18/05/2017 – v0.1 Page 15 of 41

applications become interoperable and are provided with a deeper, machine-processable and commonly agreed understanding of the underlying domain of interest. Reusing existing ontologies, reduces the costs related to ontology development, because it avoids the re-implementation of ontological components, which are already available on the Web and can be directly—or after some additional customization—integrated into a target ontology. Furthermore, it contributes to an enhancement of the quality of the ontological content, which is going to be continuously revised by various parties. In the framework of ENTROPY, it would be desirable to get based on existing ontologies regarding behavioral and energy concepts. Reusing part of existing ontologies and making some extensions over them, increments the possibilities of adoption of the models from a wide community.

Constraints Find ontologies that represent satisfactorily the concepts of ENTROPY ecosystem.

Priority Medium

Architectural Part Behavioral Semantic Model , Energy Efficiency Semantic Model

ID DATA.5

Title Use of open source frameworks for modeling ontologies


Description Use of open source frameworks for designing / documenting and promoting the Entropy semantic models. Indicative tools could be protégé, TopBraid Composer etc.

Constraints Low software quality issues (limited supported features, low performance, absence of active support community)

Priority Medium

Architectural Part Behavioral Semantic Model, Energy Efficiency Semantic Model

ID DATA.6

Title Data Storage Scalability

Involved Roles Software Developer, Platform Administrator

Description Adoption of a scalable storage solution for historic data coming from users actions and sensors measurements. Given the volume of produced data, the selected data storage should have high performance capacity in terms of data storage and response querying time. The data storage should support High Availability access, data replication and sharding capacities.

Replicas sets provide high availability using automatic failover. Failover should allow secondary members to become primary if the current primary becomes unavailable. Sharding for storing data across multiple machines is a strong requirement since in the framework of ENTROPY, it should be supported deployments with very large data sets and high throughput operations. A good participant could be mongodb with use of JSON-LD format for storing sensors and end-users data.

Constraints Scalable data storage does not support reasoning upon underlying data.

Priority Top

Architectural Part ENTROPY Big Data Repository

ID DATA.7

Title Scalable triplestore


Description Adoption of a scalable triplestore solution for recent/aggregated data coming from users actions and sensors measurements. Given the volume of produced data, the selected data storage should have high performance capacity in terms of data storage and response querying time. The data storage should support High Availability access, data replication and sharding capacities.

In order to keep the response time acceptable and support fast graph processing and reasoning, the ENTROPY Triplestore should get cleaned of unnecessary historic data (that keep being part of the Big Data Repository). A good participant could be the Blazegraph Triplestore for storing recent sensors and end-users data.

Constraints Achieve fast graph processing and reasoning.

Priority Top


18/05/2017 – v0.1 Page 16 of 41

Architectural Part ENTROPY Triplestore

ID DATA.8

Title Reasoning support at least to RDFS / OWL-Lite reasoning.


Description The selection of linked data technologies in the ENTROPY framework is done for two basic reasons. Firstly for achieving high interoperability via a rich expressivity of the data. Secondly in order to facilitate reasoning upon data so as to come up with complex queries and get deep knowledge of the stored data. Ideally OWL-full reasoning would be requested, but performance issues and current implementation of reasoning engines leads to adopt less powerful reasoning with better response times and more accurate decisions. Thus, it would be strongly recommended to be able to support RDFs or/and OWL-lite reasoning.

Constraints Lack of efficient implementation of high level semantic reasoners that make accurate, fast decisions.

Priority Top


ID DATA.9

Title Definition and implementation of a data management policy


Description Define a full workflow so as to:

realize data archiving (reduce the granularity of the collected data);

clean historic data with too high granularity;

realize aggregation of produced data so as to make them better comparable / manageable at the future (e.g. Implement operations upon fine grained data so as to get SUM/AVG day consumption per day/month/year).

Data management process should be configurable depending on the administrators vision about the maintenance of the selected data.

Constraints

Priority Top

Architectural Part ENTROPY Big Data Repository, ENTROPY Triplestore

ID DATA.10

Title Support Authentication mechanisms for access to data

Involved Roles Software Developer, Platform Administrator , End Users

Description Since part of the data will be sensible and may arise data privacy issues, ENTROPY platform should support authentication mechanisms to provide communication between the distinct layers as well as between the platform and the external world.

Constraints

Priority Top


ID DATA.11

Title Support interlinking of ENTROPY triplestore with LOD

Involved Roles Software Developer, Platform Administrator , End Users

Description The Entropy platform should provide interfaces that permit interlinking of entropy data with external RDF datasources (e.g. Explore ENTROPY data sources within the Linda Workbench http://linda.epu.ntua.gr/ )

Constraints Find valuable sources to LOD that can be interlinked with ENTROPY produced Knowledge.

Priority Medium


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


18/05/2017 – v0.1 Page 17 of 41

ID DATA.12

Title RESTful based communication between ENTROPY components


Description There is a need for a low overhead, more standardized (well understood and operate consistently) and human readable and testable way to communicate between ENTROPY components.

REST is proposed because it helps to minimize the coupling between client and server components in a distributed application. It is recommended to provide REST support from Data Fusion Layer to Analysis and Applications Layers. There is also a need of RESTful based communication with the Communication Layer.

Constraints Clear definition of the supported RESTful web services among the ENTROPY partners.

Priority Top


ID DATA.13

Title SPARQL Endpoint provision


Description Expose ENTROPY public SPARQL endpoint with authentication mechanism. Such an endpoint may be used by third-party tools for getting data from the ENTROPY platform.

Constraints

Priority Top


ID DATA.14

Title Data mapping to Semantic models


Description A set of mechanisms should be supported that provide data mapping based on the semantic models in high expressivity format (example: JSON-LD, RDF formats).

Constraints Receive data in a common format from the Communication Layer

Priority Top

Architectural Part Semantic Enrichment Component

ID DATA.15

Title Pull of aggregated data from Aggregation Components in a Common Format


Description Define Interface to pull aggregated data from both IoT Data Aggregation Component and CrowdSensing Data Aggregation Component in a common format. Common format needs extra coordination on behalf of the Pilots data but makes ENTROPY platform more robust and augments the possibilities for the ENTROPY paradigm to be adopted by other institutions.

Constraints Authentication constraints, it is very challenging to obtain common format

Priority Medium

Architectural Part Semantic Enrichment Component

ID DATA.16

Title Fast detection of modified data


Description Develop mechanisms that allow the fast detection of when the data of a sensor or entity of interest has changed in a certain way.

Constraints Potential low response rate of RFD-based repositories (ENTROPY Triplestore)

Priority Top



18/05/2017 – v0.1 Page 18 of 41

4.1 Analysis Layer

In the analysis layer, three different type of functionalities have to be supported. Specifically,

analytics (energy and behavioral), recommendation and gamification mechanisms have to be

implemented supporting a wide set of data mining and analysis algorithms, the creation and

execution of sets of rules that trigger the undertaking of specific actions and recommendations

and the design and creation of a set of mechanisms for development of serious games within

ENTROPY. The following requirements are identified:

ID ANALYSIS.1

Title Support a set of robust algorithms and visualizations

Involved Roles Software Developer, Data scientist, Energy Expert

Description Basic and robust data analytic functionality is needed so as to utilize and share analytic methods for the discovery of meaningful new patterns that are unattainable or hidden in the ENTROPY data. High importance should be given on the design and deployment of tools with emphasis on their user-friendliness. Data scientist should decide what kind of algorithms should be supported. Some indicated widely used algorithms categories could be classification algorithms (decision trees), association algorithms, clustering, multiple linear regression, forecasting-time series algorithms, Factor Analysis, t-test, Cronbach's alpha etc.

Constraints Quality and Quantity of ENTROPY data sources

Priority Top

Architectural Part Analytics Tool

ID ANALYSIS.2

Title Use of open source frameworks for machine learning algorithms

Involved Roles Software Developer, Data scientist

Description Use of open source frameworks for development in the numeric analysis and machine learning spaces. With machines becoming more important as data generators, the need for fast processing and analyzing of data can only be expected to grow. Proposed open source frameworks are the R language, python, big data analysis frameworks such as Apache Spark etc.

Constraints

Priority Top


ID ANALYSIS.3

Title Provide Analytics & Visualization Dashboard

Involved Roles Software Developer, Platform Administrators, Energy Expert

Description Promote Analysis results to ENTROPY Dashboard so as to be easily observable by Platform Administrators. ENTROPY analytics Dashboard should be always updated with latest analytic results. Analytics Dashboard should contain both stream data representation and historic data representation.

Constraints

Priority Top



18/05/2017 – v0.1 Page 19 of 41

ID ANALYSIS.4

Title Development of mechanisms able to process both static and mobile data

Involved Roles Data scientist

Description The platform should include algorithms and tools able to analyze data coming from both static (infrastructure) sensors and mobile ones. This requires a set techniques to detect the relationship between these types of data.

Constraints The variety of types of data sources store in the ENTROPY repository

Priority Top


ID ANALYSIS.5

Title Fast analysis of meaningful changes of data related to entities of interest (e.g. buildings, groups of people, etc.)

Involved Roles Software developer, Data scientist

Description Development of a communication mechanism able to inform to algorithms and tools in the analysis module when a sudden or remarkable change in the data or status of certain entities of interest occurs

Constraints Definition of a common interface between the ENTROPY repository and the analytics tools.

Priority Top


ID ANALYSIS.6

Title Real-time analysis support

Involved Roles Software developer, Data scientist

Description The analysis tool component must be able to perform certain data mining tasks in a timely manner in order to provide results with low latency. Such results could be the detection of certain sudden behaviors that might have an impact on the overall consumption of a building.

Constraints The latency of the RFD-based repository could penalize the timely processing.

Priority Top


ID ANALYSIS.7

Title Recommender System-Application Layer Interface


Description Define an interface to establish communication between recommender engine and application layer which consists of the personalized applications and the game engine

Constraints

Priority High

Architectural Part Recommendation Engine


18/05/2017 – v0.1 Page 20 of 41

ID ANALYSIS.8

Title Recommender System Rule Engine


Description 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.

An issue might raise is that these rule engines usually require knowledge bases to be represented as sets of Java objects. This situation brings the load of conversion of RDF triples to Java objects and vice-versa. Therefore implementation of a simple rule engine that supports RDF triples as knowledge base should be considered.

Constraints Using a third party rule engine will be taken account only if pure SPARQL options fail

Priority Moderate


ID ANALYSIS.9

Title Rule Registration

Involved Roles Software Developer, Platform Administrator, Domain Expert

Description There is a need for registering SPARQL rules to fire them when appropriate contextual conditions occur. Since we operate mostly on RDF, using SPARQL rules is a feasible option. Adoption of SPARQL rules also allows us to share the rules along with the data.

Constraints

Priority High


ID ANALYSIS.10

Title Implicit and Explicit Recommender Engine Tuning

Involved Roles Software Developer, Platform Administrator, Data Scientist

Description There is a need for analyzing implicit and explicit inputs for the recommendation engine tuning. Inputs will come from the data analytics/machine learning outputs and from user ratings on the mobile app, that will tune the recommendation engine

Constraints

Priority High


ID ANALYSIS.11

Title Data-To-Behaviors mapping rules

Involved Roles Software Developer, Data Scientist

Description Specific data maps will be created in the analytics layer that will map energy data analytics outputs to specific behavioral profiles and models. This will be done under the combination of the energy and behavioral analytics profiles. The outputs will be fed to the recommender engine

Constraints

Priority High



18/05/2017 – v0.1 Page 21 of 41

4.2 Applications Layer

The application layer concerns the development of the ENTROPY applications and serious games that are

targeting the engagement and behavioural change of the end users with regards to their energy efficiency

lifestyle. On one hand these applications and games are going to consume information coming from the

recommendation and gaming engine as well as the ENTROPY Database and Triplestore, while it provides

back information to the Entropy Database through direct feedback as well as a set of crowdsensing

mechanisms. Thus, the requirements that have to be fulfilled for this layer regard mainly the support of

appropriate interfaces for exchanging in a reliable and efficient way the aforementioned type of

information. The following requirements are identified:

ID APP.1

Title Provide different Versions based on Users clusters

Involved Roles Software Developer, Platform Administrator, end-users, Domain experts (Gamification, Recommendation, Energy)

Description The developed applications should include the ability to assign different versions of the app to groups of users based on the results of their initial feedback. This will enable platform administrators to conduct pre-launch (and mid-operation) tests to fine tune the incentives and setup. Accomplished by “showing” or “hiding” parts of the UI relative to the user groups.

Constraints

Priority Top

Architectural Part Personalized Applications, Serious Games

ID APP.2

Title Provide Interfaces that support the use of game mechanics


Description The developed applications should provide interfaces that utilize among others Points, Achievements, Goods, Roles, Missions, Feedback, Events, Notifications, Narrative context(s), Avatar introduction, Leaderboards, Social Connections, Team formation etc.

Constraints

Priority Top


ID APP.3

Title Provide Push Notifications


Description The developed applications should provide push notifications/emails to all users, according to their interests and digital content analytics. The engine will follow their performance and digital walk-through and will send personalized messages

Constraints

Priority Top



18/05/2017 – v0.1 Page 22 of 41

ID APP.4

Title Provide Content and Games Administration panel


Description The developed applications should have a central administration panel in order for the Platform administrator to manage and upload content and also manage games and procedures

Constraints

Priority Top


ID APP.5

Title Provide Games KPIs tracking


Description The developed Admin Panel should have specific dashboard for real-time games KPI tracking and engagement performance management. The results will be used for analyzing gamers efficiency and link them with actual savings and statistics

Constraints

Priority Top



18/05/2017 – v0.1 Page 23 of 41

5. ENTROPY PILOT SITES TECHNICAL REQUIREMENTS

In this section, description is provided regarding existing and envisaged installation of ICT

equipment that is going to be realized per pilot site in ENTROPY. The objective is to identify

requirements that have to be taken into account during the pilots’ implementation as well as

requirements that are extracted from existing installations and can provide hints for mechanisms

that have to be supported in the ENTROPY architecture. Towards this direction, a list of the

sensor nodes and network aggregation devices and tools are detailed per pilot, along with

information regarding technological solutions adopted and any constraints identified.

5.1 Navacchio Technology Park – Pilot A

5.1.1 List of H/W IoT Sensors and AMR devices with Technical Specs Navacchio Technology Park will be exploiting the intelligent meters of ENEL for a detailed data

collection on energy consumption. Despite private companies at Polo owning or rent offices

and/or laboratories, have their own meters, Navacchio Technology Park will be able to gather all

due data from a (small) sample of the companies and from all common spaces, services and

facilities it manages, namely: bar and canteen, nursery, guestrooms, auditorium, meeting rooms,

incubator, indoor and outdoor lighting.

Each ENEL Smart Meter will provide the following data:

Meter ID

Energy Consumption (KWh) divided into 3 time slots

Polo's data on energy consumption could be exploited to perform data analytics and to elaborate

the information for an accurate analysis of the performances obtained through the project

solution. In fact, Polo Navacchio annually monitors the needs of companies and the habits of

employees in order to make businesses more competitive, improve workers’ working life and

monitoring energy consumption within the park.

It is worth pointing out that HVAC systems installed within the Park (namely at Polo Navacchio

S.p.A. management offices, in common spaces and at each company premises), particularly

energy intensive, are used for both heating during winter season and cooling in summer. There

are 3 centralized powerhouses working from 7am to 7pm; within these 12 hours, the fan coil

units in each office can be switched on/off with no restriction. Guesthouses have also split-

systems which can be controlled 24H, independently from the powerhouse.

In case of need and to perform comparisons and best practices exchange with the other two

ENTROPY pilots (namely Murcia and HESSO), further off-the-shelf meters and/or IoT sensors

might be integrated in the overall monitoring infrastructure.

Furthermore, concerning weather conditions, forecasts, etc., open data released by Tuscany

Region through its own Lamma consortium (established by Region of Tuscany, the Italian

Research Council and the Foundation for Climate and Sustainability),

http://dati.toscana.it/dataset/stazioni-meteo-idrologiche and http://www.sir.toscana.it/, will be

exploited as additional "sensors" for the pilot itself.

In particular, for environmental conditions monitoring many parameters and related data could

be gathered, namely: temperature, barometric pressure, humidity, wind speed, wind direction,

precipitation, etc.

http://dati.toscana.it/dataset/stazioni-meteo-idrologiche

http://www.sir.toscana.it/


18/05/2017 – v0.1 Page 24 of 41

Use case 1: Managing Subject - Polo Navacchio S.p.A.

Management Polo offices are located on the first floor of Lot 1 buildings. The ground floor is

unheated and the entrance doors are often left open causing more expenditure of energy than

effectively needed to heat the offices positioned on the first floor. The building has 6 offices, 5

toilets, a large mezzanine (35.52 m2) open space, one main entrance space (20.54 m2) and it

occupies a total surface of 325 m2, approximately. ENEL Smart meters for these offices allow to

gather all data for monitoring related energy consumption.

Figure 2 Planimetry of Polo Navacchio S.p.A. offices

Use case 2: Companies belonging to the LOTS involved in the pilot

The main body of Navacchio Techno Park, which will be examined during the project, is divided

into 3 blocks and includes almost 60 high-tech companies (ICT, Energy & Environment,

Microelectronics and Robotics) with approximately 500 employees. As already anticipated in the

introduction section, there are 3 centralized powerhouses working from 7am to 7pm; within

these 12 hours, the fan coil units in each office of the companies premised within the Park can be

switched on/off with no restriction. By monitoring the data at its disposal, Polo Navacchio S.p.A.

has detected energy consumption anomalies especially during summer holidays and other

vacation periods when the offices of the companies are closed. The main electrical infrastructure

of Polo is reported below to show ENEL smart meters deployment, also.


18/05/2017 – v0.1 Page 25 of 41

Figure 3 ENEL Smart Meters deployment for the companies involved in the project pilot

Use case 3: Bar and Canteen

The building has a very large open space used by the bar and canteen (185.94 m2), the kitchen

canteen area (44,25 m2), 4 toilets (15 m2) and five service rooms (33.6 m2). The total surface is

therefore 279 m2, approximately. Companies' employers, visitors, managers, etc. have access to

both bar and canteen. Cafeteria is open from 8.30AM to 5.30PM, while the canteen self-service

is available from 12PM to 2PM. Unfortunately, both during winter and summer people

frequenting this common areas often leave the main doors open with consequent waste of energy

consumption for both heating and cooling. Furthermore, the building temperature during summer

season is colder than needed as detected by Polo Navacchio S.p.A. during yearly surveys.


18/05/2017 – v0.1 Page 26 of 41

Figure 4 Planimetry of Cafeteria and Canteen

Use case 4: GUESTHOUSES

There are four guestrooms managed by Polo Navacchio S.p.A. They have a living area with

kitchenette, dressing room and bathroom with shower and toilet. The rooms are equipped with

refrigerator, dishes, microwave, toaster and hairdryer. Each guesthouse has a total surface of 33.5

m2, approximately.

We may have:

1. Short-term guests (less than one week), whose habits are difficult to be monitored;

2. Long-term guests (one month and over), who can be easily involved in the project.

They usually go back home for the weekend. As already pointed out before, it is rather difficult

to monitor the behavior of guests. However, the involvement of these persons in the pilot is

considered by Polo interesting to prevent possible bad behavioral habits.


18/05/2017 – v0.1 Page 27 of 41

Figure 5 Planimetry of each Guesthouse

Use case 5: Nursery School

Piccole Orme is a nursery school for children from 3 to 36 months. It has an in-house canteen where

balanced meals are prepared according to children’s nutritional needs. The building has 3 multi-functional

rooms (73.40 m2), a large open space (128,84 m2), 5 toilets (23 m2), services spaces (55 m2), one teachers

meeting room (34 m2), mezzanine open space (37,10 m2). The building occupies a total surface area of

352 m2, approximately. Outside there are a garden and two external open galleries (246 m2). This Use

Case is considered very important for the project as there is the intention to involve the teachers in the

surveys to study behavioral habits towards energy consumption in order to monitor how they behave and

proactively exploit ENTROPY serious games to modify their habits in the domain targeted by the project.


18/05/2017 – v0.1 Page 28 of 41

Figure 6 Planimetry of Nursey School

5.2 University of Murcia – Pilot B

5.2.1 List of H/W IoT Sensors and AMR devices with Technical Specs The University of Murcia (UMU) Building Management System is based on the platform called

Open Data. This platform is derived from some improvements and expansions made over the

initial platform presented as Domosec, which was developed by the Dept. of Information and

Communication Engineering of UMU.

This platform is based on multi-user SCADA web technology that centralizes all sensor

information and carries out the intelligent programmed actions. The connection among the

different buildings of the university and the platform is done through IP-based connections.

Depending on the technology of the manufacturer, these connections can be linked directly to a

SCADA or by means of an IP gateways called IPex16. The IPex16 are IP-based controllers able

to connect all kinds of sensors and control units to Internet (Figure 7). IPex16 supports the most

important building technologies and provide an easy way to connect sensors and actuators to the

platform. This controller can be used to connect non-IP sensors or actuators to the network or

also can be used as gateway between different technologies (wired and wireless).


18/05/2017 – v0.1 Page 29 of 41

Fig. 7. Overview of the Open Data System in UMU Pilot

Currently, the UMU facilities have a set of these controllers installed in different buildings to

connect sensors, actuators and non-IP Control Unit to the control network of the Open Data

platform. The kind of collected data is related with environmental parameters such as

temperature, humidity and lighting, there are multiple presence sensors installed in strategic

building points as well as an access control system based on RFID for each monitored building.

There are energy meters measuring the real consumption due to HVAC and lighting systems, etc.

In this direction, the main actions carried out by the Open Data platform are related with systems

regulation to provide efficient services of security, energy efficiency, comfort provisioning, etc.

to the university community.

In addition to that, the described management system has been adapted so as to be compliant

with the FI-WARE architecture [521-2]. In brief, FI-WARE is a platform that intends to ease de

development of novel applications based on the Future Internet. In particular, the Orion Context

Broker (OCB) [521-3] and the COMET [532-4] modules are to be used in order to store in a

mongoDB repository the historical data comprising the measurements from the different

datasources. In both cases, such modules are accessed by means of a REST API based on NGSI

9 & 10.

Now we will describe the deployment in the reference buildings acting as use cases.

Use case 1: Faculty of Chemistry.

The Faculty of Chemistry of the University of Murcia is the heir of the former Faculty of

Sciences began offering the Bachelor of Science (Chemistry Section) in 1944. The Degree in

Chemistry is therefore one of the oldest in the UMU. The building has 6 floors and it occupies a

surface area of 1500 m2 the largest floor, approximately.

Nowadays, the building sensor deployment allows an indoor temperature monitoring with 239

temperature sensors embedded in HVAC systems in different rooms of the building (e.g. offices,

labs, etc.). In addition to that, an energy consumption meter also allows to collect several energy

measurements related to the whole facility. Moreover, the weather forecast of the region is


18/05/2017 – v0.1 Page 30 of 41

extracted from two public web sites, Open Weather Map1 and AccuWeather2. Other details of

such a building are provided in Table 1. Lastly, the detailed list of the sensor infrastructure of the

building is included in Fig. 8.

Name Chemistry Faculty Envelope area 1500

Address Espinardo Campus Glazed area

City/Post code Murcia/30100 Country Spain

Location (coordinates)

Latitude: 38.020939 Longitude:-1.169722

Orientation South-West

Altitude (m) Unknown Year of construction

1944

Typology of building

University Faculty Heating System Splits

Lighting System Light bulbs (not controlled)

Floors 6

Alarm System Fire detection system

Access Control System

None

Water distribution 2 pump drives

Table 1: UMU Faculty of Chemistry Building Characterization

1 http://openweathermap.org/ 2 http://www.accuweather.com/


18/05/2017 – v0.1 Page 31 of 41

Figure 8: List of H/W IoT Sensors and AMR devices with Technical Spec for UMU Faculty of Chemistry


18/05/2017 – v0.1 Page 32 of 41

Use Case 2: Technological Transfer Centre (TTC) of the University of Murcia

This building is used by technological companies and some research groups that collaborate with

companies developing industrial scientific projects. The building has a wide deployment of

sensors and devices integrated in a home automation system which is working to improve indoor

comfort at the same time that energy is saved. In addition to that, the current environmental

conditions of the surrounding area of the building are gathered by means of the AccuWeather

web service and a local weather station. Moreover, the weather forecast of the region is

extracted from two public web sites, Open Weather Map and AccuWeather. Other

details of such a building are provided in Table 2. Lastly, the detailed list of the sensor

infrastructure of the building is included in Fig. 8.

Name Technological

Transfer Centre

Fuente Alamo

Country Spain

Address Estrecho-Lobosillo Road Km 2

Orientation South-West

City/Post code Fuente Álamo (Murcia)/ 30320

Year of construction

2004

Location (coordinates)

Latitude: 37.724383 Longitude: 1.093324

Heating System Splits

Altitude (m) Unknown

Typology of building

Incubator

Lighting System Light bulbs (not controlled)

Alarm System Fire detection system

Table 2: UMU TTC Building Characterization


18/05/2017 – v0.1 Page 33 of 41

Figure 9: List of H/W IoT Sensors and AMR devices with Technical Spec for UMU TTC


18/05/2017 – v0.1 Page 34 of 41

5.3 Technopole – Pilot C

5.3.1 List of H/W IoT Sensors and AMR devices with Technical Specs The data are stored in mongo Database or Axibase. The local weather station is connected by

Wifi. The data from regional weather station are collected by an API. The installations of new

smart meters in ENTROPY project used Zwave communication protocol. The data are stored

Axibase. The data are formatted in JSON.

The global active power is collected every second by a beckhoff smart metering which compute

the number impulses on the global electrical meter. ELKO smart meters collect the active power

and the reactive power every second for the production by photovoltaique panel. The APi Go of

MongoDB with the TCP/IP protocol enable the storage in mongo Database. An API REST

enables the connection between the Mongo Database, Axibase and an analysis software .The

data are formatted in JSON. Actually, data’s from gamers (Customers number predicted, real

customer number) are stored in excel file.

Figure 10: Information system installed in technopole

Use Case 1: Mikado

Mikado is the name of the restaurant located in the Technopole site. The restaurant is

comprised of five zones: one zone is in the entrance of the restaurant, two zones are in the

main dining room, one zone is in the kitchen and one zone is in the room of fridges and

freezers. Outside the restaurant there is a terrace. Mikado is frequented by the Staff of the

restaurant (Proprietors, Cooks, Waiters, Other kitchen staff), and the clients. Practically

clients are people working in the Technopole site (including people form the IIG, the IEM,

and Icare), as well as people external to Technopole (mostly visitors). The total count of

clients per day is recorded. Actually there is no control of presence and entering/exciting

Mikado is done without an RFID card. A detection of presence (being aware of how many

people are inside the restaurant each moment, without identifying peoples ID), will be

possible in the future.


18/05/2017 – v0.1 Page 35 of 41

Figure 11: MIKADO localization in technopole

Figure 12: MIKADO Building Characterization

Parameter Value Name MIKADO

Building TP10

Building Level 0

ID 201'046'862.004

Size 168.7m2

Week-end Work No

Base Line (Kw) 3

Construction year 2000


18/05/2017 – v0.1 Page 36 of 41

Installed

In progress

Name

uses cases

Data

characterization

Name

sensorFrequency Parameters

Parameters

description

Database

storage

type

Access

Data

type

Format URL

Sensorname Mikado

granDatas Granularity

(second)

format csv/json

fronts timestamp start

tots timestamp end

paramdouble : ActivePower1

(KiloWatt)

Sensorname ELKOPROD01


(second)

format csv/json

fronts timestamp start

tots timestamp end

param

ActivePower1(KiloWatt)

Activepower2(KiloWatt)

ActivePower3(KiloWatt)

ReactivePower1(VAR)

ReactivePower2(VAR)

ReactivePower3(VAR)

Battery 1s KiloWatt (KW)

People Number 1s

Menu t - 1 week "" "" "" xls

Custormers number prediction for lunch t - 1 week "" "" "" xls

Real Custormers number for lunch Day "" "" xls

Inside temperature 1s

Global Hot/Cool water flux level 1s

Global gaz building TP10 consumption gaz Flow Gaz flow (Kwh) "" "" xls

Global water building TP10 consumption Water Flow Water Flow(m3) "" "" xls

MongoDB

API REST

API REST

API REST

Axibase API REST

Global Active power consumption MongoDB

Active and Reactive power production

Month

http://194.209.53.12/dowload?sens

orname=Mikado

&gran=1

&format=json

&fromts=1393628400000

&tots=1396628400000


orname=ELKOPROD01

&gran=1

&format=json

&fromts=1393628400000

&tots=1396628400000

1s

ELKO

Axibase

Concierge

JSON

JSON

JSON

Bechkoff

Mikado

Proprietor

Figure 13: List of H/W IoT Sensors and AMR devices with Technical Spec for Mikado

Use Case 2 : IIG + IEM + Icare

The Institute of Information Systems (IIG) and the Institute of Entrepreneurship and

Management (IEM) are two distinct environments comprised of a set of offices, other rooms

(e.g., room with printer/scanner/photocopy machine, meeting rooms), and corridors.

The research institute Icare is located next to the IIG. Its layout is similar to that of the institutes.

It comprises offices, meeting rooms, and corridors.The history of the electrical energy

consumption is represented in yellow. In orange, they are the new part of the building (electrical

energy consumption) which monitored in entropy project.

Each institute has its own entrance/exit (there are two external doors for IIG and IEM, and one

for Icare). Entering each institute necessitates using a personal RFID card, whereas exiting is

done without the use of the card. The offices inside the institutes are usually occupied by one or

more users and meeting rooms may be used by anyone. Moving from one room to another is free

and there is no control of entrance or detection of presence. Presence detectors will be installed

to some rooms of the IIG in the future.


18/05/2017 – v0.1 Page 37 of 41

Figure 14: IIG, IEM and ICARE institutes localization in technopole

IEM, entrepreneurship and management institute

Figure 15: IEM localization in technopole


Building TP3

Building Level 1

ID 201'046'862.004

Size 463.5m2

Week-end Work No


ICARE

IIG IEM


18/05/2017 – v0.1 Page 38 of 41

Installed

In progress

Name

uses cases

Data

characterization

Name


Parameters

description

Database

storage

type

Access

Data

type

Format URL

Sensorname KiloWatt(KW)


(second)

format csv/json

fronts timestamp

tots timestamp

param double : ActivePower1

Global Inside temperature °C

Global Hot/Cool water flux level ""

Global People Number Door 3 ""


Inside temperature Room X1 °C



Hot/Cool Water flux Room X1 int : [0;…;5]



Global gaz building TP3 consumption Gaz Flow Gaz flow (Kwh) "" ""

Global water building TP3 consumption Water Flow Water Flow(m3) "" ""xls

API REST JSON

API REST JSON

Month

Axibase

1s


orname=Beckhoff_TP3_122

&gran=1

&format=json

&fromts=1393628400000

&tots=1396628400000

Global Active power Bechkoff MongoDB

IEM

Concierge

Figure 16: List of H/W IoT Sensors and AMR devices with Technical Spec for IEM

IIG, information system institute

Figure 1: IIG localization in technopole

Figure 17: IIG localization in technopole


Building TP3 + TP5

Building Level 1

ID 19,406,654

Size 896.4m2

Week-end Work No



18/05/2017 – v0.1 Page 39 of 41

Installed

In progress

Name

uses cases

Data

characterization

Name


Parameters

description

Database

storage

type

Access

Data

type

Format URL

Sensorname KiloWatt(KW)


(second)

format csv/json

fronts timestamp

tots timestamp


Global Inside temperature °C

Global Hot/Cool water flux level int : [0;…;5]






Hot/Cool Water flux level Room X1 int : [0;…;5]



Global gaz building TP3+TP5 consumption Gaz Flow Gaz flow (Kwh) "" "" xls

Global water building TP3 + TP5 consumption Water Flow Water Flow(m3) "" "" xls

JSON

API REST JSON

API REST

Axibase

1s

Month

Bechkoff1/2 Global Active power consumption


orname=Beckhoff_TP3_126

&gran=1

&format=json

&fromts=1393628400000

&tots=1396628400000

MongoDB

IIG

Concierge

Figure 182: List of H/W IoT Sensors and AMR devices with Technical Spec for IIG

Icare institute

Figure 19: ICARE localization in technopole


Building TP10

Building Level 1

ID 12,272,861

Size 196.1.5m2

Week-end Work No



18/05/2017 – v0.1 Page 40 of 41

Installed

In progress

Name

uses cases

Data

characterization

Name


Parameters

description

Database

storage

type

Access

Data

type

Format URL

Sensorname Icare_TP10

gran

format csv/json

fronts timestamp

tots timestamp





Global gaz building TP10 consumption gaz Flow Gaz flow (Kwh) "" ""

Global water building TP10 consumption Water Flow Water Flow(m3) "" ""xls


orname=Icare_TP10

&gran=1

&format=json

&fromts=1393628400000

&tots=13966284000001s

API REST

API REST

JSON

Month

Axibase

MongoDBGlobal Active power consumption Bechkoff

Icare

Concierge

Figure 20: List of H/W IoT Sensors and AMR devices with Technical Spec for ICARE

Finally, we have the same weather data for all uses cases. We use a local weather station in

Technopole and a station located in Montana to have weather data predicted.

Installed

In progress

Name

uses cases

Data

characterization

Name


Parameters

description

Database

storage

type

Access

Data

type

Format URL

Hourly precipitation sums ending at the indicated

time, Sierre

Snow height , Sierre

Wind speed at 10m, Sierre

Wind direction at 10m, Sierre

Temperature at 2m, Sierre

Air Dewpoint Temperature, Sierre

Global shortwave Radiation, Sierre

Sun duration,Sierre

Total cloud area fraction [0..1],Sierre

Surface pressure,Sierre

Surface pressure reduced

to mean sea level,Sierre


time, Montana

Snow height , Montana

Wind speed at 10m, Montana

Wind direction at 10m, Montana

Temperature at 2m, Montana

Air Dewpoint Temperature, Montana

Global shortwave Radiation, Montana

Sun duration,Montana

Total cloud area fraction [0..1],Montana

Surface pressure,Montana

Surface pressure reduced

to mean sea level,Montana


time predicted , Montana

Snow height predicted, Montana

Wind speed at 10m predicted, Montana

Wind direction at 10m predicted, Montana

Temperature at 2m predicted, Montana

Air Dewpoint Temperature predicted, Montana

Global shortwave Radiation predicted, Montana

Sun duration predicted,Montana

Total cloud area fraction [0..1] predicted,Montana

Surface pressure predicted,Montana

Surface pressure reduced predicted

to mean sea level predicted ,Montana

All uses cases Axibase API REST JSON

1 min

10 min

1h

Weather

station

technopole

Weather

station

Montana

Weather

station

Montana


18/05/2017 – v0.1 Page 41 of 41

6. CONCLUSIONS

In this document, the set of technical requirements for the development of the ENTROPY

platform is identified and presented. Upon the identification of the ENTROPY stakeholders,

requirements are detailed per layer of the envisaged architecture and namely the

Communications, Data Fusion, Analysis and Application layers. The set of identified

requirements regard functionalities that have to be supported per ENTROPY layer and

component, type of protocols and mechanisms that have to be supported (e.g. communication

protocols for IoT data collection), definition of interfaces for interconnection of components

within the layer or throughout the identified layers and interfaces for interaction with the

ENTROPY end users. In addition to the list of requirements per layer of the architecture,

description of the envisaged deployments per pilot case is provided, aiming at the identification

of pilot-specific requirements that have also to be taken into account (e.g. constraints in

deployment, technical limitations).

The existing list of requirements is considered crucial for the design and specification of the

ENTROPY architecture. However, further requirements may be also added, or existing ones may

be partially updated, prior to the description of the ENTROPY architecture in M9. Such an

update may be necessitated by evolution of the considered technologies or any extra

requirements that may be identified during the pilots detailed definition phase (documented in

D1.5 in M9).

Documents

649849 ENTROPY Design of an Innovative Energy …...649849 ENTROPY D1.2 ENTROPY Technical Requirements 18/05/2017 – v0.1 Page 7 of 41 2. ENTROPY ROLES In ENTROPY, a set of roles