#  Executive Summary

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

The present document is a deliverable “D9.3 – 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).

The VICINITY Consortium has identified several areas that need to be
addressed; Protocol interoperability, identification tokens, encryption keys,
data formats and packet size. Also, several issues are related to latency,
bandwidth and general architecture.

VICINITYs activities will involve human participants, as some of the pilots
will be conducted in real homes with actual

residents. For some of the activities to be carried out by the project, it may
be necessary to collect basic personal data (e.g. name, background, contact
details), even though the project will avoid collecting such data unless
necessary. Such data will be protected in accordance with the EU's Data
Protection Directive 95/46/EC  1  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 annex 2: ethics and security).

All personal data, or data directly related to the residents, will first be
collected when the project has received a signed informed consent form from
the subjects participating.

This is the second version of the project Data Management Plan (DMP). It
contains preliminary information about the data the project will generate,
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 provide an analysis of the main elements of the data
management policy that will be used by the consortium with regard to all the
datasets that will be generated by the project. The DMP is not a fixed
document, but will evolve 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-M24), a preliminary version of the
updated DMP of D9.3 was delivered prior to M24 (December 2017), in order to be
enable a better assessment of the progress of the Data Management in the
project by the reviewers._

The datasets referred to in this document are drafted during the first project
stages (completed 30th of June 2016) of the project. The document can only
reflect the intentions of the project partners toward developing the overall
project’s datasets. The second revision (D9.3) has been prepared for 31st
December 2017, and the third (D9.4) will be ready by 31st December 2019. This
follows the H2020 guidelines on Data Management Plans, and as stated in the
Grant Agreement 688467.

As the project progresses and results start to arrive, the datasets will be
elaborated on. The detailed descriptions of all the specific datasets that
have been collected will be described, made available under the relevant Data
Management framework.

#  Introduction

The purpose of the Data Management Plan (DMP) deliverable is to provide
relevant information concerning the data that will be collected and used by
the partners of the project VICINITY. The project aims to develop a solution
defined as “Interoperability as a Service” which will be a part of the
VICINITY open gateway (Figure 2). In order to achieve this, a platform for
harvesting, converting and sharing data from IoT units has to be implemented
on the service layer of the network.

**Figure 2: Domains and some of the functionalities the DMP has to cover**

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.

The datasets collected will belong to four main domains; smart energy,
mobility, smart home and eHealth (Figure 3: Example of potential data points
in use cases that generate data.). There exist several standards and
guidelines the project needs to be aware within each of these fields. There
are a number of different vendors and disciplines 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 privacy
concerns when collecting and distributing. 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. Participation in the Pilot on Open Research Data

VICINITY participates in the Pilot on Open Research Data 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 obviously need to be
balanced with the other principles described below.

##  3.2. IPR management and security

As a research and innovation action, VICINITY aims at developing an open
framework and gateway – but with support for value added services and business
models. The project consortium includes partners from private sector, public
sector and end-users (Figure 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.

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

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

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

##  3.3. Personal Data Protection

The technical implementation of VICINITY does not expose, use or analyze data,
but some activities will involve human participants. The pilots will be
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 behavior analysis –related data gathering purposes.
Some of the activities to be carried out by the project may need to gather
some basic personal data (e.g. name, background, contact details, interest,
IoT units and assigned actions), even though the project will avoid collecting
such data unless data is really necessary for the application.

Such data will be protected in accordance with the EU's Data Protection
Directive 95/46/EC  2  “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 (Figure 5).

**Figure 5: VICINITY complies with European and national legislations**

WP3 and WP4 activities dealing with the implementation and deployment of core
components will be 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 will be 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 should be
approached in the VICINITY project will be provided in other deliverables.

All personal data collection efforts of the project partners will be
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.4: Ethics and Security.

Beside this, certain guidelines will be 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 

  

A more formal description of best practice principles can be found in Table 1:
Best practice for use of production data.

##  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
neighborhood. For this reason, human participants will be involved in certain
aspects of the system development by contributing real life data. 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).

The VICINITY architecture is decentralised by design (Figure 6). Production
data will be used for testing purposes. 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.

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

The public will 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 – PRODUCTION DATA**

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 amount 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**

  

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

</td>  
<td>

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.

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

•

</td>  
<td>

**Legal Controls**

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

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

•

</td>  
<td>

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

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

**Table 1: 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.11 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
neighborhood. For this reason, human participants will be involved in certain
aspects of the project and data will be collected. This will be done in full
compliance with any European and national legislation and directives relevant
to the country where the data collections are taking 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. 

  

In addition to this, to further ensure that the fundamental human rights and
privacy needs of participants are met whilst they take part in the project, in
the Evaluation Plans a dedicated section will be delivered for providing
ethical and privacy guidelines for the execution of the Industrial Trials. In
order to protect the privacy rights of participants, a number of best practice
principles will be followed. 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 behavior 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.8
Open Call).

##  3.6. The VICINITY Data Management Portal

VICINITY will develop a data management portal as part of the project. This
portal will provide to the public, for each dataset that will become publicly
available, a description of the dataset along with a link to a download
section. The portal will be updated each time a new dataset has been collected
and is ready of 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 2.  
  
<table>  
<tr>  
<th>

**One dataset for (I/II)**

</th>  
<th>

**One dataset for (II/II)**

</th>  
<th>

**Administrative tools**

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

each IoT unit

</td>  
<td>

Datasets from pilots (see section 3.5 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)

</td>  
<td>

each smart home device

(temperature, smoke, motion, sound)

</td>  
<td>

Evaluation / feedback

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

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

##  3.7. Format of datasets

For each dataset the following will be 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>

_Has 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 3: Format of dataset description**

##  3.8. Open Call

**NB: The actual content of the Open Calls, such as documents and other
material, is at the moment of this deliverable, still being worked out by the
project participants. All descriptions and considerations related to open
calls must therefore be considered tentative, and this section can be thought
of as a tool for implementing best practise.**

The Open Call process of the VICINITY project will involve third parties.
System integrators (Figure 7) will be one of target groups for the calls.
These will be presented for opportunities to integrate IoT infrastructures
based on the VICINITY framework. Implementation/integration of Value-Added
Services will also most likely be part of issues Open Calls will tackle. The
calls should adhere to the principles which govern Commission calls. These
principles all include confidentiality: all proposals and related data,
knowledge and documents are treated in confidence.

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

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

The Project Coordinator will present a legal contract with the third parties
that are granted open calls. This contract will specify all the control
procedures and made compliant with the Grant Agreement and the Consortium
Agreement. This is 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 will
include sections that describe how the data management principles have been
implemented. It is expected the papers will follow 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 will
present how the chosen architecture and methodologies will be handled by the
stakeholders, integrators and SME’s.

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

##  3.9. Description of methods for dataset description

Example test dataset will be generated by research teams from the participants
in the project. These test datasets will be prepared in XML-files. They will
also be made available in XML and JSON format (Figure 8). The datasets will be
based on semantic analysis of data from test sensors and applied to an
ontology.

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

**Figure 8: 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).

No comparable data is available as of yet, but there are several descriptions
that will be used as basis for the test data.

All datasets are to be shared between the participants during the lifecycle of
the project. Feedback from other participants and test implementations will
decide when the dataset should be made publicly available. When the datasets
support the framework defined by the VICINITY ontology, they will 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. 

  

  

##  3.10. Standards and metadata

The data will be 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  3  (SysML) is used for the collection, analysis
and processing of requirements as well as for the specification message
exchanges and overviews of architecture and behavior specifications (Figure
9).

**Figure 9: 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 will also be 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.11. Data sharing

The project aims to prepare 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 cloud based service that assumes the data has already
been gathered and transferred to the software running on the service layer.
These data will be made available for researchers in a controlled environment,
where login credentials are used to get access to the data in XML and JSON-
format (Figure 10).

**Figure 10: 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.

The goal is to ultimately support the Europe 2020 strategy  4  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.12. Archiving and preservation (including storage and backup)

As specified by the "rules of good scientific practice" we 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.

Associated costs for dataset preparation for archiving will be 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.

#  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. AAU will scale-up by using hardware in the loop
solution and will participate actively in the implementation at the Energy
sites proposed in VICINITY. AAU will act as interface between ICT experts and
Energy sites in the project, as well as test interactions between the
developed concepts on the ICT side and the control and management of electric
power networks. Implementation and experimental results will be an important
outcome for the project.  
  
<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 sensors that feed this dataset are; energy generation and consumption on-
site from RES, instant grid cost of energy consumed and 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>

_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 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 Aalborg University Facilities. Data exploitation is foreseen to be
achieved through testing valueadded 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 will be confidential and only the authorized AAU personnel
will have access as defined. AAU could provide energy data to specific
consortium members under a detailed confidentiality framework._

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

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_The created dataset could be shared under a detailed confidentiality
framework 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>

_Due to privacy issues, the collected data are stored at a secured database
scheme at Aalborg University Facilities. Data exploitation is foreseen to be
achieved through testing valueadded services, data analytics and statistical
analysis._

_A back up will be stored in an external storage device, kept by AAU in a
secured place. This back-up will be available when it is required from the
pilot sites._

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

**Table 4: Dataset description of the AAU GRID status**

#  Datasets for smart energy from Enercoutim (ENERC)

ENERC will participate providing the facilities and the experience in
implementing solar production integrated into municipality smart city efforts.
To this end, ENERC will actively participate in the deployment, management and
evaluation of the “Smart Energy Microgrid Neighbourhood” Use Case. Its
contribution will be focused on the energy resource potential demand studies
and economic sustainability. Its expertise will allow 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 5: 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 6: 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, AAU_

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

Partner in charge of the data

analysis (if different)

</td>  
<td>

_ENERC, AAU_

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

Partner in charge of the data

storage (if different)

</td>  
<td>

_ENERC, AAU_

</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 and AAU servers, 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/AAU
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 and AAU servers, 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 7: Dataset description of the ENERC grid status**

#  Datasets for eHealth from GNOMON Informatics SA (GNOMON)

GNOMON will provide its background knowledge in the specific field of assisted
living and tele care in the context of social workers. In addition, GNOMON
will actively contribute 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 could be 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 will be 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 once a
day, requiring the patient to make use of the device placed within their
apartment. 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 will be 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 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>

_GNOMON, MPH_

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

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, 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 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 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 will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from health
devices deployed at seniors’ houses will 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 will be stored in a database scheme
at the headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 8: 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 will be 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 once a
day, requiring the patient to make use of the device placed within their
apartment. 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). Future subset may contain information about resting
metabolism, visceral fat level, skeletal muscle and body age._

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

Source (e.g. which device?)

</td>  
<td>

_The dataset will be 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 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>

_GNOMON, MPH_

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

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, 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 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 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 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

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

_The full dataset will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

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

**DS.GNOMON.03.Fall_sensor**

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

**Data Identification**

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

Dataset description

</th>  
<th>

_The fall sensor is a wearable sensor that will be 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 Center._

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

Source (e.g. which device?)

</td>  
<td>

_The dataset will be 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 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>

_GNOMON, MPH_

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

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, 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 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>

_An audit log containing alerts (incl. false alarms) is stored. The amount of
alerts is estimated to be 50 alerts (incl. false alarms) per month._

</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

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

_The full dataset will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 10: 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 will be 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 will try to
promote fitness awareness and improve citizens’ health under the concept of a
municipal-scale competition that will be based on activity related data coming
from the sensors (e.g. step counting, hours of sleep, etc)._

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

Source (e.g. which device?)

</td>  
<td>

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

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

**Partners services and responsibilities**

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

Partner owner of the device

</th>  
<th>

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

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

Partner in charge of the data

collection (if different)

</td>  
<td>

_GNOMON, MPH_

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

Partner in charge of the data

analysis (if different)

</td>  
<td>

_GNOMON, 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 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>

_Τhe 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 will 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 will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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. Dataset from VICINITY could be used and
exploited anonymized from another European project. Dataset from wearable
fitness trackers will 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 will be stored in a database scheme
at the headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 11: 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 be deployed in municipality’s sport
facilities, e.g. gym, pool, etc. and also tested at CERTH/ITI’s Smart Home.
The municipality will try to promote fitness awareness and improve citizens’
health under the concept of a municipal-scale competition that will be 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 will be 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 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>

_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 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>

_Τhe 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 will 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

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

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

_The full dataset of beacons deployed in houses of elderly people are
sensitive, therefore, will be confidential and only the authorized MPH
personnel and related end-users will have access as defined. The latter
authorized groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 12: 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 will
be provided by Gorenje partner and will be 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 will also
be 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), trigger alerts 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 will be 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 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>

_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 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>

_Τhe 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 trigger relevant
alerts._

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

Data access policy

Dissemination level (Confidential,

only for members of

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

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

_The full dataset from Gorenje devices deployed in elderly’s people houses
will be confidential and only the authorized MPH personnel and related end-
users will have access as defined through Gorenje Cloud. The latter authorized
groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

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

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

CERTH / ITI will contribute 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 will also provide 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.Occupancy_Sensor**

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

**Data Identification**

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

Dataset description

</td>  
<td>

_Occupancy sensors will be 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 occupancy status for the area of its responsibility. Data
coming from this sensor will be used to create behaviour profiles based on
relevant criteria (e.g. occupancy level for a specific room, etc) and trigger
alerts in case of deviation from the normal standards._

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

Source (e.g. which device?)

</td>  
<td>

_The dataset will be collected via a combination of connected occupancy
sensors (e.g. Wi-Fi, ZigBee etc.) and a Connectivity Gateway based on
Raspberry pi or other vendor._

</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>

_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 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>

_Τhe collection of data from occupancy sensors is time-driven and dispatched
every 15min (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 trigger relevant
alerts which will be sent to the call centre._

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

Data access policy

Dissemination level (Confidential,

only for members of

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

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

_The full dataset of sensors deployed in houses of elderly people are
sensitive therefore will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 14: Dataset description of the CERTH Occupancy Sensor**  
  
<table>  
<tr>  
<th>

**DS.CERTH.02.Motion_Sensor**

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

**Data Identification**

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

Dataset description

</th>  
<th>

_Motion sensors will be 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 will be used to create behaviour profiles based on relevant
criteria (e.g. motions level for a specific room and time period, etc.) and
trigger alerts in case of deviation from the normal standards._

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

Source (e.g. which device?)

</td>  
<td>

_The dataset will be collected via a combination of connected motion sensors
(e.g. Wi-Fi, ZigBee etc.) and a Connectivity Gateway based on Raspberry pi or
other vendor._

</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>

_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 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>

_Τhe collection of data from motion sensors is time-driven and dispatched
every 15min (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 trigger relevant
alerts._

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

Data access policy

Dissemination level (Confidential,

only for members of

Consortium and the Commission

Services) / Public

</td>  
<td>

/

the

</td>  
<td>

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

_The full dataset of sensors deployed in houses of elderly people are
sensitive therefore will be confidential and only the authorized MPH personnel
and related end-users will have access as defined. The latter authorized
groups of users will 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 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

distribution (How?)

</td>  
<td>

and

</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 will 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>

</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 headquarters of MPH, allowing only authorised access to external end-
users. A back up will be stored in an external storage device, kept by MPH in
a secured place. Data will be kept indefinitely allowing statistical
analysis._

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

**Table 15: Dataset description of the CERTH Motion Sensor**

#  Datasets for intelligent mobility from Hafenstrom AS (HITS)

HITS will provide the user requirements specifications and demonstration of
transport domain use case, while it will actively participate in the
dissemination and exploitation activities of the project. By employing knowhow
within standardization bodies, mobility and smart city governance, HITS will
allow municipalities and smart cities to better utilize internal resources and
improve on services offered to citizens and agencies alike.

Furthermore, HITS will be 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 will be 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 16: 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 17: Dataset description of the HITS Smart lighting**  
  
<table>  
<tr>  
<th>

**DS.HITS.03.LaptopTeststation**

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

**Data Identification**

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

Dataset description

</th>  
<th>

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

</th> </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 18: 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 19: 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 minute. 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 20: Dataset description of the Gorenje smart appliances sensor**

#  Datasets for buildings from Tiny Mesh AS (TINYM)

The primary role of Tiny Mesh Company is as a developer and technology
provider, with the company´s IoT solution as the main enabling technology. The
goal is to offer promising technology solutions through participation in use
cases. We focus on creating new products, services and business model as part
of the Internet-of-Everything (IoE). New potential arise when IoE is used for
connecting, integrating and controlling all kinds of meters, street lights,
sensors, actuators, assets, devices, tags and other devices.

TINYM will contribute in the practical implementation through their work with
definitions of use case. TINYM will take practical ownership of the various
demo sites through the role as of leader of WP7.  
  
<table>  
<tr>  
<th>

**DS. TinyMesh.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 Tiny-Mesh Workbench._

</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 21: Dataset description of the Tiny-Mesh Door Sensor**  
  
<table>  
<tr>  
<th>

**DS. TinyMesh.02.Energy_Water_Consumption_Sensor**

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

**Data Identification**

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

Dataset description

</td>  
<td>

_The sensors will be installed to measure consumption of water and
electronics.._

_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 Tiny-Mesh Workbench._

</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 KW/h or l/h on a configurable interval
of (default: 1 minute)._

</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 resource
usage to control peak electricity or alarm of abnormal use._

</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 be stored in the metering devices as well as the TinyMesh provided
Value Added Service._

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

**Table 22: Dataset description of the Tiny-Mesh consumption sensor for energy
and water.**  
  
<table>  
<tr>  
<th>

**DS. TinyMesh.03 Tinymesh_Gateway**

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

**Data Identification**

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

Dataset description

</td>  
<td>

_Data packed from any Tinymesh network_

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

Source (e.g. which device?)

</td>  
<td>

_The Tiny-Mesh Gateway relays information from different TinyMesh devices to
upstream service._

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

**Partners services and responsibilities**

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

Partner owner of the device

</td>  
<td>

_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>

_Tiny-Mesh Gateway is a serial communication device that can transfer data in
two modus; transparent and packed._

</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>

_Tiny-Mesh Gateway is serial communication device._

</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._

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

Data sharing, re-use and

distribution (How?)

</td>  
<td>

_Data and metadata will be accessible by an API in Tinymesh Cloud._

</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 and metadata will be accessible by an API in Tinymesh Cloud._

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

**Table 23: Dataset description of the Tiny-Mesh gateway**

#  Conclusions

This document is the second 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 neighborhood functions
in practical terms. More updates is 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 this report 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).

The final version of DMP is due in December 2019. It is expected to present
the final datasets and lessons learned, alongside plans for further management
of test data and production data. It will provide information on the existence
(or not) of similar data and the possibilities for integration and reuse. In
addition, issues like the period of data preservation, the approximated end
volume, the associated costs and how these are planned to be covered will be
tackled in order to make the Portal and other necessary management tools
operational and to provide a detailed Management Plan for each dataset.