#  Executive summary

This document is a deliverable of the AMANDA project, funded by the European
Commission’s Directorate-General for Research and Innovation (DG RTD), under
its Horizon 2020 Research and innovation programme (H2020). This report
provides general description related to data management, ethics and
standardisation which will be applied in the project and focuses on data
collected up to M6 of the project. The document consists of four Sections.
Section 1 provides information about the project scope, the goals of this
report and the LEPPI manager nomination. Section 2, Data management plan,
describes the needs, reasons and methods of data management, together with
examples. Section 3 details ethical aspects of the project. Section 4 provides
condensed information about data collected during the period M1 – M6 and can
be used to track data collected for the project’s duration. The information
provided in Section 2 can be used as explanation of condense description of
data provided in the Tables of Section 4.

#  Introduction

##  Overall technical objectives

AMANDA is an ambitious project aiming to develop a unique ASSC which will have
the size, feel and look of a credit card. It can be ideal for easy deployments
in buildings (smart living environments) or as wearables (bikes, valuable
assets and people). This project will cover the triangle of experimentation,
development and standardization to optimize the materials behaviour,
connectivity, miniaturization, power consumption, security, intelligence,
design and cost. AMANDA’s partners have the expertise and combination of
world-class manufacturing infrastructures and know-how. The partners are using
micro- and nano- technology, new composites, innovative architectures and
advanced software. AMANDA’s vision is to overcome the existing technological
challenges and achieve the development of a user-friendly wearable platform
not only for indoor and outdoor environmental sensing, but also for asset- or
even people- tracking. A combination of developed and existing off-the-shelf
technologies will be selected and integrated into the ASSC. Innovative PVs
(Lightricity PV), PMIC (e-peas) and batteries (Ilika solid-state battery), all
packed in under 3mm thickness. It will introduce technical breakthroughs that
will boost further miniaturization, offer increased sensitivity, small
footprint and ultra-low power consumption (maintenance free lifetime more than
10 years).

The project execution will require tight cooperation between the partners.
That will lead to the generation of a significant amount of information, such
as datasheets, specifications, measurement and reporting data as well as other
types of data. The data management task is in place to make sure that all
information is categorised and stored in a safe way and can be accessed at any
time by authorised personnel.

##  Purpose, context and scope of this deliverable

This document relates to data management and ethic plans within the AMANDA
project. As the project progresses, it will be updated if needed. Updates to
this document are foreseen at milestones M18 (v2), M30 (v3) and M36 (v4) and
will focus on the management of scientific data collected for the whole
duration of the project and making them findable, accessible, interoperable
and reusable (FAIR). The document describes the process applied by the
consortium to ensure good data management and high ethical standards. It
enables clear tracking of data collected, not only during the project
execution but also after its conclusion. External parties can have access to
public data. Therefore, this document points to the assigned project member
who can provide the dataset. The following aspects are dealt with:

  * Collected data 

  

  * Information contained in the data 

  

  * The data format 

  

  * The contact point for the data request 

  

Authorized personnel is able to track the information and access it in case
the information is needed.

The DMP is a living document, which will evolve during the lifespan of the
project. Particularly whenever significant changes arise, such as dataset
updates or changes in consortium policies. This document is the first version
of the DMP, delivered in M6 of the project. It includes descriptions of
datasets collected until M6 by the project and the specific conditions
attached to them. It also provides a framework for future data documentation.
Although this report already covers a broad range of aspects related to the
AMANDA data management, the upcoming versions will get into more detail on
particular issues such as data interoperability and practical data management
procedures implemented by the AMANDA project consortium.

##  Nomination of the LEPPI manager

There is a need to appoint a LEPPI manager. The LEPPI manager will be
responsible for the coordination of all activities related to legal, ethical,
privacy and policy issues that may arise during the development and validation
phases of the project.

In case of issues related to law, ethics and privacy, the LEPPI manager will
cooperate and advise the following decisions making bodies: Plenary Board,
Quality Control Board and Ethics Helpdesk.

Table 1 shows the assigned LEPPI manager, chosen by the project partners.  
  
<table>  
<tr>  
<th>

**Partner short name - company**

</th>  
<th>

**Name**

</th>  
<th>

**Email**

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

IMEC

</td>  
<td>

Rik van de Wiel

</td>  
<td>

Rik.vandeWiel@imec.nl

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

Table 1 LEPPI nomination

Rik van de Wiel is a senior employee at IMEC. He has been working as R&D
Manager in the field of Connected Health Solutions for eight years. Rik van de
Wiel contributed to many data collection trials, including a number of trials
in which medical devices were evaluated.

#  Data management plan

During the project and as part of WP8, administrational documentation will be
created in regards to project coordination. Shared documents within the
consortium are processed and managed by the project coordinator. Other data
generated in the project (e.g. questionnaire information, specification of the
components or measurement data and others) are managed and stored by the
partner responsible for the generation of the data. The data should be stored
and be available on request by an authorized associate. An authorized
associate can be for example another consortium partner or third party who
received authorisation for data access from Project Management Board.

The project data management should fulfil directive 2013/37/EU of reusability
of the generated data.

##  Need of DMP

The project involves carrying out data collection (in the context of the
piloting and validation phase) and a set of validation tests to assess the
technology and effectiveness of the proposed framework in real life
conditions. For this reason, human participants might be involved in certain
aspects of the project and data will be collected concerning their biometrics
and their travelling info. Since the project might collect personal-related
data, the consortium must comply with any European and national legislation
and directives relevant to the country where the data collections are taking
place. That’s why it has been decided to create a Data Management Plan (DMP)
for the AMANDA project.

Data Management Plans are a key element of good data management. A DMP
describes the data management life cycle for the data to be collected,
processed and/or generated by a Horizon 2020 project. A DMP should include
information on:

  * The data that will be collected, processed and/or generated 

  

  * The methodology and standards that will be applied 

  

  * Whether data will be shared/made open access 

  

  * The way data will be curated and preserved (including after the end of the project) 

  

##  Procedures of data collection

###  Data collection process

The data collection consists of two parts: the data collection description and
the data collection detail.

The data collection description characterizes, in plain text and for each data
collection, the types of research data that will be collected during the
study. It also describes how information will be collected and why it is
needed. This gives a general overview that can be used to fine tune the data
management if needed. The following research data types are possible (but not
limited to):

  * Observational data: captured in real time, typically cannot be reproduced exactly. Examples: sensor readings, sensory (human) observations, survey results, images 

  

  * Experimental data: from labs and equipment, can often be reproduced but may be expensive to do so 

  

  * Simulation data: from models, can typically be reproduced if the input data is known. Examples: climate models, economic models, biogeochemical models 

  

  * Derived or compiled data: after theoretical search, data mining or statistical analysis has been done, can be reproduced if analysis is documented. Examples: text and data mining, derived variables/parameters, compiled database, datasheets, 3D models, project reports 

  

The data collector can complete the matrix containing the detailed information
of the data collection in the study based upon the following check list.

  * Data collection explains how the data will be collected such as sensors, interviews and others 

  

  * Data type that will be collected could include text, numbers, images, 3D models, software, audio files, video files, reports, surveys and other types of data. 

  

  * Data format is the format in which the data will be stored 

  

  * Estimated size of the data contains a rough estimation of the size 

  

  * Which tools or software are needed to create/process/visualize the data? 

  

  * Responsible indicates which partner is responsible for the data collection 

  

  * Does the data have a specific character in terms of reproducibility, confidentiality and others? What does this mean for the management of the data? 

  

###  Data collection description

This Section describes the context and type of collected data. The description
can be done based upon the data types: observational, experimental, simulation
or derived. Furthermore, the data should be commented in wording how, what and
why it is collected.

The data collection detail shows what data will be collected in the study.
Table 2 describes who collected the data, how the data was generated, the data
format and the file size. Additionally, the table contains a column with the
information about the specific character of the data.  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible**

**Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Data collection**

</th>  
<th>

**Data format**

</th>  
<th>

**Est. size**

</th>  
<th>

**Software**

</th>  
<th>

**Specific character**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project reports

</td>  
<td>

Gathering infor-

mation from different stakeholders in the project through interview, meetings,
mails,

...

</td>  
<td>

DOC, XLS

</td>  
<td>

10mb

</td>  
<td>

MS Of-

fice

</td>  
<td>

Only personal information of project related persons included and no sensitive
data

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

Online survey

</td>  
<td>

XLS

</td>  
<td>

10mb

</td>  
<td>

MS Of-

fice

</td>  
<td>

No sensitive data included

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor reading

</td>  
<td>

CO  2  sensor

</td>  
<td>

CSV

</td>  
<td>

0,4Mb

</td>  
<td>

MS Office,

Matlab

</td>  
<td>

No personal information included

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

Table 2 Data acquisition details

##  Data storage and back-up

It is the responsibility of the project partner who collects the data to
ensure that the data is regularly backed-up and stored securely for the
lifetime of the project. The following matrix is filled in order to keep an
overview of the data collected in the whole project.

Storage indicates the medium and location of the backups. We distinguish the
following types:

  * Network drives - These are secure and backed-up regularly. They are ideal for master copies of data. However, due to its online nature they might be target of hacker attacks. 

  

  * Local drives – Data on PCs and laptops can be lost because of technical malfunction or the loss of the device itself. These are convenient for short-term storage and data processing but should only be relied upon for storing master copies when backed-up regularly. 

  

  * Remote or cloud storage - Commonly used services, such as Dropbox and Google Drive, will not be appropriate for sensitive data. Agreements with providers should be studied before using them to store sensitive data. 

  

  * External portable storage devices (external hard drives, USB drives, DVDs and CDs) - These are very convenient, being cheap and portable, but not recommended for longterm storage as their longevity is uncertain and they can be easily damaged. Backup indicates the location and frequency of the backups. The data in this study will be stored and backed up as described in Table 3. 

  

  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Storage medium and location**

</th>  
<th>

**Backup location and backup frequency**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project reports

</td>  
<td>

Remote and cloud storage using Office365

</td>  
<td>

Automated backup using Microsoft

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

Local drive

</td>  
<td>

No backups made

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor reading

</td>  
<td>

Internal IMEC SharePoint

</td>  
<td>

Automatic MS office service backup

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

Table 3 Data storage and data backup information

##  Data documentation

The data processed in the study is documented and labelled for immediate usage
and future reference. The labelling consists of two parts:

  * File naming. Files will have naming conventions for each data type. There are many conventions for file naming. It is suggested to follow the well documented, practical guidance from Purdue University [1]. Naming convention is very helpful in case of manual and automatic search. 

  

  * Metadata. Files can have metadata that describe the data stored in the file. Metadata have a description what the data contains and what each value represents. The reason to use metadata is, that it can be found easily when looking for information. Wherever possible, existing community standards should be identified and reused. An example of commonly used generic metadata can be found at Dublin Core Metadata Initiative [2]. The data processed in the study will be documented according to the standards with the data type as described in Table 4\. 

  

  
<table>  
<tr>  
<th>

**Ref. Nr.**

</th>  
<th>

**Responsible partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Naming convention**

</th>  
<th>

**Metadata**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project reports

</td>  
<td>

For facilitating common browsing and storage in different platforms and
Operating System’s, no spaces should be used in the document names and instead
the dash character “-” should be used. All project document names must start
with the prefix “AMANDA-” to facilitate quick identification and indexing.
Names of deliverable documents should follow the convention:

“AMANDA-Dw.n-Title-vX.Y.ext” where: “Dw.n” is the deliverable number: “w” is
the WP number; “n” is the numbering within the specific WP; “Title” is the
title of the deliverable;

“vX.Y” is the version number: “X” is the version; “Y” is the sub-version;
“ext” is the file extension pertaining to the format used.

</td>  
<td>

n/a

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

Database name: AMANDA_Surveys_2019

</td>  
<td>

n/a

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor reading

</td>  
<td>

Sensor designation+”_”+Place of measurement+ “_”+participant+”_” date of

trial e.g.IMEC_CO2_eindho-

ven_Tom_20190522

</td>  
<td>

Description:

Data from CO  2  sensor based upon events like entering, leaving the room

Subject: Sensor information Created:

14.06.2019

Creator: Jon

Smith

Classification:

Confidential

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

Table 4 Data documentation

##  Data access

This Section describes how authorized access to the data is managed during the
project for each dataset. During the project, it is required to keep data safe
and secure. The process of data collection will already determine who has
access to data. Data security is needed to prevent unauthorised access.
Otherwise the data might be intentionally or unintentionally disclose, changes
or delete. The storing partners are responsible for ensuring data security.
The level of security required depends upon the nature of the data – personal
or sensitive data need higher levels of security.

Table 5 shows an example of the data access presentation. The access
controller is responsible for the access management of the data. Access
management is the description on how the access to the data will be managed.

Data can be labelled as:

  * Public information 

  

  * Restricted information 

  

  * Confidential information 

  

  * Strictly confidential 

  

Access is limited to the appointed persons, functions and groups. It can be
extended on demand.

The access to the data of the study will be managed by the assigned access
controller for each data type. It will be done according to the access
management description linked with the data type.  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Access controller**

</th>  
<th>

**Access management**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project reports

</td>  
<td>

C. Kouzinopou-

los

</td>  
<td>

Access will be granted to people working on the project after approval by the
responsible from the company they represent and approval from the overall lead
of the project.

Data will not be made public at any time unless all parties agree to it or the
necessary agreements are in place.

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

C. Kouzinopou-

los

</td>  
<td>

Access is limited to the controller

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor reading

</td>  
<td>

P. Bembnowicz

</td>  
<td>

Access is limited to the controller

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

Table 5 Data access information

##  Data sharing and reuse

This Section describes if and how the data processed in the study can be
shared including:

  * What agreements are in place to share the data between consortium partners or third party 

  

  * What purpose of reuse can be envisioned for the data type in a later phase 

  

  * Will the data be shared with limited stakeholders or made publicly available 

  

  * How will the sharing and re-use be managed 

  

  * What safeguards are implemented for data sharing and re-use (such as anonymisation or scrambling of certain information) 

  

The data processed in the study can be shared or reused as described in Table
6.  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Sharing of data**

</th>  
<th>

**Reuse of data**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project reports

</td>  
<td>

Only shared with stakeholders of the project

</td>  
<td>

For future EU project proposals

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

Only shared with stakeholders of the project

</td>  
<td>

Reuse for all work packages development

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor reading

</td>  
<td>

No data sharing

</td>  
<td>

No reuse

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

Table 6 Data sharing and reusing

##  Data retention and archiving

This Section describes how long the data will be stored for this study, what
data can be archived and what safeguards are setup for the data archiving.
Examples of safeguards are limited access, anonymisation, scrambling and
deleting parts of data.

The data processed in this study should have the defined retention period for
each data type. The default retention period is set to the end of the AMANDA
project activities. However, the retention time should be adjusted to
significance of collected data. Table 7 shows suggested retention time with
regards different type of data Nevertheless, the experiment designer should
have decisive voice about retention period. Moreover, the files can be
archived or deleted directly after processing.  
  
<table>  
<tr>  
<th>

**Nr.**

</th>  
<th>

**Data type**

</th>  
<th>

**Suggested retention period**

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

1

</td>  
<td>

Voice recording

</td>  
<td>

Delete subsequent to project end

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

2

</td>  
<td>

Pure technical information

</td>  
<td>

5 years or more

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

3

</td>  
<td>

Non-anonymised raw measurements

</td>  
<td>

Delete subsequent to project end

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

4

</td>  
<td>

Anonymised raw measurements

</td>  
<td>

5 years or more

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

5

</td>  
<td>

Project reports

</td>  
<td>

5 years or more

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

Table 7 Suggested retention time with respect to type of data

Table 8 shows the model description of the archiving process.  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Retention**

</th>  
<th>

**Archiving**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Project re-

ports

</td>  
<td>

5 years

</td>  
<td>

No archiving after the foreseen 5-year period

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

2

</td>  
<td>

CERTH

</td>  
<td>

Survey

</td>  
<td>

During the project execution

</td>  
<td>

No archiving

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

3

</td>  
<td>

IMEC

</td>  
<td>

CO  2  Sensor

reading

</td>  
<td>

During the project execution

</td>  
<td>

No archiving

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

Table 8 Data retention and archiving

##  Best practice advice for data collection process

During trials, where sensitive data is collected, the data collector can
consider additional restriction in the internal communication. Sensitive
massages can be encrypted. Only authorised limited personnel should receive
the encryption keys. Thus, non-authorised persons do not get access to data.

Data gathered can be anonymised and only limited personnel should be able to
track back experiments results to the personal identification of volunteer.

People in the premises or involved in the trials shall be instructed
accordingly prior to the experiment execution.

#  Ethical concerns of the AMANDA project

The AMANDA consortium confirms that each partner will check with their
national legislation/practice and their local ethics committee. That will
provide guidelines on data protection and privacy issues, in terms of both
data protection and research procedures in relation to any of the proposed
public engagement and potential volunteer research activities. Any procedures
for electronic data protection and privacy will conform to Directive (EU)
2016/680 and Regulation (EU) 2016/679 on the protection of personal data and
its enactments in the national legislations.

The process of adhering to the applicable regulations begins with a thorough
investigation of the EU and National research projects’ ethical guidelines as
well as the examination of the directives regarding privacy and protection of
personal data and free movement of data issues. The legislation with which the
AMANDA consortium must conform includes:

  * The Universal Declaration of Human Rights 

  

  * The Convention 108 for the Protection of Individuals with regard to Automatic Processing of Personal Data 

  

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

  

  * The Declaration of Helsinki on research involving human subjects 

  

  * Greek Law 2472/1997: Protection of Individuals regarding to the Processing of Personal Data 

  

  * Greek Law 3471/2006: Protection of personal data and privacy in the electronic telecommunications sector and amendment of law 2472/1997 

  

  * The Constitution of the Kingdom of the Netherlands, Article 10 Privacy. 

  

The AMANDA project expects the development of a set of qualitative information
collecting activities. In particular, interviews and questionnaires (Task 1.3)
are planned. The double nature of consent appears again as both personal data
and potentially sensitive information might be collected. Therefore, two
issues become crucial from an ethical perspective: the confidentiality of the
information and the anonymisation of personal data. The Code of Ethics of the
International Sociological Association reminds researchers that "The security,
anonymity and privacy of research subjects and informants should be respected
rigorously” [3]. The sources of personal information obtained by researchers
should be kept confidential, unless the informants have asked or agreed to be
cited. Should informants be easily identifiable, researchers should remind
them explicitly of the consequences that may follow from the publication of
the research data and outcomes." [3]. From this article it is possible to
extract some general rules that investigators must apply when designing and
conducting their research:

  * Information gathered from the participants should be kept confidential, unless specific consent to be cited is given by the participant. 

  

  * Information gathered should be anonymised and used only for the purpose for which it was collected. 

  

  * Participants must be informed when the investigator believes that some of the information shared may make them identifiable and the potential consequences. 

  

  * Participants must be given, in a clear and transparent manner, the opportunity to withdraw at any time and especially after being informed of their potential identification and potential the consequences. 

  

In case the collected data contains personal information, data protection
principles and legal requirements extracted from Regulation 2016/679 should be
taken into consideration. In particular the investigator needs to put in
practice organizational and technical measures directed to "minimising the
processing of personal data, pseudonymising personal data as soon as possible,
transparency with regard to the functions and processing of personal data,
enabling the data subject to monitor the data processing" [4].

In case the collected data contains personal information, the responsible
partner of the AMANDA project should apply the following rules:

  * Information collected from the participants should be anonymised. Responsible partners of the Consortium will prepare a summary, of the conducted research’s results. The raw information will be kept in local resources by the partners under their own responsibility and according to the data protection policies of their own organisations. Partners should pay special attention to the respect of the minimisation principle following article 89 (1) of Regulation 2016/679. 

  

  * Each task leader will collect the summaries and send them to the Ethics Helpdesk. The Ethics Helpdesk will review that no personal or sensitive information is contained in the summary, unless the participant has given specific consent. If needed, the Ethics Helpdesk can consult LEPPI during the process. The summary can be shared within the Consortium once this point is verified. 

  

  * The investigator must obtain specific consent from all the participants prior to their involvement in the different activities. The example of the consent template is provided in the Annex 1. The responsible partner should adjust provided template towards experiment. 

  

  * The task leader of each of the activities will propose to the Ethics Helpdesk a text containing the specific information concerning the activity. The Ethics Helpdesk will validate the specific Informed Consent Form before it is used with any participants. Informed consent must be obtained, in written form. 

  

  * Oral informed consent is highly discouraged. Although oral consent is legally valid, the data controller must be able to "demonstrate that the data subject has consented to processing of his or her personal data" (Regulation 2016/679, article 7.1). Therefore, investigators should only use this procedure when there is no other possibility and after having consulted with the Ethics Helpdesk. The Ethical Body will evaluate the situation, bearing in mind the potential value of the information that could be obtained from the participant. 

  

Duly signed Informed Consent forms, both written and electronic or proof of
the oral consent, should be kept by the controller for a 5 years period to be
available for auditing by the Ethics Helpdesk or any competent authority.

The AMANDA project goal is to develop pervasive technology as described in the
Section Overall technical objectives. Miniaturizing the electronic system is
going to be safe and non-intrusive. The project goals are technical. Most of
the collected datasets are going to describe electronic system behaviour e.g.
power consumption, voltage stability, radio connectivity performance and
others. The measurements, which are not related to the technical evaluation of
the system, are foreseen to be related to environmental conditions. An
investigated subject is exposed to the measured conditions. There is no
intention to directly gather measurement from bodies of living creatures.
Thus, there is no interaction between the electronic system and the body of
the subject. The project does not have the aim to perform human trials.
However, experiments where the device is placed in the room where people are
present is considered. The project is not in the scope of Utilisation of
Genetic Resources the Access and Benefit Sharing (ABS)

This check will be done prior to the data collection in the AMANDA study and
the findings will be added to this report in Section 4.

#  Documentation of data collected in the AMANDA project during the M1 – M6
period

##  Context of the data collection

###  Voice of the customer data collection

IoT devices are nonstandard computing devices that connect wirelessly to a
network and have the ability to transmit data. The IoT sector involves
extending internet connectivity beyond standard devices, such as desktops,
laptops and others, to any range of traditionally non-smart or non-internet-
enabled physical devices and everyday objects. With applications in
residential as well as industrial environments and the nonstandard nature of
this technology, the need to acquire more data from the end-user point of view
is increased. The AMANDA consortium is interested to investigate the variety
of use case scenarios. The use cases where the ASSC can be implemented and
used in. Thus, Voice of the Customer data acquisition plan is created.

In particular, a questionnaire was created by CERTH and PENTA as part of Task
1.2 System Requirements and Needs in order to complete Deliverable D1.3 Voice-
of-the Customer, as part of the Industrial IoT application Section. The
objective was to gather the end-user requirements from available industrial
stakeholders, such as end users, product providers, suppliers and developers
that have previously collaborated with anyone involved in the consortium. The
industries were targeted by their interest in new ways to improve their
business with the integration of new technologies.

The chosen platform to host the online questionnaires was Google Forms, due to
previous experience of CERTH in data acquisition via questionnaires from
relevant projects as well as the simplicity of the end reports. Anonymity of
the answers was a critical priority. Therefore, no questions that could make
the responsible employee identified were used. In fact, except from the
company name and a single company contact email address, all questions in the
form were strictly related to the IIoT subject and different use case
scenarios.

The first Section of the questionnaire was focused on the currently used
solutions by industrial partners. With these questions, important insight was
gathered on the type of sensor data that is already being measured in
industrial environments as well as the type of power supply and autonomy of
the utilized monitoring systems. Lastly, recommendation on improvements on the
state-of-the-art components were collected.

The next Section of the questionnaire was mainly informative as the AMANDA
ASSC is presented, with brief description of all available sensors and a link
to the project’s official website. The most critical part of the online
questionnaire was the third Section on AMANDA use cases. Here, each company
was asked to construct an ideal sensor monitoring system, with a selection of
the most appropriate and useful sensor types as well as additional hardware
options. A brief application description was asked along with questions
concerning the desired power management solution, wireless communication and
data transfer specifications as well as potential size constrains.

Although there was not any personal information or confidential data questions
included in the online questionnaire, AMANDA partners decided to request a
written consent from all companies that participated, to share their answers
in Deliverable D1.3. Due to time delays on the reply of the consent, no raw
data and company details were included in the Deliverable. The AMANDA
consortium collected and merged the answers into a final list to make good use
of the acquired data. The list contained State-of-the-Art monitoring systems
along with proposed use cases scenarios. In this way, anonymity was kept
through the whole process and in the same time, useful results and information
were shaped to be used for the Deliverable.  
  
<table>  
<tr>  
<th>

**Use cases**

</th>  
<th>

**ASSC functionality**

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

Cargo transportation conditions

</td>  
<td>

Collect information about temperature, CO  2  /smoke levels, noise levels and
distance from a set point to ensure proper conditions and safety for the cargo
and its means of transportation.

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

Indoor asset

tracking

</td>  
<td>

Keep track of a company’s high value assets and their condition

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

Worker comfort level monitoring

</td>  
<td>

Ensure comfort levels for the employees to increase their efficiency and
motivation

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

Workplace information delivery

</td>  
<td>

Keep an overview of the working conditions to ensure the health and safety of
the employees

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

Table 9 Use cases merged from the distributed questionnaires

###  Voice of the customer data collection

The primary purpose of data collection is to obtain the information needed to
create an ASSC architecture. Information is collected from end users. To
ensure a certain quality of information, it was necessary to explain the
purpose and objectives of the project. The aim of the implemented activities
was to collect as much information as possible about the needs and wishes of
end users.

Besides the survey interviews were used as well. The interview was conducted
as part of WP1. Results and analyses were published in the completed
Deliverable D1.3 Voice of the Customer Completed.

Surveys and interviews do not contain ethical questions and no ethical
questions arise. All surveys and interviews are fully aligned with the EU
Regulation 2016/679 [5] containing General Data Protection Regulation (GDPR).

###  Specification of the required components data collection

Components data was collected as part of WP1 “System Specifications,
Requirements and Use Cases”. This includes data from components being
developed as part of the AMANDA project (e.g. temperature, touch, CO  2  ,
imaging sensor, solid-state battery, energy harvester, MCU, PMIC) but also
data from state of the art, off-the shelves electronic components (RF chipsets
and modules, additional sensors: accelerometer, Volatile Organic Compounds,
Humidity, Light and others) and peripherals (timers, displays, memory and
others). Each technological partner within the consortium has contributed to
the required data based on its current expertise and on technology scouting
(literature survey of patents, datasheets). The collected data was compiled
into a spreadsheet document that comprised various tables of relevant
technical specification parameters (electrical and mechanical), graphs (power
consumption profiles) and electronic block diagrams (PMIC). The purpose of the
document is to share the same level of information between all partners,
regardless of the individual level of expertise, in order to mutually
understand the current status of each respective technology and put these into
perspective with the intermediate and final project specification targets. As
such, it can be considered as an internal technical project roadmap. Finally,
it is also a comprehensive comparison tool for assessing the various sensors,
RF and loads that will be integrated into the ASSC. This reference document
contains sensible and confidential information that is therefore only
accessible by the AMANDA project partners. Any relevant non confidential
information can then be included into the public deliverable documents (for
example D1.2 or D1.3). The spreadsheet document will be updated throughout the
project and the latest version is regularly circulated to all partners by
email and stored on a local Git repository.

##  Data collection  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data Type**

</th>  
<th>

**Data collection**

</th>  
<th>

**Data Format**

</th>  
<th>

**Est. size**

</th>  
<th>

**Software**

</th>  
<th>

**Specific character**

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

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

1

</td>  
<td>

CERTH

</td>  
<td>

Industrial IoT use case suggestions and SoA solutions

</td>  
<td>

Company name and contact email, currently utilized monitoring systems,
suggestions on type of sensors, power management and wireless communication
specifications, size constrains, impact of the potential use of the

AMANDA ASSC

</td>  
<td>

Online questionnaire in a commercial platform. Multiple choice questions as
well as text

</td>  
<td>

21 questions in total

</td>  
<td>

Google Forms platform

</td>  
<td>

n/a

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

2

</td>  
<td>

PENTA

</td>  
<td>

Survey, interview

</td>  
<td>

Gathering information through interview, email, project presentation,
technical talk….

</td>  
<td>

DOC, XLS

</td>  
<td>

0,5M

b

</td>  
<td>

MS-Office

</td>  
<td>

Only personal information related to the occupation

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

3

</td>  
<td>

Lightricity

</td>  
<td>

Technical specification tables, graphs, block diagrams

</td>  
<td>

Technical specification of all components on the AMANDA card: electrical and
mechanical specifications, including power consumption and footprint

</td>  
<td>

PPT

</td>  
<td>

3-4

Mb

</td>  
<td>

MS-Office

</td>  
<td>

2 types of information:

  * Specific to the innovative technologies developed as part of AMANDA (Sensors, PV, Battery, PMIC, MCU) 

  

  * More general information, e.g. related to state-of-the-art and off-the-shelf components (RF, displays, additional sensors, peripherals and others) 

  

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

##  Data storage and back-up  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Storage medium and location**

</th>  
<th>

**Backup location and backup frequency**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Industrial IoT use case questionnaire answers

</td>  
<td>

Original online spreadsheet document, created automatically by the Google
Forms platform to gather all answers. Document was destroyed after the merge
of the answers

</td>  
<td>

No backup of data

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

2

</td>  
<td>

PENTA

</td>  
<td>

Survey, interview

</td>  
<td>

Local drive, network drive

</td>  
<td>

Daily backup, RAID array disk, external hard drives

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

3

</td>  
<td>

Lightricity

</td>  
<td>

Technical specification tables, graphs, block diagrams

</td>  
<td>

Local drive, Git repository

</td>  
<td>

Daily backup (local)

Cloud storage (OneDrive)

External hard drives

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

##  documentation  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Naming convention**

</th>  
<th>

**Metadata**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Industry IoT use case questionnaire answers

</td>  
<td>

No naming convention needed

</td>  
<td>

No metadata

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

2

</td>  
<td>

PENTA

</td>  
<td>

Survey, interviews

</td>  
<td>

Database name: AMANDA project; folder name: Surveys; folder name: Interviews

</td>  
<td>

n/a

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

3

</td>  
<td>

Lightricity

</td>  
<td>

Technical specification tables, graphs, block diagrams

</td>  
<td>

No naming convention required

</td>  
<td>

n/a

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

##  access  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Access controller**

</th>  
<th>

**Access management**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Industrial IoT use case questionnaire answers

</td>  
<td>

Data removed after parsing. No access control required

</td>  
<td>

Data removed after parsing. No access control required

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

2

</td>  
<td>

PENTA

</td>  
<td>

Survey, interviews

</td>  
<td>

O. Vujičić

</td>  
<td>

Access is limited to the controller

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

3

</td>  
<td>

Lightricity

</td>  
<td>

Technical specification of all components on the AMANDA card: electrical and
mechanical specifications, including power consumption and footprint

</td>  
<td>

M. Bellanger (local access)

C. Kouzinopoulos (Git)

</td>  
<td>

Access to the Git repository is limited to project partners (registration
process and password required)

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

##  sharing and reuse  
  
<table>  
<tr>  
<th>

**Ref. nr.**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Data type**

</th>  
<th>

**Sharing of data**

</th>  
<th>

**Reuse of data**

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

1

</td>  
<td>

CERTH

</td>  
<td>

Industrial IoT use case questionnaire answers

</td>  
<td>

No sharing, data merged only for the purpose of D1.3 and deleted immediately
after

</td>  
<td>

No reusing of data is planned

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

2

</td>  
<td>

PENTA

</td>  
<td>

Survey, interviews

</td>  
<td>

Only shared with stakeholders of the project

</td>  
<td>

Reuse for all work packages development

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

3

</td>  
<td>

Lightricity

</td>  
<td>

Technical specification tables, graphs, block diagrams

</td>  
<td>

Only shared with project partners (contains sensible and confidential
information)

</td>  
<td>

Reuse for all technical work packages (WP1-6)

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

#  Conclusions and future work

This report details the data management and ethics of the project. After a
short introduction, Section 2 provides guidance on how to make Data Management
Plans. Section 3 puts emphasis on ethical issues and refers European
legislation related to ethics in research. Detail information of collected
data in the AMANDA project is placed in Section 4\. This Section can later be
used to track all the generated data in the project. It therefore satisfies
the need of reusability of the generated data required by directive
2013/37/EU.

During this project, no human trials are planned. However, data collection in
form of questionnaires was conducted. Personal or sensitive data must be
labelled as such. The data shall then only be stored, analysed and used
anonymously. The individuals will be informed comprehensively about the
intended use of the information collected from them. Participants shall give
their permission for data collection for a scientific purpose, with their
active approval in form of a written consent.

There is a potential for field tests, if time permits and lab testing is
successful. These tests can include the deployment of prototypes at the
location of end users for a preliminary evaluation of the ASSC. However, this
decision will be made towards the end of the project. For each data set,
ethical issues are considered separately in Section 4.1. The ethical aspect of
each dataset is evaluated in the data description.

The data which will be generated during the project is mostly related to the
performance of the electronic hardware. Section 4 describes and systematizes
data originated form the project. The data management approach presented in
this report mostly consists of labelling and describing the generated data. In
this way the data can be tracked during and after the project’s execution.

The data management plan & ethics document is an iterative report which will
be updated repeatedly at months M18 (v2), M30 (v3) and M36 (v4). Future
versions of the Deliverable will focus on the management of scientific data
collected for the project and making them findable, accessible, interoperable
and reusable. As a combined set of reports, it will document the progress of
data generation and its storage. The data description should point ethical
consideration towards the collected data. The data will be treated according
to its sensitivity.

#  Bibliography

  1. S. Brandt, “Data Management for Undergraduate Researchers: File Naming Conventions,” Purdue University Libraries, [Online]. Available: http://guides.lib.purdue.edu/c.php?g=353013&p=2378293. [Accessed 24 06 2019]. 

  

  2. D. Hillmann, “Dublin Core Metadata Initiative,” 12 04 2001. [Online]. [Accessed 24 06 2019]. 

  

  3. U. C. Faculty of Political Sciences and Sociology, “Code of Ethics,” ISA Forum of Sociology International Sociological Association, [Online]. Available: https://www.isasociology.org/en/about-isa/code-of-ethics. 

  

  4. The European Parliament And The Council Of The European Union, “Regulation (Eu) 2016/679 Of The European Parliament And Of The Council,” _Official Journal of the European Union,_ vol. L, no. 119, pp. 1-88, 2016. 

  

  5. “https://publications.europa.eu/en/publication-detail/-/publication/3e485e15-11bd11e6-ba9a-01aa75ed71a1/language-en,” [Online]. 

  

  6. “https://www.gotomeeting.com/,” [Online]. 

  

  7. E. Commision, “Participant Portal H2020 Online Manual - ethics,” European Commision, [Online]. Available: http://ec.europa.eu/research/participants/docs/h2020-fundingguide/cross-cutting-issues/ethics_en.htm. [Accessed 24 06 2019].