#  Executive Summary

_«The VICINITY project will build and demonstrate a bottom-up ecosystem of
decentralised interoperability of IoT infrastructures called virtual
neighbourhood, where users can share the access to their smart objects without
losing the control over them.»_

The present document is a deliverable “D9.4 – Data Management Plan” of the
VICINITY project (Grant Agreement No.: 688467), funded by the European
Commission’s Directorate-General for Research and Innovation (DG RTD), under
its Horizon 2020 Research and Innovation Programme (H2020). This is the third
version of the project Data Management Plan (DMP) and contains updated
information about datasets generated or collected through the project. This
includes information on whether and how it will be exploited or made
accessible for verification and re-use, and how it will be curated and
preserved.

The purpose of the Data Management Plan is to present a way forward with the
data management policy that has been used by the consortium. This is made with
regard to all the datasets

generated by the project. The datasets referred to in this document were
completed during the first stages (completed 15  th  of January 2019) of the
project. The document can only reflect the intentions of the project partners
toward the final project’s datasets. This third and final version (D9.4) will
be put in effect the 31  st  December 2019 and follows the H2020 guidelines on
Data Management Plans, and as stated in the Grant Agreement 688467.

Changes in this final document is caused by some changes in the organisations,
the datasets from the use cases, more legal considerations are being
presented, as well as the project have received a lot more information from
Open Call winners. As the project progressed and the partners gained insight
in results, the datasets were elaborated on. The detailed descriptions of all
the specific datasets that were collected are described and made available
under the relevant Data Management framework.

All personal data, or data directly related to the residents, was collected
after the project received a signed informed consent form from the
stakeholders participating in the pilots. The DMP will also be put in effect
after the completion of the project as it presents a structure that follows
guidelines The DMP is not a fixed document and evolved during the lifespan of
the project (Figure 1).

**Figure 1: Data Management Plan – deliverables 2016 – 2019**

Note: In order to assist the official project review process by the Commission
for the first project period (M1-M18), a preliminary version of the updated
DMP of D9.3 was delivered prior to M20 (August 2017) in order to be enable a
better assessment of the progress of the Data Management. The preliminary
version was accepted, and laid the groundwork for this third and final
version.

#  Introduction

The purpose of the Data Management Plan (DMP) deliverable is to provide
relevant information concerning data collected and used by the partners of the
project VICINITY. The projects aim was to develop a solution defined as
“Interoperability as a Service”. This concept became a part of the VICINITY
Open Gateway (Figure 2), and was achieved by implementing a platform for
harvesting, converting and sharing data from IoT devices on the service layer
of the network.

**Figure 2: Domains and some of the functionalities the DMP covers**

This goal entails the need for good documentation and implementation of
descriptors, lookup-tables, privacy settings and intelligent conversion of
data formats. The strength of having a cloud-based gateway is that it should
be relatively simple to upgrade with new specifications and implement
conversion, distribution and privacy strategies. In particular, the privacy
part is considered an important aspect of the project, as VICINITY needs to
follow and adhere to strict privacy policies. It will also be necessary to
focus on possible ethical issues and access restrictions regarding personal
data so that no regulations on sensitive information are violated.  
  
<table>  
<tr>  
<th>

**Purpose of access restrictions: Right of access, Art. 15:**

  * Purposes of processing 

  

  * Affected categories of personal data 

  

  * Recipients or categories of recipients 

  

  * Expected storage time 

  

  * All available information on where the personal data originated 

  

  * The occurrence of automated decisions 

  

</th> </tr> </table>

**Table 1: GDPR on right of access**

The datasets collected belong to four main domains;

  1. Smart energy and buildings as demonstrated by ENERC in Portugal and tested at AAU in Denmark. 

  

  2. Mobility as demonstrated by HITS in Norway and tested at AAU. 

  

  3. Smart home as demonstrated by the Norwegian partners HITS and TINYM and tested at AAU. 

  

  4. eHealth as demonstrated by GNOMON and CERTH in Greece. 

  

  

(Figure 3: Example of potential data points in use cases that generate data.).

Several standards and guidelines were taken into consideration that the
project needs to be aware within each of these fields. A number of different
vendors and disciplines are involved – and much of the information that is
available only exists in proprietary data formats. For this reason, VICINITY
will target IoT units that follow the specifications defined by oneM2M
consortium, ETSI standardization group and international groups and
committees.

The DMP has been undergone some changes in particular in regards to agreement
concerns when storing and handling data after the completion of VICINITY. This
version of the document is based on the knowledge generated through
discussions, demonstrations and preparations for deployment at pilot sites.

**Figure 3: Example of potential data points in use cases that generate
data.**

#  General Principles

##  3.1. IPR management and security

As a research and innovation action, VICINITY aims at developing an open
framework and gateway – demonstrated through a subset of Value-Added Services
and the related business models. The project consortium includes partners from
private sector, public sector and end-users (Table 4). Some partners may have
Intellectual Property Rights on their technologies and data. Consequently, the
VICINITY consortium will protect that data and crosscheck with the concerned
partners before data publication.  
  
<table>  
<tr>  
<th>

**Partner**

</th>  
<th>

**Sector**

</th>  
<th>

**Domain**

</th>  
<th>

**IPR**

</th> </tr>  
<tr>  
<td>

ATOS Spain SA (ATOS)

</td>  
<td>

Private

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Aalborg University (AAU)

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Bavenir S.R.O. (BVR)

</td>  
<td>

Private

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Centre for Research and Technology Hellas

</td>  
<td>

Public

</td>  
<td>

Health

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Climate Associates Limited (CAL)

</td>  
<td>

Private

</td>  
<td>

Environ mental

consulta ncy

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Enercoutim (ENERC)

</td>  
<td>

Private

</td>  
<td>

Energy,

Buildings

O&M

services

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Gnomon Informatics S.A. (GNOMON)

</td>  
<td>

Private

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Gorenje Gospodinjski Aparati D.D. (GRN)

</td>  
<td>

Private

</td>  
<td>

White goods and services

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Hafenstrom AS (HITS)

</td>  
<td>

Private

</td>  
<td>

Mobility

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Hellenic Telecommunications Organization S.A. (OTE)

</td>  
<td>

Private

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Intersoft A.S. (IS)

</td>  
<td>

Private

</td>  
<td>

</td>  
<td>

X

</td> </tr>  
<tr>  
<td>

Municipality of Pilea-Hortiatis (MPH)

</td>  
<td>

Public

</td>  
<td>

Health

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Technical University of Kaiserslautern (UNIKL)

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Tiny Mesh AS (TINYM)

</td>  
<td>

Private

</td>  
<td>

Building

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Universidad Politecnica de Madrid (UPM)

</td>  
<td>

Public

</td>  
<td>

Energy

</td>  
<td>

</td> </tr> </table>

**Table 4: The VICINITY consortium includes partners from different sectors
with confidential data**

A holistic security approach has been followed, in order to protect the
pillars of information security (confidentiality, integrity, availability).
The security approach consists of a methodical assessment of security risks
followed by their impact analysis. This analysis is performed on the personal
information and data processed by the proposed system, their flows and any
risk associated to their processing.

Security measures include secure protocols (HTTPS and SSL), login procedures,
as well as protection against bots and other malicious attacks such as CAPTCHA
technologies. Moreover, the VICINITY pilot sites apply procedures related to
the data collection, their integrity and protection. The data protection and
privacy of personal information include protective measures against
infiltration as well as physical protection of core parts of the systems and
access control measures.

##  3.2. Personal Data Protection

The VICINITY architecture does not expose, use or analyse data. However, some
activities have involved human participants and utilize Value-Added Services
(VAS) that may operate on datasets. The pilots have been conducted in real
apartments and cover real use scenarios related to health monitoring, booking,
home management, governance, energy consumption and other various human
activity and behaviour analysis –related data gathering purposes. Some of the
activities that were carried out by the project gathered some basic personal
data (e.g. name, background, contact details, interest, IoT units and assigned
actions), even though the project avoided collecting such data unless data is
really necessary for the application.

Such data is protected in accordance with the EU's Data Protection Directive
95/46/EC  1  “on the protection of individuals with regard to the processing
of personal data and on the free movement of such data” and of the Council of
24 October 1995 on the protection of individuals with regard to the processing
of personal data and on the free movement of such data ( **Fehler!
Verweisquelle konnte nicht gefunden werden.** ).

Info windows containing relevant links and descriptions to GDPR Articles and
sections as well as best practice are placed throughout this deliverable.  
  
<table>  
<tr>  
<th>

**General Data Protection Regulation is a common regulation for all EU/EEA
countries. GDPR introduced several changes in privacy legislations and new
privacy rules May 25, 2018. It represents a significant tightening of rules
and possibility of large fines in case of breach.**

This also includes more stringent requirements for documentation of IT systems
and security solutions (Art. 28):

• Fines up to EUR 20,000,000 or 4% of the company's turnover (Art. 79) •
Inadequate data security for the processing of personal data will have such
high financial risk that it must be reported in annual and audit reports

</th> </tr> </table>

**Table 2: General Data Protection Regulation description**

This document aims to address issues related to responsibilities as there are
considerations to be made when several partners and external stakeholders
involved. Examples of such issues are what actions that are to be undertaken
by project coordinator, responsibilities assigned to partner organisations and
the role of the ethics committee in handling data. This is even more prominent
with the number of Open Call winners that have access to the innovation
results – but which also have their own legal contacts as well as third party
suppliers. Who can ensure the data is actually gone – and who are responsible
if traces still can be found? Additionally, a project such as VICINITY also
has providers of value-adding services that are either within or outside the
ecosystem that the partners in the project have direct control over. This is
just the beginning; Who is responsible if personal data that violates the
regulations should have been stored? Or rather; what happens if the personal
data is leaked or used incorrectly?

That being said, GDPR does not represent a big issue for most the partners in
VICINITY as it only applies to data where a person can directly be identified
by the stored information. The labs are using test users, and therefore have
other concerns to made. That being said - it is still a good habit to follow
up and have proper data management strategies, regardless of what is being
stored. Thus, a reminder will be sent to the partners at the end of the
project, requesting partners and Open Call winners to remove or anonymize data
in accordance with GDPR.

WP3 and WP4 activities dealing with the implementation and deployment of core
components have been performed in Slovakia under leadership of local partners
(BVR and IS). For this reason, the solution will be reviewed for compliance
with Data Protection Act No. 122/2013 approved by National Council of the
Slovak Republic together with its amendment No. 84/2014 which already reflects
the EC directive proposal 2012/0011/COD.

WP7 and WP8 activities have been performed in Greece, Portugal and Norway
under the leadership of local partners. In the following the consortium
outlines the legislation for the countries involved in the Trial:

  1. Greek Trial in Municipality of Pilea-Hortiatis, Thessaloniki, for Greece, legislation includes “Law 2472/1997 (and its amendment by Law 3471/2006) of the Hellenic Parliament”. 

     * Regulatory authorities and ethical committees: Hellenic Data Protection Authority http://www.dpa.gr/ 

  

  

  2. Norwegian trials in Teaterkvarteret healthcare assisted living home in Tromsø and offices in Oslo Sciencepark, Oslo, have to comply with national legislation “Personal Data Act of 14 April No.31” 5relating to the processing of personal data. 

     * Each pilot demonstration has to notify regulatory body Datatilsynet pursuant to section 31 of the Personal Data Act and section 29 of the Personal Health Data Filing System Act. 

  

  

  3. Portuguese Trial in Martim Longo microgrid pilot site in the Algarve region, Portugal. The Portuguese renewable energy legislative base dates back to 1988, and was upgraded and reviewed multiple times since then. The most important legislative diplomas are listed; DL 189/88, DL 168/99, DL 312/2001, DL 68/2002, DL 29/2006 and DL 153/2014. The last on the list refers to also one of the most important legislative changes, being the legislative base for broad based auto-consumption, with possibility to inject excess energy in to the grid under certain conditions. 

     * The collection and use of personal data in Portugal are regulated by the following two laws: “Law 41/2004” (and its amendment “Law 46/2012”), and “Law 32/2008”. 

  

  

  

Further information on how personal data collection and handling were
approached in the VICINITY project have been described in D4.3: “VICINITY
Security Services”, D5.2 “VICINITY value- added services implementation
framework”, D6.4: “VICINITY security and privacy evaluation report”, and also
addressed in the D8.2 – D8.5 that covers pilot results from smart energy,
smart buildings, smart parking and eHealth.

All personal data collection efforts of the project partners have been
established after giving subjects full details on the experiments to be
conducted, and obtaining from them a signed informed consent form (see Annex
2: VICINITY consent form template), following the respective guidelines set in
VICINITY and as described in section 3.5: Ethics and security.  
  
<table>  
<tr>  
<th>

**Importance of GDPR:**

  * All legal companies are given new duties 

  

  * Everyone should provide good information on how they process personal data 

  

  * Everyone should consider risk and privacy consequences 

  

  * Everyone should embed privacy in new solutions 

  

  * Many companies must establish privacy ombudsman/Privacy Advisor 

  

  * The rules also apply to businesses outside Europe 

  

  * All data processors are given new duties 

  

  * Everyone has new requirements for non-conformity management 

  

  * Everyone must be able to fulfil citizens' new rights 

  

</th> </tr> </table>

**Table 3: Importance of GDPR as applied in VICINITY**

Beside this, certain guidelines were implemented in order to limit the risk of
data leaks;

  * Keep anonymised data and personal data of respondents separate; 

  

  * Encrypt data if it is deemed necessary by the local researchers; 

  

  * Store data in at least two separate locations to avoid loss of data; 

  

  * Limit the use of USB flash drives; 

  

  * Save digital files in one of the preferred formats (see Annex 1), and 

  

  * Label files in a systematically structured way in order to ensure the 

  

coherence of the final dataset

GDPR may be broad in its descriptions. To give some examples;

  * All kinds of personal data can be stored - as long as the data cannot be combined and used to identify the person. E.g. - it's perfectly OK to save date of birth. However, if combined with an address or apartment number, potential issues may arise. 

  

  * IP address, time and login data that can be correlated with member registers used for statistical purposes represents also a risk. 

  

  * Transactions related to service or product linked to customer profiles is yet another example. 

  

  * There are other things that also come into play; whether the data sets are encrypted/hashed, how the tables are indexed, etc. 

  

To avoid this situation, DMP is now focusing on "security by design", not
"security on demand". Recommended course of action requires a common approach
from all EU funded projects. A brief course which leads up to a written
statement indicating the partner has understood and adhere to GDPR as
presented in the course.

A more formal description of best practice principles can be found in Table 5:
Best practice for use of production data.  
  
<table>  
<tr>  
<th>

**GDPR - Prominent Rights:**

  * Easier Access to Own Data (Art. 43) 

  

  * Data Portability, Right to Access and Freely Transfer Data to Other Service Providers (Art. 18) 

  

  * Right to Correction (Art. 16) 

  

•

The Right to “Be Forgotten” (Art. 17)

  * The right to know if your information is subject to abuse 

  

  * Service providers; Only deal with one supervisor for the entire area (Art. 55-62) 

  

  * “Data protection by design and by default” (Art. 25) 

  

</th> </tr> </table>

**Table 4: GDPR - Prominent Rights**

##  3.3. Participation in the Pilot on Open Research Data

VICINITY participates in the Pilot on Open Research Data  2  launched by the
European Commission along with the Horizon2020 programme. The consortium
believes firmly in the concepts of open science, and the large potential
benefits the European innovation and economy can draw from allowing reusing
data at a larger scale. Therefore, all data produced by the project may be
published with open access – though this objective will need to be balanced
with the other principles and sensitivities described below.

##  3.4. Production data

The consortium is aware that a number of privacy and data protection issues
could be raised by the activities (use case demonstration and evaluation in
WP7 and WP8) to be performed in the scope of the project. The project involves
the carrying out of data collection in all pilot applications on the virtual
neighbourhood. For this reason, human participants were involved in certain
aspects of the system development by contributing real life data. During the
development life cycle process, it was necessary to operate on datasets. None
of the datasets were based on production data, a few were generated
(synthetic), but started out from a test environment and did not contain any
personal data that will be used for future reference.

**Figure 5: The VICINITY architecture is decentralised by design**

The VICINITY architecture is decentralised by design (Figure 5). Production
data were planned being used for testing purposes, but deemed unnecessary as
relevant datasets were created for the project. Certain functionality like the
discovery function and the related search criteria, raise the need for proper
implementation of Things Ecosystem Description (TED) – which describes IoT
assets that exists in the same environment.

The public have access to the VICINITY ontology alongside the VICINITY
discovery function at the conclusion of the project. However, all data
generated through the test phase and development process will be removed.  
  
<table>  
<tr>  
<th>

**BEST PRACTICE FOR PRODUCTION DATA ADOPTED BY VICINITY**

The consortium will follow what is considered best practice for handling both
copies of production data and live data.

  * **Data Obfuscation and security safeguards**

  

Use obfuscation methods to remove/protect data or reduce the risk of personal
information being harvested on data breach, and encrypt data where
appropriate.

  * **Data minimization**

  

Minimize the size of datasets and the number of fields used.

  * **Physical/environmental protection and access control**

  

Restrict and secure the environment where the data is used and stored and
limit the ability to remove live data in either physical or electronic format
from the

environment. Also limit access to the data to authorized users with business
needs and who have received appropriate data protection training.

  * **Retention limits and data removal**

  

Limit the time period for use of the data and dispose of live data at end of
use period. Destroy physical and electronic live data used for training,
testing, or research at the conclusion of the project.

  * **Use Limits**

  

Limit through controls and education the likelihood that live data, whose
integrity is not reliable, is re-introduced into production systems or
transferred to others beyond its intended purpose.

  * **Watermarking**

  

Include warning information on live data where possible to ensure users do not
assume it is dummy data. This applies to all pilot sites where time critical
actions have to be taken, and where forecast analysis needs to be based on
accurate data.

  * **Legal Controls**

  

Implement Confidentiality and Non-Disclosure Agreements if applicable. This
applies to all operators responsible for living labs that address eHealth and
assisted living.

  * **Responsibility for accountability, training and awareness**

  

Ensure that identified personnel (by role) are assigned responsibility for
compliance with any conditions of the approval for the use of live data. The
personnel responsible for the technical description of the dataset will also
serve as contact for the use of live data. This also applies to providing
safety and training sessions for all persons having access to live data. The
partners responsible for pilot sites handling real time data from living labs
will prepare information that is to be handed out to relevant stakeholders.

</th> </tr> </table>

**Table 5: Best practice for use of production data**

How these best practice principles are being implemented, are described in
more detail in section 3.5: Ethics and security and 3.9: Data sharing.

##  3.5. Ethics and security

The consortium is aware that a number of privacy and data protection issues
could be raised by the activities (use case demonstration and evaluation in
WP7 and WP8) to be performed in the scope of the project. The project involves
the carrying out of data collection in all pilot applications on the virtual
neighbourhood. For this reason, human participants became involved in certain
aspects of the project and data that was collected. This has been done in full
compliance with any European and national legislation and directives relevant
to the country where the data collections took place (INTERNATIONAL/EUROPEAN):

  * The Universal Declaration of Human Rights and the Convention 108 for the Protection of Individuals with Regard to Automatic Processing of Personal Data and 

  

  * Directive 95/46/EC & Directive 2002/58/EC of the European parliament regarding issues with privacy and protection of personal data and the free movement of such data. 

  

  
<table>  
<tr>  
<th>

**Data Protection Impact Assessment (DPIA):**

The assessment shall include at least

  * a systematic description of the planned treatment activities and the purposes of the treatment, including, where relevant, the legitimate interest pursued by the treatment officer; 

  

  * an assessment of whether the treatment activities are necessary and proportionate. for the purposes, 

  

  * an assessment of the risks to the data subjects' rights and freedoms referred to in paragraph 1; and 

  

  * the planned measures to manage the risks, including guarantees, security measures and mechanisms for safeguarding personal data and demonstrating that this Regulation be respected, taking into account the rights and legitimate interests of the data subject and other persons concerned. 

  

</th> </tr> </table>

**Table 6: Data Protection Impact Assessment (DPIA)**

In addition to this, the project further ensures that the fundamental human
rights and privacy needs of participants have been met whilst they take part
in the project. A dedicated section for providing ethical and privacy
guidelines for the execution of the Industrial Trials is presented in the
Evaluation Plans. In order to protect the privacy rights of participants, a
number of best practice principles were prepared. These include:

  * No data will be collected without the explicit informed consent of the individuals under observation. This involves being open with participants about what they are involving themselves in and ensuring that they have agreed fully to the procedures/research being undertaken by giving their explicit consent. 

  

  * The owners of personal data are to be granted the right of inspection and the right to be removed from the registers. 

  

  * No data collected will be sold or used for any purposes other than the current project; 

  

  * A data minimisation policy will be adopted at all levels of the project and will be supervised by each Industrial Pilot Demonstration responsible. This will ensure that no data which is not strictly necessary to the completion of the current study will be collected; 

  

  * During the development life cycle process, it will be necessary to operate on datasets. Some of the datasets may be based on production data, while others may be generated (synthetic). These data will be removed by the end of the project. 

  

  * Any shadow (ancillary) personal data obtained during the course of the research will be immediately cancelled. However, the plan is to minimize this kind of ancillary data as much as possible. Special attention will also be paid to complying with the Council of Europe’s Recommendation R(87)15 on the processing of personal data for police purposes, Art. 2 : 

  

_“The collection of data on individuals solely on the basis that they have a
particular racial origin, particular religious convictions, sexual behaviour
or political opinions or belong to particular movements or organisations which
are not proscribed by law should be prohibited. The collection of data
concerning these factors may only be carried out if absolutely necessary for
the purposes of a particular inquiry.”_

  * Compensation – if and when provided – will correspond to a simple reimbursement for working hours lost as a result of participating in the study; special attention will be paid to avoid any form of unfair inducement; 

  

  * If employees of partner organizations, are to be recruited, specific measures will be in place in order to protect them from a breach of privacy/confidentiality and any potential discrimination; In particular their names will not be made public and their participation will not be communicated to their managers. 

  

  * Data should be pseudomised and anonymized to allow privacy to be upheld even if an attacker gains access to the system. 

  

  * Furthermore, if data has been compromised or tampering is detected, the involved parties are to be notified immediately in order to reduce risk of misuse of data gathered for research purposes. 

  

The same concern addressed here also applies to open calls (see section 3.7:
Open Call).

These issues are be exemplified when for instance health related data is
gathered as part of service were information is exchanged within a 3rd party
ecosystem. Why are these data gathered? How are the data processed? Where are
data temporarily stored? How are aggregated data accessed? When are data
further exchanged with other actors? VICINITY allow for the interoperability
to take place, but the architecture serves as a facilitator – it cannot
determine what happens with the data afterward. Even more so if the data are
exchanged or processed within other partners ecosystems? Responsibilities
cannot be outsourced. Personal responsibilities and approach used in
protecting the privacy rights must be clarified.  
  
<table>  
<tr>  
<th>

**10 National Security Agency (NSM** 3  **) Security Requirements:**

  1. An established information security and certification management system in accordance with international standards, such as ISO / IEC 27001: 2017 

  

  2. Insight into the security architecture used to deliver the service. 

  

  3. Development of security in service production and at the supplier, in line with developments in technology and the threat picture over time. 

  

  4. An overview of who should have access to the company's information, where and how it should be processed and stored, and the degree of mechanisms for segregation from other customers. 

  

  5. Access management which includes encryption, activity logging, physical and logical security. 

  

  6. Security monitoring suitable for detecting incidents and actions in line with the business threat image and relevant threat actors. 

  

  7. Procedures for incident management, nonconformity and safety reporting. 

  

  8. Emergency and contingency plans to harmonize with the company's own plans. 

  

  9. That the use of subcontractors and their use of subcontractors must be approved before implementation. 

  

  10. What activities are to be performed upon termination of the contract, including the return / relocation / deletion of the company's information. 

  

  

</th> </tr> </table>

**Table 7: 10 Security Requirements**

##  3.6. The VICINITY Data Management Portal

VICINITY developed a data management portal as part of the project. This
portal provides a description of the dataset along with a link to a download
section in the case the datasets have been made publicly available:

  * The portal will be updated each time a new dataset has been collected and **is ready for public distribution** . 

  

  * The portal will however not contain any datasets that should **not become publicly available** . 

  

The initial version of the portal became available during the 2nd year of the
project, in parallel to the establishment of the first versions of project
datasets that can be made publicly available. The VICINITY data management
portal will enable project partners to manage and distribute their public
datasets through a common infrastructure as described in Table 8.  
  
<table>  
<tr>  
<th>

**Datasets for:**

</th>  
<th>

**Datasets (continued)**

</th>  
<th>

**Administrative tools**

</th> </tr>  
<tr>  
<td>

each IoT unit

</td>  
<td>

Datasets from pilots

(see section 4.2 for examples)

</td>  
<td>

List of sensor / grouping

</td> </tr>  
<tr>  
<td>

personal information

</td>  
<td>

groups of devices

</td>  
<td>

List of actions / sequences

</td> </tr>  
<tr>  
<td>

energy related domains

</td>  
<td>

each health device

</td>  
<td>

List of users

</td> </tr>  
<tr>  
<td>

• each interface (energy)

</td>  
<td>

node/object

</td>  
<td>

List of contacts

</td> </tr>  
<tr>  
<td>

• each measuring device (energy)

</td>  
<td>

messaging

</td>  
<td>

Balancing loads

</td> </tr>  
<tr>  
<td>

• each routing device (energy)

</td>  
<td>

sequences / actions

(combination tokens / nodes)

</td>  
<td>

Booking

</td> </tr>  
<tr>  
<td>

mobility related domains

</td>  
<td>

biometric (fingerprint, retina)

</td>  
<td>

Messaging

</td> </tr>  
<tr>  
<td>

• parking data (mobility)

</td>  
<td>

camera

</td>  
<td>

Criteria

</td> </tr>  
<tr>  
<td>

• booking (mobility)

</td>  
<td>

access

</td>  
<td>

Priorities

</td> </tr>  
<tr>  
<td>

• areas (mobility)

_(list continues in next coloumn)_

</td>  
<td>

each smart home device (temperature, smoke, motion, sound)

</td>  
<td>

Evaluation / feedback

</td> </tr> </table>

**Table 8: datasets stored in the VICINITY management portal**

##  3.7. Open Calls

The Open Call process of the VICINITY project involved third parties. System
integrators (Figure 6) will be one of target groups for the calls. These were
presented for opportunities to integrate IoT infrastructures based on the
VICINITY framework as well as implementation/integration of ValueAdded
Services. The calls adhered to the principles which govern Commission calls,
and were referred to in all papers. These principles all include
confidentiality: all proposals and related data, knowledge and documents are
treated in confidence.

**Figure 6: Involving 3rd parties through open calls will provide**

**VICINITY with valuable experience, and evolve interoperability**

The Project Coordinator presented a legal contract with the third parties that
are granted open calls and specified control procedures to be made compliant
with the Grant Agreement and the Consortium Agreement. This was done in order
to assure that their contributions are in line with the agreed upon work plan;
that the third party allows the Commission and the Court of Auditors to
exercise their power of control on documents and information stored on
electronic media or on the final recipient's premises.

Proposals for open calls and the deliverables that come as a result included
sections that describe how the data management principles have been
implemented. The papers followed the outlines that are presented in the legal
contract and adhere to GDPR. This also applies to sharing ideas and
intellectual properties. Furthermore, the deliverables presented how the
chosen architecture and methodologies will be handled by the stakeholders,
integrators and SME’s. That being said, very few of the Open Call winners
gathered data that would be affected by privacy concerns.

According VICINITY concept the participants can decide with whom they wish to
cooperate and to which extent. Participants are held responsible for partners
they team up with follow the same guidelines as the main project and the open
call project.

##  3.8. Standards and metadata

The data that were generated and tested through different test automation
technologies, e.g. TDL (Test description language), TTCN-3 (Test and Test
Control Notation), UTP (UML Testing Profile). The profile should mimic the
data communicated from IoT units following the oneM2M specifications. The
Systems Modeling Language  4  (SysML) is used for the collection, analysis and
processing of requirements as well as for the specification message exchanges
and overviews of architecture and behaviour specifications (Figure 7).

**Figure 7: Example of SysML model of Virtual Oslo Science City**

The project intends to share the datasets in an internally accessible
disciplinary repository using descriptive metadata as required/provided by
that repository. Additional metadata to example test datasets will be offered
within separate XML-files.

They have also been made available in XML and JSON format. Keywords will be
added as notations in SysML and modelled on the specifications defined by
oneM2M. The content will be similar to relevant data from compatible IoT
devices and network protocols. No network protocols have been defined yet, but
several have been evaluated. Files and folders will be versioned and
structured by using a name convention consisting of project name, dataset
name, date, version and ID.

##  3.9. Data sharing

The project prepared the API for internal testing through the VICINITY open
gateway.

The VICINITY open gateway is defined as Interoperability as a Service. In
other words - it is a cloudbased service that assumes the data has already
been gathered and transferred to the software running on the service layer.
These data were made available for developers and researchers in a controlled
environment, where login credentials are used to get access to the data in XML
and JSONformat (Figure 8).

**Figure 8: Data will only be provided partners with proper login
credentials**

The project focus on developing a framework that allows for a scalable and
futureproof platform upon which it can invest and develop IoT applications,
without fear of vendor lock-in or needing to commit to one connectivity
technology.

The researchers must therefore be committed to the requirements, architecture,
application programming interface (API) specifications, security solutions and
mapping to common industry protocols such as CoAP, MQTT and HTTP. Further
analysis will be performed using freely available open source software tools.
The data will also be made available as separate files.  
  
<table>  
<tr>  
<th>

**Five Key Concepts (Art. 4):**

❶ **Personal Information:**

"any information about an identified or identifiable natural person (" the
data subject "); an identifiable natural person is a person who can be
directly or indirectly identified, in particular by means of an identifier,
e.g. a name, identification number, location information, an online identifier
or one or more elements specific to the physical, physiological, genetic,
psychological, economic, cultural or social identity of the said person

❷ **Processing:**

"any operation or sequence of operations done with personal data, whether
automated or not" e.g. collection, registration, organization, structuring,
storage, adaptation or modification, retrieval, consultation, use, delivery by
transmission, distribution or any other means of making available, assembling
or merging, limiting, deleting or destroying

❸ **The controller:**

"determines the purpose of the processing of personal data and the means to be
used"

</th> </tr>  
<tr>  
<td>

❹

</td>  
<td>

**The data processor:**

"processes personal data on behalf of the controller"

</td> </tr>  
<tr>  
<td>

❺

</td>  
<td>

**Consent:**

"any voluntary, specific, informed and unambiguous expression of the data
subject where the person in a declaration or clear affirmation gives his
consent to the processing of personal data relating to the person"

</td> </tr> </table>

**Table 9: Five Key Concepts in GDPR**

The goal is to ultimately support the Europe 2020 strategy  5  by offering the
open data portal. The Digital Agenda proposes to better exploit the potential
of Information and Communication Technologies (ICTs) in order to foster
innovation, economic growth and progress. Thus, VICINITY will support EUs
efforts in exploiting the potential offered by using ICT in areas like climate
change, managing ageing population, and intelligent transport system to
mention a few examples.

##  3.10. Archiving and preservation (including storage and backup)

As specified by the "rules of good scientific practice" the project aim to
preserve data for at least ten years. Approximated end volume of example test
dataset is currently 10 GB, but this may be subject to change as the scope of
the project may change. The VICINITY architecture itself does neither generate
nor store any information. Data in this context refers to Value-Added
Services, code and documentation produced as part of the project.

Associated costs for dataset preparation for archiving is covered by the
project itself, while long term preservation will be provided and associated
costs covered by a selected disciplinary repository. During the project data
will be stored on the VICINITY web cloud as well as being replicated to a
separate external server.

The source code and descriptions are available from the project website and
GitHub, but no actual data is stored at these locations:

  * _https://vicinity2020.eu/vicinity/public-deliverables_

  

  * _https://github.com/vicinityh2020_

  

#  Datasets

Information that is collected or aggregated from a data source needs to adhere
to a common format. This format is used to organise the data for further
exchange, storage or manipulation. Datasets can be made up of several parts,
and in VICINITY is based on the definition found in W3 “The RDF Data Cube
Vocabulary  6  ”, section 5.1:

Some of the pilots were deployed in “living labs” with actual residents or
other human participants. Several of the activities carried out by the
project, depended on collecting some basic personal data (e.g. name,
background, contact details). VICINITY2020 avoided collecting this kind of
data. However when data was gathered the project protected the data in
accordance with “the EU's Data Protection Directive 95/46/EC  7  of the
European Parliament” and of “the Council of 24  th  of October 1995 on the
protection of individuals with regard to the processing of personal data and
on the free movement of such data”. National and local legislations applicable
to the project will also be strictly applied (full list described in section
3.5: Ethics and security).

Data in a data set can be roughly described as belonging to one of the
following kinds:

  * **Observations**

  

This is the actual data, the measured values. In a statistical table, the
observations would be the values in the table cells.

  * **Organizational structure**

  

To locate an observation, spatial information or coordinates are necessary.
This applies also to other kind of information about origin and particular
information on the sensors that are relevant to the observations.

  * **Structural metadata**

  

Metadata is necessary to interpret the observations. What is the unit of
measurement? Is it a normal value or a series break? Is the value measured or
estimated? These metadata are provided as attributes and can be attached to
individual observations, or to higher levels.

  * **Reference metadata**

  

This is metadata that describes the dataset as a whole, such as categorization
of the dataset, its publisher, and a SPARQL endpoint where it can be accessed.

At the time of this deliverable was written, datasets that so far have been
provided by partners and open call winners are presented in “Table 10:
Datasets currently provided by partners” and “Table 11: Datasets currently
provided by Open Call winners”. **Fehler! Verweisquelle konnte nicht gefunden
werden.**  
  
<table>  
<tr>  
<th>

**Partner**

</th>  
<th>

**Sector**

</th>  
<th>

**Role**

</th>  
<th>

**GDPR**

</th> </tr>  
<tr>  
<td>

**Aalborg University (AAU)**

DS.AAU.01.GRID_Status

DS.AAU.02. Gorenje_Smart_Appliances_Sensor

DS.AAU.03. PlacePod_Parking_Sensor

DS.AAU.04. Tinymesh_Door_Sensor

</td>  
<td>

Smart grid

</td>  
<td>

Partner

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Enercoutim (ENERC)**

DS.ENERC.01.METEO_Station

DS.ENERC.02.BUILDING_Status

DS.ENERC.03.GRID_Status

</td>  
<td>

Smart energy

</td>  
<td>

Partner

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**GNOMON Informatics SA (GNOMON)**

DS.GNOMON.01.Pressure_sensor

DS.GNOMON.02.Weight_sensor

DS.GNOMON.03.Fall_sensor

DS.GNOMON.04.Wearable_Fitness_Tracker_Sensor

DS.GNOMON.05.Beacon_Sensor

DS.GNOMON_CERTH.06.Gorenje_Smart_Appliances_Se nsor

</td>  
<td>

eHealth

</td>  
<td>

Partner

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Centre for Research and Technology Hellas (CERTH)**

DS.CERTH.01.Door_Sensor

DS.CERTH.02.Motion_Sensor

DS.CERTH.03.Pressure_Mat

</td>  
<td>

eHealth

</td>  
<td>

Partner

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Hafenstrom AS (HITS)**

DS.HITS.01.Parkingsensor

DS.HITS.02.SmartLight

DS.HITS.03.LaptopTeststation

DS.HITS.04.Sensio_sensors_temperature_motion_lock

DS.HITS.05.Gorenje_Smart_Appliances_Sensor

</td>  
<td>

Smart parking

</td>  
<td>

Partner

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**Tiny Mesh AS (TINYM)**

DS. VITIR.01.Door_Sensor

DS. VITIR.02.CO2 Sensor

</td>  
<td>

Smart building

</td>  
<td>

Partner

</td>  
<td>

No

</td> </tr> </table>

**Table 10: Datasets currently provided by partners**  
  
<table>  
<tr>  
<th>

**Open Call**

</th>  
<th>

**Sector**

</th>  
<th>

**Role**

</th>  
<th>

**GDPR**

</th> </tr>  
<tr>  
<td>

**PilotThings**

DS. PilotThings.01.Building

DS. PilotThings.02.OPA_Grid

</td>  
<td>

Smart building

</td>  
<td>

Open

Call

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**WearHealth**

DS. WearHealth.01.SmartShirt

</td>  
<td>

Smart building

</td>  
<td>

Open

Call

</td>  
<td>

Yes

</td> </tr>  
<tr>  
<td>

**SaMMY**

DS. SaMMY.Patras.Air_Temperature

DS. SaMMY.Patras.Humidity

DS. SaMMY.Patras.Water_Temperature

DS. SaMMY.Patras.Water_pH

DS. SaMMY.Patras.Water_ORP

DS. SaMMY.Patras.BerthSpace(5-15)_Occupancy

</td>  
<td>

Marina

</td>  
<td>

Open Call

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Thinkinside Srl**

DS. ThinkInside.01.INCANT

</td>  
<td>

Positioning

</td>  
<td>

Open

Call

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Sensinov**

DS.Sensinov.01.F2IS-VAS

</td>  
<td>

Smart building

</td>  
<td>

Open Call

</td>  
<td>

No

</td> </tr> </table>

**Table 11: Datasets currently provided by Open Call winners**

For each dataset in VICINITY the format in “Table 12: Format of dataset
description” were specified:  
  
<table>  
<tr>  
<th>

**DS. PARTICIPANTName.##.Logical_sensorname**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Where are the sensor(s) installed? What are they monitoring/registering? What
is the dataset comprised of? Will it contain future sub-datasets?_

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_How will the dataset be collected? What kind of sensor is being used?_

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_What is the name of the owner of the device?_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_What is the name of the partner in charge of the device? Are there several
partners that are cooperating? What are their names?_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_The name of the partner._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_The name of the partner._

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WPxx and WPxx._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_What is the status with the metadata so far? Has it been defined? What is the
content of the metadata (e.g. datatypes like images portraying an action,
textual messages, sequences, timestamps etc.)_

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_Has the data format been decided on yet? What will it look like?_

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Example text:_

_Production process recognition and help during the different production
phases, avoiding mistakes_

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_Example text:_

_The full dataset will be confidential and only the members of the consortium
will have access on it. Furthermore, if the dataset or specific portions of it
(e.g. metadata, statistics, etc.) are decided to become of widely open access,
a data management portal will be created that should provide a description of
the dataset and link to a download section. Of course, these data will be
anonymized, so as not to have any potential ethical issues with their
publication and dissemination_

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Have the data sharing policies been decided yet? What requirements exist for
sharing data? How will the data be shared? Who will decide what to be shared?_

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Who will own the information that has been collected? How will it adhere to
partner policies? What kind of limitation is put on the archive?_

</td> </tr> </table>

**Table 12: Format of dataset description**  
  
<table>  
<tr>  
<th>

**Current legal requirements as described in General Data Protection
Regulation OJ L 119, 04.05.2016:**

  * Information systems and security measures must be documented (section 13 and pof. section 2-16) 

  

  * Documented internal control measures (section 14) 

  

  * Description of security objectives and strategy (section 2-3) 

  

  * Regular review of the use of IT systems, which must be documented (section 2-3) 

  

  * Establish criteria for acceptable risk (section 2-4) 

  

  * Conduct and document risk assessments (section 2-4) 

  

  * Implement and document security audits (section 2-5) 

  

  * Report to the Data Inspectorate for certain security breaches (section 2-6) 

  

  * Establish responsibility and authority structures for the use of the IT system (section 2-7) 

  

  * Configure IT systems to achieve satisfactory security (section 2-7) 

  

  * Establish access control and authorizations (section 2-8) 

  

  * Educate and train personnel in the proper use of IT systems (section 28) 

  

  * Physical measures against unauthorized access to IT systems (section 2-10) 

  

  * Document measures against authorized access to confidential 

  

information (section 2-11)

  * Encryption solutions when transferring confidential information (section 2-11) 

  

  * Ensure necessary accessibility of information (section 2-12) 

  

  * Proper backup procedures (section 2-12) 

  

  * Security measures to prevent unauthorized use and measures to detect such attempts (section 2-14) 

  

  * Measures against unauthorized changes to information (section 2- 13) 

  

  * Measures against malicious software (section 2-13) 

  

  * Proper use of cookies / cookies (Electronic Communications Act., section 2-7b) 

  

For interactive navigation, please visit _https://gdpr-info.eu/_

_Table is based on material by Kjell Steffner, attorney-at-law, Hill & Co
Advokat _

</th> </tr> </table>

**Table 13: Current legal requirements in GDPR**

##  4.1. Description of methods for dataset description

Some example test dataset was generated by research teams from the
participants in the project as XML-files. Certain datasets were based on
semantic analysis of data from test sensors and applied to an ontology and
made available in XML and JSON format (Figure 9).

The collected dataset encompassed different methodological approaches and IoT
standards defined by the global standard initiative oneM2M. The data were
processed in different test environments like TDD (Test Driven Development),
ATDD (Acceptance Test Driven Development), PBT (Property Based Testing), BDD
(Behaviour Driven Development). The project focused on using model-based test
automation in processes with short release cycles.

**Figure 9: Datasets will be prepared and provided in XML and JSON format**

Apart from the research teams, these datasets will be useful for other
research groups, Standard Development Organisations (SDO) and technical
integrators with within the area of Internet of Things (IoT).

All datasets were shared between the participants during the lifecycle of the
project. Feedback from other participants and test implementations would
decide the dataset should be made publicly available, but there were no
requests made and only the eHealth and smart parking pilots had data that
could be of relevant. Datasets supported the framework defined by the VICINITY
ontology can be made public and presented in open access publications.

The VICINITY partners can use a variety of methods for exploitation and
dissemination of the data including:

  * Using them in further research activities (outside the action) 

  

  * Developing, creating or marketing a product or process 

  

  * Creating and providing a service, or 

  

  * Using the data in standardisation activities 

  

Restrictions:

  1. All national reports (which include data and information on the relevant topic) will be available to the public through the HERON web-site or a repository or any other option that the consortium decides and after verification by the partners so as to ensure their quality and credibility. 

  

  2. After month 18 so that partners have the time to produce papers; 3) Open access to the research data itself is not applicable. 

  

  

##  4.2. Datasets for smart grid from Aalborg University (AAU)

AAU will mainly deal with control design, energy management systems
implementation and Information and Communication Technology (ICT) integration
in small scale energy systems. Intensive and iterative Lab tests have been
conducted in AAU by using the hardware in the loop solution and experimental
platform to 1. restrict some features of VICINITY Gateway API to define a
stability and proper operating range for VICINITY platform; 2. ensure that
local infrastructure, to be deployed at pilot sites, operates with the
VICINITY platform as expected. The lessons learned from the Lab trial will be
forwarded to WP3 and WP4 for performance/function improvements, and to WP7 for
helping a correct deployment of VICINITY platform at the pilot sites from a
technical perspective, as well as to WP8 for helping a technical evaluation
approach design.  
  
<table>  
<tr>  
<th>

**DS.AAU.01.GRID_Status**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_This dataset comprised different parameters characterising the electrical
grid from the generation to the distribution sections. The cost of the
electricity will also be considered in this dataset, so as to have full
information that enables micro-trading actions._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The source that feed this dataset is from the hardware in the loop simulation
and experimental platform and adapters based on Python 3._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP6, WP7, and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open portal
/ repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository.
Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr> </table>

**Table 14: Dataset description of the AAU GRID status**  
  
<table>  
<tr>  
<th>

**DS.AAU.02. Gorenje_Smart_Appliances_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors related to Gorenje smart appliances are sensors embodied to a
Gorenje smart oven and a Gorenje smart fridge. The equipments are provided by
Gorenje partner and are deployed in AAU IoT-microgrid laboratory. The main
goal of the sensors is to automatically detect when a resident opens the
fridge or uses the oven in order to create behaviour profiles based on
relevant criteria (e.g. frequency of use, etc), produce notifications in case
of deviation from the normal standards of use and inform the call centre._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data are collected by specific smart appliances (i.e. oven, fridge)
provided by the Gorenje partner and adjusted to VICINITY requirements._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_AAU, Gorenje_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_AAU, Gorenje_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_AAU, Gorenje_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP6, WP7, and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open
portal/repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository.
Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr> </table>

**Table 15: Dataset description of the Gorenje smart appliances sensor in AAU
IoT-microgrid laboratory**  
  
<table>  
<tr>  
<th>

**DS.AAU.03. PlacePod_Parking_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The PlacePod parking sensor deployed in AAU IoT-microgrid laboratory are also
installed in Tromsø pilot site. The main goal of the sensors is to
automatically detect when a car parking at the parking slot in order to create
behaviour profiles based on relevant criteria (e.g. vacant parking slot,
frequency of use, etc), produce notifications with the number of vacant
parking slots._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The source that feed this dataset is from the PlacePod parking sensors and an
adapter based on Python 3._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_AAU_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP6, WP7, and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open
portal/repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository.
Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr> </table>

**Table 16: Dataset description of the PlacePod smart parking sensor in AAU
IoT-microgrid laboratory**  
  
<table>  
<tr>  
<th>

**DS.AAU.04. Tinymesh_Door_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The Tinymesh door sensor deployed in AAU IoT-microgrid laboratory is provided
by Tinymesh partner. The main goal of the sensors is to automatically detect
when a door status is changed in order to create behaviour profiles based on
relevant criteria (e.g. frequency of use, etc), produce notifications with the
number of usages and cleaning requirements._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data are collected by the Tinymesh door sensor provided by the Tinymesh
partner and adjusted to VICINITY requirements._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_AAU, Tinymesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_AAU, Tinymesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_AAU, Tinymesh_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP6, WP7, and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open portal
/ repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_The full dataset of grid status deployed in AAU IoT-microgrid testing lab,
that is not sensitive, is accessible through a local experimental repository.
Data exploitation is foreseen to be achieved through testing value-added
services, data analytics and statistical analysis._

</td> </tr> </table>

**Table 17: Dataset description of the Tinymesh door sensor in AAU IoT-
microgrid laboratory**

##  4.3. Datasets for smart energy from Enercoutim (ENERC)

ENERC contributed by providing the facilities and the experience in
implementing solar production integrated into municipality smart city efforts.
To this end, ENERC actively participated in the deployment, management and
evaluation of the “Smart Energy Microgrid Neighbourhood” Use Case. Its
contribution focused on the energy resource potential demand studies and
economic sustainability. ENERCS expertise allowed ICT integration with smart
city management focused on better serving its citizens.

The main aim of this project is the demonstration of a Solar Platform which
provides a set of shared infrastructures and reduces the total cost per MW as
well as improves the environmental impact compared to the stand-alone
implementation of these projects. As main responsibilities, ENERC will be in
charge of strategic technology planning and integration coordination,
designing potential models for municipal energy management, as well as
identifying the optimal ownership structure of the microgrid system with a
focus on delivering maximum social and economic benefit to the local
community.  
  
<table>  
<tr>  
<th>

**DS.ENERC.01.METEO_Station**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The weather conditions will influence the energy production, so it becomes
critical to understand the current and foreseen scenarios. It is fundamental
to constantly carry out different measures with the meteo station equipment of
the parameters that can influence both energy production and consumption over
time._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensors that feed this dataset are; temperature, humidity, wind speed and
wind direction, barometer, precipitation measurement and sun tracker._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices. However, it is
estimated to be 4 KB/transmission._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at SOLAR LAB Facilities, allowing access to registered users. Data
exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users (e.g. facility
managers), and for a broader use in an anonymised/aggregated manner for data
analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be confidential and only the authorized ENERC personnel
and related end-users will have access as defined. Specific consortium members
involved in technical development and pilot deployment will further have
access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data will be stored in a database scheme
at the SOLAR LAB facilities, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by ENERC
in a secured place. Data will be kept indefinitely allowing statistical
analysis._

</td> </tr> </table>

**Table 18: Dataset description of the ENERC METEO station**  
  
<table>  
<tr>  
<th>

**DS.ENERC.02.BUILDING_Status**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The information associated to the energy consumption in buildings will allow
identifying the usage of resources for each measurement point._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensors that feed this dataset are; Cooling energy demand, heating energy
demand, hot water demand, building equipment demand_

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices. However, it is
estimated to be 4 KB/transmission._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at SOLAR LAB Facilities, allowing access to registered users. Data
exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users (e.g. facility
managers), and for a broader use in an anonymised/aggregated manner for data
analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be confidential and only the authorized ENERC personnel
and related end-users will have access as defined. Specific consortium members
involved in technical development and pilot deployment will further have
access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware_ _as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None._

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data will be stored in a database scheme
at the SOLAR LAB facilities, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by ENERC
in a secured place. Data will be kept indefinitely allowing statistical
analysis._

</td> </tr> </table>

**Table 19: Dataset description of the ENERC building status**  
  
<table>  
<tr>  
<th>

**DS.ENERC.03.GRID_Status**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_This dataset comprises the different parameters that characterise the
electrical grid from the generation to the distribution sections. Moreover,
the cost of the electricity will be considered in this dataset so as to have
full information that enables micro-trading actions._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensors that feed this dataset are; Electrical energy generated on-site
from RES, thermal energy generated on-site, thermal energy consumed, grid
electricity consumed, instant grid cost of energy consumed, value of energy
purchased from the grid_

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_ENERC_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in JSON format. Regarding the volume of data, it
depends on the motion/activity levels of the engaged devices. However, it is
estimated to be 4 KB/transmission._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at SOLAR LAB Facilities, allowing access to registered users. Data
exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users (e.g. facility
managers), and for a broader use in an anonymised/aggregated manner for data
analytics and statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be confidential and only the authorized ENERC personnel
and related end-users will have access as defined. Specific consortium members
involved in technical development and pilot deployment will further have
access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data will be stored in a database scheme
at the SOLAR LAB facilities, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by ENERC
in a secured place. Data will be kept indefinitely allowing statistical
analysis._

</td> </tr> </table>

**Table 20: Dataset description of the ENERC grid status**

##  4.4. Datasets for eHealth from GNOMON Informatics SA (GNOMON)

GNOMON provided its background knowledge in the specific field of assisted
living and tele care in the context of social workers. In addition, GNOMON
actively contributes in the use case pilot setup, assessment and benchmarking.

The company has developed and provided the remote care and monitoring
integrated system for people with health problems as well as of the software
applications for support and organization using information and communication
technologies of the business operation of HELP AT HOME program in the
Municipality of Pilea-Hortiatis. This infrastructure is further exploited and
extended for the scope of VICINITY project and specifically for the
realisation of the eHealth Use Case.  
  
<table>  
<tr>  
<th>

**DS.GNOMON.01.Pressure_sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors are in possession of patients in need of assisted living and
identified by the equivalent municipality (MPH) health care services to ensure
the validity of each case. The measurements are taken depending on the
scheduling they have agreed with their doctor. The main task of the sensor is
to monitor pressure (systolic/diastolic) and heart rate levels._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset is collected via a combination of connected devices consisting of
a Bluetooth Blood Pressure monitor and a Connectivity Gateway based on
Raspberry pi._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device is property of the test site owners, where the data collection is
being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in XML format. In a later stage, they are converted to
JSON format and stored in a database. Regarding the volume of data, it depends
on the participation levels of the engaged patients. However, it is estimated
to be 16 KB/measurement._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at MPH headquarters, allowing access to registered users (i.e. MPH
health care services personnel and eHealth call center). Data exploitation is
foreseen to be extended through envisioned value-added services, allowing full
access to specific authorised users (e.g. doctors), and for a broader use in
an anonymised/aggregated manner for creating behaviour profiles and clustering
patients to different medical groups._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset is confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from health
devices deployed at seniors’ houses provides added value and be the base for
other research projects (e.g. statistical data). VICINITY could have an open
portal / repository on its website, providing anonymized data’s information
like timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 21: Dataset description of the GNOMON pressure sensor**  
  
<table>  
<tr>  
<th>

**DS.GNOMON.02.Weight_sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors are in possession of patients in need of assisted living and
identified by the equivalent municipality (MPH) health care services to ensure
the validity of each case. The measurements are scheduled to be taken
depending on the agreement between the patient and the doctor. The main task
of the sensor is to keep track of weight measurements and mass index (given
the fact that the patient provides an accurate value of his/her height)._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset is collected via a combination of connected devices consisting of
a Bluetooth Body Composition monitor and a Connectivity Gateway based on
Raspberry pi._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device is a property of the test site owners, where the data collection
is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received in XML format. In a later stage, they are converted to
JSON format and stored in a database. Regarding the volume of data, it depends
on the participation levels of the engaged patients. However, it is estimated
to be 48 KB/measurement._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at MPH headquarters, allowing access to registered users (i.e. MPH
health care services personnel and eHealth call centre). Data exploitation is
foreseen to be extended through envisioned value-added services, allowing full
access to specific authorised users (e.g. doctors), and for a broader use in
an anonymised/aggregated manner for creating behaviour profiles and clustering
patients to different medical groups._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset is confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from health
devices deployed at seniors’ houses provides added value and be the base for
other research projects (e.g. statistical data). VICINITY could have an open
portal / repository on its website, providing anonymized data’s information
like timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 22: Dataset description of the GNOMON weight sensor**  
  
<table>  
<tr>  
<th>

**DS.GNOMON.03.Fall_sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The fall sensor is a wearable sensor that is in possession of patients in
need of assisted living and identified by the equivalent municipality (MPH)
health care services to ensure the validity of each case. The main goal of the
sensor is to automatically detect when a patient falls either due to an
accident or in the case of a medical incident. The event is triggered
automatically after a fall, but a similar event is also triggered by pressing
the equivalent panic button (wearable actuator). In both cases, an automated
emergency phone call is placed to the eHealth Call Centre._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset is collected via a combination of devices consisting of a hub
(Lifeline Vi) and a fall detector that are wirelessly connected._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device is the property of the test site owners, where the data collection
is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_An audit log containing alerts (incl. false alarms) is stored._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Due to privacy issues, the collected data are stored at a secured database
scheme at MPH headquarters, allowing access to registered users (i.e. MPH
health care services personnel and eHealth call centre). Data exploitation is
foreseen to be extended through envisioned value-added services, allowing full
access to specific authorised users (e.g. patient’s doctors), and for a
broader use in an anonymised/aggregated manner for data analytics and
statistical analysis._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset is confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from fall sensors
at seniors’ houses provides added value and be the base for other research
projects (e.g. statistical data). VICINITY could have an open portal /
repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 23: Dataset description of the GNOMON fall sensor**  
  
<table>  
<tr>  
<th>

**DS.GNOMON.04.Wearable_Fitness_Tracker_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The fitness sensors are sensors embodied to wearable fitness trackers such as
activity wristbands. The latter equipment is in possession of middle aged
citizens, either with a chronic health issue (e.g. obesity) or not, that are
identified by the equivalent municipality (MPH). The municipality tries to
promote fitness awareness and improve citizens’ health under the concept of a
municipal-scale competition that is based on activity related data coming from
the sensors (e.g. step counting)_

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data are collected by wearable fitness trackers, mainly in the form of
activity wristbands (e.g. Xiaomi MiBand)._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device is the property of the test subject, in this case the
participating citizen._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, CERTH, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_Collection of data from wearable fitness tracker sensors is event-driven. New
data are dispatched once they are produced._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users (e.g. doctors),
and for a broader use in an anonymised/aggregated manner for data analytics
and statistical analysis. Additionally, as one of the value-added services
introduced is related to the concept of a municipalscale competition, data
analysis also serves the needs of calculating and providing a ranking among
the competitors._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset is confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from wearable
fitness trackers provide added value and be the base for other research
projects (e.g. statistical data). VICINITY could have an open portal /
repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 24: Dataset description of the GNOMON Wearable Fitness Tracker
Sensor**  
  
<table>  
<tr>  
<th>

**DS.GNOMON.05.Beacon_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The beacon sensors are sensors to deployed in municipality’s sport
facilities, e.g. gym, pool, etc. and also tested at CERTH/ITI’s Smart Home.
The municipality tries to promote fitness awareness and improve citizens’
health under the concept of a municipal-scale competition that is based on
activity related data gathered by the sensors and processed accordingly (e.g.
translation of beacon signals to actual time spent in sport facilities)._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data are collected by beacons deployed in municipality’s sport facilities
and at CERTH/ITI’s Smart Home._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device are the property of the test site owners, where the data
collection is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The collection of data from beacons is event-driven. New data are dispatched
once they are produced for example when middle-age person visits a sport
centre._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users (e.g. doctors),
and for a broader use in an anonymised/aggregated manner for data analytics
and statistical analysis. Additionally, as one of the value-added services
introduced is related to the concept of a municipalscale competition, data
analysis also serve the needs of calculating and providing a ranking among the
competitors._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of beacons deployed in CERTH / ITI’s smart house, that is
not sensitive, are accessible through a local experimental repository._

_The full dataset of beacons deployed in houses of elderly people are
sensitive, therefore, are confidential and only the authorized MPH personnel
and related end-users have access as defined. The latter authorized groups of
users access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from beacons at
sport centres provide added value and be the base for other research projects
(e.g. statistical data). VICINITY could have an open portal / repository on
its website, providing anonymized data’s information like timestamp and
description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 25: Dataset description of the GNOMON Beacon Sensor**  
  
<table>  
<tr>  
<th>

**DS.GNOMON_CERTH.06.Gorenje_Smart_Appliances_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors related to Gorenje smart appliances are sensors embodied to
specific house equipment such as ovens and fridges. The latter equipment are
provided by Gorenje partner and are in possession of patients in need of
assisted living and identified by the equivalent municipality (MPH) health
care services to ensure the validity of each case. Similar equipment are also
deployed in CERTH / ITI’s facilities. The main goal of the sensors is to
automatically detect when a patient opens the fridge or uses the oven in order
to create behaviour profiles based on relevant criteria (e.g. frequency of
use, etc), produce notifications in case of deviation from the normal
standards of use and inform the call centre._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data are collected by specific smart appliances (i.e. oven, fridge)
provided by the Gorenje partner and adjusted to VICINITY requirements._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices are the property of the test site owners, where the data
collection is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_CERTH, GORENJE, GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_CERTH, GORENJE, GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_CERTH, GORENJE, GNOMON, MPH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP6, WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The collection of data from Gorenje devices is time-driven and dispatched
every 15min and it is depended on the standards that Gorenje provides._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services and for a broader use in an anonymised/aggregated manner for creating
behaviour profiles and clustering patients to different medical groups.
Significant deviation from the latter profiles is expected to produce relevant
notifications._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of Gorenje devices deployed in CERTH / ITI’s facilities,
that are not sensitive, is accessible through Gorenje Cloud in a local
experimental repository._

_The full dataset from Gorenje devices deployed in elderly’s people houses is
confidential and only the authorized MPH personnel and related end-users have
access as defined through Gorenje Cloud. The latter authorized groups of users
access data in a tamper-proof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from Gorenje
devices deployed at seniors’ houses provides added value and be the base for
other research projects (e.g. statistical data). VICINITY could have an open
portal / repository on its website, providing anonymized data’s information
like timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 26: Dataset description of the GNOMON/CERTH Gorenje Smart Appliances
Sensor**

##  4.5. Datasets for eHealth from Centre for Research and Technology Hellas
(CERTH)

CERTH / ITI contributes in the use case pilot setup for houses at Municipality
of Pilea-Hortiatis and provide its background knowledge in the field of
assisted living. It also provides its infrastructure of Smart House for cross-
domain implementation including building sensors and devices which have been
also integrated to houses at MPH.  
  
<table>  
<tr>  
<th>

**DS.CERTH.01.Door_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Door sensors are deployed, on the one hand, in houses of patients in need of
assisted living, identified by the equivalent municipality (MPH) health care
services to ensure the validity of each case, but also in CERTH’s smart house
facilities for testing reasons. The main task of the sensor is to provide a
24/7 door status for the area of its responsibility. Data coming from this
sensor are used to create behaviour profiles based on relevant criteria and
produce notifications in case of deviation from the normal standards._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset are collected via a combination of connected door sensors (Zwave)
and a Connectivity Gateway based on_

_Raspberry pi._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices are the property of the test site owners, where the data
collection is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_Τhe collection of data from door sensors is event-driven (e.g._

_through REST Services, XML format etc.)._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services and for a broader use in an anonymised/aggregated manner for creating
behaviour profiles and clustering patients to different medical groups.
Significant deviation from the latter profiles is expected to produce relevant
notifications._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of door sensors deployed in CERTH / ITI’s smart house, that
are not sensitive, are accessible through a local experimental repository._

_The full dataset of sensors deployed in houses of elderly people are
sensitive therefore are confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamperproof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open portal
/ repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 27: Dataset description of the CERTH Door Sensor**  
  
<table>  
<tr>  
<th>

**DS.CERTH.02.Motion_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Motion sensors are deployed, on the one hand, in houses of patients in need
of assisted living, identified by the equivalent municipality (MPH) health
care services to ensure the validity of each case, but also in CERTH’s smart
house facilities for testing reasons. The main task of the sensor is to
provide the 24/7 motion levels for the area of its responsibility. Data coming
from this sensor are used to create behaviour profiles based on relevant
criteria (e.g. motions level for a specific room and time period, etc.) and
produce notifications in case of deviation from the normal standards._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset are collected via a combination of connected motion sensors
(Zwave) and a Connectivity Gateway based on Raspberry pi._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices are the property of the test site owners, where the data
collection is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_GNOMON, MPH, CERTH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP6, WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The collection of data from motion sensors is event-driven (e.g._

_through REST Services, XML format etc.)._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services and for a broader use in an anonymised/aggregated manner for creating
behaviour profiles and clustering patients to different medical groups.
Significant deviation from the latter profiles is expected to produce relevant
notifications._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of door sensors deployed in CERTH / ITI’s smart house, that
is not sensitive, is accessible through a local experimental repository._

_The full dataset of sensors deployed in houses of elderly people are
sensitive therefore are confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamperproof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open portal
/ repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 28: Dataset description of the CERTH Motion Sensor**  
  
<table>  
<tr>  
<th>

**DS.CERTH.03.Pressure_Mat**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Pressure mats are deployed, on the one hand, in houses of patients in need of
assisted living, identified by the equivalent municipality (MPH) health care
services to ensure the validity of each case, but also in CERTH’s smart house
facilities for testing reasons. The main task of the device, which is deployed
on beds, is to provide the sleeping hours of the users. Data coming from this
sensor are used to create behaviour profiles based on relevant criteria and
provide notifications in case of deviation from the normal standards._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset is collected via a sensor triggered when a person lies on the
bed, an Arduino which reads the pressure mat measurement and a Connectivity
Gateway based on Raspberry_

_Pi._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The devices are the property of the test site owners, where the data
collection is being performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_MPH, CERTH_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_MPH, CERTH_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are being collected within activities of WP6, WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset is accompanied with the respective documentation of its contents.
Indicative metadata include device id, measurement date, device owner, state
of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The collection of data from motion sensors is event-driven (e.g._

_through REST Services)._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services and for a broader use in an anonymised/aggregated manner for creating
behaviour profiles. Significant deviation from the latter profiles is expected
to produce relevant notifications._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of pressure mat deployed in CERTH / ITI’s smart house, that
is not sensitive, is accessible through a local experimental repository._

_The full dataset of devices deployed in houses of elderly people are
sensitive therefore are confidential and only the authorized MPH personnel and
related end-users have access as defined. The latter authorized groups of
users access data in a tamperproof way with an audit mechanism triggered
simultaneously to guarantee the alignment with relevant requirements coming
from the recently introduced General Data Protection Regulation (GDPR).
Specific consortium members involved in technical development and pilot
deployment further have access under a detailed confidentiality framework._

_Furthermore, if the dataset in an anonymised/aggregated manner is decided to
become of widely open access, a data management portal will be created that
should provide a description of the dataset and link to a download section._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from sensors
deployed at seniors’ houses provide added value and be the base for other
research projects (e.g. statistical data). VICINITY could have an open portal
/ repository on its website, providing anonymized data’s information like
timestamp and description._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Due to ethical and privacy issues, data are stored in a database scheme at
the headquarters of MPH, allowing only authorised access to external end-
users. A back up is stored in an external storage device, kept by MPH in a
secured place. Data are kept indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 29: Dataset description of the CERTH Pressure Mat**

##  4.6. Datasets for intelligent mobility from Hafenstrom AS (HITS)

HITS provided the user requirements specifications and demonstration of
transport domain use case, while actively participating in dissemination and
exploitation activities of the project. By employing knowhow within
standardization bodies, mobility and smart city governance, HITS allowed
municipalities and smart cities to better utilize internal resources and
improve on services offered to citizens and agencies alike.

Furthermore, HITS was responsible for the Use cases “Virtual Neighbourhood of
Buildings for Assisted Living integrated in a Smart Grid Energy Ecosystem” and
“Virtual Neighbourhood of Intelligent (Transport) Parking Space”. Towards this
direction, it was the main partner to bring/arrange the required
infrastructure, in collaboration with other Consortium partners (i.e., TINYM
partner), for the use case demonstration.  
  
<table>  
<tr>  
<th>

**DS.HITS.01.Parkingsensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors will be installed at a test site, and will register proximity of
objects of a certain size. Future subset may contain information about
temperature, humidity, noise, light and other temperature, visual and touch
related data. The sensors main task is to detect if the space is occupied.
This information will later on be integrated with identification in order to
verify that the vehicle/unit that occupies the space is licenced through
either booking or ticketing action being taken._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset will be collected through a sensor that is mounted at the parking
site._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device will be the property of the test site owners, where the data
collection is going to be performed_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata include: (a) description of the experimental
setup (e.g. process system, date, etc.) and procedure which is related to the
dataset (e.g. proactive maintenance action, unplanned event, nominal
operation. etc.), (b) scenario related procedures, state of the monitored
activity and involved workers, involved system etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored at XML format and are estimated to be 50-300 MB per
month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Registering parking activity based upon availability, vehicle,
ownership/licence, comparing with nearby infrastructure and surrounding ITS
technology._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be available to participants in the project. If the
dataset or specific portions of it (e.g. metadata, statistics, etc.) are
decided to become of widely open access, a data management portal will be
created that should provide a description of the dataset and link to a
download section. Of course these data will be anonymized, so as not to have
any potential ethical issues with their publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device of the developed system (computer).
A back up will be stored in an external storage device. Data will be kept
indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 30: Dataset description of the HITS parking sensor**  
  
<table>  
<tr>  
<th>

**DS.HITS.02.SmartLight**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Smart lights will be installed at the lab, and will demonstrate how light and
colours can indicate the state of access and availability. Future subset may
contain information about proximity, movement, heat sensing (infrared), sound
sensing and door contact sensors. The smart lights main task is to visually
inform about the state of the parking space. This information may later on be
integrated with indicators for occupancy, time to availability and validity._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset will be received from a laptop in the lab._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device will be the property of the test site owners, where the data
collection is going to be performed_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata include: (a) description of the experimental
setup (e.g. process system, date, etc.) and procedure which is related to the
dataset (e.g. proactive maintenance action, unplanned event, nominal
operation. etc.), (b) scenario related procedures, state of the monitored
activity and involved workers, involved system etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored at XML format and are estimated to be 50-300 MB per
month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Registering parking activity based upon availability, vehicle,
ownership/licence, comparing with nearby infrastructure and surrounding ITS
technology._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be available to the members of the consortium. If the
dataset or specific portions of it (e.g. metadata, statistics, etc.) are
decided to become of widely open access, a data management portal will be
created that should provide a description of the dataset and link to a
download section. Of course, these data will be anonymized, so as not to have
any potential ethical issues with their publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device of the developed system (computer).
A back up will be stored in an external storage device. Data will be kept
indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 31: Dataset description of the HITS Smart lighting**  
  
<table>  
<tr>  
<th>

**DS.HITS.03.LaptopTeststation**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The laptop test station will be installed at the workbench where the operator
normally works, and will aggregate data and process information received
wirelessly from other devices delivering data of relevance to the mobility
domain and parking in particular. Future subset may contain information about
other domains – energy, and data packages from smart home and health-devices.
The test stations main task is to process data and trigger activate and log
actions accordingly._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset will be collected wirelessly and via USB ports._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device will be the property of the test site owners, where the data
collection is going to be performed_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata include: (a) description of the experimental
setup (e.g. process system, date, etc.) and procedure which is related to the
dataset (e.g. proactive maintenance action, unplanned event, nominal
operation. etc.), (b) scenario related procedures, state of the monitored
activity and involved workers, involved system etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored at XML format and are estimated to be 50-300 MB per
month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Registering parking activity based upon availability, vehicle,
ownership/licence, comparing with nearby infrastructure and surrounding ITS
technology._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be available to the members of the consortium. If the
dataset or specific portions of it (e.g. metadata, statistics, etc.) are
decided to become of widely open access, a data management portal will be
created that should provide a description of the dataset and link to a
download section. Of course, these data will be anonymized, so as not to have
any potential ethical issues with their publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the middleware
as well as a data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device of the developed system (computer).
A back up will be stored in an external storage device. Data will be kept
indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 32: Dataset description of the HITS laptop test station**  
  
<table>  
<tr>  
<th>

**DS.HITS.04.Sensio_sensors_temperature_motion_lock**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensors for measuring temperature, motion detection and identifying status of
door/window lock will be installed in apartments that are managed by
caretakers employed by Tromsø municipality._

_The datasets will contain general information about activities, and offer
insight that building manager, caretakers and medical staff can utilize to
offer better service and trigger messages should deviations situations occur._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset will be received from a Sensio gateway that stores the data on an
external server, and made available to a laptop at the pilot site through an
API._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device will be the property of the test site owners, where the data
collection is going to be performed_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information on location, and be accompanied with the
respective documentation of its contents. Indicative metadata include:
scenario related procedures, state of the monitored activity and involved
workers, involved system etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored at XML format and are estimated to be 30-50 MB per
month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Identifying usage history used for resource planning and detecting unexpected
activities based on activity or lack of activity, as well as measured values
versus expected data._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset will be available to the members of the consortium. Specific
portions will be accessible to building managers and medical staff. Parts of
the data will be anonymised, while other will available through a two-pass
data management porta. For privacy reasons, the data access will be limited,
so configuration will be made in close cooperation with the service provider._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Due to confidentially, the created dataset will only be made accessible
through a data management portal that is open to medical staff and managers._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device of the developed system (computer).
A back up will be stored in an external storage device. Data will be kept
indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 33: Dataset description of the Sensio sensors**  
  
<table>  
<tr>  
<th>

**DS.HITS.05.Gorenje_Smart_Appliances_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The Gorenje smart appliances installed at the Tromsø pilot site includes a
fridge and an oven. The appliances are managed by caretakers employed by
Tromsø municipality, the tenants themselves and the building manager. The
appliances contain sensors that among other things can measure timestamps and
temperature._

_The data harvested will be used to identify usage history in order to offer
better service, identify abnormal behaviour, and otherwise generate logs that
can be used for statistical analysis._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The data will be collected by specific smart appliances (i.e. oven, fridge)
provided by Gorenje and adjusted to VICINITY requirements. The data will be
made available to a laptop at the pilot site through an API._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The device will be the property of the test site owners, where the data
collection is going to be performed._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_HITS, GORENJE_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_HITS, GORENJE_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_HITS_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP6, WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_A collection of data is dispatched every 15 minutes. The format is based on
standards provided by Gorenje._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Usage data to identify behaviour patterns and as mean for training disabled
users in being more self-sufficient are examples are examples of value-added
services that can be built on top of the platform. As the data pool increases,
more services are expected to be included._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_The full dataset of Gorenje devices deployed at the Tromsø pilot site
“Teaterkvarteret 1. Akt”, will be stored at the Gorenje Cloud in a local
experimental repository._

_The full dataset will be available to selected members of the consortium.
Specific portions will be accessible to building managers and medical staff.
Parts of the data will be anonymised, while other will available through a
two-pass data management porta. For privacy reasons, the data access will be
limited, so configuration will be made in close cooperation with the service
provider._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Anonymised parts of the dataset will be available for training and statistic
purposes. Aggregated data that could be used to identify the user or other
privacy related information will be limited. Due to confidentially, the
created dataset will only be made accessible through a data management portal
that is open to medical staff and managers._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device of the developed system (computer).
A back up will be stored in an external storage device. Data will be kept
indefinitely allowing statistical analysis._

</td> </tr> </table>

**Table 34: Dataset description of the Gorenje smart appliances sensor**

##  4.7. Datasets for buildings from Tiny Mesh AS (TINYM)

Tiny Mesh focus on creating new products, services and business model as part
of the Internet-ofEverything (IoE). New potential arises when IoE is used for
connecting, integrating and controlling all kinds of meters, street lights,
sensors, actuators, assets, devices, tags and other devices.

The primary role of Tiny Mesh Company was as a developer and technology
provider, with the company´s IoT solution as the main enabling technology. The
goal was to offer promising technology solutions through participation in use
cases.

TINYM contributed in the practical implementation through their work with
definitions of use case. TINYM took practical ownership of the various demo
sites through the role as of leader of WP7.  
  
<table>  
<tr>  
<th>

**DS. VITIR.01.Door_Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors will be installed in the door of a room where there is a need for
monitoring usage._

_Data packet contains sensor data of movement._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_Discrete digital input_

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The property owner Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_Metadata about location of the sensor, network topology and network status
will be available in VITIR’s mqtt server.._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_Data is delivered as a discrete value indicating if door has been opened or
closed, volume of data depends on the usage._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_The purpose of this collection is to give input data for analysis of room
usage for analyses to the building owner and Facility manager._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_Data access for building manager and facility manager. Data will be
anonymized, so as not to have any potential ethical issues with their
publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Data access is confidential. Only members of the consortium, building manager
and facility manager will have access on it for privacy reasons._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Unless specified otherwise by client the data will be stored in a Value-Added
Service._

</td> </tr> </table>

**Table 35: Dataset description of the VITIR Door Sensor**  
  
<table>  
<tr>  
<th>

**DS. VITIR.02.CO2 Sensor**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_The sensors will be installed to measure CO2 levels. Data packet contains
sensor data of movement._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_Data is retrieved through industry-standard meters and communicated through
Tiny-Mesh infrastructure before being made available to the consortium._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The property owner Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_Tiny-Mesh_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected within activities of WP7 and WP8._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_Metadata about location of the sensor, network topology and network status
will be available in VITIR’s mqtt server._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_Communication with meter will be on a proprietary interface according to
meter vendor. Data will be delivered as ppm_

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Purpose is to give additional information about air quality inside various
office spaces to the building management._

</td> </tr>  
<tr>  
<td>

Data access policy / Dissemination level

(Confidential, only for members of the Consortium and the

Commission Services) / Public

</td>  
<td>

_Data access is restricted to the consortium, building manager and facility
manager. Data will be anonymized, so as not to have any potential ethical
issues with their publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Data access is confidential. Only members of the consortium, building manager
and facility manager will have access on it for privacy reasons._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will only be stored by the Value Added Service._

</td> </tr> </table>

**Table 36: Dataset description of the VITIR’s sensor for CO2.**

##  4.8. Datasets for buildings from Open Call Winner PilotThings

RTNRG – Real Time EneRGy management

Pilot Things focus is IoT Data as a service: we transform real sensors data to
human data. Our novel approach helps cities and industries to leverage IoT.
Our software Pilot Things is compliant with oneM2M worldwide standard since
the origin thanks to a collaboration with the research laboratory LAAS-CNRS.
oneM2M is based on a centralized architecture with interworking and semantic
representation capabilities. oneM2M suits very well to integrate multiple
buildings protocols. Our project fits in the smart building and energy
management use case. The main objective is to build an infrastructure for
facility management companies to help them deliver energy management services.

The extension objective is to monitor an office building energy consumption
and compare it to a grid production.

The drawing hereunder sum-up the data flow:

**Figure 10: PilotThings data flow**

Here is a dataflow from the plug to VICINITY:

**Figure 11: PilotThings global dataflow**

The oneM2M ADN client connects to oneM2M IN. Pilot Things is also a oneM2M
client. The oneM2M ADN is advised for new plugs data. It then exposes the data
to VICINITY cloud. To understand oneM2M terminology see oneM2M TS001 spec here
http://www.onem2m.org/technical/publisheddrafts/release-3

Documentation and software can be found in GitHub at:

  * M2MoneM2M IPE VICINITY adapter: _https://github.com/vicinityh2020/adapter-pilot-things-one_

  

  * This agent gets the OPA dataset and send it to VICINITY network: https://github.com/vicinityh2020/adapter-pilot-things-OPA 

  

SPIE group ask us to connect this project to their IoT solution so called
Colligo. Colligo is based on Thingsworx platform. So we plan to develop an
interface to Thingsworxto send VICINITY and Pilot Things data. This project
will be used by SPIE operational business entities. We also introduced
VICINITY to Vinci Energie group which is a big worldwide SI. We won a smart
city challenge at vivatechlogy show. We will have more information on Vinci
objectives after the show (see _www.vivatechnology.com_ )

During the project we developed an oneM2M zwave IPE (aka driver) allowing us
to connect any commercial zwave product. The oneM2M Pilot Things VICINITY
adapter bridges Pilot Things and VN thus allowing the connection of all the
sensors we support including zwave. We now have more than 200 LoRaWan and
Sigfox sensors preintegrated in our catalog  
  
<table>  
<tr>  
<th>

**DS. PilotThings.01.Building**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_This dataset includes energy consumption measurement points for buildings to
identity usage._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset includes smartplugs energy consumption and building global energy
consumption from building management system._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The smartplugs and the gateway are Pilot Things property._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_Pilot Things_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_Pilot Things_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_Pilot Things_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected during OC WP4._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data are received using ZWave radio protocol and csv files from the
building management system._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_The collected data are store in Pilot Things database and used to produce
energy consumption dashboards. The building facility manager will have access
to the dashboard and thus the data._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be confidential and only the members of the consortium
will have access on it. Furthermore, if the dataset or specific portions of it
(e.g. metadata, statistics, etc.) are decided to become of widely open access,
a data management portal will be created that should provide a description of
the dataset and link to a download section. Of course, these data will be
anonymized, so as not to have any potential ethical issues with their
publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using Pilot Things APIs as well as a
data management portal._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be store in Pilot Things database for 1 year period._

</td> </tr> </table>

**Table 37: Description of the PilotThings building dataset.**  
  
<table>  
<tr>  
<th>

**DS. PilotThings.02.OPA_Grid**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_This dataset includes solar energy production measurement._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The dataset includes the net AC production per minute._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_The solar premises are LAAS/CNRS property._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_Pilot Things gateway retrieves the data._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_Pilot Things_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_Pilot Things_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are going to be collected during OC WP4._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will be accompanied with the respective documentation of its
contents. Indicative metadata may include device id, measurement date, device
owner, state of the monitored activity, etc._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data format is acsv files from the OPA._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_The collected data are store in Pilot Things database and used to produce
energy consumption dashboards. The building facility manager will have access
to the dashboard and thus the data._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be confidential and only the members of the consortium
will have access on it. Furthermore, if the dataset or specific portions of it
(e.g. metadata, statistics, etc.) are decided to become of widely open access,
a data management portal will be created that should provide a description of
the dataset and link to a download section. Of course, these data will be
anonymized, so as not to have any potential ethical issues with their
publication and dissemination._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using Pilot Things APIs as well as a
data management porta._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be store in Pilot Things database for 1-year period._

</td> </tr> </table>

**Table 38: Description of the PilotThings OPA Grid-dataset.**

##  4.9. Datasets for buildings from Open Call Winner WearHealth

WearHealth – Safety and Health Intelligence

**WearHealth is an intelligent decision support system that can use any 3rd
party wearables and IoT devices. 3rd party hardware is integrated into our
proprietary cognitive technologies to build an intelligent software platform
that can identify markers of workers’ occupational risks, health, workload,
and work efficiency. With these insights, businesses can detect and predict
worker safety and health risks, thus preventing accidents and managing their
workforce to improve productivity and operational efficiency.**

IoT communication infrastructures and data stream integrations are not yet
standardized in the industry and need to comply with the EU General Data
Protection Regulation. The goal of this project is to further develop our
technology and market WearHealth version 2.0 that includes a modularity
approach to connect to wearables and process the data integrated into VICINITY
following its decentralized interoperability concept.

The key functionality of the adapter is to upload semantic data from the
wearable to the Gateway. We have also implemented a Value-Added Service (VAS)
to provide real-time response to another service/adapter. The semantic data
for the service and adapter was stored in the VICINITY Cloud using the
VICINITY Neighbourhood Manager. For this, we used the VICINITY gateway API and
VICINITY agent API. The integration of wearables and our cloud services was
planned together with the VICINITY technical team and the final system was
deployed and tested in an industrial environment. The key results are: we have
built an adapter for a wearable (smart shirt) and a value-added service,
uploaded semantic data to the VICINITY cloud, improved data privacy and
security for our solution and validated the value of the integration of our
cloud service with VICINITY.

Key elements of the final WearHealth – VICINITY integration are the VICINITY
gateway API and VICINITY agent API to communicate and deliver access to the
wearables sensor semantic data to the VICINITY Neighbourhood Manager. We have
developed a custom adapter in order to access the semantic data from the
wearable via BLE and a gateway. Moreover, a value-added service (VAS) was
developed to provide real-time feedback based on the raw data from the
wearable.

The smart shirt has been successfully registered to the VICINITY Neighbourhood
Manager by integrating our gateway. The data from the smart shirt was
collected in an industrial environment. Due to the VICINITY integration, we
have validated the improvements in terms of data privacy and the value for
potential customers. In this report, we will show the final results of the
integrations and evaluations.

WearHealth improve data privacy and transparency in such form that:

  * The user has full control over his own data 

  

  * Conclusions only at an aggregate level, not from each user 

  

  * All data is anonymized and stored securely 

  

  * No data shared with third parties 

  

  * No data collected without the explicit and voluntary consent of the use 

  

  * No data is used for purposes other than occupational safety and health 

  

Based on the results of this project, WearHealth will strongly focus on the
further improving data privacy strategy and access to additional data sets to
increase the service.  
  
<table>  
<tr>  
<th>

**DS. WearHealth.01.SmartShirt**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_This dataset includes a one channel ECG (Electrocardiogram) to generate heart
rate, R-R intervals, steps, activity and motion data of the users._

_This wearable uses which_

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The main input device in the present use-case is the smart-shirt from
Ambiotex using standard BLE (Bluetooth Low Energy) transmission._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_Private owned_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_WearHealth_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_WearHealth_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_WearHealth_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_WearHealth provides analysis on the data from the smart shirt such as heart
rate and heart rate variability to detect high workers workload to reduce
potential accidents and health related problems._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The Worker decides who has access to the data._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The owner of the data (User or worker) will be able to share his data with
other solutions providers. The collected data during the project can be made
available in_

_anonymized form to partners for additional services. Test users (volunteers)
will sign specific documentation to allow the processing of their raw data._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the WearHealth cloud and compliant with the GDPR. Key
features are:_

  * _Personal data is stored anonymously_

  

  * _Encrypted data transmission and storage_

  

  * _Data is stored in a private European data base_

  

  * _The right to be forgotten_

  

  * _Data is stored for the shortest time possible The following standards are employed:_

  

  * _SHA-256_

  

  * _SSL_

  

  * _AES-COM at the BLE_

  

  * _Login information are raw data are stored in physically_

  

  * _separated servers_

  

  * _Passwords expire every 60 days_

  

</td> </tr> </table>

**Table 39: Description of the WearHealth dataset.**

##  4.10. Datasets for yachting marina from Open Call Winner SaMMY

**SaMMY is an IoT cloud-based service solution for the Yachting Marina
ecosystem, which enables the Marinas to efficiently manage their resources, to
attract and efficiently service more yachts and support the local markets by
linking them with the yachting community. Its main goal is to simplify
Yachting Marinas’ operational processes, strengthening the yachters’
engagement with them as well as with the surrounding economies and also offer
easy-to-use online services to yachters and skippers.**

Taking advantage of its open architecture (FIWARE enablers and RESTful data
model interfaces) SaMMY can definitely contribute to any IoT ‘Smart City’
or/and ‘Smart Mobility’ ecosystem, enhancing the availability of Yachting-
Marina sector data resources.

VICINITY Adapter for SaMMY code repository has been uploaded in VICINITY
Github repository in URL:

_https://github.com/vicinityh2020/vicinity-adapter-sammy_

VICINITY SaMMY demo IoT dashboard for code repository has been uploaded in
VICINITY Github repository in URL: _https://github.com/vicinityh2020/vicinity-
sammy-demo_

A demo application illustrating the integration between SaMMY IoT platform and
VICINITY infrastructure is publicly available at:
https://vicinity.optionsnet.gr/demo/. The application is a web application
developed with Spring Boot, Thymeleaf and other web technologies. The values
are continuously refreshed every 10-seconds, a value that is configurable in
the application.properties files. However, user can directly request an IoT
value by pressing “Query Now” link at the desired IoT.

SaMMYacht IoT platform neither gathers nor handles any kind of personal data
as its infrastructure involves environmental and occupancy sensors. Sensors’
data are saved and kept for statistical/historical and evaluation reasons in
the cloud database of the SaMMYacht platform. On the other hand, SaMMY-
VICINITY integration does not consider these historical data, since Vicinity
adapter implemented for this integration only handles the current values of
the sensors, which in turn are ot saved. Moreover, no aggregated data
regarding the integration of the SaMMY-Vicinity are stored.

Finally, the demonstration webapp only keeps the last set of sensors’ data in
order to minimize querying the SaMMY infrastructure, which are in turn served
in the demo UI.

Concluding, due to the nature of the SaMMY IoT platform sensors and data, only
READ operations are allowed and supported, since platform does not involve any
kind of services or actuators at the IoT level. That being said, malicious
actions won‘t have any effect.  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.Air_Temperature**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensor for measuring Ait temperature, have been installed in Patras Port
Mooring for Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensor that feed this dataset is Libelium Smart City Plug &Sence - Air
Temperature probe). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for Environment Temperature on Patras
Port Mega Yacht Mooring and geolocation info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 40: Description of the Air Temperature dataset.**  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.Humidity**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensor for measuring Humidity, has been installed in Patras Port Mooring for
Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensor that feed this dataset is Libelium Smart City Plug &Sence -
Humitidy probe). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for Environment Humidity on Patras Port
Mega Yacht Mooring and geo-location info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 41: Description of the Humidity dataset.**  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.Water_Temperature**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensor for measuring Water Temperature, has been installed in Patras Port
Mooring for Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensor that feed this dataset is Libelium Smart Water Plug &Sence - Water
Temperature probe). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for Water Temperature on Patras Port
Mega Yacht Mooring and geo-location info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 42: Description of the Water Temperature dataset.**  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.Water_pH**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensor for measuring Water pH, has been installed in Patras Port Mooring for
Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensor that feed this dataset is Libelium Smart Water Plug &Sence - Water
pH probe). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for Water pH on Patras Port Mega Yacht
Mooring and geo-location info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 43: Description of the Water pH dataset.**  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.Water_ORP**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensor for measuring Water Oxidation Reduction Potential, has been installed
in Patras Port Mooring for Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensor that feed this dataset is Libelium Smart Water Plug &Sence - water
ORP probe). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for Water ORP on Patras Port Mega Yacht
Mooring and geo-location info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 44: Description of the Water ORP dataset.**  
  
<table>  
<tr>  
<th>

**DS. SaMMY.Patras.BerthSpace(5-15)_Occupancy**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_Sensors for monitoring berth spaces availability at Patras Port Mooring for
Mega-yachts._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_The sensors that feed this dataset is Libelium Smart City Plug &Sence -
UltraSound probes). _

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_SaMMYacht (Patras Port Mooring / Patras Port Authority)._

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_SaMMYacht_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_The data are already collected._

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_The dataset will contain information for berth space availability at Patras
Port Mega Yacht Mooring and geo-location info._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_The data will be stored to the CLOUD and are estimated to be 5 MB per month._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_Data exploitation is foreseen to be extended through envisioned value-added
services, allowing full access to specific authorised users._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_The full dataset will be available to the members of the consortium or
public._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_The created dataset could be shared by using open APIs through the
middleware._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_Data will be stored in the storage device on the Cloud. A back up will be
stored in an external cloud storage device. Data will be kept indefinitely
allowing statistical analysis._

</td> </tr> </table>

**Table 45: Description of the Berth Spaces occupancy dataset.**

##  4.11. Datasets for INCANT from Open Call Winner Thinkinside Srl

**INCANT integrates IoT infrastructures providing indoor positioning data and
the relevant supporting services into the VICINITY ecosystem.**

Location is a first-class citizen in IoT: it can play a role in the
aggregation/processing of IoT-generated information (e.g., spatial
aggregation) or it can be the data point itself (e.g., tracking). In
particular, we focus on indoor location, where the support for location-based
services can enable and augment a rich set of application scenarios, ranging
from retail marketing, interactive spaces, to healthcare medical portable
equipment tracking, facility management and manufacturing safety of personnel,
process monitoring.

INCANT will provide a set of standard and actionable APIs, based upon the
VICINITY ones, able to overcome such fragmentation of technologies and
services in the indoor positioning area, enabling interoperability across
indoor location technology, platforms and domains with the aim of unlocking
the full potential of IoT applications. Break silos, avoid duplication of
efforts and infrastructures) will be one of the primary outcomes of the INCANT
proposal for the VICINITY ecosystem.

During the initial months of the project, we have performed the initial design
of the INCANT architecture and corresponding mapping to the existing VICINITY
infrastructure. The Real Time Locating System (RTLS) is an infrastructure used
to locate assets inside an indoor environment. It is typically based on a
network of localisation antennas connected with each other, and able to
localise a number of transmitting devices. A transmitting device can be either
a TAG or a mobile device such as, e.g., a Smartphone. The output of an RTLS
system is typically a timestamped series of location coordinates.

All adapters have been implemented and tested. The adapters allow to introduce
localisation into the IoT scenarios supported by VICINITY. The INCANT adapters
have been released as open source and can be accessed in the VICINITY GitHub
at the following link:

https://github.com/vicinityh2020/vicinity-adapter-thinkinside

The INCANT project aims at proving an indoor localisation service to the
VICINITY infrastructure and ecosystem. This will be based on the ThinkIN
platform and technology, integrated with a set of VICNITY adapters for the
collection and sharing of location data streams. This will allow to abstract
developers from the creation and management of an RTLS infrastructure. No data
will be stored in the INCANT infrastructure and no specific knowledge is
present beforehand on the Object being localised and tracked. In terms of
system architecture, the INCANT project will be running in (i) the ThinkIN
cloud infrastructure (ii) a local deployment managing the RTLS component and
the integration with VICINITY (iii) the VICINITY infrastructure. The data
exchanges between all components will occur over secure connections (https)
thus ensuring the end-to-end confidentiality and security of the data being
exchanged.

Developers or System integrators will rely on INCANT to develop specific
application scenarios. This will range from retail applications, to smart
manufacturing and smart buildings. In all cases, they will be in charge of
defining the specific policy according to which data will be managed and in
case enforce any privacy protection action that might be required to comply
with the current GDPR regulation. For the INCANT pilot and demonstrator we
have utilised a retail scenario, where we have tracked anonymously the
shopping carts and baskets moving in a retail store. Each asset is not linked
to any personal information (e.g., shopper ID or other personal identifier)
and data is utilised for store operational efficiency (e.g., detect queuing
patterns at checkouts).  
  
<table>  
<tr>  
<th>

**DS. ThinkInside.01.INCANT**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

_ThinkInside_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

_ThinkInside_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data

analysis (if different)

</td>  
<td>

_ThinkInside_

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

_ThinkInside_

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

_None_

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

_No relevant information provided._

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

_No relevant information provided._

</td> </tr> </table>

**Table 46: Description of the INCANT dataset.**

##  4.12. Datasets for F2IS-VAS from Open Call Winner Sensinov

Ensuring accurate datasets through fault monitoring and isolation is crucial
for operational Internet of Things (IoT) deployments. In fact, IoT devices and
sensors can generate incorrect measurements which can be attributed to
software and hardware issues. As an example, if an IoT system is used to
perform predictive maintenance of a smart building, the collected IoT datasets
must accurately reflect the status of the monitored system. Continually
monitoring and isolating faults is an important feature in IoT.

The objective of F2I-VAS project is experimenting and validating a Value-Added
Service for fault detection in a smart building environment. F2IS-VAS relies
on IBM Watson IoT platform to capture incorrect measurements which can be
attributed to software and hardware issues.

F2I-VAS objectives are articulated around the following aspects:

  * Integration of VICINITY with IBM Watson IoT platform to offer fault detection as a service providing insights to dashboard application of smart building operators. Fault detection with IBM Watson IoT is based on both machine learning of data sets as well as detection models known as SPSS (Statistical Package for the Social Sciences). We refine SPSS models for data sets pertaining to Smart Building. 

  

  * To integrate smart building infrastructure and fault detection and isolation capabilities, we need to develop adapters that translate between NGSI-LD model and the VICINITY Thing Description and VICINITY ontology to Watson IoT data model. 

  

  * To enhance the learning capabilities of our value-added service, we bring different datasets types from smart building. 

  

Djane is available in sensinov github. Link:
_https://github.com/sensinov/djane_

The anomaly detection service is available in this link _:_
_https://github.com/mbenalaya/VCNT_F2I_VAS_  
  
<table>  
<tr>  
<th>

**DS.Sensinov.01.F2IS-VAS**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

The sensors are deployed on ADREAM building at LAAS-CNRS. They measure
building occupants’ comfort, energy/ water consumption, access, lighting.

Registered data types are as follows:

  * Temperature 

  

  * Humidity 

  

  * Luminosity 

  

  * Energy consumption 

  

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

Smart building data is collected via connectors (software) which get data in
device-specific data format and translate it into NGSI-LD data model.
Integrated device types are:

  * electricalCounter 

  

  * waterCounter 

  

  * temperature 

  

  * humidity 

  

  * luminosity 

  

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

LAAS-CNRS

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

Sensinov

</td> </tr>  
<tr>  
<td>

Partner in charge of the data analysis (if different)

</td>  
<td>

Sensinov

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

Sensinov

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

The data are going to be collected within activities of WP2

(System implementation, testing and documentation) and WP3 (System
integration, exploitation plan and business model).

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata

(Production and storage dates, places) and documentation?

</td>  
<td>

We provide metadata related to location and timestamp.

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

We follow these standards to specify the data model: SAREF4BLDG and NGSI-LD.

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

Data is used to train fault detection models and perform analysis to isolate
faulty data.

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

Our solution does not deal with personal data. Regulation such as free flow of
(non-personal) data will apply in the context of the digital single market. We
will comply with application regulations from this perspective.

The full dataset will be confidential and only the members of the consortium
will have access on it.

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

The data will be processed to make learning and detect anomalies and will be
destroyed gradually.

There is not storage nor preservation of the VICINITY data after the
processing and insights generation. Vicinity Infrastructures owners have the
complete control of their data.

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

Sensinov will store data with backups.

</td> </tr> </table>

**Table 47: Description of the F2I-VAS dataset.**

##  4.13. Datasets for drEven from Open Call Winner Ubiwhere

drEVen allows any supplier of energy and owner of an OCPP-compliant Electrical
Vehicle (EV) charging station to easily become a real e-mobility Operator,
offering EV charging services with a proper transparent billing and
settlements layer. The decentralised solution uses blockchain and smart
contracts technology to process all monetary transactions and transparently
manage energy tariff and financial settlements. In a nutshell, it provides
energy suppliers with a suite of software allowing for complete management of
Electrical Vehicle stations, users’ RFID tokens, transaction monitoring and
transparent financial settlements; on the other hand, end users of the
solution (EV drivers) make use of a dedicated mobile app facilitating the
discovery of available and geo-positioned charging stations, as well as
management of all monetary transactions: topping up of different wallets,
acceptance of energy tariff and monitoring of past transactions (amount paid
to a specific provider, based on the consumed energy and provider’s specified
tariff).

Leveraging the project’s use of ontologies and abstraction layers, Ubiwhere
was able to design and implement a Vicinity adapter for this specific EV
charging station, exposing the services which effectively allow such partner
like Enercoutim to offer e-mobility services, making use of the
Vicinityenabled EV charging station. The set of services abstract the
complexities associated with the business layer (financial settlements and
billing processes), exposing also the set of Smart Contracts deployed in the
Ethereum blockchain, via common RESTful interfaces.  
  
<table>  
<tr>  
<th>

**DS. Ubiwhere.##.EVCharger**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

The EV charging station has been deployed at Enercoutim’s facilities,
providing information about meter readings, realtime operation status, and
information about last start and stop timestamp of an EV charging session. The
collected information references only data that has been collected during the
experiment phase, from either Ubiwhere or Enercoutim.

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

The information will be relayed from the platform managing the actual charging
station which has been installed on premises. The device naturally sends this
data to a platform which, in turn, relays to our device adapter, for others
(Entities registered in Vicinity Neighbourhood) to consume, after proper
authorisation (device adapter) from Ubiwhere.

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

Ubiwhere

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

Ubiwhere and, partially, Enercoutim (the latter during the experiment phase
only, when using the actual device)

</td> </tr>  
<tr>  
<td>

Partner in charge of the data analysis (if different)

</td>  
<td>

Ubiwhere and Enercoutim

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

Ubiwhere

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

NA

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata

(Production and storage dates, places) and documentation?

</td>  
<td>

Collected data during testing of this EV charging solution took place only
during the official testing period with Enercoutim, on the 08th of November.
This data has been temporarily stored in Ubiwhere’s controlled Servers (cloud-
level) for further analysis (more details afterwards) and reporting (this
deliverable only).

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

Only a very small portion of data has been stored during the 08th of November,
in an SQL database. No specific data standard nor format has been followed -
the data model has been entirely designed from scratch by Ubiwhere. As for the
device adapter, the temporary collection of data followed the available
ontologies, as already documented in previous sections.

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

The small portion of data collected during the real pilot, which has happened
at Enercoutim’s facilities, reflected the bare minimum required to assess the
viability of such a solution, by Ubiwhere alone. This data allowed us to
determine the outcome of different tests (section 4).

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

Access to data may be provided to the public, if required. Data which has been
deployed in the distributed ledger (Ethereum testnet), will forever be
publicly accessible.

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

Ubiwhere sees no value in sharing such data (besides the one stored in
Ethereum), neither re-using it nor distributing.

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

NA

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

Collected data will be stored only until this deliverable has been officially
deemed as valid and accepted by Vicinity’s consortium. Afterwards, it shall be
archived with an encryption key held by Ubiwhere only, for 6 months,
temporarily stored in the company’s data center.

</td> </tr> </table>

**Table 48: Description of the EVcharger dataset.**

##  4.14. Datasets for MyBigFitnessTwin from Open Call Winner Nissatech

Using the VICINITY concept of interoperability as a service, this proposal has
paved the way for a new generation of fitness monitoring and analytics
services which enable improving performances of a trainee, based on the
advanced real-time analytics on the data integrated from various information
silos in a sport club. The main outcome is a novel service for a deep analysis
of the personal fitness data, obtained from fitness wearables and
smartwatches. The goal is to learn the model of the usual behaviour of a
trainee and to apply that model in the real-time for the detection of unusual
situations. The main advantage is the application of the novel algorithms for
the comparison of the fitness data in order to get a very precise modelling
and consequently very accurate anomaly detection.

We support the GDPR through the rights to be removed, the rights to have
access to your own data, and secure storage of data. All users will have to
give their consent through a contract with terms of use in order to get access
to data and use the system. Content of consent is our policy with info about
collected data and way of processing it.

The owner (the originator of the data) cannot have any control of how
aggregated data is used for statistics or tailormade offers. In order to be
either removed or have data anonymized, concrete actions need to be taken. A
request needs to be directed to a trainer who will forward request for
deletion to us, and in period of 30 days the all users data will be anonymized
or completely removed. The same way, a user needs to send a request, which
will be processed by us as soon as possible and within 30 days the latest. The
user data will be exported in CSV format.

We have implemented security protocols to avoid man-in-the-middle attacks.
These measures include encrypted data available using JWT tokens during data
transfer through a REST interface.

The data is currently physically stored on our server, but plan is that
database will be put in the cloud. There can be various Value-Added Services
prepared for collected data, and we already implemented Anomaly detection
services, as described in the report. Data are secured at rest and in transit
with encryption. We are using JWT tokens while sending data to avoid man-in-
the-middle attacks.  
  
<table>  
<tr>  
<th>

**DS. Nissatech.##.smartWatch**

</th> </tr>  
<tr>  
<td>

**Data Identification**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

Dataset description

</td>  
<td>

The sensors are wearables. Trainees in a fitness club are using them. They are
monitoring the psychophysiological

parameters of a trainee during a training (usually HIIT – High Intensive
Interval Training)

</td> </tr>  
<tr>  
<td>

Source (e.g. which device?)

</td>  
<td>

Smartwatch Polar M600 is used. Data is collected in the real time and sent
(BTE) for further processing

Huawei smartscale and Contour plus One glucometer are used as contextualized
sensors

</td> </tr>  
<tr>  
<td>

**Partners services and responsibilities**

</td> </tr>  
<tr>  
<td>

Partner owner of the device

</td>  
<td>

Nissatech

</td> </tr>  
<tr>  
<td>

Partner in charge of the data collection (if different)

</td>  
<td>

Nissatech

</td> </tr>  
<tr>  
<td>

Partner in charge of the data analysis (if different)

</td>  
<td>

Nissatech

</td> </tr>  
<tr>  
<td>

Partner in charge of the data storage (if different)

</td>  
<td>

Nissatech

</td> </tr>  
<tr>  
<td>

WPs and tasks

</td>  
<td>

The data are going to be collected within activities of WP10.

</td> </tr>  
<tr>  
<td>

**Standards**

</td> </tr>  
<tr>  
<td>

Info about metadata

(Production and storage dates, places) and documentation?

</td>  
<td>

Metadata is related to the fitness context of the training, like the type of
exercises.

In addition, the data from the glucometer and smartscale are used as the
context for a fitness training.

</td> </tr>  
<tr>  
<td>

Standards, Format, Estimated volume of data

</td>  
<td>

Data format is defined, based on Smart4Fit data format.

</td> </tr>  
<tr>  
<td>

**Data exploitation and sharing**

</td> </tr>  
<tr>  
<td>

Data exploitation (purpose/use of the data analysis)

</td>  
<td>

Data analysis enables the creation of the models of the normal behavior (in a
fitness training) that will be compared with the real-time data during a
training in order to detect unusual/anomalous behavior

</td> </tr>  
<tr>  
<td>

Data access policy /

Dissemination level

(Confidential, only for members of the Consortium and the Commission Services)
/ Public

</td>  
<td>

First point here is the authentication, by using credentials (username and
password).

Second, is that all communication is SSL-encrypted. Which means that by using
certificates and keys, trainees data is protected from outside attacks while
being sent through network

</td> </tr>  
<tr>  
<td>

Data sharing, re-use and distribution (How?)

</td>  
<td>

There is no data sharing planned

</td> </tr>  
<tr>  
<td>

Embargo periods (if any)

</td>  
<td>

NA

</td> </tr>  
<tr>  
<td>

**Archiving and preservation (including storage and backup)**

</td> </tr>  
<tr>  
<td>

Data storage (including backup):

where? For how long?

</td>  
<td>

Nissatech

Data belongs to the partner fitness club and will be not deleted (except on
the request from a user)

</td> </tr> </table>

**Table 49: Description of the MyBigFitnessTwin dataset.**

#  Conclusions

This document is the third and final version of the Data Management Plan. It
is based on knowledge harvested through describing requirements, preparing the
VICINITY architecture, and planning the pilot sites. The updated datasets have
been delivered from the participants that are responsible for the test labs
and the living labs, and describes procedures and infrastructure that have
been defined at this point in the project.

The work on semantics and privacy issues has continued. It is the process of
clarification of procedures that has led to many of the updates that are found
in this document. Certain areas still need some attention. This will in
particular matter for Open Calls, as these are still tentative and the
documents and other material is still being worked out by the VICINITY
consortium. Activities for a Data Management Portal have proceeded, and a
demonstration has been held twice that presented how the VICINITY architecture
works, how it integrates and how the concept of virtual neighbourhood
functions in practical terms. More updates are envisaged after studies of the
pilot sites proceeds, and open calls are being presented. Future versions may
have updated Consent forms as well since the upcoming GDPR may lead to changes
in how privacy and ethics issues are formulated.

Lessons learned from the work conducted in this period is there has been
introduced more IoT assets that will be integrated within the ecosystems that
will be tested. There has been a fruitful discussion between project partners,
which increases the quality of this document. Ownership of data become more
important, and will receive special attention in the next part. The Data
Management Portal is still under work, but need for each project partner to
contribute to editing / access rights will need to be managed accordingly. It
must also be noted that the partners are unable to exactly specify what kind
of datasets that will be relevant as the project proceeds. This is what they
expect to learn from the pilot sites and other tests conducted at the
workbench. It is therefore expected that the datasets may change accordingly.

The VICINITY Data Management Plan still put a strong emphasis of the
appropriate collection – and publication should the data be published – of
metadata, storing all the information necessary for the optimal use and reuse
of those datasets. This metadata will be managed by each data producer, and
will be integrated in the Data Management Portal. This is considered even more
important with the upcoming deployment of the General Data Privacy Regulations
(GDRP).

This is the final version of DMP from December 2019. It presents the final
datasets and lessons learned, alongside plans for further management of test
data and production data. The document debates information of data,
integration and reuse. The document also discuss data preservation, costs and
a detailed Management Plan for each dataset.