**Executive Summary**

This Deliverable is the second update of Deliverable 10.2 ‘Data Management
Plan’ and the new additions in relation to the previous versions are
introduced in **Chapter 1** .

**Chapter 2** presents the implementation of GDPR to the project and the
aspects affected or potentially affected because of the new Directive.

**Chapter 3** includes the Data Privacy Impact Assessments (DPIAs) carried out
separately by each UC team in order to identify if any issues or risks exist
because of data collection. No risks were identified in any of the Use Cases
because partners have already taken the necessary steps to anonymize data even
before GDPR was implemented.

**Chapter 4** briefly presents the different data clusters and introduces the
consolidated data table that is an elaborate and in-depth account of all data
collected across UCs as well as an update of the ADAS&ME data privacy (section
4.1) that was included in the first version of this Deliverable (submitted
M6). Partners have decided data to remain available only within Consortium.
The reasons are discussed in section 4.2. In addition, sections 4.3 and 4.4
shortly addressed the open access publications and where they will be
available after the end of the project. The Deliverable concludes with
**Chapter 5** , where the main outcomes of this version are summarized
considering potential lessons learnt from the implementation of GDPR halfway
through the project.

The adjustment of the existing informed consent form template in order to be
GDPR compliant is added in **Annex 1** .

The Data Privacy Impact Assessment (DPIA) template can be found in **Annex 2**
that was distributed to partners to be completed and the results are presented
in Chapter 3. The latter will be circulated and completed two times by the end
of the project. The first assessment is included in the final version of the
Deliverable (M30) and the final version in the final technical report, if any
changes or additions are expected.

The updated data privacy policy has been added in **Annex 3** . The update
considers the GDPR requirements and is written in a format to address the
participants in UC Pilots (i.e. whole duration of testing period) and user
tests (i.e. individual user testing session).

Finally, partners updated the existing data collection template for data
collected until this project period. The consolidated table including data for
UCs can be found in **Annex 4** .

**1 Introduction**

This document is the third update of the deliverable; the other two versions
were submitted in M6 and M24, respectively. The Data Management Plan aims to
define the processes of data handling during and after the end of the project.

In the first version of this Deliverable, data generated by sensors and
devices were gathered and annexed, the standards and methodologies were
presented, and the data privacy protection procedure and policy were defined
and established along with guidelines on how data can be openly shared in
order to comply with ORDP requirements with regards to their storage, curation
and preservation.

The second version included information about all the data types collected for
the test requirements of each Use Case (UC) and this information was used to
update the existing table of all gathered data during user testing across UCs
and sites. A description of the ADAS&ME repository and its functionalities was
included (Georgoulas & Gavrilis, 2018).

This table has been continuously updated because there are two complexity
factors that define the data clusters and their treatment: a) data collected
are UC-specific (i.e. data collected for creating the physical fatigue
algorithms may be different from the ones collected during the investigation
of distraction and sleepiness) and b) testing objectives are different across
phases (i.e. in the first phase, data are collected for developing/refining
the affective states’ algorithms and in the second phase, data are collected
to select the preferred HMI configurations for each affective state and in the
final stage the systems will be tested in real (like) life conditions). The
data table annexed in this document refers to the data collected during the
first two these phases.

However, the data collected during the final stage will include much less data
than the first two phases, but data will be from the categories already
addressed and thus not an update to this table is necessary.

The reason for the addition of a third version of this document is the fact
that GDPR was implemented long after the beginning of the project and thus the
processes relevant to the new regulation were applied after this date to the
project and are reported in this version.

As this is a UC-based project, the objectives and data collection are
performed at UC level, therefore separate Data Private Impact assessment
(DPIA) reports were prepared per UC.

The following table presents the content enrichment across the three separate
updates.

**Table 1.** D10.2 content per version  
  
<table>  
<tr>  
<th>

**First version (preliminary; M6)**

</th>  
<th>

**First update (intermediate; M24)**

</th>  
<th>

**Second update (final; M30)**

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

  * Data processes. 

  

  * Data sharing. 

  

  * Initial data policy. 

  

  * First data collection table was included in Annex I. 

  

  * Relevant legislation and guidelines. 

  

</td>  
<td>

• Data collection per UC pilots, as presented within D7.1 (Cocron et al.,
2018; submitted M18). Types of data along information about privacy,
confidentiality, and other characteristics are presented in Table 3 (Annex 4),
following the same format with the table annexed in the

</td>  
<td>

  * Results of GDPR implementation in the project: 

  

− Data Privacy Impact assessment (DPIA).

  * GDPR compliant consent form. 

  

  * Final datasets collected and 

  

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

**First version (preliminary; M6)**

</td>  
<td>

**First update (intermediate; M24)**

</td>  
<td>

**Second update (final; M30)**

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

</td>  
<td>

first version of this deliverable.

• A short description of the ADAS&ME data

repository, based on D4.1, submitted in M18.

</td>  
<td>

decision about their openness.

• Open access publications current status and future availability.

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

  2. **Implementation of GDPR in ADAS &ME **

  

  

GDPR was implemented in the middle of the project’s lifetime and the following
steps were taken:

  1. Defined a GDPR compliant informed consent form template with clear reference to subject’s rights to access, retrieve, and delete their data post-testing (Annex 1). 

  

  2. Assessed the potential data privacy issues at UC level by the teams involved in each Use Case (Chapter 3). As the data collection was not big and it was on pilot level, then a DPO was available were it was already appointed. These partners were advised to discuss any data privacy issues with their DPOs, if one was appointed. However, no such issues and risks were identified due to data anonymity and restricted access. 

  

  3. Defined who the data controllers and data processors are in the project as well as the duration of data preservation period after the end of the project. 

  

  

  3. **Data Privacy Impact assessment (DPIA)**

  

  

A data privacy impact assessment process was initiated as soon as the GDPR was
implemented. As the project’s work started long before GDPR, this impact
assessment was not applied before data collection and processing.

A template was prepared based on the GDPR requirements (as defined within Art.
35) and was circulated to UC leaders to discuss and complete in communication
and agreement with the pilot sites’ controllers and processors. Assisting and
guiding questions were included in each section of the template to help UC
teams in completing it with relevant information harmoniously across UCs. The
circulate template have been annexed in this update (Annex 2).

Data controllers and processors were the following organizations: SCANIA,
VEDECOM, VALEO, VTI, DUCATI, CERTH/HIT, DLR, FORD, FhG, Autoliv, uPatras. The
latter is perceived as both controller and processor because is the partner
who created the database and therefore acts as a data manager of the project
as well as was involved in the development of algorithms across affective
states.

Only data processors were the following partners: RWTH Aachen, EPFL, OVG,
Continental, and SmartEye.

Sections 3.1-3.5 present the results of each separate UC DPIA. Some parts of
the text are similar in different UCs and validate the harmonious data
procedure and policy implemented across the project. An overview of these
reports is discussed in the last section of this Chapter.

####  3.1 Use Case A: Automation behaviour

A DPIA was performed because participants are asked to provide feedback and
data that could be identified as personal will be collected but participants
remain anonymous.

#####  3.1.1 Aims

  * Development and evaluation of a system to detect driver’s sleepiness; 

  

  * Development and evaluation of a system to detect driver’s visual distraction; 

  

  * Development and evaluation of a system to detect driver’s resting; 

  

  * Development and evaluation of a system to detect driver’s frustration; 

  

  * Development and evaluation of HMI elements and their combinations to inform and warn riders when they are sleepy, visually distracted, frustrated, or resting. 

  

#####  3.1.2 The need

The need for a PIA is based on the fact that data collected may be anonymous
but some of the data collected maybe classified in the ‘sensitive data
category’ (e.g. heart rate).

#####  3.1.3 Data treatment process

Data is being collected for two purposes; (1) data to support development of
driver state detection algorithms, (2) data to support HMI development.

Data are collected anonymously through sensors and questionnaire completion.
Identifying information afforded from provision of consent to participate, is
stored separately to all other data collected from the participant. All paper
data are anonymous and stored in a locked cabinet.

Data were collected to support the development of the driver state detection
algorithms (Sleepiness, Visual Distraction, Frustration, and Rest) were
collected (WP4). As per the informed consent obtained from the participant
(and as was approved by the Stockholm Region Ethical Board), the only source
of data in which the participant could be identified (raw camera data used for
developing the Sleepy and Visual Distraction algorithms) was shared with three
partners (the data owner, Scania, Smart Eye, and EPFL). These data were
collected prior GDPR implementation; however, anonymity was protected. This
digital information is stored on an isolated data storage device and is not
connected to the Scania network. Other camera data not required for algorithm
development is stored on an isolated data storage device and is not shared
with other partners. All other non-identifying data will be shared with
project partners via a secure data repository. Only pre-specified contributors
can access the data that is needed for that partner (i.e. data
compartmentalization).

Additionally, data were collected to support the development of the Human
Machine Interaction (HMI; WP5). No data collected from this work is shared
with other partners. Identifiable digital information (from eye trackers) will
be stored on an isolated data storage device that is not connected to the
Scania network. Non-identifiable driver information is stored on a shared
director accessible by all Scania project contributors.

Digital and paper data will be destroyed five years after the completion of
the project.

#####  3.1.4 Data sources

As shown above, data sources are sensors and questionnaire data. For a
complete list, please refer to the data collection spreadsheet completed for
UC A (Annex 4).

#####  3.1.5 Data sharing

In addition to the identifiable raw video camera data explained above,
anonymized raw data was shared with VTI for generation of the Rest algorithm.
Identifiable driver data (raw camera data from eye tracking cameras): stored
on isolated memory storage device. Shared with two additional partners
(consistent with approved participant consent, and Stockholm region ethics
board), beyond the data owner (Scania).

Non-identifiable (digital) participant data (e.g. heart rate) were stored on
Project hosted data repository and available to specific partners requiring
access to the data for algorithm development. No high-risk data processing was
involved.

#####  3.1.6 Data clusters

No special categories of data are included. The main data clusters are the
following and include fata collected for algorithm training:

  * Demographics Questionnaire 

  

  * Background Sleep Questionnaire 

  

  * Sleep Diary 

  

  * Alertness & Sustained Attention (TAP-M) task performance 

  

  * Lane Change Test & N-Back Task Performance 

  

  * Physical Ergonomics Measurements 

  

  * Karolinska Sleepiness Scale 

  

  * Stress Scale 

  

  * VITAPORT II: EOG, ECG, GSR, EMG 

  

  * CAN data (steering wheel, levels, and Instrument Panel buttons and Switches) 

  

  * Eye Tracker (x 3) 

  

  * Optical Cameras (x 3): 

  

  * Hypnodyne: EEG data 

  

  * Bitium sensor: Heart rate parameters 

  

  * Data collected for HMI development includes: 

  

  * Performance associated with handovers/takeovers of control between the participant and the automated vehicle 

  

  * Geneva Emotion Wheel 

  

  * Human Trust in Automation Scale 

  

  * System Usability Scale (SUS) 

  

  * AATT 

  

  * 10-grade Scania scale 

  

  * Open interview questions 

  

Data have been so far collected in two stages with ten drivers participating
for two days in Stage I and 13 drivers participating for two hours each in
Stage II. All data collected were used (i.e. data minimization principle was
followed). Separate HMI driving simulator study will be conducted with two
hours participation for each user and aiming again to use all collected data.

Two rounds of data collection to support algorithm training were conducted.
One round of simulator driving testing was conducted. Anonymous datasets will
be stored for five years after the end of the project. Individuals are not
affected because data collection and storage are anonymous.

The identifiable eye tracker camera information that was shared between three
partners is from 23 participants. It covers participants in the Stockholm
County (län).

#####  3.1.7 Context of processing

All participants are Scania (or Scania subsidiary) employees. Drivers
participated voluntarily and were free to stop and leave whenever they wanted
and if they wanted their data to be deleted and not stored, they were informed
they could ask for it. They were informed about data being treated anonymously
and used for research purposes and publications. No concerns existed because
data collection is anonymous. Data collection was not novel. Children or other
vulnerable groups were not involved. All data collected was done so using off-
the-shelve technologies. There were no issues related to public concerns. Data
collection for algorithm development was approved by the Stockholm region
ethics board.

#####  3.1.8 Purposes of processing

As described previously, some data are used for development driver state
detection algorithms. Other data is used as input to the HMI. No indented
effect is anticipated on the person. This process ensures a user-defined and
accepted system, as it is being developed during the lifetime of the project
and, as whole, it did not pre-exist. In addition, it ensures the system is
safe, reliable, accurate, valid and usable.

#####  3.1.9 Consultation process

Participants’ views will be collected through self-reports and standardized
questionnaires. For HMI development, no one else but the local (Scania)
project team will be involved in the data collection process. The team member
names have been added in both the ethics application and the informed consent
form. Data collected from Stage I and Stage II testing has been made available
to the relevant partners (see previous description). Information about data
security was received internally from the project.

#####  3.1.10 Necessity and proportionality

Data processing is performed within the framework of the European project
ADAS&ME and is part of our contractual obligations. The data processing
achieves its goal because it is based on careful and considerate experimental
planning, as it is described in D7.1 of the ADAS&ME project. There was no
other way or method in order to achieve this outcome and especially if the
same level of system performance is required/requested. Function creep is
prevented by the fact that the system and its respective functions cannot be
used for another purpose. The endproduct will be a prototype that will not be
used by people outside the consortium. Further development and improvements
can be made but they will not involve usage of data collected at this stage
for different applications. Further exploitation of the products generated
within this project will not require any further access to participant data.
Data quality is ensured because of technical verification and pre-testing
sessions taking place before any actual testing. Certain indices were set for
technical performance with regards accuracy, validity, sensitivity and
reliability. Data treatment and minimization was controlled by trained data
scientists. All participants completed an informed consent form. Stage I and
Stage II testing has been completed and was GDPR compliant, even though parts
of them were performed before GDPR was implemented.

Users receive information about data treatment and storage, anonymization
process, their own rights during testing, a copy of the informed consent form,
testing duration, description of the project and contact points.

All data are anonymous, and processors have no access to any information about
the participants (except as mentioned for the identifiable camera data).
Participants have agreed for those data to be shared within the consortium.

Identifiable video data were transferred by a wired local connection from one
encrypted data storage device to another encrypted data storage device. Non-
identifiable data was transferred to a project hosted data repository.

#####  3.1.11 Identified, assessed and mitigated risks

No data related risks are envisaged and were encountered during the tests
already completed or are scheduled to be carried out. Simulator sickness was a
potential risk for test conduction, not related to data privacy, that would
result in immediate cessation of the test session. Participants were informed
beforehand of this possibility through the informed consent process.

####  3.2 UC B – Range anxiety (VALEO)

#####  3.2.1 Aims

To help drivers mitigate their range-related anxiety and increase the
acceptability of electric vehicles, tests were conducted to determine whether
we can reliably provoke and detect anxiety and other emotions in electric
vehicle drivers. Additionally, these tests aimed to determine which part the
HMI is responsible for the anxiety and stress of the driver of an electric
car, and to see whether it is indeed possible – that is whether the intra-
individual variability of the person’s behaviour and physiological condition
is detected and interpreted reliably and correctly enough - to develop an
adaptive approach to the HMI; whereby a vehicle would progressively amass data
and learn to behave in the most appropriate way towards its driver.

Research Hypotheses:

  * Spontaneously experienced positive and range anxiety can be induced while driving an electric car; 

  

  * A discrimination of experienced positive and range anxiety during driving is possible based on video recordings of the face; 

  

  * A discrimination of experienced positive and range anxiety during driving is possible based on speech data; 

  

  * To identify the electrical vehicle range anxiety among other emotions; 

  

  * To evaluate the efficacy of the various parts of the test plan for reliably provoking emotional responses. 

  

#####  3.2.2 The need

Over the last year, we did three data collections to fulfil the needs of data
for Audio anxiety, video anxiety and HR/RR anxiety algorithms. The audio
algorithm is developed by OVGU, a University partner within the Consortium.
The video algorithm is developed by EPFL and the HR/RR by Valeo. After the
data collections, each partner trained their algorithm on anonymized data to
build a robust algorithm.

#####  3.2.3 Data treatment process

Three data collection took place within 2018. All of them were on open roads
in the vehicle demonstrator of VEDECOM. The last stages (II and III) were
conducted after GDPR and a confidentiality and release form was additionally
signed.

  1. **Stage I:** During April 2018 with 5 subjects in France, around Paris. 

    1. Objective: CAN Vehicle, Audio and face video. 

  

    2. Subjective: BFI-10, GEW, KSS, Stress and Gagge scales. 

  

    3. Audio-visual capture agreement 

  
  

  

  2. **Stage II:** During September 2018 with 20 subjects in France, around Paris. 

    1. Objective: CAN Vehicle, Audio, face video, HR/RR signals and the road. 

  

    2. Subjective: Personality, Attrakdiff, Feedback on the test and HMI. 

  

    3. Audio-visual capture agreement 

  

    4. Confidential agreement 

  
  

  

  3. **Stage III:** During November 2018 with 20 subjects in France, around Paris. 

    1. Objective: CAN Vehicle, Audio, face video, HR/RR signals and the road. 

  

    2. Subjective: Personality, Attrakdiff and Feedback on the test. 

  

    3. Audio-visual capture agreement 

  

    4. Confidential agreement 

  
  

  

  

#####  3.2.4 Data sources

In terms of Go, we had an average of 200Go for the Stage II and 670Go for the
Stage III. In terms of time, we had an average of 60mins per participant for
the Stage II & III. Each partner used all exploitable data to build their
algorithm. Some of these collected data as the scene camera and the cockpit
camera are used for Ground Truth annotating. The headset microphone and the
BioHarness belt are used for Ground truth development. The data collected are
recorded only once per participant. The recorded data are safely kept till the
end of the European project. In total, 45 users participated that live in
Paris and suburbs.

#####  3.2.5 Data sharing

Personal data handling was and will be performed strictly according to EU
regulations which have been laid out to and agreed by the cooperating partners
and participants in advance. The consent form signed by all the participants
of the study, allows the sharing of the audio, video and physiological raw
data among all relevant driver-state emotions partners (OVGU, VEDECOM, EPFL,
SEYE, VALEO). Further, no personalized data may be distributed among other
partners. Anonymized data, like extracted features and markers, may be
distributed to other partners.

Data will be made available to the partners using the repository system
provided by WP4. Audio and physiological recordings can be downloaded only by
the corresponding partners. The video recordings are distributed by SEYE on
request only to involved partners.

#####  3.2.6 Data clusters

The nature of the data are videos (.avi), audio (.wav) and other data (i.e.
subjective measures) are stored in to Excel files (.csv).

#####  3.2.7 Context of processing

Experienced drivers participated once in a driving session (e.g. at least five
years since they obtained their driving license). Each of them had a full
control on the possibility to perform the test or not. They were no
constraints during driving, however, directions about which road to choose,
were given. Participants completed a separate audio-visual agreement and they
were fully aware about the data usage, storage, processing and sharing.

#####  3.2.8 Purposes of processing

Range anxiety (or range paradox) is a concept emerged in the late 90s which is
the concern of not reaching to the destination or to the next charging spot
while traveling in an EV (Nilsson, 2011). This is a stressful experience of a
present or anticipated range situation, where the range resources and personal
resources are in fact available to effectively manage the situation; however,
they are perceived to be insufficient.

Studies show that electric vehicle drivers usually need around 160 km of
autonomy per charge. Nevertheless, they often prefer vehicles with
considerably higher available range (around 350 km). This demand (which seems
to be avertable) comes from the worry of experiencing such a situation in the
future or present, worry of what will happen if such a situation emerges,
worry of not being able to find a solution to the situation and further worry
of being stranded in this uncomfortable situation (Nguyen, Cahour, Forzy, &
Licoppe, 2011).

If the manufacturers cannot lower range anxiety, electric vehicles will not be
able to compete with gasoline and diesel cars. The four important physical
parameters that will make a difference in range anxiety level are the
following: the battery size (kWh), the energy consumption (this parameter is
mostly affected by the weight of the car) (kWh/km), the charging speed (kW)
and the minimum state of charge (%). Despite the fact that each one of these
parameters could be optimized individually, their effects are inversely
proportional. As an example, implementing a bigger battery will increase the
range but all the same the weight of the vehicle (so the energy consumption)
and the charging time will increase. Therefore, the range anxiety cannot be
eliminated by purely quantitative means, and this is the motivation behind the
Use Case of the project.

Current vehicles do not address this issue whether through intelligent vehicle
power management system or whether through a routing and traffic analysis and
mitigation.

The ADAS&ME approach is to create a driver monitoring system to reliably
detect driver emotional and physiological state, in order to detect and
mitigate the range anxiety through both the means of adapting the vehicle HMI
to the situation at hand, and managing the vehicle’s operational parameters,
as to reliably and safely provide a technical solution, when the remaining
range is truly insufficient for the driver to reach the destination.

The aim is the creation of a system able to reliably understand and
discriminate between different types of emotional states.

**3.2.9 Consultation process**

Not relevant to testing conducted so far.

#####  3.2.10 Necessity and proportionality

VEDECOM applied to respective Ethics committee and ensured that every part of
testing complied with French legislation and relevant Directives. The research
team succeeded in observing real range anxiety during the Stage II & III.
Detecting actual range anxiety during a controlled driving test is very
complex because the participant knows that everything is under control
(expectation and testing bias) and, thus, an electrical breakdown has lower
probability to happen. So, the other way to proceed would be to record driver
during every day driving experience where an electrical breakdown can happen.
Through RTMaps, records, status trackers were set per sensor type to ensure
quality of data was not affected. Following the data minimization principle,
only the necessary data were recorded and shared. Private servers are used to
safeguard data and data sets’ structure and storage ensures deletion of data
upon participant’s request.

#####  3.2.11 Identified, assessed and mitigated risks

No risks identified that are relevant to user data privacy. All necessary
steps were taken beforehand to ensure and safeguard data anonymity.

####  3.3 Use Case C (DLR – automation to manual) & Use Case D (Fraunhofer –
during manual driving & DLR – during automation)

#####  3.3.1 Aims

  * Development and evaluation of a system to detect drivers stress; 

  

  * Development and evaluation of a system to detect drivers’ emotions; 

  

  * Development and evaluation of a system to detect visual distraction in drivers; 

  

  * Development and evaluation of HMI elements and their combinations to inform and warn drivers of an upcoming transition of control. 

  

#####  3.3.2 The need

Project includes information about the participants that might be perceived as
personal data.

The use case C and D of the ADAS&ME project focuses on a safe and smooth
transition between automated and manual driving. Therefore, different driver’s
states need to be considered to provide the best possible support to human
driver. To achieve this goal, personal data as physiological data need to be
collected and processed to monitor the driver state.

Since different project partners are responsible for different driver states,
use case C/D needed to collect and share date with involved project partners.
This includes sharing personal data with internal project partners involved in
use case C/D. The overarching purpose is to provide the internal project
partners with enough data to develop algorithms for the driver state
assessment. The benefits of collecting and processing the personal information
is to have a robust driver state monitoring which makes it possible to tailor
HMI and automated functions to the needs of the driver.

Therefore, DLR collects -in two data collection phases- demographic data,
audio data, video data for face recognition, physiological data and driving
behaviour data and shares them with SmartEye, RWTH Aachen, Ford, Continental,
EPFL and UPatras.

Further, different use case partner collected data in HMI studies (DLR,
Frauenhofer). Ford collected physiological data and shared it with RWTH
Aachen. The work performed is described in the following document that is
confidential to Consortium (i.e. D5.1 ‘HMI and Automated Functions’), where
the Interaction/ Transition framework was fully developed and all basic HMI
elements were selected. The need for a PIA is based on the fact that data
collected maybe anonymous but some of the data collected maybe classified in
the ‘sensitive data’ category (e.g. heart rate, gaze data, facial
recognition).

#####  3.3.3 Data treatment process

Data collected in Use Case C/D are mainly collected in “Data collection
phases” and in HMI studies. In both types of studies personal data from the
participants are collected. The data collections focus more on sensor data
(ECG, Voice, Gaze behaviour) while HMI studies are focusing on the behaviour
of the participants.

All data is shared at the ADAS&ME repository in an anonymized format. Data
from participants who consent for video recordings (e.g. face recognition) can
only be accessed by a limited number of project partners and results are used
only for scientific purposes, in an anonymised manner.

#####  3.3.4 Data sources

As shown above, data sources are sensors and questionnaire data. For a
complete list, please refer to the data collection spreadsheet completed for
UCs C and D (included in the overall data sheet in Annex 4).

#####  3.3.5 Data sharing

Anonymized raw data from data collection are shared internally -in Use Case
C/D- with the related use case partners. Data is stored on local servers with
restricted access only to DLR employees. Gaze data is stored on a hard-disk
and sent to SmartEye. Anonymization is not possible by the latter data. Data
resulting from tests conducted by Ford can be accessed by all project
partners, as no high-risk data processing is involved.

#####  3.3.6 Data clusters

No special categories of data are included. The main data clusters are the
following:

  * Facial recognition data 

  

  * Gaze data 

  

  * Voice data 

  

  * Heart rate 

  

  * GSR 

  

  * Driver behavioural parameters (steering, braking, acceleration/deceleration, pedal pressure, steering pressure) 

  

  * Questionnaire and scale data 

  

  * Background data 

  

DLR collected data from 42 participants in two data collection phases. Ford
collected data from

24 participants in March 2018. Both DLR’s data collections were conducted in
controlled experimental conditions in 2018. Anonymous datasets will be stored
for five years after the end of the project. Individuals are not affected
because data collection and storage are anonymous. Testing geographically
covers participants in the area of Braunschweig, Germany (DLR employees and
externals). Participants of the Ford study were recruited within NRW, Germany.

#####  3.3.7 Context of processing

In the first data collection participants were citizens of Braunschweig. In
the second data collection all participants were DLR employees. Participants
of the Ford study were recruited by an external company. All the informed
consent procedures were carried out by Ford. Drivers participated voluntarily
and were free to stop and leave whenever they wanted. Further participants
were informed that their data will be stored and used for scientific purposes.
All participants agreed that their data can be stored and used for further
scientific analysis. They were informed about data being treated anonymously
and used for research purposes and publications. No children or other
vulnerable groups were involved in the data collections or HMI studies. No
concerns existed because data collection is anonymous. Experimental setup was
novel and for this reason a security driver was present in the second data
collection. But data collection was not novel.

The real time processing of physiological data is not new and was already done
in some series produced cars (sleepiness detection). Nevertheless, new sensors
are used in the current project. All data will only be processed and analyzed
in the vehicle and no communication of these data is performed. Similar
systems exist in respective market for most of the in-house builds. No public
related concerns are relevant or anticipated for the remaining pilot
activities.

###  3.3.8 Purposes of processing

The goal of the processing is to have a robust driver state assessment in
automated vehicles. With the knowledge of the driver state, new tailored
interaction strategies can be performed by the vehicle to achieve the maximum
level of driver support, when it is needed.

**Ford Stress study:** 1.To gather data that will be used for algorithm
development in order to determine the driver’s state. 2.To identify methods by
which periods and intensity of certain driver states can be detected in a
minimally obtrusive way.

**Phase I:** Collect voice data from participants in different emotional
states. This data is used to develop a robust algorithm for driver state
detection.

**Phase II:** Collect ECG data from participants in different stress states.
Further gaze data was collected for the distraction algorithm. This data is
used to develop a robust algorithm for driver state detection.

**Ford Stress study:** The goal was to induce stress.

**Phase I:** Different emotional states (happiness, anxiety, neutral, sad)
were induced in a controlled environment.

**Phase II:** Stress and distraction were induced in controlled environment
while driving in manual or automated mode on a test track. A safety driver was
always present.

Ensures a user-defined and accepted system, as it is being developed during
the lifetime of the project and, as whole, it did not pre-exist.

All drivers will benefit from this, since they will get the right level of
system support, if they need it. Due to this, the safety of the driver and his
driving environment can be achieved.

###  3.3.9 Consultation process

Through self-reports and standardized questionnaire comprising mostly close-
ended questions. Only the research team have access to these data. The team
member names have been added in both the ethics application and the informed
consent form. The same organization is the data collector and data processor.
However, the algorithms are developed by UPatras that has access to anonymised
data only and manages the data storage on the central project repository, as
it is described in WP4-IR –MS7 document.

###  3.3.10 Necessity and proportionality

Data processing is performed within the framework of the European project
ADAS&ME and is part of our contractual obligations. Yes, it is based on
careful and considerate experimental planning, as it is described in D7.1 of
the ADAS&ME project. Participant data collection is mandatory for a UCD
approach when designing a user-specific safety system. The system and its
respective functions cannot be used for another purpose. The end-product will
be a prototype that will not be used by people outside the Consortium. Further
development and improvements can be made but they will not involve usage of
data collected at this stage for different applications. Data quality is
ensured because of technical verification and pre-testing sessions taking
place before any actual testing. Certain indices were set for technical
performance with regards accuracy, validity, sensitivity and reliability Data
treatment and minimization was controlled by trained data scientists. All
participants completed an informed consent form. Both data collections are
completed, and the informed consent form was GDPR compliant. Users receive
information about data treatment and storage, anonymization process, their own
rights during testing, a copy of the informed consent form, testing duration,
description of the project and contact points. All data are anonymous, and
processors have no access to any information about the participants. In
addition, data processors are all informed about GDPR new guidelines and their
responsibilities.

All date shall be handled in accordance to the ADAS& ME Ethics Manual D10.3
(Jansson et al., 2017). This manual refers to the Regulation (EU) 2016/679 of
the European Parliament and of the Council of 27 April 2016 on the protection
of natural persons about the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (The General Data
Protection Regulation, GDPR). Thus, GDPR restricts transfers of personal data
outside the EEA unless the rights of the individuals in respect of their
personal data is protected in another way. In any case, no transfer of
personal data is foreseen in the ADAS&ME project.

###  3.3.11 Identified, assessed and mitigated risks

Identified risks were included in the performed risk analysis (e.g. part of
ethical approval of DLR stress study) about potential accidents during driving
at DLR campus (Phase I) and with test vehicle while automated driving on test
track (Phase II). These issues were mitigated by conducting tests only in
times without heavy traffic and the safety driver was always able to brake
(Phase I) and no other traffic on closed test track and safety driver always
on board (Phase II). However, these aspects are related to ethical conduction
of user testing and not related to data privacy issues. Therefore, no data
privacy related issues and risks have been identified.

##  3.4 UCs E & F – Physical fatigue and fainting (DUCATI & CERTH/HIT)

###  3.4.1 Aims

  * Development and evaluation of a system to detect rider’s stress; 

  

  * Development and evaluation of a system to detect physical and thermal fatigue; 

  

  * Development and evaluation of a system to detect visual distraction in riders; 

  

  * Development and evaluation of HMI elements and their combinations to inform and warn riders when they are fatigued and distracted. 

  

###  3.4.2 The need

The need for a PIA is based on the fact that data collected maybe anonymous
but some of the data collected maybe classified in the ‘sensitive data
category (e.g. heart rate).

###  3.4.3 Data treatment process

Data are collected anonymously through sensors and questionnaire completion.
Data are stored only in CERTH offline storage and will be deleted five years
after the end of the project.

As shown above, data sources are sensors and questionnaire data. For a
complete list, please refer to the data collection spreadsheet completed for
UCs E and F (included in the consolidated data collection table that can be
found in Annex 4).

Anonymized raw data were shared with UPatras for algorithms creation and data
repository management, who is the data manager of the project.

The data flow is presented in the following diagram (Figure 1).

**Figure 1.** Use case E/F HMI data management No high-risk data processing is
involved.

###  3.4.4 Data sources

No special categories of data are included. The main data clusters are the
following:

  * Heart rate 

  

  * Galvanic skin response (GSR) 

  

  * Internal and external temperature 

  

  * External humidity 

  

  * Rider behavioural parameters (steering, braking, acceleration/deceleration, pedal pressure, steering pressure, body stature) 

  

  * Questionnaire and scale data 

  

  * Background data 

  

Data from 22 participants were collected across 2 phases. Data were collected
in controlled experimental and simulated conditions for both phases.
Experiments conducted during Phase I aimed to the collection of data for the
development of physical fatigue and visual distraction algorithms (conduction
2017/2018). Phase II tests were aiming to evaluation the HMI configurations
developed within the project in order to detect and inform/warn riders when
visual distraction or physical fatigue was detected (conduction 2019). Some
riders participated in both phases and they were in their majority CERTH
employees, all naïve to the project and testing objectives.

Anonymous datasets will be stored for five years after the end of the project.
Individuals are not affected because data collection and storage are
anonymous. It covers participants that are residents in Thessaloniki, Greece.

###  3.4.5 Data sharing

Anonymous data are shared only with UPatras for data management (i.e. storing
in data repository) and development of algorithms for distraction and physical
fatigue. Data sharing is anonymous. Pseudonimization was handled offline and
related documents were deleted after the end of respective testing phase (i.e.
Pilot). This means that during the Pilot, personal details were kept only for
organizational reasons (e.g. arranging appointments) and destroyed after the
end of the testing period.

###  3.4.6 Data clusters

Data are clustered into three main categories: a) self-reported/perceived
questionnaires, b) physiological measures (e.g. ECG, GSR) and c) riding
behaviour/performance indicators (e.g. braking behaviour,
acceleration/deceleration).

###  3.4.7 Context of processing

Riders participated voluntarily and were free to stop and leave whenever they
wanted and if they wanted their data to be deleted and not stored, they were
informed they could ask for it. Participants were informed about data being
treated anonymously and used for research purposes and publications. No
children or vulnerable groups were involved and/or recruited and explicit
inclusion and exclusion criteria were set. No concerns existed because data
collection is anonymous. Experimental setup was novel and for this reason a
medical practitioner was always present during the thermal fatigue experiments
in phase 1. But data collection was not novel. Similar systems exist in
respective market for most of the in-house builds. No data privacy concerns
exist or were envisaged.

###  3.4.8 Purposes of processing

The objectives are different per Phase:

  * **Phase I:** Create algorithms to detect rider’s acute stress, visual (acute) distraction and thermal fatigue. Thermal fatigue, stress and distraction were induced in controlled environment with a medical practitioner always being present. Participants to understand the HMI role and select the ones (or their combinations) they preferred. 

  

  * **Phase II:** Select the most appropriate and accepted HMI elements for informing riders when they are distracted and when they are physically tired (3 levels: information, warning, critical and activation of recovery and then stabilization modes). This approach ensures a user-defined and accepted system, as it is being developed during the lifetime of the project and, as whole, it did not pre-exist as well as that they system is safe, reliable, accurate, valid and usable. 

  

###  3.4.9 Consultation process

Direct subjective feedback is collected by participants through self-reports
and standardized questionnaire comprising mostly close-ended questions. Only
CERTH research team had access to subjective data. The team member names have
been added in both the ethics application and the informed consent form.

The same organization is the data collector and data processor. However,
UPatras was involved in the development of the algorithms and therefore has
access to anonymised data only and manages the data storage on the central
project repository, as it is described in WP4-IR –MS7 document.

###  3.4.10 Necessity and proportionality

Data processing is performed within the framework of the European project
ADAS&ME and is part of our contractual obligations. Data collection is based
on careful and considerate experimental planning, as it is described in D7.1
of the ADAS&ME project.

Participant data collection is mandatory for a UCD approach when designing a
user-specific safety system. The system and its respective functions cannot be
used for another purpose. The end-product will be a prototype that will not be
used by people outside the Consortium. Further development and improvements
can be made but they will not involve usage of data collected at this stage
for different applications.

Data quality is ensured because of technical verification and pre-testing
sessions taking place before any actual testing. Certain indices were set for
technical performance with regards accuracy, validity, sensitivity and
reliability Data treatment and minimization was controlled by trained data
scientists.

All participants completed an informed consent form. Phase I was conducted
before implementation of GDPR and the informed consent form was not GDPR
compliant. For the second phase of user testing (Phase II), the informed
consent form was further adapted to be GDPR compliant. Users receive
information about data treatment and storage, anonymization process, their own
rights during testing, a copy of the informed consent form, testing duration,
description of the project and contact points. An update informed consent and
release form can be found in Annex 1. The release form can be used in case the
research teams wish to collect audio, video and photographs. Updated versions
of these forms were primarily annexed in this deliverable because of the final
real-life tests that remain to be conducted within WP7.1 at IDIADA, as the
material that can be collected during these tests can be used for
demonstration of the results of the ADAS&ME project.

All data are anonymous, and processors have no access to any information about
the participants. In addition, data processors are all informed about GDPR new
guidelines and their responsibilities. One day training seminar by a
counselling firm was held at CERTH and data collection and PIA was discussed
with CERTH’s DPO. There are no international transfers of data.

###  3.4.11 Identified, assessed and mitigated risks

No risks related to data privacy were identified and thus no data related
mitigation strategy is necessary. The only identified risk is related to
participants falling from the riding simulator during testing. This potential
risk was mitigated by adding padded surfaces around the riding simulator to
ensure participants are not hurt in case of fall.

##  3.5 Use Case G – Automating approaching at and departing of bus stops
(VTI)

A DPIA was performed because participants are asked to provide feedback and
data that could be identified as personal were collected but participants
remain anonymous.

###  3.5.1 Aims

The aim was to collect data on stress, sleepiness and fatigue of bus drivers
in relation to repeated tasks like approaching at a bus station and departing
from it. Tasks that can be automated and thus alleviate bus driver’s fatigue
and stress. These data were used for tuning the algorithms on sleepiness and
inattention. In addition, the aim was to test the setting of the final
evaluation and to make sure that integration of sensors and the connection to
the HMI is working, but also that the design of the study supports the results
needed for the final evaluation.

###  3.5.2 The need

The need for a PIA is based on the fact that data collected may be anonymous
but some of the data collected maybe classified in the ‘sensitive data
category’.

###  3.5.3 Data treatment process

Data is being collected for two purposes; (1) data to support development of
driver state detection algorithms, (2) data to support HMI development.

Data are collected anonymously through sensors and questionnaire completion.
Identifying information afforded from provision of consent to participate, is
stored separately to all other data collected from the participant. All paper
data is stored in a locked cabinet.

Data was collected to support the development of the driver state detection
algorithms was collected (WP4). Only pre-specified contributors can access the
data that is needed for that partner.

Data is being collected to support the development of the Human Machine
Interaction (HMI; WP5). No data collected from this work is shared with other
partners. Identifiable digital information will be stored on an isolated data
storage device that is not connected to the online network. Non-identifiable
driver information is stored on a shared director accessible by all Scania
project contributors.

Digital and paper data will be destroyed five years after the completion of
the project.

###  3.5.4 Data sources

As shown above, data sources are sensors and questionnaire data. For a
complete list, please refer to the data collection spreadsheet completed for
UC G (see Annex 4).

###  3.5.5 Data sharing

Non-identifiable (digital) participant data are stored on Project hosted data
repository and available to specific partners requiring access to the data for
algorithm development. No highrisk data processing is involved.

###  3.5.6 Data clusters

No special categories of data are included. The main data clusters are the
following and include fata collected for algorithm training:

  * Demographics Questionnaire 

  

  * Background Sleep Questionnaire 

  

  * Karolinska Sleepiness Scale (KSS) 

  

  * Subjective Stress (SUS) 

  

  * ECG, Heart Rate / Variability 

  

  * Blink duration, EOG 

  

  * Respiratory rate 

  

  * Kinematic data of moving base simulator (i.e. velocity/acceleration) 

  

  * Closed and Open question items 

  

###  3.5.7 Context of processing

At this stage, three testing steps were taken. The first step was an
exploratory study with the aim to understand bus drivers working conditions
and problems. The second step was a Virtual Reality (VR) simulation study with
10 bus drivers in which a first HMI concept was evaluated. The outcome of the
VR study was then modified and integrated in a moving-base driving simulator
were also driver state algorithm for distraction and hands on steering wheel
(except Sleepiness) were integrated and evaluations. Algorithms for sleepiness
will be added to the final driver state detection system. In total 6 bus
drivers (some of them also used in the VR data collection) were invited to
drive at two different occasions; one time in an alert condition and one time
in a supposedly fatigued condition. The HMI evaluation was based on a
questionnaire that was filled in after the fatigue driving session. This study
followed the data collection conducted before GDPR compliance that aimed on
the affective state algorithms.

###  3.5.8 Purposes of processing

As described previously, some data is used for development driver state
detection algorithms. Other data is used as input to the HMI. No indented
effect is anticipated on the person. Ensures a user-defined and accepted
system, as it is being developed during the lifetime of the project and, as
whole, it did not pre-exist. In addition, it ensures that the system is safe,
reliable, accurate, valid and usable.

###  3.5.9 Consultation process

Participants’ views will be collected through self-reports and standardized
questionnaire. For HMI development. Information about data security was
received internally from the project.

###  3.5.10 Necessity and proportionality

Data processing is performed within the framework of the European project
ADAS&ME and is part of our contractual obligations. The data processing
achieves its goal because it is based on careful and considerate experimental
planning, as it is described in D7.1 of the ADAS&ME project. There was no
other way or method in order to achieve this outcome and especially if the
same level of system performance is required/requested. Function creep is
prevented by the fact that the system and its respective functions cannot be
used for another purpose. The endproduct will be a prototype that will not be
used by people outside the consortium. Further development and improvements
can be made but they will not involve usage of data collected at this stage
for different applications. Further exploitation of the products generated
within this project will not require any further access to participant data.
Data quality is ensured because of technical verification and pre-testing
sessions taking place before any actual testing. Certain indices were set for
technical performance with regards accuracy, validity, sensitivity and
reliability Data treatment and minimization was controlled by trained data
scientists. All participants completed an informed consent form. Stage I and
Stage II testing has been completed and all data collection was GDPR compliant
regardless if data collection was performed before its implementation.

Users receive information about data treatment and storage, anonymization
process, their own rights during testing, a copy of the informed consent form,
testing duration, description of the project and contact points.

All data are anonymous, and processors have no access to any information about
the participants.

###  3.5.11 Identified, assessed and mitigated risks

No data related risks are envisaged and were encountered during the tests
already completed or are scheduled to be carried out. Simulator sickness was a
potential risk for test conduction, not related to data privacy that would
result in immediate cessation of the test session. Participants were informed
beforehand of this possibility through the informed consent process.

###  3.5.12 Overview of privacy assessment

As it is obvious from each separate UC data privacy assessment, no major
privacy risks were identified as data collection was largely anonymized and
data sharing was at a required basis and only of anonymized data. Data
collection of audio and video data was stripped of any personal data, stored
safely and shared only on need basis and isolated by the other collected data.
In addition, in all cases, participants have agreed in writing these data to
be collected, stored and shared with the Consortium.

No recognition was possible and informed consent was obtained across all
stages of testing. The UC leading teams conducting each assessment stated that
they are now aware and ready of all steps required for implementing GDPR, as
completing this template was a valuable experience to be utilized and re-used
in other projects they are currently working or will be involved in the near
future.

The most important lesson learnt from this experience is that a DPIA is a
time-consuming process and thus it is necessary to be organized early in the
project. In addition, roles should be assigned very early in order to ensure
that ‘privacy by design’ is a necessity and will be evident in the
architecture, the data repositories as well as the data flows. Within ADAS&ME,
because of the addressed data clusters, this process was inherent (i.e.
utilization of data like heart rate, blink rates, etc.). This is not the case
for other transport (or not) oriented project and the three aspects mentioned
above must be addressed at the beginning of the project along with the data
privacy policy that will be based on again these three aspects.

Moreover, the relation between the Ethics and data privacy policy also needs
to be addressed early in the project by the collaboration of both responsible
teams within a project that will be reported in the respective Deliverables.
This process will ensure that the policies are agreeable and complementary.

As GDPR was not adopted from the beginning of the project, then certain
procedures and documents had to be updated and roles to be assigned that did
not exist beforehand. However, as involved partners are experienced in this
field, the positive outcome was that most considerations and requirements were
fulfilled even before GDPR implementation.

#  4 Data descriptions and updated policy

##  4.1 Updated data privacy policy

The initial ADAS&ME data privacy policy is included in the first version of
this Deliverable submitted in M6. An update of this data privacy is prepared
for two reasons:

  1. GDPR compliance requires an elaborate description of related processes and actions; 

  

  2. Written in a format to be shared by partners conducted tests or other activities required to get in contact with people/users outside the Consortium. 

  

  

The updated policy governs the collection of information (private or not)
during the Pilots (i.e. whole testing period duration) and user tests (i.e.
dedicated user testing session) and can be found in Annex 4\.

##  4.2 Final datasets per UC

The datasets collected per UC were updated based on the current evaluation
stage. The complete dataset is annexed in this final version of this report,
but the table below provides a summary of the qualitative and quantitative
characteristics of the data collected during testing within the project.
Overall, 141 data categories have been identified across all UCs in the
project. It is important to note that for the data collected so far (stages I
and II) are included in this file. Data collection during the final evaluation
activities, as they have been planned within WP7 will utilize data sources
from phases I and II and additional subjective (perceived) scales.

**Table 2.** Data description categories and explanatory text  
  
<table>  
<tr>  
<th>

**ASPECT**

</th>  
<th>

**CATEGORY**

</th>  
<th>

Explanatory text

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

**DATA**

</td>  
<td>

**Collected/Created**

</td>  
<td>

Collected/created

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

**Name**

</td>  
<td>

Name of the data/ metadata/ exploitable result

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

**Description**

</td>  
<td>

Description of the data/ metadata

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

**Category**

</td>  
<td>

FW/SW/ Algorithm/Raw data/ Dissemination material/etc.

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

**Type**

</td>  
<td>

Document/video/images/Source code/etc.

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

**Format**

</td>  
<td>

File extention/ prototype

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

**Size**

</td>  
<td>

size in MB/GB

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

**Owner**

</td>  
<td>

Partner name/ Consortium/ external stakeholder

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

**Privacy level**

</td>  
<td>

Public/ consortium/ partner/etc.

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

**ASPECT**

</th>  
<th>

**CATEGORY**

</th>  
<th>

Explanatory text

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

</td>  
<td>

**Metadata**

</td>  
<td>

Any metadata that are linked to these data and/or describe this data type.

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

</td>  
<td>

**Relevant standards and legislation**

</td>  
<td>

Any standards or laws that need to apply that are relevant to the systems that
produce these data.

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

**DATA**

**SHARING**

</td>  
<td>

**Repository during the project (for private/public access)**

</td>  
<td>

BAL.PM or other Open access repository/ partner storage (private cloud/private
drop box)/etc.

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

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

**Data sharing**

</td>  
<td>

**Open:** Open for public disposal

**Embargo:** It will become public when the embargo period applied by the
publisher is over. In case it is categorized as embargo the end date of the
embargo period must be written in DD/MM/YYYY format.

**Restricted:** Only for project internal use.

Each data set must have its distribution license. Provide information about
personal data and mention if the data is anonymized or not. Tell if the
dataset entails personal data and how this issue is taken into account.

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

**Back-up frequency**

</td>  
<td>

daily/ monthly/ yearly/once

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

**Destroyed at the end of the project?**

</td>  
<td>

NO (1)/No (2)/NO (3)/ Yes / Unnecessary

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

**Duration of preservation (in years)**

</td>  
<td>

number of years

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

**Repository after the project**

**(open/embargo or never open) GDPR compliance**

**(Yes/No/In process)**

**Data role**

</td>  
<td>

BAL.PM or other Open access repository/ partner storage (private cloud/private
drop box), etc.

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

**GDPR**

</td>  
<td>

State if you have completed/initiated a process to be compliant with the new
Directive.

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

Please state if you are a data controller, processor or both within the
framework of the project. For further information about these roles you may
find here: https://www.gdpreu.org/the-regulation/keyconcepts/data-controllers-
and-processors/

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

**ASPECT**

</td>  
<td>

**CATEGORY**

**DPO**

**Publications**

</td>  
<td>

Explanatory text

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

</td>  
<td>

Present/have discussed project with/ not appointed yet

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

**Open**

**publications**

</td>  
<td>

Please add any papers you have already submitted/ presented in open-access
journals and/or ones you are planning to submit by the end of the project. In
addition, please add any publications to journals that are not open, but you
are planning/ or have already paid to make them open.

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

Therefore, any data privacy issues have been covered already in all the
versions of the Data Management Plan reported so far in the project. The
following table presents an overview of the data clusters across UCs based on
the consolidated information that can be found in the aggregated table in
Annex 4.

**Physiological measures** (related mostly to algorithms’
development/refinement): heart rate/variability, eye gaze/blinking, Galvanic
skin response (GSR), blood pressure, etc.

**Vehicle performance/behaviour measures** (related to both algorithms
creation and HMI testing): lateral position, acceleration/deceleration,
braking, steering angle, etc.

**Self-reported/perceived questionnaires/interviews:** relevant to all testing
taking place within the project.

##  4.3 Decision about data openness

Due to the nature of data collected, no datasets will be open to the public,
but findings will be presented in conferences and peer-reviewed journals. This
result is evident by the decision per data type on embargo period, as reported
by the UC leaders in the consolidated data pool (Annex

4).

##  4.4 Open access publications

So far, two open-access publications are available by VTI (they are available
in the Excel spreadsheet in Annex 4). The open access publications will be
made available via the website and potentially Zenodo (https://zenodo.org/) by
the end of the project.

#  5 Conclusions

The final version of the Data Management Plan accommodates for the efforts put
by UC teams and leaders to ensure that GDPR guidelines are implemented and
involved partners are getting familiarized with the process of data privacy
impact assessment.

Overall, identified risks were more relevant to actual testing conduction
(e.g. participant falling from motorcycle) rather than actual privacy leaks or
user profile loss/revealing.

The related mechanisms were in place in dedicated pilot sites and anonymized
files with no recognition potential were shared among partners and only within
the project.

However, setting a data privacy impact assessment methodology early in the
project, facilitates the ‘data privacy by design’ concept actualization very
early in the project and allows for harmonization of activities with less
iterations and changes.

The final testing phase will be conducted after the submission of this
Deliverable and therefore the results of the final round of DPIA per UC will
be reported in the final technical report only if the results are different
from the ones already reported in this document and if changes in the data
privacy policy are necessary as well as if the data collection table
considerably changes.