renewable mobility services in smart...

D1.2: Page [1] of [54]

Renewable Mobility Services in Smart Cities

FP7 - Information and Communication Technologies

Grant Agreement No: 609026 Collaborative Project

Project start: 1 November 2013, Duration: 36 months

D1.2 Project Quality Plan

Work package: WP1 – Project Management Due date of deliverable: 28 February 2014

Actual submission date: 28 February 2014 Responsible Partner: CERTH Contributing Partners: AVG Nature: Report Prototype Demonstrator Other Dissemination Level: PU : Public PP : Restricted to other programme participants (including the Commission Services) RE : Restricted to a group specified by the consortium (including the Commission Services) CO : Confidential, only for members of the consortium (including the Commission Services) Keyword List: Project work plan, project management

The MOVESMART project (http://www.movesmartfp7.eu) is funded by the

European Commission, Information and Communication Technologies, Snart Cities and Communities (FP7-SMARTCITIES-2013), under the FP7 Programme.

http://www.movesmartfp7.eu/

FP7-SMARTICITIES-2013 609026 - MOVESMART

D1.2: Page [2] of [54]

The MOVESMART Consortium

Ayuntamiento de Vitoria-Gasteiz (coordinator), Spain

Asociacion para la Promocion de la Innovacion Denokinn, Spain

Centre for Research and Technology Hellas / Information Technologies Institute, Greece

Computer Technology Institute & Press “Diophantus”, Greece

Karlsruher Institut für Technologie / Institute of Theoretical Informatics

Universidad de la Iglesia De Deusto, Energy Unit, Spain

South West College, UK

Grad Pula - Pola, Croatia

Going Green SL, Spain

MLS Multimedia SA, Greece

Flexiant Limited, UK


D1.2: Page [3] of [54]

Document history

Version Date Status Modifications made by

0.1 05.01.2014 First Draft Dionisis Kehagias, CERTH

0.2 31.01.2013 Second draft Sandra Busturia, AVG

0.3 15.02.2014 Final review by authors Dionisis Kehagias, CERTH

0.9 24.02.2014 Reviewed by evaluator – ready to be submitted.

Cristina Martín Andonegui (UD)

1.0 28.02.2014 Review comments incorporated - Submitted to EC

Sandra Busturia, AVG

Deliverable manager

Dionisis Kehagias, CERTH

List of Contributors

Sandra Busturia, AVG

List of Evaluators

Cristina Martín Andonegui, UD Sandra Busturia, AVG

Executive Summary

This deliverable intends to set-up the rules and procedures to achieve deliverables and deliveries of adequate quality. It also describes the specific arrangements implemented in order to keep the developments which are made in several design and development centres under close control.

In addition to the other management procedures which strongly contribute to the timely production and the quality of the deliverables, this document also describes the procedures to be followed if changes to the agreed specifications become necessary, during the course of the developments.


D1.2: Page [4] of [54]

Table of contents

TABLE OF CONTENTS ................................................................................................................. 4

ABBREVIATIONS AND ACRONYMS ............................................................................................ 7

1 INTRODUCTION .................................................................................................................. 8

1.1 SCOPE OF THIS DOCUMENT ................................................................................................ 8

1.2 QUALITY CONTROL .......................................................................................................... 8

1.3 STRUCTURE OF THIS DOCUMENT ......................................................................................... 9

2 QUALITY CONTROL INSTRUMENTS AND PROCEDURES ................................................. 10

2.1 QUALITY CONTROL INSTRUMENTS ..................................................................................... 10

2.1.1 ORGANISATIONAL STRUCTURE OF THE PROJECT ............................................................ 10

2.1.2 THE TECHNICAL QUALITY MANAGER ......................................................................... 10

2.1.3 QUALITY BOARD .................................................................................................... 11

2.1.4 PLENARY BOARD ................................................................................................... 12

2.1.5 LIST OF DELIVERABLE PEER-REVIEWERS ....................................................................... 12

2.2 QUALITY CONTROL PROCEDURES ...................................................................................... 13

2.2.1 SUCCESS MEASURES AND CRITERIA ........................................................................... 13

2.2.2 CORRECTIVE AND PREVENTATIVE ACTIONS .................................................................. 16

2.2.3 RISK MANAGEMENT AND CONTINGENCY PLANNING ..................................................... 26

2.3 DELIVERABLE REVIEW AND APPROVAL ............................................................................... 29

2.4 INTERNAL AUDITS .......................................................................................................... 31

2.5 QUALITY SYSTEM REVIEW ............................................................................................... 31

3 CONTROL OF DELIVERABLES AND DOCUMENTATION ................................................... 33

3.1 DOCUMENTATION ......................................................................................................... 33

3.1.1 DOCUMENT FORMATS AND TEMPLATES ..................................................................... 33

3.2 DOCUMENT NAMING AND CODING ................................................................................... 34

3.3 RELEASE OF DELIVERABLES .............................................................................................. 35

3.4 DISSEMINATION ACTIVITIES ............................................................................................. 35

3.4.1 ACKNOWLEDGMENTS ............................................................................................. 37

3.5 TEMPLATES .................................................................................................................. 37

4 DEVELOPMENT PROCEDURE AND COORDINATION BETWEEN PARTNERS ................... 38

4.1 GENERAL ..................................................................................................................... 38

4.2 APPLICABILITY OF THE PROCEDURE .................................................................................... 38

4.3 HANDLING NECESSARY CHANGES DURING THE DEVELOPMENT PROCESS .................................... 39


D1.2: Page [5] of [54]

4.4 NUMBERING OR CHANGE REQUESTS AND NOTIFICATIONS ..................................................... 39

REFERENCES ............................................................................................................................. 40

A. ANNEX I – MOVESMART DELIVERABLE TEMPLATE ........................................................ 42

B. ANNEX II – MOVESMART PRESENTATION TEMPLATE .................................................... 48

C. ANNEX III –CHANGE REQUEST OR NOTIFICATION .......................................................... 49

D. ANNEX IV – MOVESMART DELIVERABLE PEER REVIEW REPORT TEMPLATE ................ 51


D1.2: Page [6] of [54]

List of Tables

Table 1: List of peer reviewers ................................................................................................. 17

Table 2: Deliverable Success Criteria ....................................................................................... 19

Table 3: Expected General Risks............................................................................................... 26

Table 4: Technological Risks ..................................................................................................... 28

Table 5: Deliverable Evaluation Procedure .............................................................................. 30

Table 6: Available document formats ...................................................................................... 34


D1.2: Page [7] of [54]

Abbreviations and Acronyms

Abbreviation Explanation

CA Consortium Agreement DM Deliverable Manager DoW Description of Work EC European Commission GA Grant Agreement IPR Intellectual Property Rights PO Project Officer PU Public QB Quality Board QP Quality Plan TQM Technical Quality Manager UI User Interface WP Work Package WPL WP Leader


D1.2: Page [8] of [54]

1 Introduction

1.1 Scope of this document

This deliverable describes the MOVESMART Quality Plan, whose purpose is to determine in a clear and concise way the organisation of the quality control procedures for MOVESMART. The purpose of quality control is to set up the appropriate actions and supporting tools for making sure that the produced project documents as well as technical achievements adhere to a set of quality standards. Furthermore it presents a set of quality measures and the required document templates for preserving a minimum level of presentation quality.

More specifically, the Project Quality Plan describes:

the roles of different actors in the project and their responsibilities

the project’s management bodies

the information exchange procedures among partners and their coordination

the general quality control measures and actions, including success measures and criteria, corrective and preventative actions, risk management and contingency planning

the quality control of deliverables and documentation, including document types, documents naming, and document templates

the project’s dissemination procedures

the quality control of the whole project, including the peer-reviewing evaluation of project’s deliverables

general guidelines for performing the required day-to-day project management activities.

1.2 Quality Control

Quality control shall not only be addressed for the reports and deliverables but also for the prototypes, demonstrations and for the project process itself. It is a continuous process that aims to ensure that the project evolves in such a way to ensure that the project adheres to an accepted level of quality standards. The quality control process shall be submitted to periodical reviewing with respect to:

Adequacy of the project management procedures and how the work performed complies with it, including IPR management and results dissemination

How well the project processes are synchronized and inter-linked

Identification and evaluation of activities and results that would adversely affect the achievement of the project objectives

Process improvement in the project by identifying deviations and changes.

The Quality Board (see Section 2) continuously monitors and controls in cooperation with the project management (i.e. taking corrective actions) expenses, resources and schedules versus plans (i.e. technical and financial annexes to the EC Grant Agreement). This is done through:

The internal Quarterly Management Reports (QMR) to the Project Coordinator and the PO.

The official annual reporting to the European Commission (Project Officer)

The periodic review to be performed towards the end/beginning of each year (final dates are open) 2014/2015, 2015/2016, end of 2016, and the Final Report at the end of the project.

The specific rules regarding reporting process and documents are available under D1.1 Project Reference Manual [4].


D1.2: Page [9] of [54]

Any deviation, be it shortages or excesses, in costs, resources and schedules shall be identified, recorded and used as input for continuous improvement. Possible impacts on the schedule, changes on the budget and resources of the project and on the quality of the product should be determined.

All these procedures are based upon consensus decision making procedures; in case of conflict, as described in [2] DoW (B2.1.12 – Emergency Cases) decisions should be submitted to the Consortium.

1.3 Structure of this document

This Quality Plan document is structured as follows:

Section 2 outlines the various quality control instruments that are define to undertake those measurements that are necessary for ensuring conformance to project quality requirements. The same section describes the necessary tools for applying the previous quality measures.

Section 3 describes in detail the specific quality control measures that are applied to the project documentation, including deliverables, technical and financial reports, scientific papers and presentations, among others, as well as other dissemination activities.

Section 4 refers to the necessary quality control procedures that are applied to the technical development processes in the project in order to maintain adherence of the project developments to the initial project requirements.

Finally, various MOVESMART templates are presented in Annexes I-IV.


D1.2: Page [10] of [54]

2 Quality Control Instruments and Procedures

This section describes the organizational structure of the MOVESMART Quality Management Process, including the various instruments that are designated to take the appropriate measures for ensuring quality control, as well as the various procedures and relevant tools, e.g. for the information exchange and coordination among partners.

2.1 Quality Control Instruments

2.1.1 Organisational Structure of the project

The management of the project must offer sufficient control and flexibility, so that the Project carries out its ambitious goals as smoothly as possible. Consequently, a formal management structure is set up, as simple as possible, to ensure unambiguous responsibilities and also allowing for a number of practical arrangements to be made.

The MOVESMART management is structured both hierarchically and horizontally and is conducted by three bodies:

1. Project Management (Project Coordinator & Technical Quality Manager) – Project Office 2. Project Plenary Board 3. Quality Board (QB)

The proposed management structure does not allow the creation of “islands” of autonomous research and the waste of resources in work repetition. The roles and tasks of the various bodies, for which allocations have been agreed, are described in detail in Deliverable D1.1 “Project Reference Manual” [4]

2.1.2 The Technical Quality Manager

The Technical Quality Manager (TQM) of the project is Dr. Dimitrios Tzovaras (Research Director Grade A and Director of the Information Technologies Institute of CERTH). He received the Diploma and the PhD in Electrical Engineering from the Aristotle University of Thessaloniki, Greece in 1992 and 1997, respectively. Prior to his current position, he was a Senior Researcher on the Information Processing Laboratory at the Electrical and Computer Engineering Department of the Aristotle University of Thessaloniki.

During his service as Researcher Grade D’, C’, B’, and A’ and also as Research Director, he has participated with his team in 71 Research and Development projects of CERTH/ITI: of which 37 are funded by the EC (5 FP7 ICT IP, 9 FP7 ICT STREP, 1 FP7 CSA, 1 FP7-TRANSPORT, 3 FP7 ICT PSP, 2 FP6 IP, 4 FP6 IST STREP, 2 FP6 NoE, 1 FP6 CSA, 2 FP5 IST, 1 Transnational Cooperation Program, 1 AAL Joint Programme and 5 structural/cross border), 21 are funded by the General Secretariat for Research and Technology and 13 are subcontracts from the industry), acting both as Scientific Responsible of the Research Group of CERTH/ITI and as the Project Coordinator of the whole European consortium (coordinator and/or technical and scientific manager of the project in 11 projects - 1 FP7 ICT IP, 6 FP7 ICT STREP, 3 FP6 IST STREP and 1 Greek National project).

At the same period, Dr. Tzovaras, in cooperation with prestigious National and International organizations, has participated in the preparation and submission of proposals for research and development projects in various thematic areas for funding from the European Commission (mainly in IST Programme of FP5 and FP6 and ICT Programme of FP7) and from the General Secretariat for Research and Technologies.

His main research interests include data analysis, virtual and augmented reality, multimodal data fusion and visual analytics. His involvement with those research areas has led to the co-authoring of


D1.2: Page [11] of [54]

over of 2 books, 84 publications in International Journals with Referees (of which 38 are IEEE papers), 26 book chapters, and 215 presentations in International Conferences with Referees.

In the same period, Dr. Tzovaras has acted as a reviewer of a large number of submitted scientific papers for a plethora of International Journals and Magazines such as IEEE, ACM, Elsevier and EURASIP, as well as International Scientific Conferences (ICIP, EUSIPCO, CVPR, etc.). Since 2004, he has been the Associate Editor in the following International journals: Journal of Applied Signal Processing (JASP) and Journal on Advances in Multimedia of EURASΙP. He is also an Associate Editor in the IEEE Signal Processing Letters Journal (since 2009) and a Senior Associate Editor in the IEEE Signal Processing Letters journal (since 2012), while since mid 2012 he has been also an Associate Editor in the IEEE Transactions on Image Processing journal.

He has also a long teaching experience, by serving two Universities in Greece (Department of Electrical and Computer Engineering in the Aristotle University of Thessaloniki, as well as the University of Macedonia) as a Faculty Member.

The project TQM is assisted in technical tasks by his deputy. The deputy TQM of MOVESMART is Dr. Dionysios Kehagias (Senior Researcher at CERTH). Dr. Kehagias holds a Diploma (1999) and a PhD (2006) in Electrical and Computer Engineering from Aristotle University of Thessaloniki (AUTH). His publication record enumerates more than 40 journal & conference publications in scientific areas such as Semantic Web Services, Ontologies, Machine Learning and Software agents, among others. In addition to his research achievements, Dr. Kehagias has substantial experience in quality control procedures, as he has participated in 14 European and national research projects, both as a senior software developer and a project manager during the last fifteen years. He has also served as a Program Committee member in the following conferences: International Workshop on Agents and Data Mining Interaction (2007-2013), International ICSC Symposium on Information Technologies in Environmental Engineering (2009), Behavior Informatics Workshop (2010-2011), International Conference on e-Health Services and Technologies (2010), International Conference on Data Mining, Computational and Business Intelligence (2012), European Conference on Service-Oriented and Cloud Computing (2012-2014), and also as a referee for the following journals: IEEE Intelligent Systems, IEEE Internet Computing, IEEE Transactions on Dependable and Secure Computing Advances in Engineering Software (Elsevier), Behaviour & Information Technology (Taylor & Francis), Electronic Commerce Research and Applications (Elsevier), Future Generation Computer Systems (Elsevier), Journal of Intelligent Manufacturing (Springer), Knowledge & Data Engineering (Elsevier), etc.

The Technical Quality Manager is assisted in all the non-technical tasks by the Project Office, the Project Coordinator and the WP leaders.

2.1.3 Quality Board

The QB will be responsible for the co-ordination and supervision, regarding the implementation of the measures for the quality assurance. Also, it will be responsible for the project’s quality assurance matters. In accordance with the contractual agreements, the project’s quality management plan will be prepared, defining organisational structure, flow of the quality system and the quality management procedures to be applied.

The QB will consist of the following permanent members selected from the consortium, based on their background and role in the project:

The Project coordinator, Mrs. Sandra Busturia

The Technical Quality Manager, Dr. Dimitrios Tzovaras

A Users’ Representative. This is a person appointed internally by the pilot cities. AVG is assigned as the primary user’s representative and PULA as the secondary representative.

A person in charge of Standards. This is appointed to Dr. Konstantinos Genikomsakis by UD to act as a liaison to standards and relevant bodies.


D1.2: Page [12] of [54]

In addition to the above members, other internal members will be selected, so that all beneficiary categories are sufficiently represented in the QB. These include:

The project’s Academic Research Partners:

o Primary: Dr. Dionysios Kehagias (CERTH), Prof. Christos Zaroliagis (CTI), and Dr. Diego López-de-Ipiña (UD)

o Secondary: Dr. Andreas Gemsa (KIT), Prof. John Harrison (SWC)

Industrial/SMEs:

o Primary: Mr. Craig Sheridan (FLEX), Dr. Adamantion Stavridis (MLS)

o Secondary: Mr. Gonzalo Alonso (GG), Mr. Javier Finez (BiB)

Secondary members replace the primary members, when a primary member is also a deliverable manager for a particular deliverable under quality control.

The deliverable peer-reviewers are appointed by the QB for the purpose of reviewing specific deliverables and reports. These are senior researchers of the project partners with extensive expertise on the subject of the specific deliverable, excluding of course its authors. Moreover members of different forums of MOVESMART will be used as reviewers especially for public deliverables. A list of peer-reviewers is maintained by the Technical Quality Manager and is updated regularly upon its members’ requests.

2.1.4 Plenary Board

The Plenary Board is the ultimate and main decision body of the project, chaired by the Coordinator and consists of the work package leaders, all major Contractors, representing all different types of Partners (scientific & industrial). Plenary Board Members are permanent for the project duration, except if they wish to leave the Plenary Board themselves or due to EU intervention. One representative person from each Beneficiary will participate in the Plenary Board being responsible for major parts of the work.

The Plenary Board shall be in charge of supervising the project progress and deciding upon all relevant technical and administrative issues, such as redirection of work in a WP, major transfer of resources across WP or Partners (over 20%), technological choices, changes in time plans, inclusion of a new Partner, substitution or exclusion of existing Partner, MOVESMART of conflict between different WP.

Recommendations for amendments to the work plan, major technical, financial and resource allocation decisions along with periodic and final reports will be submitted to the Plenary Board Group for ratification, including without limitation, decisions regarding:

Technical and business direction of the project.

Amendments to the description of work and effort allocation.

Specific contractual issues with the EC.

Policies for promotion and exploitation of results.

Financial planning and control and other administrative arrangements

All Partner Representatives will have a single vote. In case of equal votes, the vote of the Coordinator shall be the decisive one. This Group will meet once every three months and will be the projects driving force.

2.1.5 List of deliverable peer-reviewers

In order to ensure that the deliverables will be reviewed internally by non-conflicting partners, a list of peer reviewers’ responsibilities has been assigned to all project partners.

Table 1 presents the list of the assigned deliverable reviewers for all deliverables beyond M3 and excluding the QMR.


D1.2: Page [13] of [54]

2.2 Quality Control Procedures

This section presents the success measures and criteria for assessing the project’s objectives, the corrective and preventative actions regarding the performance of a partner, and the risk analysis and contingency planning of MOVESMART.

2.2.1 Success Measures and Criteria

This Quality Plan suggests a list of measurable success criteria in the form of key performance indicators (KPIs) for all project deliverables. These criteria are set for assessing the success of the Project objectives and therefore are compliant to the project success criteria that are mentioned in the DoW [2]. The deliverables success criteria are presented in Table 2. Some of them are expressed in numerical form. For those, the numbers indicated in Table 2 are justified as follows.

KPI-5: Number of literature research on the state-of-the-art on crowd sourcing methods, practices and commercial products, especially in the area of ITS. For this KPI, the minimum required number of literature research findings is set to be at least 5 relevant projects, 30 references, 15 internet sites and documents. These numbers are derived from preliminary research studies of the state-of-the-art approaches on crowd sourcing with emphasis on ITS, as they were reported on Dow – Section B.2.1.1 [2], taking into account several studies on the accuracy of the most popular scientific literature databases, (e.g. Scopus, Google Scholar, Microsoft Academic Search, etc.), such as the one by Walters [5]. For example, the precision of Google Scholar for the first 100 hits is estimated to be 45%. According to [5], the average precision of eight online databases (including Google Scholar, SSCI, etc.) is estimated for simple (keyword) search to range from 5-43%, for the first 100 hits, i.e., 5-43 documents of the returned results should be relevant. Hence, a number of 30 literature references as a minimum requirement, is justified. The other numbers are calculated using a similar rationale.

KPI-7: Number of traffic prediction algorithms based on crowd sourcing data. According to existing literature reviews, such as the ones found in [6] and [7], traffic prediction modelling techniques can be classified into the following categories:

a. naïve methods, that are characterised by the absence of any advanced mathematical model for the exploitation of traffic data, thus comprising basically simplistic techniques, with minimum computational requirements, but low accuracy

b. parametric techniques, that are based on specific models, whose general structure and primitives have been defined in advance and only the exact values of their parameters need to be determined on the basis of the available data

c. non-parametric techniques, that typically do not presuppose a particular model structure, hence both the exact model structure and its parameters need to be specified from training data

d. hybrid methods, which include several different approaches that exploit a wide variety of mathematical theories and techniques that have been successfully applied to other disciplines, optimally adjusted in the field of traffic forecasting.

For the development of the core algorithmic component for traffic prediction, which will be based on crowd sourcing data, our target will be to focus on b, c and d. Hence, the expected number of new algorithms will be 1-3 (1st year) and 3-5 (2nd year), including their variations.

KPI-8: Number of records stored in the Urban Traffic Knowledge Base (both real and simulated data). Each record may comprise information about the position and speed of a user, as well as a report that a user sends via the crowd sourcing framework. If we assume that 100 users will be simulated or connected to MOVESMART, according to the most common practices, one record of data will be generated e.g. every 10 minutes. Hence, in


D1.2: Page [14] of [54]

one hour an amount of 6 * 10 * 100 = 6,000 records will be generated. 10,000 records correspond to 1 hour and 40 minutes of continuous operation, 20,000 to 3 hours and 20 minutes, and so on. In the first year the users will be simulated, whereas in the second and third year of the project the users will be real. As a smaller amount of users than 100 are expected in the second year, these numbers are realistic for a sufficient amount of operation. Under real operational conditions more records are expected to be generated.

KPI-9: Number of literature research on the state-of-the-art of renewable mobility algorithmic approaches and commercial products. The same rationale for KPI-5 also applies here.

KPI-10: Number of innovative time-dependent route planning algorithms. This is set to 1-4 during the project lifecycle, because based on existing literature reviews, e.g. [8], a limited number of approaches have been proposed, most of them focusing on speed-up techniques. The authors of [9] who are MOVESMART partners, will work on extending their work, hence at least one new algorithm is expected. Additional algorithms, max. 3, will be developed based on extending previous work (e.g. [10]-[14]).

KPI-11: Estimated achieved energy gains by the use of the proposed personal mobility schema based on simulations and data from pilots deployment. These numbers were derived in line with the EU Roadmap and strategy for moving to a low carbon economy [15], [16], according to which, EU has put in place legislation to reduce its emissions to 20% below 1990 levels by 2020.

KPI-12: Measurable improvement of the developed approaches with respect to State-of-the-Art approaches, in a simulated environment. Detailed metrics will be defined in the first year. The goal of 10-15% and 15%-30% in years 2 and 3, respectively, was chosen as being realistic in a controlled environment. In case that the predefined goal cannot be achieved during the project course, with real data, related research efforts will focus on clarifying the conditions, under which the target improvement could be realised.

KPI-13: Percentage of users positive feedback on the developed user interfaces. Based on various studies on user-driven evaluation of user interfaces, e.g. [17]-[19], as well as evaluation of ITS, e.g. [20], the user satisfaction is deemed positive if at least 65% on average of the users who participate in evaluations express their positive opinion (e.g. “like”) with 0.0001< p < 0.01. Hence in MOVESMART we select 70-85% in order to increase the confidence level. These numbers are set as desirable goals. A statistical methodology to be applied at the pilots will be able to reveal the real measured values of user satisfaction.

KPI-14: Number of interoperable user interfaces integrated with existing portable navigation applications. The target number of user interfaces (1-2, 3-5 for the first and second years, respectively) that will be integrated with existing applications are determined by the number of MOVESMART foreseen services, i.e. Renewable Mobility on Demand Service, Incentivised Vehicle Sharing Service, and Integrated Personal Mobility Service. For each one of those, 1-2 new interfaces are expected to be developed. In addition, a new crowd sourcing application will be introduced in the project with its own new user interface.

KPI-16: Number of interconnected users until the end of the prototypes. This number reflects a design parameter of the pilot sites and it relies on the number of users who will be recruited for answering the questionnaires, in the user requirements elicitation phase. This number is deemed sufficient for statistical purposes, i.e. comprises a statistical significant user sample.

KPI-17: Number of legacy data sources and public data interfaces, including public transport, traffic data, EV fleet data, integrated into the envisaged cloud infrastructure.


D1.2: Page [15] of [54]

The number of data interfaces that will be supported by MOVESMART is related to the number of the external data providers that the system needs to connect to. The exact number of the different data interfaces to be deployed will be decided in the context of Task T5.3, which starts in M13. Based on the envisaged functionality and the MOVEMSART use cases, it is expected that at least the following data types will be supported: 1) live traffic data, 2) EV data, 3) Public Transport data, 4) POI, 5) geographical data (maps and GIS data). For those types it is expected that at least two data providers will be connected (one per pilot city). This results in about 10 interconnected data providers.

KPI-20: Number of interconnected users participating in Pilots. The number of users was selected so that it matches the one set for KPI-16.

KPI-21: Number of electric vehicles that will be provided for running the pilots. Based on: a) project budget limitations, b) a cost analysis that was conducted for the needs of costs justification to appear both in the MOVESMART proposal and the DOW, c) the capacity of Going Green (for EV car rental in the case of Vitoria-Gasteiz), the number of EV to be provided will range from 6-10.

KPI-22: Estimated achieved energy gains by the use of the proposed personal mobility schema based on simulations and data from pilots deployment. Here the same rationale applies as for KPI-11.

KPI-23: User satisfaction measured through appropriate feedback collection surveys. Here the same rationale applies as for KPI-13.

KPI-24: Number of newly introduced business models, based on the application of the MOVESMART crowd sourcing schema. Based on the MOVESMART Indicative Use Cases and enabling Business Models that are presented in DOW - Section B.1.1.2.2, at least one business model is foreseen for each one of the three cases, hence 2-4 newly introduced business models are foreseen.

KPI-25: Percentage of estimated Cost Benefits gained through the adoption of the proposed business models. Detailed KPIs will be devised after conducting a thorough cost benefit analysis in the context of D7.2. The target values of 20% and 30% represent business goals, based on the preliminary estimation of the potential gains that could be achievable provided that the goals set for KPIs-10-13 will be fulfilled. These numbers are expected to be updated by means of D7.2 cost benefit analysis.

KPI-26: Percentage of business models considered to be adopted by the commercial partners and municipalities. From KPI-24, the minimum number of business models, which is 2, corresponds to the 50% of the maximum number of business models, which is 4.

KPI-27: Increased public interest in MOVESMART concept measured by web server logs (number of visits). There are no golden standards about the total number of visits required by a successful web site to be considered successful. Hence, these numbers reflect a minimum requirement for making sure that a significant visibility of the website is achieved. Based on these numbers and the extent of their achievement during the course of the project, appropriate actions will be taken, if necessary, to ensure acceptable levels of web site visibility.

KPI-28: Number of supported languages. The number of supported languages is set to three, i.e. English plus the pilot sites languages, Spanish and Croatian.


D1.2: Page [16] of [54]

2.2.2 Corrective and Preventative Actions

The issues below are related to general performance of a Partner and the quality of his work outcome and not to Project Deliverables, for which the particular procedure of the previous Section is to be followed.

In case of complaints by any partner about a non-conforming performance of another partner, the QB initiates an investigation of the matter. A participant not conforming to its role in the project or not conforming to its work performance and quality is entailed to follow certain corrective actions that are decided by the QB. The QB is responsible for establishing procedures in order to ensure:

effective handling of all complaints;

reports of non-conformities;

investigation of the cause of non-conformities in relation to the quality system;

recording the results of the investigation;

determining the corrective / preventing action needed to eliminate the cause of the non-conformity;

application of controls to ensure that corrective action is taken and is effective;

initiation of preventative action and application of controls to ensure that it is effective;

relevant information on actions taken is submitted for review.

The QB and the Coordinator are responsible for resolving matters of complaint under this procedure, within their own areas of responsibility. The QB informs all involved for the complaints and the actions being taken. The complaints are recorded in a Complaint Register and are being controlled. Corrective and possible preventative actions are recorded and all involved are informed of the actions taken.

D1.2: Page [17] of [54]

Table 1: List of peer reviewers

Deliverable Deliverable name Work Package Delivery month Responsible partner Reviewer 1 Reviewer 2

D1.2 Project Quality Plan 1 4 CERTH AVG UD

D1.3.1 First Annual progress report 1 12 AVG CTI DENOKINN

D1.3.2 Second Annual progress report 1 24 AVG CERTH DENOKINN

D1.3.3 Third Annual progress report 1 36 AVG CTI DENOKINN

D1.4 Ethics Manual 1 14 AVG PULA DENOKINN

D1.5 Final Project Report 1 36 AVG KIT SWC

D2.1 User group definitions, user needs and requirements analysis 2 6 PULA CTI UD

D2.2 Use case analysis and priority application scenarios 2 9 UD MLS FLEX

D2.3 MOVESMART Technical Specifications 2 10 CTI SWC KIT

D2.4 MOVESMART System Architecture 2 12 CERTH FLEX UD

D3.1 Most prominent crowd sourcing techniques 3 4 CERTH KIT CTI

D3.2.1 & D3.2.2 Crowd sourcing techniques for on-route, post-route and emergency data collection 3 14 CERTH UD FLEX

D3.3.1 & D3.3.2 Traffic Prediction Module 3 16 CERTH KIT SWC

D3.4.1 & D3.4.2 Development of the Urban Traffic Knowledge Base 3 24 CTI CERTH UD

D4.1 New prospects in renewable mobility 4 4 CTI CERTH MLS

D4.2.1 & D4.2.2 Renewable Energy-efficient multimodal route planning algorithmic approaches 4 33 KIT SWC CERTH

D4.3.1 & D4.3.2 Renewable Personal Mobility Trip Planner 4 33 MLS AVG GG

D5.1 Prototype web services 5 30 CTI CERTH MLS

D5.2 Data interfaces to EV, public transport and infrastructures 5 32 CERTH GG SWC


D1.2: Page [18] of [54]

Deliverable Deliverable name Work Package Delivery month Responsible partner Reviewer 1 Reviewer 2

D5.3 Cloud integration product delivered 5 33 MLS CERTH KIT

D6.1 MOD Methodology 6 17 DENOKINN KIT SWC

D6.2 Pilot plans and preparation 6 19 PULA MLS AVG

D6.3 Report on MOVESMART pilots deployment 6 33 AVG UD DENOKINN

D6.4 Pilot results consolidation - Lessons learnt and recommendations 6 36 PULA MLS FLEX

D7.1 Preliminary MOVESMART Business Models 7 16 DENOKINN CTI AVG

D7.2 Cost Benefit & Effectiveness Analysis and Impact assessment 7 20 DENOKINN GG PULA

D7.3 Definition of MOVESMART Business Model 7 24 DENOKINN GG FLEX

D8.2 Multi-lingual training material 8 18 AVG PULA GG

D8.3 Dissemination strategy and actions 8 6 AVG PULA CTI

D8.5 MOVESMART exploitation and business plans 8 36 DENOKINN PULA AVG


D1.2: Page [19] of [54]

Table 2: Deliverable Success Criteria

WP Deliverable Indicator Success Criteria

Year 1 Year21 Year320

WP2

D2.1 User group definitions, user needs

and requirements analysis

KPI-1: Number of user groups and categories for MOVESMART end users. Also, completion of a formal user requirement analysis procedure to capture the user-related parameters and constraints and specification of the UI functionality and expected output of the services

- Main user groups associated with the key

MOVESMART end services have been taken

into account.

- Precision of the user group identification and

compliance of the methodology with the User Centered Design

(UCD) to ensure usability and acceptance of

MOVESMART services.

D2.2 Use case analysis and priority application

scenarios

KPI-2: Number of use cases and application scenarios for each of the MOVESMART services

Innovation and level of detail of application scenarios; analytical

presentation of MOVESMART use cases to be taken into account

in the system

1 Cumulative value


D1.2: Page [20] of [54]


architecture specification

D2.3 MOVESMART Technical Specifications

KPI-3: Specification of the MOVESMART system architecture components and the user-perspective technical requirements.

Detail and clarity of technical specifications and conformance to the

user requirements

D2.4 MOVESMART System Architecture

KPI-4: Definition of the MOVESMART architecture and determination of the architecture entities positioning.

Detail of specification of the structure of the

MOVESMART architecture, highlighting

the communication among the discrete parts

of the system.

WP3

D3.1 Most prominent crowd sourcing

Techniques

KPI-5: Number of literature research on the state-of-the-art on crowd sourcing methods, practices and commercial products, especially in the area of ITS

- Research / survey on relevant projects (at least

5)

- At least 30 references

- At least 15 internet sites and documents

D3.2: Crowd sourcing techniques for on-route,

post-route and emergency data

collection

KPI-6: Realisation of crowd sourcing mechanisms for the collection of (a) on-route, (b) post-route, and (c) emergency situation-related data, safeguarding collected data and protecting user privacy.

Existing working

prototype for the three types of data

D3.3: Traffic Prediction Module

KPI-7: Number of traffic prediction algorithms based on crowd sourcing

1-3 3-5 -


D1.2: Page [21] of [54]


data

D3.4: Development of the Urban Traffic Knowledge Base

KPI-8: Number of records stored in the Urban Traffic Knowledge Base (both real and simulated data)

4000 records 10000 records 20000 records

WP4

D4.1 New prospects in renewable mobility

KPI-9: Number of literature research on the state-of-the-art of renewable mobility algorithmic approaches and commercial products

- Research / survey on relevant projects (at least

5)

- At least 50 references

- At least 15 internet sites and documents

D4.2: Renewable Energy-efficient

multimodal route planning algorithmic

approaches

KPI-10: Number of innovative time-dependent route planning algorithms

1-2 2-4 over 4

KPI-11: Estimated achieved energy gains by the use of the proposed personal mobility schema based on simulations and data from pilots deployment.

Key Performance Indicators identified for benchmarking energy

gains

10-20% estimated improvement

15-25% real improvement

KPI-12: Measurable improvement of the developed approaches with respect to State-of-the-Art approaches, in a simulated environment

Key Performance Indicators identified for

benchmarking algorithmic performance

10-15% improvement

15%-30% improvement

D4.3: Renewable Personal Mobility Trip

Planner

KPI-13: Percentage of users positive feedback on the developed user interfaces

Key Performance Indicators identified for

benchmarking user

Minimum: 70% Minimum:

85%


D1.2: Page [22] of [54]


feedback

KPI-14: Number of interoperable user interfaces integrated with existing portable navigation applications

1-3 3-5

WP5

D5.1 Prototype web services

KPI-15: Web services prototypes implementing the algorithmic solutions developed in WP4

All foreseen web services will be implemented.

All web services to be

tested in a real env.

KPI-16: Number of interconnected users until the end of the prototypes

100 per site

D5.2 Data interfaces to EV, public transport and

infrastructures

KPI-17: Number of legacy data sources and public data interfaces, including public transport, traffic data, EV fleet data, integrated into the envisaged cloud infrastructure.

2 4 10

D5.3 Cloud integration product delivered

KPI-18: Implementation, setup and configuration of the MOVESMART integrated cloud computing infrastructure

Working Cloud infrastructure

WP6 D6.1 MOD Methodology KPI-19: Number of test scenarios Detailed specification of all


D1.2: Page [23] of [54]


D6.2 Pilot plans and preparation

test parameters: pilot sites, numbers and groups of test

subjects, road type, equipment,

targeted applications and tools and other

critical parameters

D6.3 Report on MOVESMART pilots

deployment

KPI-20: Number of interconnected users participating in Pilots

100 per site

KPI-21: Number of electric vehicles that will be provided for running the pilots

6-10 per site

D6.4: Pilot results consolidation – Lessons

learnt and recommendations

KPI-22: Estimated achieved energy gains by the use of the proposed personal mobility schema based on simulations and data from pilots deployment.

Key Performance Indicators identified for benchmarking energy

gains

10-20% estimated improvement

15-25% real improvement

KPI-23: User satisfaction measured through appropriate feedback collection surveys.

- - Minimum 85% positive

relevance feedback

WP7 D7.3 Definition of

MOVESMART Business Models

KPI-24: Number of newly introduced business models, based on the application of the MOVESMART crowd sourcing

-

Minimum: 2 Minimum: 4


D1.2: Page [24] of [54]


schema.

D7.2 Cost Benefit & Effectiveness Analysis

and Impact assessment

KPI-25: Percentage of estimated Cost Benefits gained through the adoption of the proposed business models

- Key Performance Indicators identified

for benchmarking cost benefits / 20%

improvement

More than 30%

improvement

D7.1 Preliminary MOVESMART Business

Models

KPI-26: Percentage of business models considered to be adopted by the commercial partners and municipalities.

-

50% 60%

WP8

D8.1 MOVESMART public website

KPI-27: Increased public interest in MOVESMART concept measured by web server logs (number of visits).

500-1000 1000-5000 Over 5000

D8.2 Multi-lingual training material

KPI-28: Number of supported languages

At least three

D8.3 Dissemination strategy and actions

D8.4 MOVESMART factsheet and

dissemination material

KPI-29: Number of publications, number of workshops organised by the consortium and audience size, number of conferences attended, number of leaflets and newsletters, website, size of user forum, membership to ITS organisations and forums/ - to disseminate project concept, vision and innovation - to spread out the

1. Web site of MOVESMART with press

release/blog available and working (Month 2)

2. Project dissemination material available

(posters, leaflets) as defined in WP8

3. At least 2 presentations of the

project objectives and

1. Workshop organisation with

external participants. Vast

consensus of Consortium and

several experts on project business

scenarios and use cases.

2. At least 4 papers

1. At least 7 papers

published in conference proceedings

and journals or articles in

prestigious scientific review

journals (e.g. IEEE


D1.2: Page [25] of [54]


outcomes and achievements of the project to all interest groups.

results (conferences, workshops, etc)

published in conference

proceedings and journals

3. Over 1500 web visits per month (on

average)

4. Project draft video available

(Month 24)

Transaction on Intelligent

Transportation Systems, Transport

Reviews, etc).

3. Acceptance by consortium end users (aim

is 90%)

4. Project video available through web site (Month

30)

D8.5 MOVESMART exploitation and business plans

KPI-30: Delivery of an effective, pragmatic and viable business & exploitation plan for project results uptake and commercialisation potential

MOVESMART draft dissemination

exploitation strategy and decisions

1. Revised versions of dissemination and exploitation

2. Initiation of an Open Source

Community for further extending the MOVESMART

tools.

1. Agreement & Signature of

Final Dissemination

and Exploitation

Plans including Business Plans

2. Exploitable products

available and exploitation strategy for

each of them


D1.2: Page [26] of [54]

2.2.3 Risk Management and Contingency Planning

MOVESMART pertains to a key area with a major environmental and societal impact. The proposed research is innovative both scientifically and technologically, and consequently is associated with an increase level of risk. However, this risk is cautiously and well supervised within the project. Several risks that have been identified by the Consortium, as well as their contingency plans, are provided in Table 3 and

Table 4. Certainly, during the course of the project, there will be a constant and iterative activity on the identified or the possible new risks and the necessary mitigation strategies will be determined and applied.

Table 3: Expected General Risks

Risk ID/ Risk Title Rating Proposed Counter Measures / Contingency Plans Impact to WPs

GR1. Key milestones or critical deliverable delayed.

Low The project management team (Project Coordinator and Technical Quality Assurance manager) will take care that delays in deliverables, especially reports, will not delay the overall project progress. Deliverables will be requested from partners one month before the official deadline in order to allow a review by the Quality Board in due time.

WP1

GR2. Partner underperforming.

Low The MOVESMART consortium is a strong assembly of well known companies, research institutes and universities. Based on the current R&D interests of the Consortium members it is most likely that MOVESMART beneficiaries are willing to invest additional efforts than required on specific themes, in order to reduce this risk. At an administrative level, specific regulations will be specified in the Consortium Agreement (CA) for dealing with this risk.

All WPs

GR3. Cross countries and cross development environments can result in hard integration and bad quality.

Low Within MOVESMART, from the beginning of the project, a well-defined methodology will be delivered for the overall cooperation among partners regarding the developments. In that context, development methodologies are to be enforced on developers, ensuring coordination and quality. For instance, the development/testing environment is going to be the same for all, thus minimising the risk of later on in integration and interoperability issues.

WP2-5

GR4. Key partner leaving the project (and/or temporary unavailability due to sickness / maternity leave).

Low Partner leaving the project

A partner that intends to leave the project has to announce this according to the regulation of the CA in order to allow the project to find a replacement.

Temporary unavailability problems

MOVESMART consortium addresses those issues by having the key scientific areas covered by more than one partners, thus ensuring that the project will not

All WPs


D1.2: Page [27] of [54]


suffer until a sufficient replacement is found.

GR5. Poor communication and cooperation between the consortium members.

Low A good coordination of the project and plenary meetings and phone/teleconferences will help to avoid such issues. The frequency of meetings and teleconferences can be increased if necessary.

All WPs

GR6. Failure to successfully transfer knowledge and experience from business to academia-technology providers and vice versa.

Medium The project management is structured to ensure smooth communication between technology providers, academia and users, monitoring of progress and keeping up to date with evolution. Furthermore, each partner has the expertise and policies to make the transfer of the knowledge to the key stakeholders in its areas of expertise.

WP1, WP8

GR7. Technical results of low quality / relevance to targeted users and market.

Critical The Technical Quality Assurance Manager (CERTH) with the support of all WP leaders, and especially industrial partners will continuously review the technical achievements and guarantee that the project remains focussed on its original objectives. During the project, all achievements will be re-evaluated throughout the project in order to ensure their validity with respect to targeted end users, stakeholders and according to the identified market needs.

WP1-5

GR8. Narrow dissemination of project results.

Low Dissemination actions will follow a concise plan to be initially drawn in Month 6 and will be constantly reviewed near the middle of the project (Month 16) and at the project end (Month 30). In case the targeted figures and achievements are not reached, the plan will be reviewed and revised. The project consortium partners will exploit their contacts and target markets in order to guarantee success of both Dissemination and Exploitation plans of the project, and if necessary the initially chosen dissemination targets will be broadened appropriately in order to encompass even more technology interest groups and collateral scientific and business communities.

WP8


D1.2: Page [28] of [54]

Table 4: Technological Risks


TR1. The system architecture lacks some features discovered during the development phase.

Low The consortium encompasses the required skills and experience to perform the requirement analysis and architecture design procedure, which has already started from the proposal preparation phase. In order to prevent any situation where the initial architecture will lack some features discovered during the development phase, the project will provide a first version of the architecture on Month 6 and an updated version on Month 12 of the system, when the development phase will already be in progress.

WP2

TR2. Performed requirements analysis is ineffective, resulting in a situation where projects drifts into wrong direction, subsequently efforts and performed actions yield poor results relative to the proposed R&D.

Medium

The use cases defined in the WP2 will have a strong focus on the proposed R&D applied in the specific use cases therefore mapping the activities to be performed in R&D work packages (WP3, WP4, WP5) toward identified user requirements. Involvement of all relevant partners (both use case and R&D) will ensure that all relevant aspects will be considered.

WP1

TR3. The newly developed Traffic Prediction and Time-Dependent Route Calculation algorithms fail to improve current state-of-the-art approaches.

Medium

In order to avoid this risk, a specific testbed will be developed in WP3 in order to provide a formal means for benchmarking the developed algorithmic approaches in both WP3 and WP4 with respect to current state-of-the-art approaches. Based on this testbed any potential inefficiencies will be discovered early enough in the development phase so as to allow further testing and improvement. This will result in the final selection of those algorithms that will prove the best performance after appropriate experimental analysis.

WP3, WP4

TR4. Failure to collect reliable data from users.

Low In order to deal with un-trusted and unreliable users, specific relevance feedback mechanisms will be developed for assessing the generated information that the users produce by other interconnected users.

WP3

TR5. Temporal data unavailability at the operational phase.

Medium

MOVESMART adopts at the design of the project architecture the use of well established Cloud Computing assets, such as elasticity and scalability for

WP3, WP5, WP6


D1.2: Page [29] of [54]


ensuring maximum availability and QoS of the MOVESMART services.

TR6. The performance of the Cloud Computing platform becomes poor as the volume of requests scales to large numbers.

Medium

At the design phase of the project, special care will be taken so that the UTKB will be resistant to scalability issues. An appropriate set of system parameter configurations will be thoroughly applied at the development phase in order to precisely specify the operational constraints with respect to scalability, beyond which the requested computational resources must increase accordingly.

WP3

TR7. Personal user id data leakage.

Low MOVESMART adopts a clear strategy for the protection of user data and management of ethical issues (e.g. no data will be collected without the explicit informed consent of the users, the data collected during the course of the project will be pseudonymised and stored in a secure server). Further to this, the ethics management task (T1.3) will undertake the responsibility to clearly include all required ethical guidelines for the project in the Ethics Manual.

WP1, WP3

TR8. Data management mechanisms are not able to handle efficiently a large number of requests from mobile applications.

Critical At the design phase of the project, special care will be taken so that the data collection and storage mechanisms will be sufficiently scalable. Cloud Computing solutions will be applied with essential and significant characteristics in terms of scalability, security and reliability.

WP4

TR9. The developed user interfaces do not fulfill the original user requirements and needs.

Low A User Centred Design approach will be adopted for the design of user interfaces. In addition to this, intermediate evaluation by real users will be conducted before the final prototypes will be launched.

WP5

2.3 Deliverable Review and Approval

Each deliverable is assigned a Deliverable Manager (DM), who is typically the WP or the Task Leader associated with the deliverable. The Deliverable Manager decides on the list of contributors (authors) of the deliverable, who typically come from the partners involved in the work reported on the specific deliverable.

Each deliverable will be reviewed by:

2 internal (to the consortium) Reviewers appointed by the QB, each of them not working in the institutes of the partners involved in preparing the deliverable. In the exceptional case


D1.2: Page [30] of [54]

where all partners are involved in the preparation of the deliverable, a choice will be made among partner members not participating in the work reported in the deliverable.

2 QB members, who are the most relevant (technically wise) with the deliverable under consideration, and who will control the quality of the deliverable.

The Coordinator, or a suitable member of PCO (e.g., his representative in QB) appointed by the Coordinator.

Each deliverable is evaluated according to the following criteria:

General criteria:

Deliverable contents thoroughness

Innovation level

Correspondence to project and programme objectives

Specific criteria:

Relevance

Response to user needs (if applicable)

Methodological framework soundness

Quality of achievements

Quality of presentation of achievements

In case of a document: deliverable layout, format, spelling, etc.

In case of a prototype: deliverable functionality according to the specifications

The final rating of a deliverable, which will be given by the QB, is in the following scale: Fully accepted, Accepted with minor comments, Rejected unless modified properly, Rejected. All partners who serve as peer reviewers are requested to use the Deliverable Peer Review Report Template that is presented in Annex IV – MOVESMART Deliverable Peer Review Report Template. Each deliverable is evaluated according to the schedule presented in Table 5.

Table 5: Deliverable Evaluation Procedure

Deadline Action

> 60 days before DM submits the deliverable for review (alpha version with ToC and description). After the first ToC proposal deliverable contributors respond within 5 days in order to finalise the ToC.

> 15 days before DM and deliverable contributors prepare the first and final draft

15 days before DM sends the final draft to the peer Reviewers

10 days before Reviewers send comments to DM, the associated QB members, and the Coordinator

7 days before

DM incorporates the Reviewers’ comments and sends the revised version, along with a list of actions describing how she/he has addressed the comments, to the associated QB members and the Coordinator.

4 days before The associated QB members and the Coordinator control the quality of the deliverable and if needed ask the DM for further modifications

2 days before The QB send their final approval to the Coordinator-


D1.2: Page [31] of [54]

Due Date Deliverable submission to the PO

The DM and the authors of a deliverable make every possible effort to confront with the quality criteria as well as with the comments of the peer Reviewers, the QB members, and/or the Coordinator. Possible deviations form the proposed procedure are allowed, provided that the DM sends a justification explaining the reasons behind the requested deviation. The various deadline mentioned in Table 5 can be modified in a next version of this deliverable, if necessary.

2.4 Internal audits

The progress of the project will be monitored by the Coordinator and the QB through contacts (mainly by email and/or by tele-conferencing facilities) with all the partners involved. All day to day and trivial barriers of the project have to be dealt with in this way.

In exceptional cases, when a problem of paramount importance comes up with a certain partner, an Internal Audit Procedure will be carried out by a specific project group. This group consists of:

The Coordinator

A technical partner– typically the Leader of the WP or Task within which the problem occurred, unless he belongs to the certain partner site

A member of QB (not belonging to the certain partner site)

Optionally, 1-2 other consortium members, which will be the most relevant (technically-wise) for the problem under inspection. Their participation will be decided by the by the Coordinator and the TQM and will depend on the nature of the problem.

In a first attempt, the Internal Audit Procedure will be carried out remotely through a suitable tele-conferencing facility. If the problem cannot be resolved in this way, then the aforementioned project group has to travel to the corresponding site in which the problem appeared.

All the findings of the Internal Audit will be documented in an Internal Audit Report by the QB member. Then, he will issue corrective actions, which again will be documented by her/him in the corresponding form, in order to make all the discrepancies obsolete, within the appropriate time period. Follow up actions will be arranged, so as to ensure the effectiveness of the corrective actions. The results of the Internal Quality Audits will be distributed to all Partners, related to the specific WP. The QB member will be responsible for the implementation of this procedure.

2.5 Quality System Review

The Quality system is reviewed within plenary project meetings. In such reviews, the following issues will be taken into account:

the results from project audits,

the results from internal audits,

the official project Deliverables,

the corrective action requests from all the above,

the preventive actions on all the above,

any project prototype deficiencies and subsystems/parts problems,

project participants staff training and adequacy for the tasks undertaken,

the level of used resources per category and adequacy of spent resources for the particular task.


D1.2: Page [32] of [54]

The outcomes from the above shall be discussed at PCB meetings, and their results shall be minuted and include:

Satisfaction with the audits, corrective actions and the results of complaints

Dissatisfaction and requirements for further auditing or more corrective actions

Satisfaction with the corrective actions taken by the relevant partner(s).

An agenda of such a meeting may include some of the following topics:

1. Results of Internal Audits 2. Corrective actions requests received 3. Equipment deficiencies 4. Defects in prototypes/deliverables 5. Complaints 6. Results of external audits 7. Supplier problems 8. Health and Safety 9. Training including needs and resources 10. Preventive actions 11. Review of quality policy and objectives 12. Introduction of new quality plans 13. Date of next meeting

Records to be kept are the minutes of the meeting which are to record those attending and the summary of the points raised/resolved. The records are to be produced and archived by an appointed QB member.

The revised Quality Plan is compiled and documented by the Project Coordinator with the assistance of the appointed QB member. The revised QP will be incorporated in this deliverable and will be sent to the EC Project Officer for final approval.


D1.2: Page [33] of [54]

3 Control of Deliverables and Documentation

This section provides information about the document types of the project, their templates, the naming and coding of the project’s deliverables, and the scheduling and reporting of the project’s dissemination events.

3.1 Documentation

The types of documents produced within MOVESMART are as follows:

Deliverable, which describes the work done within a WP and/or task.

Technical Report, which is a scientific paper submitted for publication, or is in press, or has already published, and which is uploaded in the MOVESMART web site.

Review Report, which is filled in by a deliverable reviewer as measure to evaluate the quality of the work done.

Meeting Agenda, used to communicate the purpose and items to be discussed in a physical or virtual meeting. In many cases, it can be just an e-mail to the appropriate emailing list(s), among those shown in document [4] - Section 4.4.

Meeting minutes, which summarize the topics dealt during the meeting as well as the actions agreed.

Conference Call minutes, which summarizes the topics dealt during a conference call as well as the actions agreed. In many cases, it can be just an e-mail to the appropriate emailing list(s), among those shown in document [4] - Section 4.4.

Presentation, which is a document used to expound topics related to the project, both internally (Consortium meetings, a partner’s vision/contribution, etc) and externally (conferences, dissemination events, meetings, annual review meetings, etc).

Financial Report, which is filled in by the partners to state their costs.

Management Report, which is filled in by the partners to report on managerial issues, cost statements and justifications, as well as on planned and actual manpower spent within a certain reporting period.

Activity/Progress Report, which is filled in by partners to collectively report on the Scientific & Technological work performed within a certain reporting period.

3.1.1 Document Formats and Templates

All document templates are located in the internal web pages of the MOVESMART web site, and can be downloaded from there for use by the partners.

The format of a document depends on its type and its use, which can be either internal to the consortium or external (including the EC).

The following table shows the allowable format of documents per type and use,


D1.2: Page [34] of [54]

Table 6: Available document formats

Document Type

Allowable Format for Internal Use

Allowable Format for External Use

Deliverable doc, docx, odt, tex PDF

Technical Report PDF PDF

Review Report doc, docx, odt, tex PDF

Meeting Program doc, docx, odt, tex PDF

Meeting Agenda doc, docx, odt, tex PDF

Meeting minutes doc, docx, odt, tex PDF

Conference Call minutes

doc, docx, odt, tex PDF

Presentation ppt, pptx, potx PDF

Financial Report doc, docx, xls, xlsx PDF

Management Report

doc, docx PDF

Activity Report doc, docx PDF

where “doc(x)” stand for MS-Word or equivalent compliant format, “odt” stands for Open Document format, “tex” stands for LaTex typesetting system format, “txt” stands for plain text format, “ppt(x)” stands for MS Power-Point presentation or equivalent compliant format, “xls(x)” stands for MS-Excel or equivalent compliant format, and “PDF” stands for the well-known portable document format.

3.2 Document Naming and Coding

For facilitating common browsing and storage in different platforms and OS’s, no spaces should be used in the document names, and instead the dash character “-” should be used.

All project document names must start with the prefix

“MOVESMART_“

in order to facilitate quick identification and indexing. In particular, the following conventions are mandatory for certain types of documents.

Names of deliverable documents should follow the convention

“MOVESMART-Deliverable-Dw.n[.m]-vX.Y.ext”

where

“Dw.n[.m]” is the deliverable number


D1.2: Page [35] of [54]

- “w” is the WP number - “n” is the numbering within the specific WP - “[.m]” (if exists) is the sub-numbering within the specific WP

“vX.Y” is the version number - “X” is the version - “Y” is the sub-version

“ext” is the file extension pertaining to the format used.

For instance, the name of (the final version of) deliverable D3.2.1 sent to the EC is

MOVESMART-Deliverable-D3.2.1-v1.0.pdf

The name of the MOVESMART Technical Reports will follow the convention

“MOVESMART_TRx_WPy_date.pdf”

where “x” is the subsequent number that is assigned to a new Technical Report that is related to WPy (y = the WP no.) and where date is the date of submission in the form ddmmyyyy.

Example:

“MOVESMART_TR2_WP5_02032014.pdf”

3.3 Release of Deliverables

All “released” versions of the project deliverables are centrally stored for download on the project Wiki, either in the “restricted” area for deliverables classified as “RE” or “CO”, or in the public area for all deliverables classified as “PU”. Support for uploading the deliverables will be provided by the project Wiki.

3.4 Dissemination Activities

Dissemination activities include:

Publications in scientific and technical journals or magazines

Publications in the printed or electronic press and media (including TV and Radio), as well as on commercial journals or magazines

Presentations in conferences and publications in conference proceedings

Exhibition stands and demos

Participation in non-project workshops, forums and/or events

All dissemination activities are governed by the procedure of Article II.30 of “Annex II – General Conditions” of the MOVESMART Grant Agreement [1] as well as by Article 8.3 of the MOVESMART Consortium Agreement [3].

If a partner is about to submit for publication a part of work performed within the project, the partner shall inform the coordinator, the TQM and the consortium members before the submission. A written acceptance shall be returned to the partner before he/she proceeds to the submission. Moreover, the participation in exhibitions through a stand and the presentation of demos of the project results require prior agreement of the whole project Consortium.

All publications, presentations, active participation to events etc. in the name of the project must be announced to the Coordinator and the TQM and will be centrally documented. Updates need to be done in the respective table in the internal Progress Report. In addition, each partner shall fill in the respective template “MOVESMART Dissemination Form” which is available from the Coordinator and the TQM.


D1.2: Page [36] of [54]

The Coordinator and the QB should be informed as early as possible about the participation of any Partner member in any dissemination activity through the completion of an appropriate form that will be available on the internal pages of the MOVESMART web site (or wiki). The Coordinator and the QB are responsible for approving or not the participation in the specific dissemination activity.

Especially for scientific publications, the following procedure applies:

1. An email regarding the planned publication along with its abstract (or a draft of the publication) is sent to the QB and the Coordinator 30 days before the submission deadline. The Coordinator informs the consortium about the planned publication.

2. The final version of the publication is uploaded as a Technical Report in the MOVESMART web site and resides in the internal pages for inspection by the rest of the partners. If within 15 calendar days, no objection is raised by any partner to QB or the Coordinator, then the publication is allowed and the Technical Report is made public.

3. A special provision is made in case of a submission to a conference publication: since there may be not enough time between the preparation of the final version and the required 15 days for final approval by the rest of the consortium, Step 2 is followed for the submitted to the conference version of the publication, provided that the submitted version is uploaded as a Technical Report at most 1 day after the conference submission deadline. If there is a major and justified objection by any partner, then the publication is withdrawn from the conference.

A partner may object to a planned publication by another partner on serious and justified grounds that have to do with confidentially of data and/or for not inclusion of the objecting partner members in the authorship of the publication if their work is included in the publication. The QB is responsible for resolving any objection raised by any partner.

Participation to dissemination activities/events requiring attendance (e.g., conferences, concertation events, workshops, seminars, etc) is governed by the following rules:

A partner should make his application as early as possible and not less than four weeks in advance of the event. The application shall be submitted to the QB.

The application should be accompanied by a copy of the event program together with a rationale describing the event and explaining the relevance of attendance to the objectives of the Project.

The application must provide a clear breakdown of the attendance cost explaining the proposed claim for the EC contribution.

Within two weeks after the event, the partner must provide to QB a concise written report (1-2 pages) about the event. If possible, the report should be accompanied by the event’s proceedings (or at least a suitable extract of it).

Notes: (a) preference will be given to those presenting papers to a conference; (b) the cost and frequency of the conference attendance should always be minimised and kept in proportion to the size and resources of the Project.

The above rules will be applied and checked by the QB in order to:

Avoid repetition of publication of the same work

Avoid publication of restrictive and/or commercial in confidence data

Avoid misunderstandings between Partners and publication of one’s work without proper referencing

Secure optimum use of dissemination resources of the project

Guarantee proper archiving of all dissemination material


D1.2: Page [37] of [54]

3.4.1 Acknowledgments

In any dissemination activity, the following quote should be included: “This work was [partially] supported by the FP7 Collaborative Project MOVESMART (Grant Agreement No 609026), funded by the European Commission.”

3.5 Templates

The following templates will be used for the preparation of MOVESMART deliverables and reports. They are available on the project web site or from the Quality Manager or Project Coordinator.

Template for deliverables (Annex I). This serves also as

o Template for quarterly management reporting

o Template for half yearly reporting

o Template for the yearly Periodic Reports

o Template for Technical Reports

Template for Presentations (Annex II)

Template for Change Request or Notification (Annex III)

Template “Peer-Review Report” (containing peer-reviewer comments on deliverables) (Annex IV)

Template for the Newsletter

Template for project leaflets

The latter two templates are part of Deliverable D8.4: MOVESMART fact-sheet and dissemination material.


D1.2: Page [38] of [54]

4 Development procedure and coordination between partners

4.1 General

The procedure described here aims to pursue two contradictory requirements:

To keep under close control, once they have been agreed, the specific features and the performance characteristics of the modules and sub-modules to be developed in the various partners’ companies;

To leave freedom to the developers to complete their tasks.

The proposed change procedure is based on the following development process:

1. System Requirements specification: this are reported in deliverables D1.1, D1.3 and D1.4, which describe the global characteristics and performances to be achieved by the integrated MOVESMART system. These specifications also describe a system partitioning in connected elements (cloud services, software assets, Eclipse plugins, etc.) and describes the information flow between them. In other words, it describes the interfaces between the various elements of the overall system.

2. Subsystem characteristics specifications (D1.3): these specifications detail the organization in modules of the different subsystems defined in specifications document: block-diagram of internal organization in modules and sub-modules, description of external interfaces of the subsystem, description of the interfaces of each module.

3. Global and detailed Implementation specifications of modules and sub-modules: this is usually a document from which the software is derived.

4. Software Modules.

4.2 Applicability of the procedure

The documents are specified, i.e. for (1) on project level, for (2) on WP level, for (3) on partner level, and for (4) on the team inside a partner’s company level.

The present change control procedure deals only with the first two levels: the project and the WP level. It assumes that there is a similar internal procedure in each partner’s side to coordinate the changes between the different development teams, when there are several.

The basic rules to be observed by the partners are:

Any change which affects the external behavior, for instance the interfaces of the unit, subunit or module concerned must be handled according to the present procedure;

Any change affecting the performance (e.g. response time, memory size) (which is another form of external behaviour) must undergo the present change procedure;

Any implementation change which does not affect the external behaviour of the network/element/module/sub-module is left to initiative of the designer or the local management.

It is however to be noted for the last point that, if the change has an impact on planning, it has to undergo the change control procedure. There is a typical example of such a change usually not affecting (supposedly) the external performance of module or sub-module: it is up to a team to


D1.2: Page [39] of [54]

optimize the performance after several modifications. This usually results in a new module or sub-module release with an impact on the planning or cost. It must therefore be handled (agreed and organized) on the project level.

4.3 Handling necessary changes during the Development Process

When a development team needs to implement a change, which will affect or is likely to affect the external performance of the module it is developing (i.e. with an impact on the work of the other partners on the WP or project levels), the procedure as indicated is launched:

1. It issues a Change Proposal (CP) (cf. Annex III) which it addresses to the relevant WPL, with a copy to the other partners of that work package.

2. The WPL analyzes the proposal, consults the other WP partners and tries to achieve a consensus internal to this WP on the change proposal. This may lead to modifications either to the proposed change or to its proposed implementation. The WPL then transmits the Change Request to the Core Group.

3. The Core Group organizes a review of the Change Request. Based on technical, planning or development cost parameters, the Core Group makes a motivated decision and notifies the decision on the project level:

In case of non OK, he distributes the corresponding information on the project level with the rationale having led to the NON-OK decision;

In case of OK, the Core Group changes the CHANGE REQUEST into a CHANGE NOTIFICATION and distributes it on the project level.

4. A Change Notification becomes mandatory. It usually entails modifications/updates to released specifications of deliverables which need to be done subsequently in an organized way, in order to keep the documentation coherent.

4.4 Numbering or Change Requests and Notifications

A Change Request has the following numbering scheme, as indicated in the numbering of the template:

MOVESMART_WPx_CRxz_deliverable number_partner_date_p.doc

For a Change Notification, the CR in the former name is changed into CN, p (for Preliminary) is changed in r (released), the rest is left unchanged.

MOVESMART _WPx_CNxz_deliverable number_partner_date_r.doc


D1.2: Page [40] of [54]

References

[1] Project Contract GA 610717

[2] Project Contract - Annex 1 “Description of the Work” (DoW)

[3] MOVESMART Consortium Agreement (CA)

[4] MOVESMART Deliverable D1.1: “Project Reference Manual”, Report, Public.

[5] Walters, W. H. (2011). Comparative recall and precision of simple and expert searches in Google Scholar and eight other databases. portal: Libraries and the Academy, 11(4), 971-1006.

[6] Van Woensel, T., & Vandaele, N. (2007). Modeling traffic flows with queueing models: a review. Asia-Pacific Journal of Operational Research, 24(04), 435-461.

[7] Vlahogianni, E. I., Golias, J. C., & Karlaftis, M. G. (2004). Short‐term traffic forecasting: Overview of objectives and methods. Transport reviews, 24(5), 533-557.

[8] Delling, D., & Wagner, D. (2009). Time-dependent route planning. In Robust and Online Large-Scale Optimization (pp. 207-230). Springer Berlin Heidelberg.

[9] Spyros Kontogiannis and Christos Zaroliagis. Distance oracles for time-dependent networks. In J. Es- parza et al. (eds.), ICALP 2014, Part I, volume 8572 of LNCS, pages 713-725. Springer-Verlag Berlin Heidelberg, 2014.

[10] Luca Foschini, John Hershberger, and Subhash Suri. On the complexity of time-dependent shortest paths. Algorithmica, 68(4):1075-1097, 2014. Preliminary version in ACM-SIAM SODA 2011.

[11] Frank Dehne, Omran T. Masoud, and Jorg-Rudiger Sack. Shortest paths in time-dependent FIFO networks. ALGORITHMICA, 62(1-2):416-435, 2012.

[12] Daniel Delling. Time-Dependent SHARC-Routing. Algorithmica, 60(1):60-94, May 2011. Special Issue: European Symposium on Algorithms 2008.

[13] Giacomo Nannicini, Daniel Delling, Dominik Schultes, and Leo Liberti. Bidirectional A* Search on Time- Dependent Road Networks. Networks, 59:240-251, 2012. Journal version of WEA'08.

[14] Gernot Veit Batz, Daniel Delling, Peter Sanders, and Christian Vetter. Time-Dependent Contraction Hierarchies. In Proceedings of the 11th Workshop on Al gorithm Engineering and Experiments (ALENEX'09), pages 97-105. SIAM, April 2009.

[15] da Graça Carvalho, M. (2012). EU energy and climate change strategy. Energy, 40(1), 19-22.

[16] COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS A Roadmap for moving to a competitive low carbon economy in 2050. Available at: http://eur-lex.europa.eu/resource.html?uri=cellar:5db26ecc-ba4e-4de2-ae08-dba649109d18.0002.03/DOC_1&format=PDF

[17] Park, K. S., & Hwan Lim, C. (1999). A structured methodology for comparative evaluation of user interface designs using usability criteria and measures. International journal of industrial ergonomics, 23(5), 379-389.

[18] Chin, J. P., Diehl, V. A., & Norman, K. L. (1988, May). Development of an instrument measuring user satisfaction of the human-computer interface. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 213-218). ACM.

[19] Jeffries, R., Miller, J. R., Wharton, C., & Uyeda, K. (1991, March). User interface evaluation in the real world: a comparison of four techniques. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 119-124). ACM.

http://eur-lex.europa.eu/resource.html?uri=cellar:5db26ecc-ba4e-4de2-ae08-dba649109d18.0002.03/DOC_1&format=PDF




D1.2: Page [41] of [54]

[20] Van Der Laan, J. D., Heino, A., & De Waard, D. (1997). A simple procedure for the assessment of acceptance of advanced transport telematics. Transportation Research Part C: Emerging Technologies, 5(1), 1-10.


D1.2: Page [42] of [54]

A. Annex I – MOVESMART Deliverable Template


D1.2: Page [43] of [54]


D1.2: Page [44] of [54]


D1.2: Page [45] of [54]


D1.2: Page [46] of [54]


D1.2: Page [47] of [54]


D1.2: Page [48] of [54]

B. Annex II – MOVESMART Presentation Template


D1.2: Page [49] of [54]

C. Annex III –Change Request or Notification



Grant Agreement No: 609026

Collaborative Project


CHANGE REQUEST or NOTIFICATION

Annex X to deliverable DX.x

Work package WPx – WP Title

Task Ta.b

Version p, d, d1, …, R

Created Date dd/mm/yyyy

Request Made By PARTNER_ACRONYM (according to the DoW)

Contributing Partners PARTNER_ACRONYM_1, …, (according to the DoW)

Date of DECISION dd/mm/yyyy

*Version:

Preliminary,

Draft 1, Draft 2,…,

Released


D1.2: Page [50] of [54]

Executive Summary: This sheet records Change Request made by a partner and/or the decision made and is to be annexed to the main deliverable concerned;

Description of the problem:

Description of the proposed solution:

Estimated impact:

Impact on technical performance

Impact on planning

Impact on cost

Impact on work of other partners (interfaces)

WPL recommendations:

PMC Decisions: OK / NON OK

List of documents to be updated:


D1.2: Page [51] of [54]

D. Annex IV – MOVESMART Deliverable Peer Review Report Template



Grant Agreement No: 609026

Collaborative Project


Deliverable Peer Review Report

Deliverable no. Deliverable Title:

Deliverable Manager: The name of the DM Deliverable Author(s): the first author is the responsible author – the leading figure –

and the rest are listed in (decreasing) order of contribution Nature: R

Dissemination Level: PU Version #: X.Y

Date of Review: dd/mm/yyyy WP number and Title:

Deliverable Leader: (short name)


D1.2: Page [52] of [54]

Procedures Used for Peer Review

The MOVESMART Consortium uses the Peer Review process for its internal quality assurance for deliverables to assure consistency and high standard for documented project results.

The Peer Review is processed individually by selected reviewers. The allocated time for the review is about two weeks. The author of the document has the final responsibility to collect the comments and suggestions from the Peer Reviewers and decide what changes to the document and actions are to be undertaken.

Reviewer Name:

Name - affliliation

Overall Review Results

The deliverable is:

Fully accepted Accepted with reservation

Rejected unless modified as suggested

Rejected

Please provide an overall rating of this deliverable in a scale from 1 (very poor) to 10 (excellent): (e.g. 8)

Summary of Suggested actions to the authors:

1. The following changes should be implemented:

2. Specify missing chapters / subjects:

3. Required changes on deliverable essence and contents:

4. Further relevant required improvements:

5. The reviewer provides specific comments within the document if appropriate (please specify Y or N).

YES NO


D1.2: Page [53] of [54]

Detailed Review Results

Comments

General comment The deliverable represents interesting scientific work of high quality…

Specific comments

Criterion 1: Relevance.

Please comment on the relevance of this deliverable to its objectives as these are stated in the DoW.

Reviewer comments:

Author response:

Criterion 2: Methodological framework soundness

Please comment on the soundness of the methodology followed and how it is explained. "Are the results arbitrary or based upon a clear methodology?"

Reviewer comments:

Author response:

Criterion 3: Quality of achievements

Please comment on the essence of the results. "Are they of high value? Are they what one should expect?" Does the deliverable achieves its objectives?

Reviewer comments:

Author response:

Criterion 4: Quality of presentation: Results / Layout / Language / Format

Please comment on the presentation of the results. Is there a link between methodology and


D1.2: Page [54] of [54]

results? Also comment on the deliverables layout. "Does it include all necessary chapters, is it readable, in comprehensive language, etc.?"

Reviewer comments:

Author response:

renewable mobility services in smart...

Documents