649849 ENTROPY Design of an Innovative Energy …...649849 ENTROPY D1.2 ENTROPY Technical...
Transcript of 649849 ENTROPY Design of an Innovative Energy …...649849 ENTROPY D1.2 ENTROPY Technical...
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)
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 4 of 41
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
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 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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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:
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 9 of 41
Figure 1: ENTROPY Conceptual Architecture
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Architectural Part IoT Data Aggregation Component
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Architectural Part IoT Data Aggregation Component
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
Involved Roles Software Developer
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
Involved Roles Platform Administrator, Building Administrator, Software Developer
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 12 of 41
ID COM.8
Title Crowdsensing filtering
Involved Roles Platform Administrator, Software Developer
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
Architectural Part Crowdsensing Data Aggregation Component
ID COM.10
Title Social Media Stream Periodic collection
Involved Roles Platform Administrator, Software Developer
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
Architectural Part Crowdsensing Data Aggregation Component
ID COM.11
Title Data Stream Distributed Engine
Involved Roles Platform Administrator, Software Developer
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 13 of 41
ID COM.12
Title Data Stream General Event Model
Involved Roles Platform Administrator, Building Administrator, Software Developer
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:
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Involved Roles Software Developer, Semantic Web Expert
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
Involved Roles Software Developer, Semantic Web Expert
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
Involved Roles Software Developer, Semantic Web Expert
Description Reusing existing ontologies increase the quality of the applications using them, as these
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Involved Roles Software Developer, Semantic Web Expert
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
Involved Roles Software Developer, Platform Administrator
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
Involved Roles Software Developer, Semantic Web Expert
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
Architectural Part ENTROPY Triplestore
ID DATA.9
Title Definition and implementation of a data management policy
Involved Roles Software Developer, Platform Administrator
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
Architectural Part ENTROPY Big Data Repository, ENTROPY Triplestore
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
Architectural Part ENTROPY Triplestore
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 17 of 41
ID DATA.12
Title RESTful based communication between ENTROPY components
Involved Roles Software Developer
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
Architectural Part ENTROPY Big Data Repository, ENTROPY Triplestore
ID DATA.13
Title SPARQL Endpoint provision
Involved Roles Software Developer, Semantic Web Expert
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
Architectural Part ENTROPY Triplestore
ID DATA.14
Title Data mapping to Semantic models
Involved Roles Software Developer
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
Involved Roles Software Developer
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
Involved Roles Software Developer
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
Architectural Part ENTROPY Triplestore
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Architectural Part Analytics Tool
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
Architectural Part Analytics Tool
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Architectural Part Analytics Tool
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
Architectural Part Analytics Tool
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
Architectural Part Analytics Tool
ID ANALYSIS.7
Title Recommender System-Application Layer Interface
Involved Roles Software Developer
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 20 of 41
ID ANALYSIS.8
Title Recommender System Rule Engine
Involved Roles Software Developer
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
Architectural Part Recommendation Engine
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
Architectural Part Recommendation Engine
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
Architectural Part Recommendation Engine
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
Architectural Part Recommendation Engine
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Involved Roles Software Developer, Platform Administrator
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
Architectural Part Personalized Applications, Serious Games
ID APP.3
Title Provide Push Notifications
Involved Roles Software Developer, Platform Administrator
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
Architectural Part Personalized Applications, Serious Games
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 22 of 41
ID APP.4
Title Provide Content and Games Administration panel
Involved Roles Software Developer, Platform Administrator
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
Architectural Part Personalized Applications, Serious Games
ID APP.5
Title Provide Games KPIs tracking
Involved Roles Software Developer, Platform Administrator
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
Architectural Part Personalized Applications, Serious Games
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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).
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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/
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
granDatas Granularity
(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
http://194.209.53.12/dowload?sens
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.
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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
Parameter Value Name MIKADO
Building TP3
Building Level 1
ID 201'046'862.004
Size 463.5m2
Week-end Work No
Construction year 2000
ICARE
IIG IEM
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 38 of 41
Installed
In progress
Name
uses cases
Data
characterization
Name
sensorFrequency Parameters
Parameters
description
Database
storage
type
Access
Data
type
Format URL
Sensorname KiloWatt(KW)
granDatas Granularity
(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 ""
Global People Number Door 4 ""
Inside temperature Room X1 °C
Inside temperature Room X2 °C
Inside temperature Room X3 °C
Hot/Cool Water flux Room X1 int : [0;…;5]
Hot/Cool Water flux Room X2 int : [0;…;5]
Hot/Cool Water flux Room X3 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
http://194.209.53.12/dowload?sens
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
Parameter Value Name MIKADO
Building TP3 + TP5
Building Level 1
ID 19,406,654
Size 896.4m2
Week-end Work No
Construction year 2000
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 39 of 41
Installed
In progress
Name
uses cases
Data
characterization
Name
sensorFrequency Parameters
Parameters
description
Database
storage
type
Access
Data
type
Format URL
Sensorname KiloWatt(KW)
granDatas Granularity
(second)
format csv/json
fronts timestamp
tots timestamp
param double : ActivePower1
Global Inside temperature °C
Global Hot/Cool water flux level int : [0;…;5]
Global People Number Door 1 ""
Global People Number Door 2 ""
Inside temperature Room X1 °C
Inside temperature Room X2 °C
Inside temperature Room X3 °C
Hot/Cool Water flux level Room X1 int : [0;…;5]
Hot/Cool Water flux level Room X2 int : [0;…;5]
Hot/Cool Water flux level Room X3 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
http://194.209.53.12/dowload?sens
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
Parameter Value Name MIKADO
Building TP10
Building Level 1
ID 12,272,861
Size 196.1.5m2
Week-end Work No
Construction year 2000
649849 ENTROPY D1.2 ENTROPY Technical Requirements
18/05/2017 – v0.1 Page 40 of 41
Installed
In progress
Name
uses cases
Data
characterization
Name
sensorFrequency Parameters
Parameters
description
Database
storage
type
Access
Data
type
Format URL
Sensorname Icare_TP10
gran
format csv/json
fronts timestamp
tots timestamp
param double : ActivePower1
Global People Number Door 5 ""
Global People Number Door 6 ""
Global People Number Door 7 ""
Global gaz building TP10 consumption gaz Flow Gaz flow (Kwh) "" ""
Global water building TP10 consumption Water Flow Water Flow(m3) "" ""xls
http://194.209.53.12/dowload?sens
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
sensorFrequency Parameters
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
Hourly precipitation sums ending at the indicated
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
Hourly precipitation sums ending at the indicated
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
649849 ENTROPY D1.2 ENTROPY Technical Requirements
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).