d.1.1. project management and quality control plandissemination level public number of pages 4 work...

PROJECT Coach assistant via projected and tangible interface GRANT AGREEMENT Nr. 769830

D.1.1. – Project management and quality control plan

SUBMISSION DUE DATE DELIVERABLE VERSION

Month 2, 31.01.2018 #3.0

ACTUAL SUBMISSION DATE

Month 2, 31.01.2018

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 769830

Ref. Ares(2018)591669 - 31/01/2018

CAPTAIN 769830 D.1.1.-Project management and quality control plan

2 | P a g e

DELIVERABLE TITLE Project management and quality control plan

DELIVERABLE No. D.1.1

Deliverable Version #3.0

Deliverable Filename Captain_Deliverable_1.1.Project management and quality control plan v.3.0.doc

Nature Of Deliverable R = Report

Dissemination Level Public

Number Of Pages 44

Work Package WP1. Management

Partner Responsible AUTH

Author(s) Valentina Conotter (SIT), Maria Nikolaidou (AUTH)

Contributor(s) Evdokimos Konstantinidis (Nively)

Editor Name 3 (Partner)

Reviewed by Giuseppe Conti (Nively), Wolfgang Kniejski (INI)

Approved by Panos Bamidis, Project Coordinator

PROJECT FULL TITLE Coach assistant via projected and tangible interface

Type Of Action Research & Innovation Action (RIA)

Topic H2020-SC1-PM-15-2017: Personalised coaching for well-being and care of people as they age

Start Of Project 1 December 2017

Duration 36 months

Project URL www.captain-eu.org


3 | P a g e

Table of Contents

LIST OF ACRONYMS ............................................................................................................................................... 5

LIST OF FIGURES ..................................................................................................................................................... 5

1 EXECUTIVE SUMMARY ................................................................................................................................... 6

2 INTRODUCTION ............................................................................................................................................. 6

3 PROJECT HANDBOOK .................................................................................................................................... 7

3.1 PROJECT WORKPLAN .......................................................................................................................................... 7 3.2 WORK PACKAGES .............................................................................................................................................. 8 3.3 PLANNED MILESTONES ....................................................................................................................................... 9 3.4 PLANNED DELIVERABLES ..................................................................................................................................... 9 3.5 EFFORT PER WORK PACKAGE .............................................................................................................................. 11 3.6 GENERAL PROVISIONS ON ELIGIBILITY OF ACTIVITIES ................................................................................................ 11

3.6.1 Eligible Activities .................................................................................................................................... 11 3.6.2 Eligible Costs .......................................................................................................................................... 11

4 PROJECT MANAGEMENT STRUCTURE .......................................................................................................... 12

4.1 CONSORTIUM ................................................................................................................................................. 12 4.2 ROLES AND ENTITIES ........................................................................................................................................ 14 4.3 STRUCTURE .................................................................................................................................................... 17 4.4 METHODOLOGY .............................................................................................................................................. 18

5 MANAGEMENT AND COMMUNICATION TOOLS .......................................................................................... 18

5.1 PROJECT MANAGEMENT SOFTWARE .................................................................................................................... 19 5.2 ONLINE MEETINGS TOOL ................................................................................................................................... 19 5.3 E-MAIL COMMUNICATION ................................................................................................................................ 19 5.4 PROJECT MEETINGS ......................................................................................................................................... 20

5.4.1 Consortium Plenary Meetings ................................................................................................................ 20 5.4.2 Project Steering Board meetings ........................................................................................................... 20 5.4.3 Project Management Board meetings ................................................................................................... 20 5.4.4 Technical or WP meetings ...................................................................................................................... 20 5.4.5 WP leaders teleconferencing ................................................................................................................. 21 5.4.6 WP teleconferencing .............................................................................................................................. 21

5.5 PROJECT WEBSITE ............................................................................................................................................ 21 5.6 ONLINE FILE SHARING TOOL ............................................................................................................................... 21

6 DOCUMENT MANAGEMENT ........................................................................................................................ 22

6.1 CLASSIFICATION OF DOCUMENTS ........................................................................................................................ 22 6.2 DOCUMENT STANDARDS ................................................................................................................................... 22

6.2.1 Allowed document types ........................................................................................................................ 22 6.2.2 File naming ............................................................................................................................................ 22 6.2.3 Format and style guidelines ................................................................................................................... 22 6.2.4 Compliance with Data Protection Guidelines......................................................................................... 23

6.3 VERSIONING ................................................................................................................................................... 23 6.4 TEMPLATES .................................................................................................................................................... 24 6.5 OTHER DOCUMENTS ........................................................................................................................................ 24

6.5.1 Publications ............................................................................................................................................ 24 6.5.2 Reports and presentation ...................................................................................................................... 25


4 | P a g e

7 PROJECT REPORTING AND FINANCING ........................................................................................................ 25

7.1 GENERAL PROCEDURES AND RULES FOR PROJECT REPORTING .................................................................................... 25 7.1.1 Reporting Periods ................................................................................................................................... 25 7.1.2 Reporting process .................................................................................................................................. 26 7.1.3 Financial Report Template ..................................................................................................................... 27 7.1.4 Effort Report Template .......................................................................................................................... 28 7.1.5 Currency ................................................................................................................................................. 29

8 QUALITY ASSESSMENT ................................................................................................................................ 29

8.1 QUALITY EXPECTATIONS .................................................................................................................................... 29 8.2 QUALITY RESPONSIBILITIES OF CONSORTIUM MEMBERS ..................................................................................... 30 8.3 QUALITY ASSURANCE AND QUALITY CONTROL PROCESS ........................................................................................... 30

8.3.1 Quality assurance for Deliverables ........................................................................................................ 30 8.3.2 Quality control of deliverables ............................................................................................................... 31 8.3.3 Quality control of project management ................................................................................................ 33

8.4 CONTROL OF CHANGES ..................................................................................................................................... 33 8.4.1 Update of user requirements ................................................................................................................. 33 8.4.2 Technical changes .................................................................................................................................. 33

8.5 RISK MANAGEMENT ......................................................................................................................................... 33 8.5.1 Risk identification and analysis .............................................................................................................. 34 8.5.2 Risk monitoring and control ................................................................................................................... 36

9 INTELLECTUAL PROPERTY RIGHT ISSUES ...................................................................................................... 36

9.1 BACKGROUND ................................................................................................................................................. 37 9.2 MONITORING OF USAGE .................................................................................................................................... 42 9.3 TRANSFER OF RESULTS ...................................................................................................................................... 42 9.4 DISSEMINATION OF RESULTS .............................................................................................................................. 42 9.5 JOINT OWNERSHIP ........................................................................................................................................... 43

10 REFERENCES ................................................................................................................................................ 44


5 | P a g e

LIST OF ACRONYMS

Acronym Description

AA Administrative Assistant AB Advisory Board

AB Advisory Board

AUTH Aristotle University of Thessaloniki CA Consortium Agreement CA Consortium Agreement

CO Confidential, only for members of consortium (including the Commission Services)

CSCC CAPTAIN Stakeholders’ community coordinator D Deliverable DoA Description of Action DoA Description of Action EB Ethical Board EC European Community

EU European Union GA Grant Agreement ICT Information and Communications Technology IPA Intellectual Property Agreement IPR Intellectual Properties Right IPR Intellectual Property Right ORDP Open Research Data Pilot P Public PC Project Coordinator PL Pilot Leader PSB Project Steering Board R Report QRM Quality and Risk Manager RTD Research and Technological Development TM Technical Manager

WP Work Package

LIST OF FIGURES

Figure 1 Gantt Chart ...................................................................................................................................... 8 Figure 2 Consortium partners across Europe ............................................................................................. 13 Figure 3 CAPTAIN Management structure .................................................................................................. 18


6 | P a g e

1 EXECUTIVE SUMMARY

The goal of this deliverable is to illustrate the project management framework of the CAPTAIN project along with all project quality control and operational procedures and associated roles required by the different managerial and operational activities planned for the whole project duration. This document is designed as a set of practical guidelines to help clearly define workflows and rules that the partners will have to follow throughout the project’s activities, to ensure the highest quality standards are met and to strengthen project management (e.g., partner responsibilities, quality control mechanisms, documentation control, documentation formats and exchange rules). The document lists the procedures required for a well-organised execution of the project, aiming to maximise cooperation of partners and to clearly define responsibilities among the beneficiaries of the project. Furthermore, the document clearly specifies the quality, administrative and communication procedures to be followed by the partners during the implementation of the project, to ensure full control of its development, from both a financial and a technical standpoint. This report complements the provisions of the Grant Agreement and its annexes as well as the Consortium Agreement, which has been already signed by all the beneficiaries, in that it clearly defines a number of practical guidelines and rules essential for the day-to-day management of the project.

2 INTRODUCTION

The main goal of project management within the CAPTAIN project is to ensure the successful collaboration and involvement of all parties, both within the project, as well as of parties identified as part of the stakeholder ecosystem, so as to develop, evaluate and develop the CAPTAIN platform for exploitation. This implies that partners and central management should be continuously aware of the relationship between their own work and the work done by others. At the same time, the management has to fulfil the administrative requirements deriving from the partners’ contractual relationship with the EC and implement quality control procedures that will ensure excellent outputs of the project activities, thorough quality review of the project deliverables and regular assessment of CAPTAIN progress and achievements. The project’s management structure/procedures and quality control/internal assessment procedures are designed to achieve these goals. Daily project management and administration beyond scientific research generally includes all non – scientific project activities, such as documentation, reporting, financial monitoring, organization of meetings and workshops, set-up of a communication structure, creation and maintenance of the project website, knowledge and IPR management within the consortium etc. The basic idea is to relieve researchers and developers from administrative chores, thereby allowing them to focus more on research and technological development (RTD) activities, resulting in more effective project work. Both scientific and administrative project activities are complementary. They are closely linked and integrated with one another, making project communication essential. On top and complementary to them, quality assurance procedures regularly assess project outcomes and guarantee their excellent quality. The Aristotle University of Thessaloniki (AUTH) has substantial experience in coordinating European RTD and national projects; hence AUTH ensures the ability of the CAPTAIN project to rapidly start-up and maintain professional management of financial and reporting requirements from the European Commission (EC). AUTH brings medical, technological, as well as innovation experience, necessary to manage this project with communication that bridges the domains of health/ageing, on the one hand, as well as information & communications technology (ICT), on the other. Thus, this management and quality assessment plan provides a detailed description of management structures and procedures that guides day-to-day tasks and improves the project’s communication


7 | P a g e

effectiveness. It represents a combination of detailed procedures, templates and interactive elements. It is therefore important that all partners agree to the implementation of this Management and Quality Assessment Plan to ensure its effectiveness. The structure of the present deliverable is as follows: Chapter 3 presents the project handbook, which gathers information on the project workplan, including timelines, lists of work packages, milestones and deliverables, as well as, the general provisions on eligibility of activities including eligibility of costs and financial management. Chapter 4 presents the management structure of CAPTAIN as described in the DoA and specified by partners during the kick-off meeting of the project. In Chapter 5, the management tools, as well as, communication tools are presented, while in Chapter 6, Document management is discussed. General provisions for progress and financial reporting are described in Chapter 7, while Chapters 8 and 9 present the Quality control plan and the main aspects of ownership and intellectual property rights.

3 PROJECT HANDBOOK

3.1 PROJECT WORKPLAN

The overall goal of the CAPTAIN project is to integrate best practices with radically new ICT based approaches in the areas of ambient assistive living for people in need as they age. CAPTAIN proposes new solutions for empowering and motivating people in need of guidance and care due to age-related conditions towards maintaining their independence, functional capacity, health status as well as preserving their physical, cognitive, mental and social well-being. The activities, as detailed in Annex I of the GA, have been scheduled according to the Gantt chart, which is displayed in Error! Reference source not found.Error! Reference source not found.Error! Reference rce not found.Error! Reference source not found. for convenience. Acknowledging the value of co-creation and participatory design, CAPTAIN builds a network of stakeholder (WP2), which follows the project through pilot trials on demand (WP7). Demand comes from the project needs and can be requirement elicitation, initial feedback on interfaces, small-scale pilot to measure usability, etc. The design and development of the prototypes (projection system) (WP3) as well as the algorithms of unobtrusive indoor monitoring (WP4) and guidance (WP5), run on top of the pilots and integrated to one final solution in WP6. The evaluation of the system in many perspectives, such as acceptance, usability, ease of use, usefulness as well as effectiveness are evaluated in WP8 and widely disseminated in WP9.


8 | P a g e

Figure 1 Gantt Chart

3.2 WORK PACKAGES

CAPTAIN is articulated into the following 10 work packages, whose coordinating partners are detailed in the following table.

WP Work Package Title WP leader Start

Month End

month

WP1 Management AUTH 1 36

WP2 Requirements Elicitation and Technical

Specifications AUTH 1 28

WP3 CAPTAIN appliance hardware prototyping and low-

level software infrastructure development NIVELY 3 24

WP4 Non-invasive user and environment sensing NVI 7 30

WP5 CAPTAIN Coach behaviour design and AI algorithms VIC 15 31

WP6 CAPTAIN system integration DIG 12 36

WP7 Pilot Data Collection and Evaluation SIT 1 36

WP8 Assessment and Evaluation DCU 5 36

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

1 Management

1.1 Project coordination and consortium management l l l

1.2 Operational management and quality/risk control

1.3 Financial management and reporting

1.4 Ethical and Security Management l

1.5 Data Management l l l

1.6 Innovation Management l l l

2 Requirements Elicitation and Technical Specifications

2.1

Active stakeholders’ network engaged throughout participatory design

phases

2.2 Agile Requirements Elicitation through user involvement l l

2.3 Software and hardware design l l

2.4 Analysis of pilot-related regulatory requirements l

2.5 Data protection/privacy, liability and consumer protection requirements

3

CAPTAIN appliance hardware prototyping and low level software

infrastructure development

3.1 Hardware Prototyping l l l

3.2

Optimisation of low-level data acquisition pipeline / test data preparation

/ stand-alone testing l

3.3 Data broker extension testing l

4 Non-invasive user and environment sensing

4.1 Human presence recognition algorithm l

4.2 Emotional, behavioural and contextual activity recognition algorithm l

4.3 Indoor location and gait analysis algorithm l

4.4

Physical and Cognitive training/intervention progress monitoring through

serious games metrics analytics l

4.5 Data Analytics and online learning

5 CAPTAIN Coach behaviour design and AI algorithms

5.1

Guidance and follow-up for risk avoidance, preventive measures and

nutrition l

5.2 Guidance and follow-up for physical activity, cognitive training l

5.3 Guidance and follow-up for lifestyle and social participation l

5.4 Motivation engine and personalised advice l

5.5 Projective, tangible and emotional UI interface – The CAPTAIN Coach l

6 CAPTAIN system integration

6.1 CAPTAIN system integration l

6.2 Data protection and access control on the server side/cloud l

6.3 CAPTAIN open API development l

7 Pilot Data Collection and Evaluation

7.1 Multisite Clinical Study Planning and Coordination l

7.2 Pilot deployment l

7.3

Production of experimental datasets to speed up algorithms

developments and evaluation

7.4 Continuous data collection pilots in controlled environments – Living Labs l l

7.5 Pilot data collection in real homes l

8 Assessment and Evaluation

8.1 Establishment of an Assessment Plan l

8.2 Laboratory Technical Assessment l

8.3 User Acceptance Evaluation l

8.4 Analysis of effectiveness of personalized recommendation l

8.5 Economic Impact l

8.6 Overall Assessment of CAPTAIN system l

9 Dissemination, Awareness and Exploitation

9.1 Awareness towards the general public and policy makers l l l

9.2 Awareness towards the industrial community l

9.3 Awareness towards the scientific community

9.4 Liaison with related projects l l

9.5 IPR and licensing agreement

9.6 New service delivery models l

9.7 Market exploitation and business model l l

MS1 MS2 MS3 MS4 MS5 MS6,MS7


9 | P a g e

WP9 Dissemination, Awareness and Exploitation INI 1 36

WP10 Ethics requirements AUTH 1 36

3.3 PLANNED MILESTONES

The following milestones have been identified within the project.

Milestone N° Milestone name WP number Delivery date

MS1 Build the CAPTAIN Stakeholder’s Network WP2 M6

MS2 Hardware Prototype WP3 M16

MS3 First system with basic functionality WP6 M21

MS4 Non-invasive algorithms’ integration WP4 M28

MS5 Coach behaviour and guidance algorithm integration

WP5 M31

MS6 Application for Patent WP9 M35

MS7 Definition of business model and business take-up

WP9 M36

3.4 PLANNED DELIVERABLES

The table below lists all the deliverables planned within each work package.

Deliv. N°

Deliverable name WP N°

Type Diss. level

Delivery Date

D1.1 Project management and quality control plan 1 R PU M2

D1.2 First version of Ethics and Safety Manual 1 R PU M6

D1.3 Project Periodic Report 1 R CO M18

D1.4 Final version of Ethics and Safety Manual 1 R PU M24

D1.5 Data management plan 1 ORDP PU M6

D1.6 Project Final Report 1 R CO M36

D1.7 First version of the Innovation strategy 1 R CO M12

D1.8 Second version of the Innovation strategy 1 R CO M24

D1.9 Final version of the Innovation strategy 1 R CO M36

D1.10 Final data management plan 1 ORDP CO M36

D2.1 First version of user requirements analysis 2 R PU M7

D2.2 First version of system specification 2 R PU M8

D2.3 Summary of Pilot-related regulatory

requirements 2 R PU M15

D2.4 Final version of user requirements analysis 2 R PU M28

D2.5 Final version of system specification 2 R CO M24

D3.1 Hardware prototype Alpha release 3 OTHER PU M16

D3.2 Test dataset 3 OTHER PU M18

D3.3 Finalized HW prototype 3 OTHER PU M24

D3.4 Low-level software components 3 OTHER PU M18

D3.5 Data broker 3 R PU M14

D4.1 Human presence recognition algorithm 4 R CO M28


10 | P a g e

D4.2 Emotional, behavioural and contextual activity

recognition algorithm 4 R CO M28

D4.3 Indoor location and gait analysis algorithm 4 R CO M24

D4.4 Physical and Cognitive serious in-game metrics

analytics 4 R CO M28

D5.1 Risk avoidance, preventive measures and

nutrition guidance 5 R PU M31

D5.2 Physical activity and cognitive training guidance 5 R PU M31

D5.3 Lifestyle and social participation guidance 5 R PU M31

D5.4 Clustering logic and identified profiles 5 R PU M31

D5.5 Per intervention profile multi-factorial guidance

modelling and intervention profiles 5 R PU M31

D5.6 Projective, tangible and emotional UI interface 5 OTHER PU M31

D6.1 CAPTAIN system 6 DEM PU M30

D6.2 CAPTAIN security/privacy report 6 R CO M32

D6.3 CAPTAIN open API 6 R PU M36

D7.1 Clinical Study plan 7 R PU M6

D7.2 Pilot deployment & test plan 7 R PU M12

D7.3 Pilot trials in living labs methodology 7 R PU M8

D7.4 Pilot trials in living labs 7 R PU M30

D7.5 Pilot trials in real homes 7 R PU M35

D8.1 Assessment Plan 8 R PU M10

D8.2 Laboratory Technical Assessment report 8 R PU M24

D8.3 User Acceptance Evaluation Report 8 R PU M36

D8.4 Evaluation of the effectiveness of personalized

recommendation 8 R PU M36

D8.5 Economic Impact Report 8 R PU M34

D8.6 CAPTAIN system assessment report 8 R PU M36

D9.1 Dissemination plan 9 R PU M10

D9.2 Media Pack 9 R PU M1

D9.3 Website and Web Channels 9 R PU M2

D9.4 Project Community Database 9 R PU M36

D9.5 Report on liaison with other projects 9 R PU M36

D9.6 Library of Forms and Tool Kits 9 R PU M30

D9.7 Value-generation chain and service delivery

analysis 9 R CO M18

D9.8 Sustainability Plan 9 R CO M11

D9.9 First version of the Business Plan 9 R CO M24

D9.10 Final version of the Business Plan 9 R CO M36

D10.1 H- Requiremnt No.1 10 Ethics CO M12

D10.2 POPD – Requirement No. 2 10 Ethics CO M12


11 | P a g e

3.5 EFFORT PER WORK PACKAGE

Partner WP1 WP2 WP3 WP4 WP5 WP6 WP7 WP8 WP9 WP10 AUTH 14.5 13 2 17 9 4 18 13 6 0

DigiFlak 3.5 9 0 6 0 11 3 1.5 3 0 DCU 5.5 7 1 2 8 0 5 6 2 0 INI 4.5 7 0 0 0 0 1 9 23 0

Nively 2.5 7 6 14 5 2 10 4 5 0 TRILOGIS 0 0 7 0 0 0 0 0 0 0

NVISO 0.5 2 2 8.5 3.5 2 0 0 2 0 Social IT 7.5 8 0 6 3 0 18 20 9 0 VICOM 0.5 4 7 10 17 8 1 5 1.5 0

SAL 1.5 4 2 3 15 0 4 6 3 0 INTRAS 1.5 5 0 0 4 2 10 10.5 2.5 0

HoloLamp 1 3 14 5 5 4 0 0 2 0 UNITN 1.5 5 0 2 0 0 11 5 1 0 APSS 1 1 0 0 0 0 3 1 1 0

AMEN 2.5 6 0 0 0 0 12 2 2 0

3.6 GENERAL PROVISIONS ON ELIGIBIL ITY OF ACT IVITIES

The Grant Agreement signed by the CAPTAIN consortium (Nr. 769830) specifies the terms and conditions applicable to the grant awarded to beneficiaries. The activities funded are the ones described in Annex 1 (Part A and Part B) of the Grant Agreement

3.6.1 Eligible Activities

The eligible activities of the CAPTAIN project are defined in Annex 1 of the Grant Agreement, and entail all necessary actions by the consortium in order to successfully implement the project. CAPTAIN partners may consult the terms and conditions set out in “Chapter 4 - Rights and Obligations of the parties” of the Grant Agreement, as well as, the Project Handbook within the present deliverable, in order to achieve effective implementation of the project. AUTH, as the Coordinator of CAPTAIN, will be coordinating the activities as planned and will be supporting collaboration and communication of CAPTAIN partners. In any circumstances or events that affect the partnership and the implementation of the CAPTAIN project, an amendment of the Grant Agreement may be requested.

3.6.2 Eligible Costs

The eligible costs of the CAPTAIN project are defined in Annex 2 of the Grant Agreement. There exist 2 types of costs, namely Direct and Indirect costs. Direct costs have 3 possible forms of costs in Captain:

A. Direct personnel Costs.

B. Direct costs of subcontracting.

D. Other direct costs.


12 | P a g e

Indirect costs are calculated on the basis of a flat-rate applied (25%) to direct costs excluding direct costs of subcontracting. The total estimated eligible costs of CAPTAIN are reimbursed in 100% when the action is implemented in accordance with the Grant Agreement, and it cannot exceed the amount specified as “Maximum grant amount” in Annex 2. CAPTAIN consortium partners having signed the Grant Agreement Nr. 769830 have agreed on terms and conditions relevant to the eligible costs. The relevant Articles on the Grant Agreement are Article 4, Article 5 and Article 6. Further explanations can be found in the Annotated Model Grant Agreement (available at http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-amga_en.pdf). The Annotated Model Grant Agreement serves as a user guide that aims to explain terms and conditions by avoiding legal references and technical vocabulary in order to assist beneficiaries to find practical guidelines for the successful implementation of the projects. Further to that, CAPTAIN consortium partners are encouraged to contact the Coordinating institution (AUTH), and request advice and support in questions related to the eligibility of costs. The Coordinator will be seeking the answers within the Annotated Model Grant Agreement and by communicating with the Project Officer appointed by the European Commission. In any circumstances or events that affect the financial management of the CAPTAIN project, an amendment of the Grant Agreement may be requested, if necessary, according to the rules set in Article 4 of the Grant Agreement.

4 PROJECT MANAGEMENT STRUCTURE

4.1 CONSORTIUM

CAPTAIN Consortium consists of 14 partners from 9 countries (Error! Reference source not found.), nvolving parties from academia, research and business communities, funding initiatives as well as living lab and citizen communities. In particular, the partners provide the project with healthcare (AUTH, INTRAS, APSS, AMEN), scientific (AUTH, DCU, SIT, SAL, INTRAS, UNITN), technical (AUTH, DIG, DCU, NIVELY, NVI, SIT, VIC, SAL, HOLO, UNITN), pilot (AUTH, NIVELY, SIT, INTRAS, UNITN, APSS, AMEN), Living Labs methodologies (AUTH, NIVELY INTRAS, UNITN, APSS) and experience.

http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/amga/h2020-amga_en.pdf


13 | P a g e

Figure 2 Consortium partners across Europe

In the following table the list of partners together with the corresponding representative contact detail are listed:

Short Name Organization Coun

try Reference person E-mail

AUTH Aristotelio

Panepistimio Thessalonikis

EL Panagiotis Bamidis [email protected]

DIG Digiflak OU EE Anastasia Kostina [email protected]

DCU Dublin City University

IE Unai Diaz Orueta [email protected]

INI INI-Novation GmbH DE Angela Ivanova angela.ivanova@ini-

novation.com

NIVELY Nively FR Giuseppe Conti [email protected]

NVISO nViso CH Timothy Llewellynn [email protected]

SIT Social IT Software

and Consulting IT Valentina Conotter [email protected]

VICOMTECH

Fundacion centro de

tecnologias de

interaccion visual y

comunicaciones

vicomtech

ES Andoni Beristain [email protected]


14 | P a g e

SALUMEDIA salumedia

tecnologias sl ES Alejandro Rivero

[email protected]

INTRAS Fundacion Intras ES Raquel Losada

Duran [email protected]

HOLOLAMP HoloLamp FR Florence Chican [email protected]

UNITN Università degli Studi

di Trento IT

Giandomenico Nollo

[email protected]

APSS Azienda Provinciale per I Servizi Sanitari

IT Giovanni Guandalini GiovanniMariaAchille.Guandalin

[email protected]

AMEN Stegi Evgirias

Archangelos Michael CY Ersi Papayianni [email protected]

4.2 ROLES AND ENTITIES

Successful collaboration and continuous communication among partners of the project and the parties identified as part of the stakeholder ecosystem, is the key for achieving the project goals. For this reason, specific roles and management entities have been identified:

Project Coordinator (Prof. Panagiotis Bamidis, AUTH)

The role of the Project Coordinator (PC) is to represent the project and the consortium, report to the Commission, monitor overall project performance, administer project resources and promote project visibility. The PC will chair the Project Steering Board meetings and is responsible for the project formal communication with the Commission and other stakeholders. Prof Bamidis brings considerable experience in the dual fields of health and technology and, as such, he has experience of managing multi-partner research projects. Prof. Bamidis has already successfully coordinated 4 large EC-funded projects (Long Lasting Memories, ePBLnet, mEducator and ChildrenHealth). Project Manager (Maria Nikolaidou, AUTH)

The role of the Project Manager (PM) is the overall responsibility for the complete management of the project in close cooperation with the project coordinator and the technical coordinator. The PM will be monitoring the project progress, will prepare and process progress and financial reports, monitor financial reporting by partners, communicate with project officer about relevant aspects of the project, enable daily communication with project partners, contribute in the organization of meetings, conferences and events. Maria Nikolaidou has strong experience in research projects and has been the PM of other large EU projects (ePBLnet, mEducator and ChildrenHealth) coordinated by AUTH. Technical Coordinator (Dr. Evdokimos Konstantinidis, NIVELY)

The role of the Technical Coordinator (TC) is to audit the R&D performance of the project and ensure accomplishment of the technical objectives. The TC is responsible for resolving work implementation problems and dead ends and is also the direct link between the Project Management Board and the people performing the work helping to bridge communications between technical and clinical parties. Dr. Evdokimos Konstantinidis brings extensive experience in EU projects, in particular, large collaborative efforts in ICT. CAPTAIN Stakeholders’ community Coordinator (Dr. Giuseppe Conti, NIVELY)

mailto:[email protected]



15 | P a g e

The role of the CAPTAIN Stakeholders’ community (CSCC) is to synchronise the goals and the objectives of the specific community. The CSCC will also advise the coordination of the Stakeholders’ network built in T2.1 and run throughout the project’s lifecycle. Quality and Risk Manager (Dr. Wolfgang Kniejski, INI)

The Quality and Risk Manager is responsible for enforcing monitoring and assessment of the project’s quality The QRM reports to the PC (Project coordinator). Dr. Wolfgang Kniejski has several years’ experience in management roles within large EC-funded projects. Work Package Leaders (WPL)

The WP Leader is responsible for the coordination of the activities of all partners involved in a WP. The WP Leader shall arrange for the timely execution and submission of deliverables to assure the attainment of the goals of each task and will keep the PC informed of the development and progress status on a regular basis. The WP Leader is the interface between the partner of the specific WP and the PC. WP Leaders will provide internal reports to the PC when requested, control the quality and the schedule of the work and actively participate in meetings. Moreover, WP leaders will maintain an archive of the results obtained within their work packages (both intermediate and final). This archive will include all working drafts (latest version), the work package deliverables, and minutes of the work package meetings. For the efficient management of the activities in each WP, the WP Leaders will communicate with the WP partners at a regular basis through emails, phone calls, teleconferences and organise WP meetings when needed (see Section 5.4.6). WP Leaders in CAPTAIN are:

WP WP leader name Organization E-mail

WP1 Maria Nikolaidou AUTH [email protected]

WP2 Panagiotis Bamidis AUTH [email protected]

WP3 Giuseppe Conti NIVELY [email protected]

WP4 Lorenzo Keller NVI [email protected]

WP5 Gorka Epelde VIC [email protected]

WP6 Maxim Kostin DIG [email protected]

WP7 Valentina Conotter SIT [email protected]

WP8 Louise Hopper DCU [email protected]

WP9 Wolfgang Kniejski INI [email protected]

WP10 Antonis Billis AUTH [email protected]

Pilot Leaders (PL)

The PL is responsible for the daily management of the various pilots. Each Living Lab pilot partner (AUTH, INTRAS, NIVELY and APSS) that does not have technical capacity is supported by a technical partner within the same geographical region, to allow for very close cooperation.

Pilot Leaders

To be defined when relevant WPs will start

Project Management Boards (PMB)

Together the Project, Technical, Pilot, Quality-Risk and CAPTAIN Community Coordinators, make up the Project Management Board (PMB) to manage and guide the CAPTAIN project. The PMB has responsibility


16 | P a g e

for monitoring the overall pilot and technical progress and direction of the project. It is also responsible for the resources used, the costs incurred as well as risk evaluation. Ethical issues and relevant assessment will be assigned by the PMB to the Ethical Board (EB) which will report back with relevant recommendations.

Project Management Board

Project Coordinator (Panagiotis Bamidis)

Technical Coordinator (Evdokimos Konstantinidis)

Community Coordinator (Giuseppe Conti)

Pilot Coordinator (TBD)

Quality & Risk Manager (Wolfgang Kniejski)

Project Steering Board (PSB)

The PSB is made up of the PC, TC, CSCC, QRM, work package leaders and the representative from each consortium member. The PSB is responsible for holistic decision making within the project and ensuring the overall aims and objectives of CAPTAIN are achieved.

Project Steering Board

Project Coordinator (Panagiotis Bamidis)

Technical Coordinator (Evdokimos Konstantinidis)

Community Coordinator (Giuseppe Conti)

Pilot Coordinator (TBD)

Quality & Risk Manager (Wolfgang Kniejski)

WP1 Leader (Maria Nikolaidou)

WP2 Leader (Panos Bamidis)

WP3 Leader (Giuseppe Conti)

WP4 Leader (Lorenzo Keller)

WP5 Leader (Gorka Epelde)

WP6 Leader (Maxim Kostin)

WP7 Leader (Valentina Connotter)

WP8 Leader (Louise Hopper)

WP9 Leader (Wolfgang Kniejski)

WP10 Leader (Antonis Mpillis)

AUTH representative (Panos Bamidis)

DiG representative (Anastasia Kostina)

DCU representative (Unai Diaz)

INI representative (Angela Ivanova)

NIVELY representative (Giuseppe Conti)

NVISO representative (Tim Llewellynn)

SIT representative (Maurizio Gianordoli)

VICOM representative (Andoni Beristain)

SAL representative (Alejandro Rivero)

INTRAS representative (Raquel Losada Durán)

HOL representative (Florence Chican)

UNITN representative (Giandomenico Nollo)


17 | P a g e

APSS representative (Giovanni Guandalini)

AMEN representative (Ersi Papayianni)

Advisory Board (AB)

The AB is composed of members, outside the project, being senior researchers, entrepreneurs and decision makers with a high reputation in the project domain. The AB will be informed on the project results and progress at regular intervals by peer review of selected deliverables. It will meet twice during the course of the project duration to provide suggestions with respect to the project strategic orientations, project research challenges, business and exploitation direction and project support of user needs. The AB members will sign appropriate confidential agreement prior to any disclosure of confidential information. During the kick-off meeting the composition of the AB has been discussed, based on suggestions by all the partners (e.g., prof. Tuija Hannele Hirvikoski from Laurea University of Applied Sciences). Advisory Board members will be defined in the process of the project, based on the steps: Suggestion, Pre-approval, Confidentiality Agreement signature, Final Approval.

Ethical Board (EB)

An Ethical Board (EB) in the form of a group of experts from within and without the consortium with multidisciplinary competences (ethics, privacy, security, finance, etc.) that will be called upon whenever a relevant issue rises. They will report to the PMB with a recommended plan of action.

Ethical Board

Panagiotis Bamidis

Maxim Kostin

Unai Diaz

TBD (Pilot Leader)

Discussion is open for additional Ethical Board members’ appointment.

4.3 STRUCTURE

Figure 3 depicts the management structure and main communication channels for CAPTAIN. Decision-making process is articulated at three different levels:

Strategic Level: At this level decisions will be taken by the PSB based on requests by one of the beneficiaries or the PC. PSB meetings will be called upon with at least 15 days of advance notice and may be held online to minimize travel costs. Ordinary meetings will occur in the context of project meetings.

Management Level: Decisions on activities to be carried across different WPs will be discussed during technical meetings which will be called with at least 5 days of advance notice and may be held online. Ordinary meetings will be held in the context of project meetings.

Operational Level: These decisions will not require official meetings and will be taken by internal working groups under coordination of the respective task leaders. The other partners will be informed via emails or during project meetings. Regarding conflict resolution, the PC will try to minimize conflict, and should it arise, act to minimize its effect through arbitration with the involved partners. In extreme circumstances, a meeting with involved parties shall be called. Should the issue remain unsolved, the PSB will be called upon to resolve it. As a last resort, in case


18 | P a g e

of extreme issues, the PSB may resort to informing the Project Officer. In case of personnel changes, new members for the above roles will be elected by the PSB.

Figure 3 CAPTAIN Management structure

4.4 METHODOLOGY

The communication management of the CAPTAIN (extending though all the WPs), adopts the SCRUM methodology which is the most widely practiced Agile process. The main points of Scrum are that it optimizes resources and creates efficiencies by empowering teams to self-organize and work at a sustainable pace. The Scrum methodology relies on 3 principles:

• Divide and Conquer: Similar to the work description described in the Grant Agreement, Scrum divides complex work into simple pieces, large groups (consortium) into small teams (WP contributors) and far-reaching projects into a series of short time horizons called sprints.

• Inspect and Adapt: When work is divided into simple pieces it can be finished in a shorter period of time. By accelerating the development process and getting a functioning product in the hands of people who will use it, the team can gather feedback more quickly than it otherwise would have.

• Transparency: Scrum makes all work transparent. There are no secrets about what needs to be done, who is doing it, and how it is being accomplished. It is easier for WP leaders and task leaders to make more informed strategic decisions when they have an honest and clear idea of how a project is progressing.

To achieve transparency, CAPTAIN uses a number of shared tools to track activity over the length of the sprint. This makes it easy for everyone to know how things are moving along. Is the team on track to finish all the work? Where is work held up and why? CAPTAIN also employs a series of meetings to increase transparency. These meetings happen in regular intervals and are designed to facilitate team communication. Shared tools make the status of any particular activity visible and meetings give the team qualitative context about how an item or activity is being accomplished.

5 MANAGEMENT AND COMMUNICATION TOOLS

Generally, the channels of communication within a European project are three – directional: (i) from the top down, (ii) from the bottom up and (iii) horizontal. The EC communicates from the top down to the


19 | P a g e

Consortium, partners communicate from the bottom up to their respective WP leaders (and vice versa) and all partners communicate horizontally, across all levels. Within the project, the structure itself generally defines the lines of communication, determining the direction in which information flows. These communication channels should be clearly defined to ensure accuracy and effectiveness, so that all partners are aware of whom they must contact, when this must take place and in what manner. Regarding communication hierarchy between management entities, the following general guidelines are introduced:

Individual project partners report to their WP Leader and/or Task Leader.

Task Leaders are responsible for the scientific management of their Tasks within the WP and

report to the WP Leader.

WP Leaders are responsible for the scientific management of their WPs and report to the PC.

The PC reports to the PSB, which supports him in conflicts resolution and major technical decision-

making. The tools that CAPTAIN partners will be using for effective project management are presented in the following sections.

5.1 PROJECT MANAGEMENT SOFTWARE

Project Management Software refers to applications that are designed to facilitate project delivery and make it more efficient. Following a discussion during the kick-off meeting, a number of available platforms were suggested and discussed, without any strong preference or objection on the exact platform that shall be used. Therefore, it has been decided by the Coordinating institution to install an Open Source Project Management tool, which can assist in project monitoring, in setting milestones and deadlines, tie up and automate interdependent assignments, and enable the consortium daily operations. The software selected is Open Project (https://www.openproject.org) as it can be hosted by the Coordinating institution (AUTH) free of charge, as it is an open source software with several features such as: Project planning and scheduling, Project roadmap, Task management, Team collaboration, Time tracking.

5.2 ONLINE MEETINGS TOOL

Teleconferencing (audio- or video-based) will be used for organising virtual meetings. For this reason, the Skype software may be used for meetings with only a few participants, while wider project online meetings will be taking place using the GoToMeeting (https://www.gotomeeting.com/) software set up by the Coordinating institution.

5.3 E-MAIL COMMUNICATION

Mailing lists are set up as an alternative way of communication within the project. In order to prevent redundant and excessive communication, partners should choose the most appropriate communication channel, i.e., the Open Project software.

The CAPTAIN mailing lists are the following:

Mailing List Description

[email protected] This list includes all partners and persons involved in the project. This

mailing list is to be used with moderation only for communication of general level which need to be addressed by the whole consortium.

https://www.openproject.org/

https://www.gotomeeting.com/



20 | P a g e

[email protected] This list includes the members involved in the technical development of the CAPTAIN framework.

[email protected] This list includes the members involved in the activities related to the pilot sites (pilots and supporting partners).

5.4 PROJECT MEETINGS

Project meetings are important for effective communication among partners and for achieving all the project’s objectives. Throughout CAPTAIN, project duration a series of plenary Consortium meetings, technical meetings and online regular teleconferences will be organised. The types of meetings and their short descriptions are presented in the sections below.

5.4.1 Consortium Plenary Meetings

The main communication and collaboration opportunity in CAPTAIN is the Consortium Plenary Meetings. They will be conducted on a regular basis, and all partners must be represented, as this is a contractual obligation. Plenary meetings will be hosted, in turn, by the participating institutions. Also, they may appoint a substitute or a proxy to attend and vote if needed. Consortium meetings will serve to present the current work in progress, the work to be done, schedule next actions, present technical issues to be dealt with, and find solutions, as well as to promote collaboration between partners, deal with integration issues and update the project vision. Consortium meetings may also be held by teleconference or other telecommunication means. The Advisory Board members shall be allowed to participate in Consortium meetings upon invitation but shall not have any voting rights.

5.4.2 Project Steering Board meetings

The Project Steering Board (PSB) is composed by the PC, TC, CSCC, QRM, work package leaders and the representative from each consortium member. The PSB is responsible for holistic decision making within the project and for ensuring the overall aims and objectives of CAPTAIN are achieved. Opportunities or occasions for PSB meetings shall be selected in accordance with the provisions set in the CAPTAIN consortium agreement. Project Steering Board meetings may be co-hosted with Consortium Plenary Meetings, but they may also be held by teleconference or other telecommunication means.

5.4.3 Project Management Board meetings

The Project Management Board (PMB) is composed by the Project, Technical, Pilot, Quality-Risk and CAPTAIN Community Coordinators to manage and guide the CAPTAIN project. The PMB has responsibility for monitoring the overall pilot and technical progress and direction of the project. It is also responsible for the resources used, the costs incurred as well as risk evaluation. The Project Management Board will run monthly consortium meetings which may be co-hosted with Consortium Plenary Meetings, or they may be held by teleconference or other telecommunication means.

5.4.4 Technical or WP meetings

Apart from Plenary Meetings, partners may decide to organize and hold face-to-face meetings focused on the works of a specific Work Package, or a selection of tasks (either scientific, or technical or other) to




21 | P a g e

enable successful collaboration and communication between partners and speed up the development and integration processes. In any such event, the Consortium as a whole should be informed, and either the Project Coordinator, or Project Manager or Technical Coordinator should try to attend in order to ensure effective coordination with other partners and tasks.

5.4.5 WP leaders teleconferencing

CAPTAIN introduces the “Stand-Up meetings” that will take place online (teleconferences) and be run every 2 weeks. These are quick update meetings which are not expected to last more than 15 minutes. All partners are encouraged to join, however, only the WP leaders will be updating on the progress of each WP. An online document split into WPs and Tasks, will be used to report updates and facilitate the Stand-Up meetings. The online shared documents will be considered as the minutes of the meeting.

5.4.6 WP teleconferencing

The WP leaders are encouraged to adopt Stand-Up meetings for their respective Work Packages task coordination. In this case, online documents, split in Tasks and sub-tasks (if required), shall be produced and used. The online-shared documents will be considered as the minutes of the meeting.

5.5 PROJECT WEBSITE

The website of the project should be informative, user-friendly and accessible and should engage simple language without technical and highly sophisticated terms. The same principles apply for the project brochure, press kit and videos as presented in D.9.2. All the important information will be made available through the project web site (www.captain-eu.org), including:

Project background.

Objectives.

Expected outcomes and target groups.

List of beneficiaries.

Public documents, including deliverables.

News regarding the project and events organised by the consortium.

Other information of relevance to the consortium.

5.6 ONLINE FILE SHARING TOOL

A Google Shared Folder in Google Drive has been set up at the very beginning of the project, to store all project documents, multimedia, data and software, as well as internal discussion papers and other documents which may or may not directly contribute to formal deliverables. The Google Drive Shared Repository may be used in addition to Document Management of Open Project, as it enables live editing by multiple users. Final documents shall be stored in OpenProject for effective tracking of project resources. The General Data Protection Regulation (GDPR) of the European Parliament will come into force in May 2018. If Google Drive fails to comply with the terms that will strengthen Data protection for individuals, the CAPTAIN management team may suggest an alternative tool.

http://www.captain-eu.org/


22 | P a g e

6 DOCUMENT MANAGEMENT

6.1 CLASSIFICATION OF DOCUMENTS

Deliverables (which include documents), must always be classified in the following dissemination level categories, using one of the following codes, as stated in the GA:

PU: Public.

CO: Confidential, only for members of the Consortium (including the EC Services).

EU-RES: Classified information: RESTRAINT UE (EC decision 2005/444/EC).

EU-CON: Classified information: CONFIDENTIAL UE (EC decision 2005/444/EC).

EU-SEC: Classified information: SECRET UE (EC decision 2005/444/EC). The CAPTAIN project will involve no activities or results raising security issues and no ‘EU-classified’ information as background or results. Therefore, all deliverables of the project will be either PU or CO, as seen in Annex I of the GA.

6.2 DOCUMENT STANDARDS

6.2.1 Allowed document types

Working documents intended for subsequent modification by partners should be produced using Microsoft Office (preferably version 2007 or later). Final versions of documents (e.g., internal and public deliverables) should be published as .PDF documents (compatible with Adobe Acrobat 7.0 or later). All other (graphics, audio and video) files should be based on recognized standards: .JPG, .PNG, .GIF, .TIFF, .PPT etc.

6.2.2 File naming

All documents will be named and identified by a standard format consisting of a series of codes as follows: "CAPTAIN_ FreeText_v(version number).ext" The codes are defined as follows:

CAPTAIN is a mandatory label;

FreeText is a short description of the document. For deliverables or reports this should be the name of the deliverable or report (or shorter description if this is too long). Papers for conferences

should be named according to the conference.

Version is a sequential version number for the document. .ext is the document’s extension, e.g. “.docx” for Microsoft Word and “.pptx” for Microsoft

PowerPoint. For example, the third version of the deliverable D1.1 created by AUTH would be

called: "CAPTAIN_D1.1_FULL_TITLE_v3.docx"

6.2.3 Format and style guidelines

Each document should include the following sections:

A document-specific cover page: this shall include the title of the document, the main author(s),

dates of interest and the version of the document.

A following page with, amongst others, details on the Project ID, the dissemination level of the document, all contributing authors and an abstract- keywords section (in case the document is a deliverable - report).


23 | P a g e

The Table of Contents (ToC).

Abbreviations List (where applicable).

An Executive summary.

The Main body of the text: All sections of the main body of the text should be clearly defined. Section headings, titles and subtitles should be used to structure the document and help the reader maintain an overview of what is being addressed and at what level of detail. Used in conjunction with the ToC, relevant sections can easily be identified for ease of browsing. Figures, tables and graphs contained in the body of the document should be properly explained and their relevance clearly demonstrated. Discussion documents that are not fully formatted should at least

clearly distinguish between main sections, titles and running text.

References and (where applicable) Annexes - Appendices.

Styles and colour schemes provided in the document templates should be followed. Documents that are deliverables (reports), should be named accordingly, with additional numbers for version updates and standard suffixes to indicate the format of the document, as stated in Section 6.3 below. The final version of the document should be made available as a .PDF document. For intermediate versions of the document, Microsoft Word (or Microsoft PowerPoint) files shall be provided, since these are much easier to annotate. Furthermore, under 29.4 of the GA, any dissemination of results (in any form) must display the EU emblem. When displayed together with another logo, the EU emblem must have appropriate prominence. Apart from the emblem, the following text should be included: "This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 690494". For draft versions of a document prepared by authors of different sites, it is advisable to include authors’ names for each section, as an annotation, to facilitate communication between interested parties.

6.2.4 Compliance with Data Protection Guidelines

The Final Deliverables which are specified as “PU: Public” will be uploaded on the Project Website following a data protection quality check and adequate editing of the document. This revision or editing of the document will allow the consortium to fulfil the requirements or comply with regulations set by the EU data protection law, such as the General Data Protection Regulation (Regulation (EU) 2016/679) which is expected to come into force in May 2018.

6.3 VERSIONING

The development of a document is supervised by the person responsible for the deliverable [member of the Lead Beneficiary as in the Description of Action (DoA)], who will be responsible for assigning subsections to other contributors, for providing clear instructions and defining deadlines, for integrating sections into the main document and for maintaining the appropriate version control. When elaborating a document, three types of intermediate versions of this document may be produced:

Working/discussion document setting out main headlines and some elaboration on specific topics.

Full draft with all the sections nearly complete. Ready-for-review version provided to the internal reviewers for major/minor comments and

changes.


24 | P a g e

Pre-final version available only for minor changes and to be circulated among the CAPTAIN

partners and provided to the PC for final approval, before submitting the document as a deliverable to the EC.

Each of these versions may require more than one round of feedback before the final version is achieved. To communicate and log detailed changes in the document, the Microsoft Word Revision Mode – recording and tracking all changes – should be switched on when modifying the document. The amended version should be uploaded onto the file repository with appropriate naming. These changes will be integrated into the current version by the person responsible for the deliverable. The numbering of versions shall be made as follows:

Version 0.00 to 0.XX for draft versions of working documents Version 1.00 for the version submitted for internal review Version 2.00 for the version submitted following reviews and relevant revisions Version 3.00 for the version uploaded to the European Commission portal Version “3.00_Open” for the version uploaded to the CAPTAIN website taking into account Data

Protection Regulation

6.4 TEMPLATES

The following templates for CAPTAIN project documents have been created and made available to the partners:

Deliverable template

Deliverable review report template

Presentation template

Financial Report template

6.5 OTHER DOCUMENTS

Throughout the course of the CAPTAIN project, a variety of reports and presentations will be produced. These documents should respect the guidelines outlined below.

6.5.1 Publications

Publications are documents that describe technologies or algorithms developed within the project. These documents can be: scientific articles, papers, book chapters, books, posters or slide presentations/talks in conferences, Ph.D. thesis and similar documents, public reports, press releases, news articles. Submission of papers for publications at conferences, journals or media should have the consent of CAPTAIN Consortium as a whole. For this reason, intention to submit a publication should be communicated to the consortium at the earliest possible date. The procedure outlined below is intended to verify that no paper is submitted without consortium knowledge, that the project is not misrepresented and that no confidential material is inadvertently made public. This could become critic, and eventually generate damage, in case of one or more partners willing to patent information that is then disclosed. More specifically:

Partners must inform the Coordinator and the WP9 Leader of planned dissemination activities

within the project context at least 30 days before the date of publication according to the CA.

Essential information with regard to the publication, such as title, name(s) of author(s), short summary, release date, where to be published and name of contact person should be provided.


25 | P a g e

A copy of the publication should be uploaded to the Open Project CAPTAIN document section before submission for comments by partners. Information about the title, authors, conference/journal/media to be published, expected date of submission/publication, contact person and deadline for comments should be provided.

Partners should also provide the PC with a copy of the publication, for project documentation and dissemination via the project website.

Partners who want to use other partners’ knowledge, pre-existing know-how etc., in own publications have to officially request consent to such publications by the corresponding partner.

No strict procedures can be defined for authorship. It is the responsibility of all partners to respect standard collegial practices when deciding on number and order of authors. When presenting global project results, input from all relevant sites should be acknowledged. In case of conflict or suspicion of abuse, the matter should be brought to the attention of the PC and the PSB. Any use of the EU emblem within publications must follow the official guidelines as described in D.9.2. These guidelines include instructions regarding the obligation prescribed by the contract to publicly acknowledge the support received from the European Union. Additional information can be found in the official website of the European Commission as “Guidelines on Open Access to Scientific Publications and Research Data in Horizon 2020”.

6.5.2 Reports and presentation

Each partner is free to produce reports and give presentations on their work throughout the CAPTAIN project. The funding sources and acknowledgement of the Project should be included. The reports and presentations should be made available to partners upon request.

7 PROJECT REPORTING AND FINANCING

7.1 GENERAL PROCEDURES AND RULES FOR PROJECT REPORTING

As specified in the CAPTAIN Grant Agreement, the Coordinator must submit to the Commission technical and financial reports.

7.1.1 Reporting Periods

The official reporting periods of CAPTAIN projects are the following: Reporting Period 1: from month 1 to month 18, i.e. from December 2017 to May 2019 Reporting Period 2: from month 19 to month 36, i.e. from June 2019 to November 2020 The periodic reports include:

A Technical report (in 2 parts, one in a structured form from the grant management system and the second in a free text form describing the progress towards the project objectives)

A Financial report consisting of individual partner financial statements, an explanation of the use of resources and a periodic summary financial statement including the request for interim payment.

Official reports will be submitted by beneficiaries into the Participant Portal of the European Commission.


26 | P a g e

7.1.2 Reporting process

The reporting procedure consists of several steps that have been defined: Partners (beneficiaries) must write and submit six-month reports. These need to include periodic

report contributions concerning their institution dissemination and exploitation activities (carried out within the respective reporting period) and administrative aspects. Finally, they should keep a record of Time Sheets of their team members.

WP Leaders must submit a description of the work progress carried out in their WP to be used for the Periodic Progress Reports. WP Leaders are responsible for gathering the necessary information, i.e., scientific contributions from partners themselves. WP Leaders should therefore ensure and support a well-functioning communication structure within their working group.

The Coordinating institution is responsible for the compilation of the various contributions into a central document, which will be submitted to the European Commission.


27 | P a g e

7.1.3 Financial Report Template


28 | P a g e

7.1.4 Effort Report Template


29 | P a g e

7.1.5 Currency

Financial statements must be drafted in euro. Beneficiaries and linked third parties with accounting established in a currency other than the euro must convert the costs recorded in their accounts into euro, at the average of the daily exchange rates published in the C series of the Official Journal of the European Union, calculated over the corresponding reporting period. If no daily euro exchange rate is published in the Official Journal of the European Union for the currency in question, they must be converted at the average of the monthly accounting rates published on the Commission’s website, calculated over the corresponding reporting period.

8 QUALITY ASSESSMENT

In this Section, the Quality Assessment Plan (QAP) of the CAPTAIN project is presented. The aim of the QAP is to provide a set of requirements and standards, as well as to specify control procedures and actions that will assure the high quality of project deliverables and project management. More specifically, the quality expectations for project deliverables, the responsibilities of project partner, quality control procedures to ensure their implementation and the strategy to deal with possible risks are defined.

8.1 QUALITY EXPECTATIONS

First, the expectations regarding the quality of the project deliverables, as well as the expectations concerning the project management are presented. In general, the quality of a given deliverable can be recognized by the presence of: efficiency, feasibility and sustainability. CAPTAIN deliverables can be classified in the following three categories:

Documents/Reports (R): Documents should follow a consistent format; thus, a set of document templates has been generated and will be used throughout the project.

Demonstrator, pilot, prototypes (DEM): These deliverables include software and hardware components that should comply with user requirements, in terms of functionality, performance and stability, defined in detail in deliverables D2.1 and D2.4 “First" and "Final version of user requirements analysis”. Moreover, they should follow the specifications defined in detail in deliverables D2.2 and D2.5 “First" and "Final version of system specification”. Furthermore, software components should allow for extensibility and reusability to simplify the process of adding new features or adjusting functionality. Another key aspect of the software quality is proper documentation, which includes English documentation in the source code to support the developers, as well as detailed user manuals to guide the end- users. Regarding hardware components, they should be easy to setup and control.

In total, as listed in Section 0 there are 50 deliverables in the CAPTAIN project (44 of them of type "R", 1 of type "DEM" and 5 of type "OTHER"). The common quality expectation of all deliverables is their on-time delivery according to the project work plan.

Project management is effective when it assures that the project progress follows the work plan agreed. For this to happen, project progresses –both technical and financial- need to frequently be documented and there must be no delay in the communication with the EC or in the resolution of plausible technical and financial issues. In order to ensure this, Gantt charts, based on the deliverables list (Annex I of the GA) will be produced and periodic project management meetings may be held if needed (preferably as side-


30 | P a g e

meetings during technical meetings to reduce travel costs). The minutes of these meetings will be recorded and distributed among partners.

8.2 QUALITY RESPONSIBIL ITIES OF CONSORTIUM MEMBERS

The PC has a plethora of responsibilities, which are vital for ensuring the proper quality of the project, either by facilitating communication among partners and ensuring their up-to-date information, or by guaranteeing the proper quality of documents. In particular, the PC is responsible for:

Monitoring compliance of partners to their obligations. Submitting the other partners’ project deliverables and all other documents required by the GA

to the EU in time, in case one or more partners are late in submitting them.

Keeping the address list of members and other contact persons updated and available.

Transmitting documents and information related to the project to any other party concerned. Providing, upon request, partners with official copies or originals of documents, which are in the

sole possession of the PC when such copies or originals are necessary for partners to present claims.

Collecting, reviewing (to verify consistency) and submitting reports, other deliverables (including financial statements and related certifications) and specific requested documents to the EU.

Moreover, under article 17.2 of the GA, each partner must immediately inform the PC, who, in turn, must immediately inform the EC and other partners in case of events which are likely to significantly affect or delay the implementation of the project, such as changes in its legal, financial, technical, and organisational or ownership situation.

8.3 QUALITY ASSURANCE AND QUALITY CONTROL PROCESS

In this Section, the quality assurance and quality control processes to be followed are described, so that the quality expectations presented in Section 8.1 are realized.

8.3.1 Quality assurance for Deliverables

The quality of deliverables is assured by providing templates and guidelines to the individuals working on different parts of the project. Documents

Standard templates shall be used for project documents (deliverables, reports, presentations, minutes, etc.). These templates can be found in Open Project, as well as in the Online (Google Drive) repository. All documents to be sent to the EC or released to the public shall be generated using these templates. Software components:

In order to ensure quality of software components, careful consideration shall be taken within CAPTAIN so as to meet the following demands:

Compliance of software components with the user requirements and

Usability of the developed software. First of all, identification of user requirements, through questionnaires and surveys, shall happen within WP2, by a direct involvement of clinical, technical, and end-user partners. These requirements shall include, among many others, the need for data safety and privacy. Thus, within WP1 (Task 1.4 and T1.5)


31 | P a g e

and WP2 (Task 2.4 and T2.5), the Data Management Infrastructure should take into consideration the latest data safety and privacy. Furthermore, within WP3-4-5-6, for the development of the CAPTAIN framework, the identified user requirements shall be used as major guidelines. Within WP8, which involves the overall assessment and evaluation of the CAPTAIN ecosystem, user acceptance criteria (usability, privacy) will be evaluated ensuring, in this way, compliance of software components with the user requirements. Moreover, within WP7, a Pilot Data Collection phase will take place, based on an Agile methodology in order to confirm that the data capturing modules work properly, performance (e.g., battery usage) is satisfactory and communication with the Cloud-based storage is reliable. Regarding the usability of the developed software, CAPTAIN goes beyond usual participatory design and requirement elicitation techniques by applying agile requirements elicitation and development methodologies through participatory design throughout the lifecycle process of the development. For this, CAPTAIN builds a network of active stakeholders (Τ2.1) (relying on the participants who already trust the partners’ living labs) which will support the participatory design through continuous small-scale data collection pilots (Τ7.4, T7.5) during the requirements elicitation, design and development processes. The network’s participants will commit to participation in small scale pilots (T7.4-T7.5) lasting from 1-shot trials to daily visits to the pilot sites for a couple of weeks when this is needed. Their main tasks will be to interact with the new versions of the CAPTAIN system, give their feedback, follow any evaluation protocols defined in T8.1-T8.4 and suggest changes or features. It will not be mandatory that all of them participate each time and thus the network should be large enough to provide valuable feedback and at the same time small enough to be easily controlled (~15 people). CAPTAIN will try to model this process, evaluate it and publish the recommendations and implications of this methodology. Hardware components

CAPTAIN will be divided into several sensors/pico projectors systems, each calibrated in order to integrate a dedicated functionality like 3D perspective or touch. The system will be designed to be modular and adaptable to different requirements. Thus, each part of the system will be specified with a detailed description of the functionalities that can be offered. A particular focus will be addressed to the calibration required between the different sensors (cameras, projectors, microphones, etc.) so that the overall CAPTAIN system reacts consistently. The communication protocol between each sensor, the formats used and the use of cloud services as FIWARE and universAAL frameworks will be included. For an overview of the existing Technology Readiness Level (TRL) of the main technologies used in the CAPTAIN, see Table 3 in the DoA.

8.3.2 Quality control of deliverables

In order to ensure the timely production and the quality of the deliverables, all deliverables will be internally reviewed. Some of them may be reviewed externally as well. The following process will apply:

Partners responsible for each deliverable are already defined in the DoA document of CAPTAIN project. A person responsible for the deliverable (DR) is designated by the partner.

Initially, the DR will define the potential contributors (with the help of the WP Leader and partners, if needed). Then, the DR and the contributors will agree upon the Table of Contents (ToC), as well as agree upon the sub-tasks each contributor will take care of. The DR and the contributors will also agree upon a provisional calendar. Both the ToC and the provisional calendar should be communicated to the PC at least 6 weeks before the deliverable deadline.

Internal Reviewers (two per deliverable) have already been assigned for all deliverables taking into account their expertise. For some strategic deliverables, the decision to submit to external


32 | P a g e

reviewers (chosen outside the project) can be taken by the PC in collaboration with DR and WP Leader. If requested even by one contributor, a Non-Disclosure Agreement (NDA) will be signed.

The contributions will be made by contributors (deadlines being under the responsibility of DR and contributors) with respect to the provisional calendar. The integration of the contributions is made under the responsibility of the DR.

When the deliverable reaches a ready-for-review version (at least three weeks before the submission deadline) it will be sent to the internal reviewers by the DR.

The internal reviewers must reply with detailed comments within one week. The reviews are sent to the DR and the PC.

The PC checks the reviews and decides whether there are major issues or not. If there are major issues, the PC together with the WP Leader and the DR, decide which corrective actions should be followed to deal with the problems. In case of disagreement, the final decision is made by the PSB.

The DR is responsible for integrating the requested remarks/revisions into an updated version together with a note/email stating how the reviewers’ comments or PC’s suggestions were addressed (at least one week before the deadline).

The DR distributes the revised deliverable to the reviewers, to be approved within two days.

The reviewers inform the DR whether the deliverable is accepted or there are still problems. In the latter case, the above procedure is repeated.

The final version is submitted for approval to the PC. Potential objections should be raised within 5 days.

The PC is responsible for submitting the Deliverable to the EC (sending the electronic version to the EC Project Officer and uploading the final version to the File Repository).

The whole procedure has to be implemented taking into account strict deadlines for each step. These are agreed early on and published for each sub-task in the Open Project platform.

The EC shall also audit and assess deliverables (under Article 22.1 of the GA). Specifically, the deliverable submission procedure is defined as follows:

Deliverable submission procedure

Deadline 30th of the month

Table of contents 1.5 month prior to final submission

First submission 15th of the month

Review 15thto 22nd of the month

Second submission 27th of the month

Review Until the 30th of the month

Final submission 30th of the month

Documents

Documents should be checked for style, completeness, presentation and accomplishment of deliverable objectives as described in Part A of the DoA. Documents should also be checked for technically valid,


33 | P a g e

sound and novel contribution (when applicable), completeness of results, and comparison with existing works, etc. Software components:

The software components are tested and evaluated so as to make sure that user requirements are met. In particular, within WP7, users will be engaged for the evaluation of the behaviour and quality of the system based on the agile methodology.

8.3.3 Quality control of project management

The control of project management shall be implemented by AUTH central administrative, legal and financial departments, which have long and significant expertise in EU project participation and coordination activities. AUTH ensures the ability of the CAPTAIN project to rapidly start-up and maintain professional management of EU financial and reporting requirements.

8.4 CONTROL OF CHANGES

Throughout the CAPTAIN project, careful consideration shall be given regarding the update of user requirements and technical updates to the system modules.

8.4.1 Update of user requirements

CAPTAIN adopts a co-creation methodology for agile requirements elicitation and validation of development. Relying on the living labs’ power, the project stakeholders (users/seniors, carers, living labs staff, clinical staff, etc.), constituting the “Stakeholders’ network”, will be the only official source of requirements. Established in T.2.1, this network will run throughout the project’s lifecycle and will be engaged in short pilot trials (T.7.4), providing their feedback, wherever and whenever this will be required, thus supporting the participatory design through a continuous set of small scale data collection pilots during the requirements elicitation, design and development processes.

8.4.2 Technical changes

In case any changes of the approaches to the realisation of the technical aspects of the project are needed, based on the agile requirements elicitation, a change request will be sent to the Technical Coordinator, who will then discuss the implication of such a change with the proposing party, as well as with the PSB. If the necessity of a major change in the technical approach of a part of the system is agreed, the proposed change will be discussed and approved during the next project meeting. If the requested change is rated as substantial, it will also be reported to the EC Project Officer through the PC.

8.5 RISK MANAGEMENT

CAPTAIN is a consortium consisting of various independent partner organisations. Its complex objectives demand the successful cooperation of many experts from different scientific fields. A successful completion of the project will again heighten the reputation of each partner and the individuals associated with them. Therefore, despite the organisational independence of partners, a successful completion of the problem at hand is in everyone’s strongest interest. Risk management addresses issues that could endanger achievement of critical objectives. Effective risk management has to consider sources for cost, schedule and performance risks, as well as other risks, and specify practices to systematically plan, anticipate and mitigate these risks in order to minimise their


34 | P a g e

impact on the project. In this Section, we describe the risk management processes to identify, analyse and mitigate risks efficiently.

8.5.1 Risk identification and analysis

The CAPTAIN implementation ensures that potential risks will be identified within the requirements elicitation, the design and pilot phases, and will be appropriately addressed, minimizing the overall implementation risks. The QRM will oversee risk management. In particular, the QRM will be in charge of i) illustrating potential risks (static and dynamic / recurring) present, together with their date, classification and the impact assessment (features, cost and time); ii) highlighting any opportunity emerging from a risk through a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis; iii) detailing causes and effects of each risks element also with support of dedicated flow charts, influence diagrams or Decision-Tree Diagrams (DTDs); iv) recommending possible allocation of human resources for any necessary mitigating action (preventive or remedial); v) as soon as a risk has been identified and needs to be addressed, the QRM will be responsible for the definition of new project activities necessary to ensure the mitigation of risk, the assignment of the priority level of activity in mitigating the risk index and status of the project and the allocation of human resources required to perform the activities of risk mitigation. Six general categories of risks have been identified: Analysis, Technical, Operational, Project Management, Dissemination and exploitation and Security risks. Risks in each category are presented in the following table, along with the mitigation plan for their effective handling, in case of their occurrence.

Description Proposed risk-mitigation measures

ANALYSIS RISKS

Agile approaches not well adopted

5 partners of the CAPTAIN’s consortium are strongly involved in living lab activities and co-creation methodologies as part of their living labs’ daily tasks. Co-creation methodologies are built around the participatory design and thus, these partners will introduce and harmonize the agile approaches throughout the consortium.

TECHNICAL RISKS

The applications suites do not fulfil end user requirements and expectations

While the participatory approach (agile requirements elicitation and development) ensures that this risk is low, CAPTAIN builds the stakeholders’ network (T2.1) around continuous data collection small scale pilots in Living Labs to meet any user requirements or expectations whenever these show up.

Incompatible or incorrect equipment for CAPTAIN system components

Although CAPTAIN will deliver new ICT approaches targeting people in need of guidance and care due to age related conditions, the technologies used have already been tested in other domains (gaming). Moreover, NIVELY and HOLOLAMP are two partners with proven capacity in designing and developing hardware prototypes (http://hololamp.io)

Technical support required for bug-fixes during the Pilots

CAPTAIN devotes a whole WP (WP6) on the final integration of the system. All the technical partners are involved in this WP and therefore, any arising technical issue will be solved event during the pilots. Besides this, The development of the CAPTAIN will be accompanied by pilots trials where new releases will be tested as soon as they emerge.

OPERATIONAL RISKS

http://hololamp.io/


35 | P a g e

Insufficient number of involved elderly citizens

Participatory Design (PD) implies active involvement and collaboration of the intended users, which is seen as one of the most significant requirements of good design. CAPTAIN builds a network of active stakeholders (Τ2.1) (relying on the participants who already trust the partners’ living labs) which will support the participatory design through continuous small-scale data collection pilots (Τ7.4, T7.5) during the requirements elicitation, design and development processes. CAPTAIN consortium will investigate the possibility on engaging some of the network stakeholders to the real seniors’ home pilot trials

Resilience from elders on being monitored

Although this will be required by family members, additional workshops and tutoring session with final users will be organised to explain and demonstrate the benefits of CAPTAIN and its unobtrusive environment sensing approaches. However, most of the partners living labs have already managed similar situations with no problem even to monitor (informed consent about what is monitored, see Section 5) the citizens in their real homes (www.aha-livinglabs.com).

Failure to deliver an integrated accessible platform

The strong participatory and agile development approach ensures that this risk is low. However, in the low probability case that we face such risk, more efforts will be devoted in the integration WP6 to deliver the envisaged outcome, and through an appropriate maintenance operation to constantly refine the prototype. A “richer” acceptance test plan will also take place if necessary.

PROJECT MANAGEMENT RISK

Limited resources for pilots

Implementation of mechanisms to redistribute workload among available resources, e.g. transmission of workload from helpdesk to relatives.

Partner/key technology provider leaves the consortium

In such an event, the consortium will, in a timely fashion, try to find a replacement organization from outside of the consortium with similar expertise in the respective area. If this is not possible, a replacement within the consortium will be found to take on the responsibilities of the partner leaving.

Disputes within a work-package

Where there is sustained disagreement within a work package, which the WP Leader is unable to mediate, the Coordinator will be invited to mediate. In the absence of consensus, the Steering Committee shall be invited to make a decision that is binding.

DISSEMINATION AND EXPLOITATION RISKS

Business results are lower than projected

The project management will examine the causes and the potential impacts to the activity plans for the following periods. If the business is still seen as viable, adjustments will be made to the plan in coordination with consortium partners.

Freedom-To-Operate analysis blocks patent application

Although CAPTAIN consortium has already gone through a freedom-to-operate analysis in order to meet the call’s “radically new ICT approaches” requirement, the innovation and radically new approaches introduced by CAPTAIN are extended to a big range enabling the consortium to apply for a patent.

SECURITY RISKS

http://www.aha-livinglabs.com/


36 | P a g e

Issues of ethics, privacy and security

A specific partner DIG has been involved with top competences in privacy and security. UNITN and AUTH have specific ethics competences complemented by experts in the Ethics Board. A task (T1.4) has been introduced to manage ethical and security issues.

8.5.2 Risk monitoring and control

After the identification of potential risks, the spiral approach of the CAPTAIN implementation ensures that these risks will be appropriately addressed within the following stages, minimising the probability of occurrence. However, there is a need for overall risk monitoring and control, throughout the project. Therefore, the risk status will be reviewed periodically during the Consortium meetings, in order to re- examine possible sources of risks, to uncover risks overlooked and reassess already identified risks. The WP leaders are responsible for identifying and evaluating new risks and communicating them to other partners. A risk register has been created. Each risk source has been given a probability of occurrence (Low, Medium, or High), level of impact to the project (again Low, Medium, High), and its impact areas are stated (impact to costs, schedule or performance of the project). Risk entries can be added, or currently open risks can be updated or closed. Depending on the re-assigned priority and consequences of each risk, the Steering Committee decides on further risk handling when monitored risks become critical. Risk handling may range from simple acceptance and monitoring in case a risk is judged as negligible, to development and implementation of risk mitigation plans for risks judged as unacceptable, due to their high impact to the project. The responsibility for development and implementation of a mitigation plan, in order to reduce the risk to an acceptable level, lies with the associated WP Leader. Risk mitigation plans will address issues, such as the development of alternative courses of action, possible workarounds, schedule for risk handling activities, performance measures on these activities and finally recommended course of action. After a risk mitigation plan is initiated, the risk will still be monitored, and the progress of open actions will be tracked until completion. Despite all attempts to mitigate a risk, some risks may be unavoidable and become a problem that affects the project. To deal with such risks, project meetings will be scheduled if needed. In these meetings, appropriate response actions will be defined and documented in a contingency plan. The resulting contingency plan will be executed by the responsible partner and monitored by the PSB.

9 INTELLECTUAL PROPERTY RIGHT ISSUES

CAPTAIN starting point towards licensing models and Intellectual Property Rights (IPR) will be the current licensing practices of commercial partners. Nevertheless, we will also make provisions for allowing the research partners to make some of their algorithms available as open source under licenses that will be both re-search and business friendly. A comprehensive Intellectual Property Agreement (IPA) will be put in place before research begins in order to govern the management of IP in the CAPTAIN project. This IPA will cover access rights and exploitation and will guide IP management throughout the course of the project. The IPA will also steer on post-project commercialization. Intellectual Property Management will be handled according to the provisions of DESCA 2020 Model Grant Agreement (v1.1, May 2014) (www.DESCA-2020.eu), as well as according to the clauses defined within the CAPTAIN Consortium Agreement.


37 | P a g e

9.1 BACKGROUND

Intellectual Property Rights (IPR) may apply either to the results (former foreground) or the background of the project. Background is the information, data, know-how, or infrastructure that a partner possesses before the start of the project and is needed to implement the project or exploit the results. Results are the information, data, knowhow, or infrastructure that is generated during the project. Such results include rights related to copyright, design rights, patent rights, or similar forms of protection. Under 24.1 article of the GA, partners must identify and agree on what constitutes background for their action, in order to be able to give access to it (‘Agreement on Background’). Unless otherwise indicated in this agreement, partners must give each other access on a royalty-free basis to background needed to implement their own tasks under the action. The same holds for access to background needed for exploiting their results. For the CAPTAIN project, the background to which partners are ready to grant access rights, subject to the provisions of the CA and the GA, is presented in the following table.

Describe Background Specific limitations and/or conditions for implementation (Article 25.2 Grant Agreement)

Specific limitations and/or conditions for Exploitation (Article 25.3 Grant Agreement)

ARISTOTELEIO PANEPISTIMIO THESSALONIKIS (AUTH)

webFitForAll (Web based physical training - exergaming platform running on PCs, Tablets, SmartPhones, SmartTVs) using sensor devices

Access to its background is subject to legal restrictions or limits, however, the software/service will be offered free of charge for the trials to be conducted within the CAPTAIN project.

The software is a result of the commercial exploitation of previous funded projects. Any new developments within the realm of the CAPTAIN project will be the subject of new exploitation opportunities

The data of previous pilot trials composing a big dataset of recordings of people performing activities of daily living and interacting with serious games.

There will only be access to relevant data in the framework of the CAPTAIN project, exclusively during the duration of the project

It is not possible under any circumstances to use data from the collected datasets to be exploited.

Many years of experience in conducting pilot trials. Experience and knowledge in conducting studies and applying co-creation approaches within living labs.

Access to its background is subject to legal restrictions or limits, however, the Knowledge and methods will be offered free of charge for the trials to be conducted within the CAPTAIN project.

Any new developments within the realm of the CAPTAIN project will be the subject of new exploitation opportunities.

DIGIFLAK OU

FlakNet- the technology and software to be used for secure communications between devices, machines, people and services. Include

Limited to the usage within CAPTAIN, no productive use outside the project No disclosure



38 | P a g e

CertMe – the technology and software for the automated management of the digital certificates lifecycle.


To be negotiated in a separate agreement

LogMe – the system and software for the strong password-less authentication on WEB-based resources



SeOS – the firmware/middleware to be integrated with embedded systems for the data, code and channels protection, mutual authentication, blockchains and smartcontracts enabling, etc.



Flak Secuter - USB/NFC-connected microcomputer, which implements strong multifactor and password-less user’s authentication on WEB-resources, secures user’s traffic in a real-time mode, creates VPN, prevents phishing and fraud attacks, encrypts and signs user’s data, manages passwords and certificates.



NIVELY

MentorAge sensing units are composed by a 3D sensing unit, which can detect the positions of multiple bodies (and their parts, i.e. head, torso, arms, legs) in a room.

Will be applied on the basis of each request for Access Rights in accordance with Section 9.2.6.


MentorAge can: 1) analyse movement of people and detect various changes and conditions related to body movements indoor and outdoor (using satellite technology) 2) provide indicators and early signals of various patterns 3) provide access to measurements of healthcare data 4) provide access to easy communication features targeted to seniors 5) allow




39 | P a g e

integration with IoT and home automation.

SALUMEDIA

Dailympics – gamified mobile platform for empowering, coaching and educating patients with chronic conditions including cancer.



SmokeFreeBrain – part of Dailympics technology has been used in the project http://smokefreebrain.eu/ where it is being adapted for the use of smoking cessation.



CHESS – part of Dailympics technology has been used in the project http://chessitn.eu/ where it is being adapted for the use of MS patients.



CATCH – part of Dailympics technology has been used in the project http://catchitn.eu/ where it is being adapted for the use of cancer patients and cancer survivors.



INTRAS

INTRAS Living Lab Methodology No access is granted to source code or object code for implementation. Background may be used only for implementation of the Project.

No access is granted to source code or object code for the exploitation of Results. Background is not Needed by the other Parties for Exploitation of their own Results thus no Access Rights will be granted by INTRAS for Exploitation, unless otherwise agreed between the Parties concerned. Considering this, the specific limitations (including third party rights) are not listed in this agreement.

http://smokefreebrain.eu/

http://chessitn.eu/

http://catchitn.eu/


40 | P a g e

The data of previous pilot trials composing a big dataset of recordings of people performing activities of daily living and interacting with serious games.

There will only be access to relevant data in the framework of the CAPTAIN project, exclusively during the duration of the project.

It is not possible under any circumstances to use data from the collected datasets to be exploited.

Many years of experience in conducting pilot trials. Experience and knowledge in conducting studies and applying co-creation approaches within living labs.

Access to its background is subject to legal restrictions or limits, however, the Knowledge and methods will be offered free of charge for the trials to be conducted within the CAPTAIN project.

Any new developments within the realm of the CAPTAIN project will be the subject of new exploitation opportunities.

HOLOLAMP

HoloLamp’s calibration software and process based on structured-light that compute: intrinsic parameters of each projector, intrinsic parameters of each camera, extrinsic parameters of each projector and each camera, so that their coordinates systems are merged in a single coordinate system.



HoloLamp experience and knowledge in projector solutions: knowledge in the benefit and limitations of each pico/mini projection technology (DLP, LBS, LCoS), collaboration with Texas Instruments (who owns DLP technology) and several Optical Module Manufacturers. know-how to analyse the requirements of a project in projection systems, and to write the optical module specifications that meet them.



HoloLamp experience in designing projection-based AR solutions (some of them are patented) in gaming, in smart kitchens, in smart home connected to AI, in sports broadcasting



https://www.youtube.com/watch?v=3gu01JbC7VY

https://drive.google.com/file/d/1pomv2EF9t2Df_yo9MAsqgChr47xAWIe-/view

https://www.youtube.com/watch?v=wEbSgAbOhe8

https://www.youtube.com/watch?v=a5bgVd2iZUc


41 | P a g e

HoloLamp software and process that warp the projected image - as a function of the environment geometry and the user’s position - to create 3D illusions directly in the user’s environment.



HoloLamp optical solution - based on a synchronous detection between IR illumination and cameras to reduce the influence of the light conditions on the tracking of the user.



AZIENDA SANITARIA PER I SERVIZI SANITARI DELLA PROVINCIA AUTONOMA DI TRENTO (APSS)

Domotic apartment with multisensorial equipment for individual and environment continuous monitoring, shared with UNITN

Access to the domotic apartment inside the rehabilitation hospital “Villa Rosa - APSS” is defined by collaboration with University of Trento.

Domotic apartment for occupation therapy and rehabilitation with multisensorial equipment, shared with UNITN


Living lab for the development and testing of innovative assistive devices and the assessment of their appropriateness for specific patient, shared with UNITN


The multidisciplinary team working in the domotic apartment is composed by the physician in rehabilitation, the occupational therapist and the physical therapist

Long-time experience in assistive technology devices and their assessment of choice with users


42 | P a g e

Experience in occupational therapy in training user and caregivers in ADL and IADL independence

For the rest of the Consortium partners, it is agreed between them under the CA that no data, know-how or information of the partner shall be needed by another partner for implementing the project (Article 25.2 GA) or exploiting Partner’s results (Article 25.3 GA).

9.2 MONITORING OF USAGE

During the project, it is important to monitor the usage of the background information and of the results. The owner will decide the publicity of the background. It should be noted that it is not allowed for the project members to disclose the background information outside of the project without the permission of the owner. The owner will be responsible for the monitoring of usage of the background and of the results produced, e.g., keeping logs of downloads.

9.3 TRANSFER OF RESULTS

Each partner may transfer ownership of its own results following the procedures of the GA (Article 30, Transfer and Licensing of Results). It may identify specific third parties it intends to transfer the ownership of its results, in Attachment 3 of the CA. Other partners hereby waive their right to prior notice and their right to object to a transfer to listed third parties according to the GA Article 30.1. The transferring partner shall, however, at the time of the transfer, inform other partners of such transfer and shall ensure that the rights of other partners will not be affected by such transfer (for more, see Section 8 of the CA).

9.4 DISSEMINATION OF RESULTS

During the project and for a period of one year after the end of the project, the dissemination of own results by one or several partners including but not restricted to publications and presentations, shall be governed by the procedure of Article 29.1 of the GA subject to the following provisions:

Prior notice of any planned publication shall be given to other partners, at least 30 calendar days before the publication. Any objection to the planned publication shall be made in accordance with the GA in writing to the PC and to the partner or partners proposing the dissemination within 15 calendar days after receipt of the notice. If no objection is made within the time limit stated

above, the publication is deemed to be permitted.

A partner shall not include another partner's results or background in any dissemination activity,

without obtaining the owning partner's prior written approval.

Partners undertake to cooperate for allowing the timely submission, examination, publication and defence of any dissertation or thesis for a degree which includes their results or background,

subject to the confidentiality and publication provisions agreed in the CA.

Nothing in the CA shall be construed as conferring rights to use in advertising, publicity or otherwise the name of partners or any of their logos or trademarks without their prior written approval.


43 | P a g e

In order to maximize research dissemination and in accordance with EU directives all project partners intend to publish all scientific achievements online and in open access following the “green” model (i.e., publish our work in prestigious venues and self-archive the full text in our institutional, online repositories and the project’s Web site with public access). More specifically, the project coordinator will manage knowledge and IP via specific activities within WP9. In line with this, specific budget may be dedicated by AUTH for funding of open access journal publications (gold open access). Coverage will be provided by institutional open access repositories managed by CAPTAIN partners to ensure the ability to comply with open access requirements. The tracking of publications in the dissemination task (T9.3) will also manage this compliance. Of course, the rules for protecting confidential information and patenting important knowledge will be covered in CAPTAIN’s Consortium Agreement. In this respect, the goal of task T9.5 is to put in place the processes by which these rules can be implemented in an efficient and lightweight way. A record will be kept including all IP assets that the project creates and plans to create, so that attention can be given to the protection of the most valuable IP using patents or other methods (e.g., trade secrets). This will be augmented by periodic discussions at the project’s management board, reviewing the IP asset list and checking whether exploitation paths are explored for the most valuable IP. Also, for IPR protection, CAPTAIN will put in place a simple publication notification procedure, so that partners wishing to publish or otherwise disclose project activities and results can notify the other partners in good time. The publication notification and IP asset tracking procedures will be lightweight, requiring partners to fill in simple templates that will be shared via CAPTAIN’s document management tool, considering the classification assigned to the planned deliverables according to the rules of general dissemination focus (PU) or restricted to the consortium (CO).

9.5 JOINT OWNERSHIP

Two or more partners own results jointly if they have jointly generated them and if it is not possible to establish the respective contribution of each partner, or separate them for the purpose of applying for, obtaining, or maintaining their protection (under article 26 of the GA). In this case, partners concerned must conclude to a joint ownership agreement (in writing). This agreement should cover:

Specific conditions for granting licenses (if they are different from those already set out in the GA).

Criteria or principles for ‘fair and reasonable compensation’ to be provided to the other joint owners, if a non – exclusive license is granted to a third party (if appropriate).

How disputes will be settled (e.g., via a mediator, applicable law etc.) where no joint ownership agreement has yet been concluded.

Each of the joint owners shall be entitled to use their jointly owned results for non-commercial research activities on a royalty-free basis, and without requiring the prior consent of the other joint owner(s).

The joint owners automatically have the right under the GA to grant non-exclusive licenses to third parties (without any right to sub-license) to exploit jointly (without prior authorisation from the other joint owners).

The joint owner that intends to grant the license must give the other joint owners at least 45 calendar days advance notice (together with sufficient information, to check if the proposed compensation is fair and reasonable), as well as fair and reasonable compensation.


44 | P a g e

Joint owners are free to agree on different arrangements in their joint-ownership agreement. Joint owners may abandon joint ownership only after the jointly-owned results have been produced.

10 REFERENCES

[1] Guidelines on Open Access to Scientific Publications and Research Data in Horizon 2020, available online at: http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/ hi/oa_pilot/h2020-hi-oa-pilot-guide_en.pdf

[2] The use of the EU emblem in the context of EU programmes Guidelines for beneficiaries and other third parties, available online at: http://eacea.ec.europa.eu/about/logos/eu-emblem-rules-hr.pdf