#  Introduction

##  Executive summary

The Project Coordinator (CRF) is responsible for technical coordination and
scientific quality assurance throughout the project. This task involves
monitoring of the technical progress, coordinating data management, the
various work packages and tasks, and risk monitoring. When necessary
corrective actions will be taken including potential work reallocation which
will be coordinated by the Project Coordinator and agreed by the Executive
Board consisting of all WP leaders. An approval procedure was defined during
the kick-off meeting and it has been agreed that the Executive Board is the
body for quality assurance in line with the Consortium Agreement. D1.1 the
Quality Assurance Guideline contains more information on the related internal
roles, rules and procedures.

This Deliverable report addresses both the risk and data management plans and
includes definitions and details of the processes being implemented with
respect to the GHOST project.

The Risk Management Plan (RMP) is an on-going process which is continuously
updated throughout the lifetime of the project to monitor known risks,
identify emerging risks, and where necessary to respond to them. As part of
the risk management plan, a risk register is compiled from risks identified in
the GHOST Grant Agreement, Deliverables to date, and from risks which are
identified during the course of the project. This register is monitored and
discussed during the Executive Board meetings and adjusted when necessary.

The Data Management Plan (DMP), which is also an on-going process, defines how
different project data will be handled during the project and aims to ensure
the appropriate level of access to and re-use of data generated by the GHOST
project in particular with respect to the public domain Deliverable reports.
The Project Coordinator (CRF) is responsible for the implementation of the DMP
and its coordination is assisted by the Executive Board.

Both the RMP and DMP should be considered to be complimentary with respect to
the other

Deliverable reports and in particular Deliverable D1.1 “Quality Assurance
Guidelines” and D9.2

“Dissemination and communication plan”. Furthermore, all the partners have
signed a Consortium Agreement, in which all relevant issues necessary for the
proper execution of the project are described in detail including: the
responsibilities (General Assembly, Project Coordinator and individual
parties), liabilities, voting rules, intellectual property rights (IPR),
knowledge management, rules for publishing information, conflict resolution,
etc.

#  Overview of the GHOST Project

##  Objectives and Scope

The aim of the GHOST project is to develop an InteGrated and PHysically
Optimised Battery System for Plug-in Vehicles Technologies.

The overall objectives of the GHOST project, looking at both the existing Li-
ion battery technologies and the future commercial post-lithium-ion ones, are:

  * Design of a novel and modular battery system with higher energy density (in weight) up to 20% based on the state- of-the-art of lithium-ion battery cell technologies through: 

  

Implementation of advanced light and functionalized battery system (BS)
housing material;

Innovative, modular, energy and cost efficient thermal management
architectures & strategies;

Optimal selection of the right battery cell technology for different
applications and use-cases that will be demonstrated in the proposed project;

  * Increase of the energy density of the battery system up to 30% based on novel Dual Battery System concept based on new emerging battery technologies and high power lithium-ion battery; 

  

  * Development of mass producible innovative and integrated design solutions to reduce the battery integration cost at least by 30% through smart design: starting from cell up to recycling, testing and modelling approaches; 

  

  * Definition of new test methodologies and procedures to evaluate reliability, safety and lifetime of different Battery Systems; 

  

  * Design of novel prototyping, manufacturing and dismantling techniques for next generation of lithium-ion BS; 

  

Evaluation of 2nd life battery potential, applications and markets starting
from requirements and specifications;

Demonstration of GHOST solutions in two demonstrators (BEV bus with ultrafast
partial charge capability and P-HEV) and one lab demonstrator (module level)
for the post Lithium-Ion technology.

The aim is to achieve these key innovations at affordable cost in order to
strengthen Europe’s competitive position in terms of Battery System, a crucial
field for electrified vehicles.

Technologies developed in the frame of the project will aim for first market
introduction between 2023 and 2024.

Importantly, the technology devised will have a strong impact on the
electrically chargeable vehicles (BEVs and P-HEVs) performance increase
(including range and related battery lifetime and reliability).  
  
<table>  
<tr>  
<th>

Aim

</th>  
<th>

GHOST Objective

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

Thermal, electrical and mechanical design of battery systems based on lithium
and post lithium cells aiming at highly increased energy density and
modularity

</td>  
<td>

Mechanical design:

Replacement of bulky and heavy housings that are used in the current
conventional BS by reliable and functionalized lightweight materials,
contributing up to 30% weight reduction and provide improved safety by higher
specific energies;

Redesign of the BS by using novel materials at module level to reduce further
the weight up to 20% and to maintain the required mechanical stability and
safety.

PCM

with

Al-foam

Cell

Cooling

system

Al

plates

Thermal design:

Development of a module level novel and modular thermal management through
advanced thermal concepts, which is independent of the cooling concept

and selected media;

Adaptive and smart active control of the cooling circuit pumps/fans;

Thermal management design for bus and future BEVs fast charging (up to 350-450
kW).

Electrical design:

Development of a modular battery module architecture (i.e. 48V), which can be
easily scaled up to 400-800 V with full commonalities in the field of used
mechanical connections between the cells, fuses, safety, and battery
controller unit concept;

Novel Dual-Cell-Battery architecture

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

Battery cost reduction

</td>  
<td>

Implementation of intelligent more integrated and simplified harness sensing
and communications (i.e. for temperature

and state of heath estimation) with high reliability;

Complete redesign of the BS by taking into account the dismantling and
recycling aspects

(reduction of integration cost up to 20% and reduction time up to 30-40%);

Standardized and innovative parameterization test protocols, models and state
functions which can speed up the battery module and system development process
by 20% compared to SoA contributing to reduce the integration cost as a
consequence;

Defining the needs to be taken into account to obtain a modular balancing
concept solution suitable for automotive and second life applications;

Improved modelling and simulation tools for BS improvement/development using
virtual modelling approach, which is mainly based on the concept of
Simulation-In-Loop (SIL), addressed through the application of the knowledge
that will be generated in the project on thoroughly insight ageing mechanisms,
SoH, SoC, SoF and electro-thermal modelling.

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

Aim

</th>  
<th>

GHOST Objective

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

Design for manufacturing, recycling and second use

</td>  
<td>

In the GHOST Project, efficient manufacturing processes will be applied for
the BS that will be designed taking into account the best experiences in the
field.

In addition, the manufacturing will be processed in such way towards recycling
in a cost efficient way thanks to the innovative solution of the physical
integration of battery modules.

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

Prototyping and mass-production technologies for battery systems

</td>  
<td>

New environmental friendly design of prototyping and manufacturing processes
of BS for automotive will be considered and analysed;

Identification of the cost efficient BS solution for mass-production.

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

Demonstration of performance, lifetime and safety behaviour including lab
testing and demonstration under real life conditions in vehicles

</td>  
<td>

Demonstration of GHOST BS solutions at lab level (TRL 5) and within 2
demonstrators (PHEV

500X and BEV bus) under real life conditions based on performances and
operational/functional safety.

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

Advanced physical integration technologies for high energy/power density
battery packs should take into account safety and modularity

</td>  
<td>

Development of a Novel Dual-Cell-Battery architecture for next generation BS
that comprises high-power (HP) battery and next generation high-energy battery
technologies (HE) with highly integrated and efficient physical integration
thanks to advanced DC/DC converter based on newest semiconductors technologies
(Si and WBG technologies). This concept will be demonstrated at lab level (TRL
4).

The integration, manufacturing and safety methodology aspects considered for
lithium-ion technology will be transferred for the Dual-Cell-Battery
architecture.

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

Demonstration of performance, lifetime and safety behaviour including bench
testing and demonstration under real life conditions in

</td>  
<td>

Test methodologies and procedures to evaluate the functional safety and
lifetime of the battery from cells, modules to system levels:

Advanced and reliable standardized test procedure focusing on lifetime,
safety, reliability for Liion and post Li-ion as well. New technologies may
need new accurate and reliable testing methods and evaluation procedures to
reflect real-life scenarios, because different C-rates, operation
temperatures, safety limits, etc. are required to verify the operational BS.
More realistic test methods can decrease testing time and enhance safety and
competitiveness;

Moreover, the novel BS architecture will require devoted new procedures for
the experimental evaluation to be applied in the validation phase;

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

Aim

</td>  
<td>

GHOST Objective

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

vehicles

</td>  
<td>

Reliability enhancement due to:

BS with less external and internal connections (i.e. advanced harness sensing
for temperature), cabling, components and also for the vehicle protection
relays architecture; Innovative simplified connection methods between BS and
battery controller unit.

Safety improvement thanks to:

In GHOST project, novel thermal-management architectures and strategies will
be implemented to increase the safety and to guarantee insulation protection;

Battery state function will be implemented to detect possible failure
mechanisms;

The battery system will be investigated in depth based on the functional
safety during the verification, validation and integration within the vehicle.

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

##  Workplan Overview

  * PHASE I: Define the specifications starting from the requirements and constraints (WP2); 

  

  * PHASE II: Define the modular novel BS architecture for lithium based technology (WP3): 

  

New functionalized lightweight materials for reducing the weight/volume of the
BS;

Novel and cost efficient modular Thermal Management at battery module level
that can be used for different types of vehicles (i.e. 400 or 800V) through
refrigerant direct cooling or liquid cooling, depending of the application
requirements;

Advanced modular electric design which can guarantee higher level of safety
and simplification of the battery system;

Modular battery system approach for current and midterm lithium-ion battery
technology; Recycle and reuse design approach for cost reduction; Eco-design
analysis of the selected material.

  * PHASE III: Advanced prototyping and manufacturing of processing of BS and verification (WP3 & WP4): 

  

Integration of the developed state functions and harness sensing in the
battery controller unit; Prototyping battery systems towards manufacturing
processes;

  * PHASE IV: Evaluation of the safety requirements of the battery system at controlled environment (WP5); 

  

  * PHASE V: Integration within the vehicle and demonstration in real environment (WP6); 

  

  * PHASE VI: Analysis of recycling and second use of batteries at end of first life in the vehicle (WP4, WP7); Implementation and exploitation of the results and disseminate the findings (WP9). 

  

  
<table>  
<tr>  
<th>

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

GHOST Work Breakdown Structure

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

##  Expected Impacts of the GHOST Project  
  
<table>  
<tr>  
<th>

Expected impact

</th>  
<th>

GHOST

Contribution

</th>  
<th>

Related Deliverables

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

Battery integra- tion costs (ex- cluding cell cost) reduced by 20 to 30%

</td>  
<td>

Implementation of intelligent harness sensing (i.e. for temperature and state
of heath estimation) with high reliability and safety;

Complete redesign of the battery system by taking into account the dismantling
and recycling aspects (like reduction of integration cost up to 20% and
dismantling time by 30-40%);

Standardised and innovative parameterization test protocols and models that
work with existing and next generation cell technologies (such as lithium
sulphur or next generation) and which can speed up the battery model
development process by 20% compared to state of the art models. Thus, the
proposed solution will contribute to reduce the integration cost and the
development time;

Defining the needs to be taken into account in order to obtain a modular
balancing concept solution suitable for automotive and second life
applications;

Improved modelling and simulation tools for battery system improve-
ment/development thanks to the use of virtual modelling approach, which is
mainly based on the concept of Simulation-in-Loop (SiL), addressed through the
application of the knowledge that will be generated in the project on
thoroughly insight ageing mechanisms, SoH, SoC, SoF and electro-thermal
modelling.

</td>  
<td>

D3.4

D3.1

D4.1

D4.5

D4.5

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

Strengthening the EU value chain, from design and manufacturing to dismantling
and recycling.

</td>  
<td>

Efficient manufacturing processes will be considered for the BS that will be
designed taking into account the best experiences in the field. In addition,
the manufacturing will be processed in such way towards recycling in a cost
efficient way thanks to the innovative solution of the physical integration of
battery modules;

New design of prototyping and manufacturing processes of battery system for
automotive will be considered and analysed;

Identification of new cost-efficient BS for mass production.

</td>  
<td>

D3.6

D3.7

D8.2

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

Contributing to climate action and sustainable development objectives

</td>  
<td>

A modular battery system will be designed that targets weight reduction. The
newly integrated battery system will not only be more efficient on pack level;
the increased total energy density will also yield a significant improvement
of the overall vehicular energy efficiency and the upstream CO2 emissions
linked to the generation of the electricity used during charging of the
vehicles.

</td>  
<td>

D3.5

D7.1

D7.2

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

Contributing to climate action and sustainable development objectives

</td>  
<td>

The GHOST proposal will investigate how reusing and refurbishing second-life
batteries can be enabled (reducing barriers and gaining leverages) in order to
meet specific sustainability goals. The dismantling process of a module will
be simplified to decrease the handling cost for second life usage. The
manufacturing of components and the mining of materials of the battery system
have an important environmental and social impact. Optimizing the usage and
need of these materials and components with a circular approach has the
potential to reduce the environmental and social impacts significantly.

</td>  
<td>

D3.5

D7.1

D7.2

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

Expected Impact

</th>  
<th>

GHOST

Contribution

</th>  
<th>

Related deliverables

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

Energy density improvement of battery packs in the order of 15 to 20%

</td>  
<td>

Mechanical design:

Replacement of bulky metallic housing of battery system that are used in the
current or conventional battery systems (i.e. BMW i3 or TESLA) by reliable and
lightweight materials, which will contribute up to 30% weight reduction;

Redesign of battery system by using novel materials such as Al-foam at module
level to reduce further the weight up to 20% and to maintain the required
mechanical stability and safety according to the standards of on-road
vehicles.

Thermal design:

Optimization of thermal management through efficient integration of phase
change materials (PCM) into Al-foam to increase the thermal buffer on one hand
and to simplify the thermal architecture on another hand. The incorporated PCM
inside Al-foam will be coupled with refrigerant or liquid cooling at the
bottom of the battery module to achieve an efficient cooling concept;

Adaptive and smart active control of the cooling circuit pumps/fans;

Design of thermal management applicable for fast charging opportunities.

Electrical design:

Development of a modular battery module architecture (i.e. 48V), which can be
easily scaled up to 400-800V or high capacity applications with full
commonalities in the field of used mechanical connections between the cells,
fuses, safety, and opti- mised electrical integration and control thanks to
battery control system (BCS);

Novel Modular Dual Battery System architecture composed by one high-power (Li-
Ion) and one high-energy (Li-Sulphur) battery modules, combined by a DC/DC
converter with integrated control unit.

</td>  
<td>

D3.1 D3.2

D3.3 D3.4

D8.1 D8.2 D8.3

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

#  Risk Management

##  Introduction

Risk is defined as an event that has a likelihood of occurring, and could have
a negative impact on a project. A risk may have one or more causes and, if it
occurs, one or more impacts. All projects assume some element of risk, and
it’s through risk management to monitor and track those events that have the
potential to impact the outcome of a project.

Risk management has four stages: risk identification, analysis, evaluation and
mitigation underpinned by continuous monitoring and control. These stages are
described below in more detail as well as the roles and responsibilities
connected to the risk management.

Figure 1: Stages of risk management

Risk management is an on-going process that continues throughout the life of a
project. It includes processes for risk management planning, identification,
analysis, monitoring and control. It is the objective of risk management to
decrease the likelihood and impact of events averse to the project. On the
other hand, any event that could have a positive impact should be exploited.

##  Types of Risk

Typically the risks in a technical research and innovation project of this
type include:

  * Technological risks 

  

  * Partnership risks 

  

  * Market risks 

  

  * Legal risks 

  

  * Management risks 

  

  * Environmental/regulation /safety risks 

  

The purpose of this document is to describe the procedures being implemented
within the GHOST project for identifying and handling risks. This risk
management plan applies to all partners in the project.

##  Risk likelihood

The risk likelihood is the chance that a risk will occur in the life time of
the project. The following chart shows the risk likelihood definitions. For
each of the identified risks the potential likelihood that a given risk will
occur must be assessed, and appropriate risk likelihood is selected from the
chart below.  
  
<table>  
<tr>  
<th>

**Likelihood Category**

</th>  
<th>

**Description**

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

Certain

</td>  
<td>

Risk event expected to occur

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

Likely

</td>  
<td>

Risk event more likely than not to occur

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

Moderate

</td>  
<td>

Risk event may or may not occur

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

Unlikely

</td>  
<td>

Risk event less likely than not to occur

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

Rare

</td>  
<td>

Risk event not expected to occur

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

**Table A: Risk Likelihood**

##  Risk impact

The risk impact is the cause or effect of the risk in the project’s progress.
It is classified in five levels:

  * Very serious: The risk would jeopardize the project’s continuity or would significantly affect the projects outcomes. A very serious impact would be that the project needs to stop. 

  

  * Serious: The risk would jeopardize the project’s continuity or would significantly affect the project outcomes. Usually, when a serious impact risk occurs, there is a need of changing the project contract, eg. one of the partners abandons the project. 

  

  * Moderate: the risk has a significant impact on the project, but it is perceived that the objectives will be still achieved eg. difficulties of defining RTD specifications lead to 6 months delay. 

  

  * Slight: the effect on the project is minor e.g. a task leader drops out the project. 

  

  * Low: the effect on the project is negligible, e.g. Shift of budget between partners. 

  

The complexity, the technical challenges and the size of GHOST require an
adequate risk management. It is therefore necessary that potential risks are
clearly identified, assessed, and that possible recovery actions be prepared.
Potential risks can be related to delays, performance, collaboration and
management. Risk is by definition the product of Probability and Impact. A
preliminary analysis of GHOST risks associated with the work plan and using a
Risk ProbabilityImpact Matrix approach is presented by a sequential step-
approach:

  * Identify potential impacts of risks; 

  

  * Evaluate Probability Impact Scores; 

  

  * Prioritize Risks for Management Action; 

  

  * Determine risk mitigation measures into actions. 

  

  
<table>  
<tr>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

IMPACT

</th>  
<th>

</th>  
<th>

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

TRIVIAL

</th>  
<th>

MINOR

</th>  
<th>

MODERATE

</th>  
<th>

MAJOR

</th>  
<th>

EXTREME

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

PROBABILITY

</td>  
<td>

RARE

</td>  
<td>

LOW

</td>  
<td>

LOW

</td>  
<td>

LOW

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

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

UNLIKELY

</td>  
<td>

LOW

</td>  
<td>

LOW

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

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

MODERATE

</td>  
<td>

LOW

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

HIGH

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

LIKELY

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

HIGH

</td>  
<td>

HIGH

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

VERY LIKELY

</td>  
<td>

MEDIUM

</td>  
<td>

MEDIUM

</td>  
<td>

HIGH

</td>  
<td>

HIGH

</td>  
<td>

HIGH

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

**Table B: Probability-impact matrix**

##  Specific aspects of the GHOST Risk Management Plan

###  Roles and responsibilities

All project partners should identify the project risks and give input to the
reports concerning those risks. The risks must be defined and reported through
the progress report template, indicating its risk likelihood, impact,
contingency plan, and responsible partner and in what period of the project
the risk is valid and should be monitored.

The Project Coordinator (CRF) with the support of the Back Office (VUB) will
review and assess the identified risks. If necessary, feedback will be
provided to the identified responsible partner. If the risk exposure is
critical or there is a need for further discussion, the Project Coordinator is
responsible for raising the issue during the Executive Board and Consortium
meetings (i.e. General Assembly’s and/or Progress Meetings). In that case, the
mitigation plan must be established through a consensus decision process, and
it may require the involvement of the Project Officer and all the partners.

###  Reporting and monitoring

The risks must be identified and reported as part of the progress reports
which are scheduled at nominally 6-month intervals in conjunction with the
General Assembly meetings. All project partners are required to participate in
the identification of the project risks and give input to the progress reports
regarding those risks.  
  
<table>  
<tr>  
<th>

**Updates of the RMP**

</th>  
<th>

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

**Version number**

</td>  
<td>

**Project month**

</td>  
<td>

**Nature**

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

**1**

</td>  
<td>

M8

</td>  
<td>

Original version

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

**2**

</td>  
<td>

M12

</td>  
<td>

Update

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

**3**

</td>  
<td>

M18 – RP1

</td>  
<td>

Update

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

**4**

</td>  
<td>

M24

</td>  
<td>

Update

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

**5**

</td>  
<td>

M30

</td>  
<td>

Update

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

**6**

</td>  
<td>

M36 – RP2

</td>  
<td>

Update

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

**7**

</td>  
<td>

M42 – RP3

</td>  
<td>

Update

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

###  The Risk Management register

The risks are registered in a repository that is presented below.

The Risk Management register is available on EMDESK, on the online management
platform used for GHOST. Work Package leaders are expected to collect feedback
from the partners involved in their Work Packages, revise and if necessary
update the register at the end of each bi-annual internal reporting period.

**Figure 2: Risk register on EMDESK**

###  Foreseen risks

An overview on significant risks and associated contingency plans is given in
the Table below. The project management approach provides mechanisms to
identify and resolve potential risks, such as continuous controls of the
project plan with its milestones and key deliverables. The progress and
resource reporting will enable the Project Management team (i.e. Coordinator,
Back-office and Executive Board) to be continuously aware of potential
problems. Hence, the team can initiate countermeasures in a timely fashion
before a problem becomes jeopardizing and fall-back solutions can be defined
and implemented in time.  
  
<table>  
<tr>  
<th>

**No.**

</th>  
<th>

**Description of risk**

</th>  
<th>

**WP**

</th>  
<th>

**Risk-mitigation measures**

</th>  
<th>

**Probability**

</th>  
<th>

**Effect**

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

**Delays**

</td>  
<td>

</td>  
<td>

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

1 Delays in providing the All Track development progress and components in
time for focus efforts especially in the most following WPs activities
sensible components.

</td>  
<td>

Medium

</td>  
<td>

High

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

**Performance**

</td>  
<td>

</td>  
<td>

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

2

</td>  
<td>

Detail level of component models when relevant data is not being supplied by
the partners

</td>  
<td>

All

</td>  
<td>

Setup 1:1 confidentiality agreements where needed.

</td>  
<td>

Medium

</td>  
<td>

Medium

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

3

</td>  
<td>

Integration effort of the components higher than expected

</td>  
<td>

WP3, WP7

</td>  
<td>

Upfront virtual design validation need to be applied where possible.

</td>  
<td>

Medium

</td>  
<td>

Medium

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

4

</td>  
<td>

Final assessment does not show expected target

</td>  
<td>

WP3,

WP7,

WP8

</td>  
<td>

Re-evaluation of specification and recommendations for future improvement.

</td>  
<td>

Medium

</td>  
<td>

Medium

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

5

</td>  
<td>

Component failure during

</td>  
<td>

WP3,

</td>  
<td>

Since from the proposal phase,

</td>  
<td>

Medium

</td>  
<td>

Medium

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

**No.**

</td>  
<td>

**Description of risk**

</td>  
<td>

**WP**

</td>  
<td>

**Risk-mitigation measures**

</td>  
<td>

**Probability**

</td>  
<td>

**Effect**

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

</td>  
<td>

testing

</td>  
<td>

WP4,

WP7,

WP8

</td>  
<td>

the potential component failure critical pathways have been identified and the
availability of a proper number of spare parts to avoid delays on the Project
timing have been planned.

</td>  
<td>

</td>  
<td>

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

6

</td>  
<td>

Bench devices failure during testing

</td>  
<td>

WP3,

WP7,

WP8

</td>  
<td>

Back-up plan for alternative test capabilities.

</td>  
<td>

Low

</td>  
<td>

Low

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

7

</td>  
<td>

Availability of high quality li-ion cells

</td>  
<td>

WP3, WP4

</td>  
<td>

Back-up suppliers involvement.

</td>  
<td>

Low

</td>  
<td>

High

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

8

</td>  
<td>

Availability of high quality Li-S cells proto

</td>  
<td>

WP8

</td>  
<td>

Contact with different possible Projects, organisations able to supply proto
cells.

</td>  
<td>

Medium

</td>  
<td>

Medium

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

**Collaboration**

</td>  
<td>

</td>  
<td>

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

9 Poor cooperation ALL In the monthly WP leader phone between partners calls,
the effectiveness of the

partner interactions will be continuously monitored. If this problem happens,
it will be managed identifying the reasons why and solving them at WP level or
at Project level depending on which are the involved partners and the nature
of the problem.

</td>  
<td>

Low

</td>  
<td>

High

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

**Management**

</td>  
<td>

</td>  
<td>

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

10

</td>  
<td>

Partners leave or Partners become insolvent

</td>  
<td>

ALL

</td>  
<td>

Back-up partners list or inside Consortium solution.

</td>  
<td>

Low

</td>  
<td>

High

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

**Table C: List of foreseen risks and associated mitigation measures**

###  Preliminary Identification of Risks

As indicated in the Grant Agreement, the GHOST Project consortium has
identified at a preliminary stage some of the main barriers, obstacles and
framework conditions that may limit and/or reduce the level of achievement of
the previously described expected impacts.

The achievement of the potential impacts that will be demonstrated via the
GHOST project is dependent upon the market adoption of the technologies.
Therefore, anything putting at risk their cost effective realization can be
considered as potential barrier or obstacle. In particular there are foreseen
to be:

  * The lack of industrial and international standards for the investigated architecture solution to set certain technical specifications, dimensions, and mechanical, electrical, and communication interfaces. Without a standard, OEMs and suppliers will be cautious in their development programs because of the financial risks associated with the risk not to be able to achieve economy of scale advantages; 

  

  * Uncertain deployment of the European Energy Taxation regulation (COM/2011/169 and COM/2011/168) and a modification of the directive 96/53/EC on weight and dimensions of commercial vehicles will result in planning uncertainty in the automotive supply chain for electrified commercial vehicles; 

  

  * The lack of homogeneous, and in some case adequate, government incentives in the different European Member States in order to stimulate the deployment of, in particular, electrified vehicles. 

  

###  International Standards

As is documented in the APPENDIX to this report, a preliminary survey of the
type approval regulatory body has been performed in order to identify any
possible hindrance to a future homologation of the developed enhanced vehicle,
taking into account those specifications and requirements which might be
affected by the introduced advanced technologies; special attention has been
paid to the hazardous aspects of the changes planned to the battery pack with
a particular focus on crashworthiness, and the protection of occupants and
vulnerable road users.

#  Data Management

##  Introduction

According to the H2020 Programme Guidelines on FAIR Data Management in Horizon
2020:

“Data Management Plans (DMPs) are a key element of good data management. A DMP
describes the data management life cycle for the data to be collected,
processed and/or generated by a Horizon 2020 project. As part of making
research data findable, accessible, interoperable and reusable (FAIR), a DMP
should include information on: the handling of research data during and after
the end of the project, what data will be collected, processed and/or
generated, which methodology and standards will be applied, whether data will
be shared/made open access and how data will be curated and preserved
(including after the end of the project).

The DMP is a living document to be updated over the course of the project
whenever significant changes arise and as a minimum in time with the periodic
evaluation/assessment of the project. The consortium will, at the time of the
bi-annual internal progress reporting assess whether the DMP needs to be
updated.

The aim of the initial version of the GHOST DMP is to provide a general
overview of data types collected and/or created by different project partners
and on the usage of such data in line with the project objectives. The Horizon
2020 FAIR DMP template has been used and as the project proceeds, more
questions will be addressed in detail, if needed.  
  
<table>  
<tr>  
<th>

**Updates of the DMP**

</th>  
<th>

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

**Version number**

</td>  
<td>

**Project month**

</td>  
<td>

**Nature**

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

**1**

</td>  
<td>

M8

</td>  
<td>

Original version

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

**2**

</td>  
<td>

M12

</td>  
<td>

Assessment whether update is needed

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

**3**

</td>  
<td>

M18 – RP1

</td>  
<td>

Update

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

**4**

</td>  
<td>

M24

</td>  
<td>

Assessment whether update is needed

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

**5**

</td>  
<td>

M30

</td>  
<td>

Assessment whether update is needed

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

**6**

</td>  
<td>

M36 – RP2

</td>  
<td>

Update

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

**7**

</td>  
<td>

M42 – RP3

</td>  
<td>

Update

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

##  The GHOST DMP  
  
<table>  
<tr>  
<th>

**Component**

</th>  
<th>

**Issues to be addressed**

</th>  
<th>

**GHOST Project DMP**

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

1\. Data summary

</td>  
<td>

State the purpose of the data collection/generation

</td>  
<td>

A wide variety of technical data will be collected, primarily via simulation
and experimental testing during the activities of the project primarily to
enable direct comparison, in order to validate the simulation models, and to
evaluate the performance of the technical solutions developed.

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

Explain the relation to the objectives of the project

</td>  
<td>

The generation of data through the testing and simulation activities will
focus on evaluating the performance of the innovative battery systems
developed during the project. In this context, the generation of data is
directly relevant to the objectives of the project.

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

Specify the types and formats of data generated/collected

</td>  
<td>

The exact types and formats of the data generated/collected, whether any
existing data is being re-used, the origin of the data, and the expected size
of specific databases, will be defined in due course as a result of the
testing and simulation activities which are planned to be conducted throughout
the project.

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

Specify if existing data is being reused (if any)

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

Specify the origin of the data

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

State the expected size of the data (if known)

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

Outline the data utility: to whom will it be useful

</td>  
<td>

The data will be primarily of use to the partners within the GHOST consortium,
bearing in mind that the exchange of technical information is effectively one
of the fundamental and essential elements of a collaborative technical
research project.

Furthermore key data generated within the project, and reported within the
Public (PU) Domain Deliverable reports, are likely to be useful to other
stakeholders external to the GHOST consortium working in fields related to the
development and deployment of battery systems for

(primarily) automotive applications.

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

2\. FAIR Data

</th>  
<th>

</th>  
<th>

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

2.1 Making data findable, including provisions for metadata

</td>  
<td>

Outline the discoverability of data (metadata provision)

</td>  
<td>

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

Outline the identifiability of data and refer to standard identification

mechanism. Do you make use of persistent and unique identifiers such as
Digital

Object Identifiers?

</td>  
<td>

With respect to the provision and sharing of data, particularly those data
relating to Deliverable reports classified as PU, every effort will be made to
ensure that the data are easily identifiable and that standard identification
mechanisms will be used.

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

Outline naming conventions used

</td>  
<td>

Together with the creation and making available of data generated within the
project, the naming conventions used will be specified. At this stage, the
approaches being adopted for keyword searching and versioning will be
specified if appropriate.

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

Outline the approach towards search keyword

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

Outline the approach for clear versioning

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

Specify standards for metadata creation (if any). If there are no standards in
your discipline describe what type of metadata will be created and how

</td>  
<td>

In this context it is assumed that the term metadata refers to “data
[information] that provides information about other data”. With respect to
this specific project, no specific existing standards are known. Nevertheless,
if and when metadata are created, the approach adopted will be specified.

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

2.2 Making data openly accessible

</td>  
<td>

Specify which data will be made openly available? If some data is kept closed
provide rationale for doing so

</td>  
<td>

The data which will be made openly available will correspond to the
Deliverables that are classified as PU and hence will be in the Public Domain.

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

Specify how the data will be made

</td>  
<td>

The data will be made available using the EMDESK platform

( _https://www.emdesk.com/en/_ ) which is the instrument

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

</th>  
<th>

available

</th>  
<th>

selected for the storage and exchange of all key documents and information
within the project.

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

Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?

</th>  
<th>

The EMDESK platform which will be used for data storage and exchange is a
standard instrument which can be accessed directly. Should any specific
instructions be required to facilitate data access, such as information
relating to the nature and origin of the data, then these will be provided
when the data is deposited.

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

Specify where the data and associated metadata, documentation and code are
deposited

</th>  
<th>

All relevant documentation, codes, etc. relating to the data to be made openly
accessible will be made available also within the EMDESK platform via public
links that are accesible by those external users with whom the URL has been
shared.

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

Specify how access will be provided in case there are any restrictions

</th>  
<th>

The data selected for open access relating to public-domain Deliverable
reports will be made available without restrictions. Conversely data relating
to Deliverables which are classified at Consortium-level will be stored within
the EMDESK platform with access restricted to the partners in the consortium.

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

2.3

Making data interoperable

</td>  
<td>

Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you

will follow to facilitate interoperability.

</td>  
<td>

Due to the nature of the data which will be generated, primarily from the
simulation and testing of the battery systems to be developed in the project,
the data will be strictly linked to the specific system or component under
investigation. Full details of the respective system/component and
test/simulation will be provided in the corresponding public-domain
Deliverable report relating to the data made available.

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

Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-

</td>  
<td>

Standard and conventional vocabulary, nomenclature, measurement units will be
used throughout the project. A full glossary of abbreviations and acronyms
will also be provided if and when necessary.

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

</th>  
<th>

disciplinary interoperability? If not, will you provide mapping to more
commonly used ontologies?

</th>  
<th>

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

2.4 Increase data re-use (through clarifying licences)

</td>  
<td>

Specify how the data will be licenced to permit the widest reuse possible

</td>  
<td>

Currently there are no plans to license the use of key data related to public-
domain Deliverables, but instead to allow open access to permit wide re-use
during and after the project. Should it instead become necessary to alter this
policy, and license the use of data, this will be specified in subsequent
version of the GHOST Data Management Plan.

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

Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data

embargo is needed

</td>  
<td>

In general, the data for open access will be made available for re-use once
deposited on the EMDESK platform, the timing of which would nominally
correspond to the delivery date of the public-domain Deliverable reports to
which the data is related. Should it become necessary, during the course of
the project, to alter this process, eg. delay the release of key data with
respect to when the Deliverable report is deposited, then this will be
specified in a subsequent release of the GHOST DMP.

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

Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why

</td>  
<td>

The key data which will be made publically available and hence useable by
third parties during the course of the project will be made available for
between 12 months and 36 months following project completion.

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

Describe data quality assurance processes

</td>  
<td>

The data quality assurance process is outlined below.

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

Specify the length of time for which the data will remain reusable

</td>  
<td>

Typically data will remain usable for 24 months after project completion.

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

3\. Allocation of resources

</td>  
<td>

Estimate the costs for making your data FAIR. Describe how you intend to cover
these costs

</td>  
<td>

The task of making key data from the project FAIR was envisaged from the
outset and are therefore covered by the project budget.

</td>  
<td>

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

Clearly identify responsibilities for data management in your project

</td>  
<td>

The responsibilities for data management are described below.

</td>  
<td>

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

Describe costs and potential value of long term preservation

</td>  
<td>

The cost of long-term preservation (ie. for longer than 36 months) will be
estimated if and when the need become apparent. Currently long-term
preservation is not planned since it is likely that data will become obsolete
within a 2-3 year timeframe following completion of the project due to new
technical developments and innovations.

</td>  
<td>

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

4\.

Data security

</td>  
<td>

Address data recovery as well as secure storage and transfer of sensitive data

</td>  
<td>

It is foreseen that none of the data to be stored and made available will be
of a sensitive nature.

</td>  
<td>

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

5\.

Ethical aspects

</td>  
<td>

To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former

</td>  
<td>

No aspects which may be considered to be sensitive from an ethical perspective
will be addressed during this project.

</td>  
<td>

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

6\. Other

</td>  
<td>

Refer to other national/funder/secto rial/departmental procedures for data
management that you are using (if any)

</td>  
<td>

References to other national/funder/sectorial/departmental procedures for data
management will be made in due course if used during the project.

</td>  
<td>

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

**Table D: Overview of the GHOST DMP at project launch**

##  Overview of individual WPs with respect to the generation of data

WP2 (Requirements & Specifications) collects requirements from the application
point of view, related to the vehicle demonstrators to define the Battery
System complete specification both for PHEV and BEV applications. At the same
time, the available cell technologies to target the most suitable for the
application will be investigated in order to have the most promising tested
within WP4. In parallel, in WP2 the test typologies need to assess the
technology development of GHOST versus the requirements previously listed.

In WP3 (Modular Battery Architecture, Design, Prototyping and Manufacturing),
first an investigation and an evaluation of the best suited battery module
architecture will be performed followed by a detailed design of the modular
battery modules for the targeted P-HEV and BEV battery systems. The outcome
will contain data relating to detailed mechanical, electrical and thermal
design of two battery systems based on the same flexible and scalable battery
modules that enable thermally optimized ultra-fast charging at up to 350kW
(for the BEV system).

WP4 (Battery Cell Characterization, Modelling and Testing for Automotive &
Second Life Batteries) focuses on developing a good understanding of the
behaviour of the battery cells considered in the project. In this work package
the cells will be characterized experimentally for the development of
electrical, thermal and lifetime models, hence generating data from
measurements. Furthermore, WP4 will provide the required information and
technical background regarding the thermal behaviour of the battery cells,
which in WP3 will be extended to module and battery system level. In addition,
in this Work Package dedicated analysis will be carried out on advanced
battery technologies e.g. Li-S and on considered lithium-ion battery cells
during second life.

WP5 (System Safety Validation of the Advanced Battery System) a methodology to
build-up a multiaspect system assurance case of the novel battery system will
be developed in order to demonstrate system safety for different system
environments (e.g. P-HEV, BEV) and different use cases (e.g. 1st life as
battery in the vehicle, 2nd life as storage system). A multi-concern safety
analysis approach will be then applied to perform the battery system safety
analysis; the ISO 26262 will be considered as initial base to start the
analysis, using methods, like the hazard analysis and risk assessment,
suggested by ISO 26262. The outcomes of these analyses will provide the
baseline data for performing appropriate safety analysis such as FMEA in order
to identify the safety critical elements of the general concepts. The analysis
will consider, in an integrated approach, electrical, thermal and functional
safety aspects of the battery system. A comparative analysis and impact
evaluation of installing the battery system in different system environments
on achieving system safety in different contexts will be also performed. Once
the multi-concern safety of the general concepts have been analysed, the
defined safety measures will be verified under lab conditions but with
realistic build-in and operational conditions.

WP6 (Vehicle Integration, Testing and Demonstration) focuses on the in-vehicle
integration of the previously developed and commissioned battery systems for
Li-ion applications. In WP6, actual vehicle testing activities in real
conditions, either on road or on rolling bench, will be performed and hence
measurement data will be generated.

Finally, a comprehensive assessment of the battery system versus the
specifications defined in WP2 will take place, considering all the tests
performed in WP4, WP5 and WP6 and also the outcomes of the second life testing
and analysis performed in WP7.

In WP7 (Dismantling and Second life use of batteries), dismantling studies on
existing batteries will provide data regarding how to improve battery design
of the new battery pack with the target to reduce efforts and cost at the EoL-
management including getting the new packs optimized for remanufacturing,
reparation, reuse and second life. This finally will be demonstrated by a
design approval based on dismantling studies. Furthermore a future oriented
concept for reuse and 2nd life application will be developed, technically and
commercially evaluated to show beneficial solutions for the expanded usage of
battery packs and/or valuable components after the first life.

In WP8 (Dual Battery System Design, Prototyping and Bench Testing), high power
Li-Ion and Li-S technology dual battery concept will be studied with the aim
of incrementing the energy density and efficiency of current Li-Ion-based
battery systems. The modular concept for Li-Ion technology developed in WP3 is
used and adapted for the design of a dual battery system together with the
development of a DC/DC converter that emerges in this novel system. A
validation and assessment of the novel dual battery system will be
investigated with a scaled-down prototype to carry out a quantitative
comparison between the scope of the dual battery system concept and the Li-Ion
modular one.  
  
<table>  
<tr>  
<th>

Number

</th>  
<th>

Title

</th>  
<th>

Type

</th>  
<th>

WP

</th>  
<th>

Lead partner

</th>  
<th>

Due

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

D1.2

</td>  
<td>

Risk and data management plan

</td>  
<td>

Report

</td>  
<td>

WP1

</td>  
<td>

CRF

</td>  
<td>

M6

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

D2.2

</td>  
<td>

Cells specification report for battery system prototype

</td>  
<td>

Report

</td>  
<td>

WP2

</td>  
<td>

VUB

</td>  
<td>

M6

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

D2.3

</td>  
<td>

Concept validation plan report

</td>  
<td>

Report

</td>  
<td>

WP2

</td>  
<td>

CRF

</td>  
<td>

M8

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

D3.3

</td>  
<td>

Prototyping, commissioning and functional verification of the designed battery
systems

</td>  
<td>

Demonstrator

</td>  
<td>

WP3

</td>  
<td>

AVL

</td>  
<td>

M28

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

D4.1

</td>  
<td>

Metholodology test, characterisation test and electro-thermal battery model
report

</td>  
<td>

Report

</td>  
<td>

WP4

</td>  
<td>

VUB

</td>  
<td>

M12

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

D8.2

</td>  
<td>

Assembly, commissioning of the dual cell Li-ion, Li-S battery module and
validation & assessment of the dual battery system concept

</td>  
<td>

Demonstrator

</td>  
<td>

WP8

</td>  
<td>

IKERLAN

</td>  
<td>

M40

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

D9.1

</td>  
<td>

Public website

</td>  
<td>

Website

</td>  
<td>

WP9

</td>  
<td>

VUB

</td>  
<td>

M3

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

D9.2

</td>  
<td>

Dissemination and communication plan

</td>  
<td>

Report

</td>  
<td>

WP9

</td>  
<td>

VUB

</td>  
<td>

M6

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

D9.4

</td>  
<td>

Report on liaison with ongoing relevant EU projects in the field of battery
system development and testing

</td>  
<td>

Report

</td>  
<td>

WP9

</td>  
<td>

VUB

</td>  
<td>

M42

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

**Table E: List of GHOST deliverables with Public dissemination level**

##  Quality Assurance and Responsibilities

###  Scientific and Technical Quality

The quality of the overall outcome of the project is primarily dependent upon
the quality of the execution of the innovation and demonstration activities.
Formally, the quality of the work is monitored throughout the project by the
General Assembly, the Executive Board and the Project Coordination team.
Informally, each and every project team member, including the WP leaders and
the Coordinator, has the responsibility to critically consider the quality of
the work and strive for the best possible results. Potential deviations from
the project plan must be anticipated and identified in a timely manner to
allow mitigating actions to be developed and planned. In this way, quality can
subsequently be maintained by taking suitable corrective actions to recover
the deficiency in output or time delay. In this process, particular attention
will be paid to monitoring, and supporting good communication and cooperation
between work packages in order to avoid a fragmentation of the activities,
which could lead to a mismatch between interrelated work packages.

###  Quality of Results

The formal deliverables of the GHOST project are the output of the research
and innovation activities and, as such, should be high-quality representations
of the activities undertaken. The quality of the deliverables will be managed
through a straightforward review process, which was agreed during the Kick-off
meeting, in the Consortium Agreement and described in D1.1.

The quality assurance mainly aims at the quality of deliverables by ensuring
smooth cooperation within the consortium and defining the process of decision
making and knowledge sharing. The deliverables primarily shall deliver all the
initially agreed information which is required by partners to carry out their
own work and to fulfil their obligations in the project. Furthermore, the
deliverables must be in line with the project targets.

During the Kick-off Meeting it was agreed that the Executive Board is the main
body for quality assurance. The procedure rests on the premise that the author
of the deliverable is the technical expert on the topic of the deliverable and
as such is responsible for the technical content. The work package leader
should check the deliverable, with a focus on the check with the objectives of
the work package and its fit with the overall work within the work package
(consistency check). Furthermore, all deliverables are reviewed by at least
one and ideally by two reviewer who is not directly involved in the
preparation of the deliverable. The Project Coordinator performs the final
review of the deliverable, focusing on general fit with the project
objectives. If the deliverable serves as input for other work packages, focus
should be put on whether the deliverable serves this purpose, both an a
qualitative as well as quantitative level. Subsequently, the Project
Coordinator is responsible for the delivery of the report to the EC.

Another important aspect of quality management is the administrative processes
of a project. The Project Coordinator, CRF, complies with the procedures
indicated by the ISO 9001 certified Quality System. The Project Coordinator,
strongly supported by VUB, will regularly monitor administrative processes in
such matters as finances and any legal issues which may arise. Key points to
be monitored such that the administration of the project is traceable and
justifiable include, finances, risks and risk mitigation, changes which may
affect the Grant Agreement, timing and reporting.

The Project Coordinator, CRF, with the support of the Back-Office, VUB,
coordinates the periodic management reports and the final report. In this
task, the H2020 Tool, which was specifically designed for the collection of
detailed use of resources and the technical status of projects, will be used.
The Coordinator will collect, check and send to the EC the required cost
statements, on the basis of the scheduled plan. The Project Coordinator with
the support of the Back-Office will monitor progress through the nominally
monthly Executive Board meetings, bi-annual Work Progress reports and annual
General Assembly meetings.

All finalised deliverables will be stored at the internal EMDESK platform for
partners. All public deliverables with a public (PU) dissemination level will
be made available on EMDESK via public sharing links also for external users
and will also be placed on the GHOST public website. Instead, if the
deliverable has a dissemination level of confidential (CO) only the
publishable executive summary will be placed on the public website.
Furthermore, the key data relating to the public deliverables which will be
made available according to the GHOST DMP (see Table D) will be made available
on the EMDESK platform and accessible for those who possesses the public link.

EMDESK, the GHOST platform serves as central data storage and secure
repository for document management and sharing. It allows the project partners
to define specific permissions for folders or documents, to track document
versions, share large documents or datasets, to share direct document link
e.g. via email, to make documents accessible to public via public sharing
link, to assign documents to related project items for easy and quick document
retrieval and to receive email digests on activities in the document manager.

Within the project, document templates have been developed for deliverables.
These templates can be found on EMDESK. As outlined in D1.1, documents shall
be named in a way that makes them easily identifiable and findable. Suggested
process to be used for giving titles to project documents: [Project] - [WP] -
[Document] - [Owner] - [Version].

For every deliverable the author will take the review comments into account. A
motivated explanation is required if it is not possible to process the
comments as requested by the reviewer, or if the author(s) disagree with the
comments received.

In case of remaining disagreement, the Project Coordinator will guide the
process and will ensure a convergence of the process towards a final result.

##  IPR: handling of intellectual property rights and data access

All the partners have signed a Consortium Agreement. This agreement addresses
the exploitation of the results and the patent and licensing issues as well as
procedures with respect to the dissemination of results. A guiding rule is
that partners investing in research should have an advantage compared to those
who do not. This means that knowledge created during projects that offer
commercial interest must be safeguarded and protected for exploitation by the
owner. On the other hand, partners of this project need to come together in
order to collaborate and benefit from their respective resources and
competencies. Thus, added value through the sharing of knowledge and promoting
exploitation represents a clear objective and driving forces of this
collaborative project. This approach to knowledge management and IPR is
detailed and regulated in the Consortium Agreement, which has been signed by
all partners at the start of the project.

Some of the major aspects covered are indicated below:

  * Background knowledge, specific limitations and/or conditions for implementation and for exploitation; Project Results, their (joint) ownership and the transfer of Results; 

  

  * Access rights to Background and Results, for consortium partners and their affiliates; 

  

  * Publications, procedures for dissemination of results and research data and open access hereto. 

  

Background (= existing know how or pre-existing intellectual property) of a
specific partner shall be made available to the Partner (or Partners) within
the consortium that needs this information for the proper execution of their
tasks within the scope of the project. The use of Background is strictly
limited for use to the achievement of the project goals and for the duration
of the project. The receiving partner or partners will sign appropriate non-
disclosure agreements with the providing partner. An overview of the
Background was included as an annex to the consortium agreement. All partners
shall be entitled to license their Background. Licensing of Background to
third parties will be done on commercial conditions whereas licensing of
Background to partners of the consortium will be done on fair and reasonable
conditions. Results (e.g. results, including intellectual property generated
in the project) shall be owned by the partner or partners who developed the
results.

Each partner is responsible for taking the appropriate steps for securing
intellectual property of the knowledge or results created in the project (e.g.
filing of patent applications). Each partner is obligated to fully inform the
project coordinator of the filing of patent applications of knowledge or
results created in the field of the project within two weeks of the date of
filing. Each partner that owns a specific Result shall be free to exploit
their Result as it sees fit. Appropriate joint ownership agreements will be
drawn up. The participating research institutes/universities are entitled to
use knowledge or results from the project, which either have been published or
have been declassified, for research and teaching purposes. The project’s
website will also contain an overview/archive of all published information
and/or links hereto.

Access Rights to Background and Results shall be free of charge to partners of
the consortium for research and development purposes within the scope and the
duration of the project. Access Rights to Background and/or Results that are
owned by one or more of the partners shall be granted on fair and reasonable
conditions and to the extent necessary to enable these partners to exploit
their own results. For this purpose, the involved partners are entitled to
conclude appropriate (bi, tri or multilateral) license, supply, product and/or
service agreements.

#  APPENDIX Overview of Relevant International Safety Standards

The international standards concerning type-approval requirements for the
general safety of motor vehicles have been reviewed and analyzed with
reference to the technical innovations in the framework of the GHOST project.

Within the European Union, two systems of type approval are in force. The
first is based on the European Commission directives and regulations, and
targets the entire vehicle system as well the subsystems and components. The
second is based on the UN regulation, and targets subsystems and components of
the vehicle, but not the whole vehicle.

The main directive for the vehicle type approval in the EU is the 2007/46/EC
of the European parliament and of the council. The directive establishes a
framework for the approval of motor vehicles and their trailers, and of
systems, components and separate technical units intended for such vehicles.
This Framework poses requirements for the different subsystem constituting the
vehicle. Hence, to gain the whole approval of the vehicle, the various
subsystems shall be verified against their compliance.

The above mentioned directive provides a list of Regulatory acts for EC type-
approval of vehicles produced in unlimited series and includes, for example:

  * General Safety Regulation (EC) No 661/2009 

  

  * Electric safety Regulation (EC) No 661/2009 UNECE Regulation No 100 

  

The main directive for the vehicle type approval with respect to the General
safety is the Regulation (EC) No 661/2009. It sets out requirements regarding
both the general safety of motor vehicles and the environmental performance of
tires.

The subsystems reported in Annex 1 of the regulation are in scope of the
requirements expressed in Article 5 (1) and (2), e.g.:

  1. Manufacturers shall ensure that vehicles are designed, constructed and assembled so as to minimize the risk of injury to vehicle occupants and other road users, 

  

  2. Manufacturers shall ensure that vehicles, systems, components and separate technical units comply with the relevant requirements set out in this Regulation and its implementing measures, including among other the requirements relating to: 

     * vehicle structure integrity, including impact tests; 

  

     * systems to provide the driver with visibility and information on the state of the vehicle and the surrounding area, including glazing, mirrors and driver information systems; 

  

     * electromagnetic compatibility; 

  

     * heating system 

  

     * electrical safety 

  

  

  

In general, pursuant with par. 7 of UNECE Regulation No. 94, any increase in
mass of the vehicle greater than 8 per cent might imply a bigger testing
effort in order to demonstrate compliance with the regulation provisions,
depending on the judgement of the Type Approval Authority.

Product certification is a fundamental precondition to establish a product at
the market. The certification comprises the tests regarding required standards
and robustness. Generally, depending on the mission profile the vehicle
manufacturer specifies the requirements on the electrical and electronic
equipment. The supplier of the Battery System is liable to observe these
requirements and to perform the appropriate tests to ensure functionality,
reliability and safety.

The Battery System as an electric device have to undergo through various tests
and likewise its electrical and electronic components have to meet various
requirements and standards. Such components are for example, circuit boards,
sensors, actuators, integrated circuits (ICs), semiconductors, active and
passive components etc.

An important standard for qualification of electrical and electronic equipment
in road vehicles is the ISO 16750, Road vehicles - Environmental conditions
and electrical testing for electrical and electronic equipment. The ISO 16750
[4-8] applies to electric and electronic systems and components for vehicles.
It describes the potential environmental stresses and specifies tests and
requirements recommended for the specific mounting location on or in the
vehicle. The ISO 16750 consists of the following 5 parts:

  * ISO 16750-1: General 

  

  * ISO 16750-2: Electrical loads 

  

  * ISO 16750-3: Mechanical loads 

  

  * ISO 16750-4: Climatic loads 

  

  * ISO 16750-5: Chemical loads 

  

Similarly to device level, the electrical and electronic components that build
up the Battery System have to undergo tests before assembling. In general, the
responsible international standardization organisations for electrotechnical
and electronic applications are:

  * IEC -International Electrotechnical Commission 

  

  * CENELEC -European Committee for Electrotechnical Standardization 

  

  * JEDEC Solid State Technology Association 

  

In the automotive field, the Automotive Electronics Council (AEC) based in the
United States was established for the purpose of setting common part
qualification and quality-system standards for the supply of components in the
automotive electronics industry. The AEC Component Technical Committee is the
standardization body for establishing standards for reliable, high quality
electronic components. Components meeting these specifications are suitable
for use in the harsh automotive environment without additional component-level
qualification testing.

The quantity, value and complexity of electronics in passenger vehicles
continue to rise. Therefore, it is suggested to ensure to the vehicle
manufacturer that the supplier of the meets the following standards of the AEC
- Q100 norm which in turn refers to many JEDEC standards.

JEDEC has been the global leader in developing open standards and publications
for the microelectronics industry. JEDEC brings manufacturers and suppliers
together to participate in more than 50 committees and subcommittees, with the
mission to create standards to meet the diverse technical and developmental
needs of the industry. JEDEC’s collaborative efforts ensure product
interoperability, benefiting the industry and ultimately consumers by
decreasing time-to-market and reducing product development costs. The JEDEC
Automotive Electronics Forum is going to bring together experts from the
worldwide automotive electronics industry to evaluate current standardization
efforts and future industry needs.

  * AEC - Q101 - Failure mechanism based stress test qualification for discrete semiconductors 

  

  * AEC - Q200 - Stress test qualification for passive components 

  

The AEC standard is well-known to customers of electrical and electronic
components. The application and compliance with AEC standards, respectively,
create clarity in reliability and standardization issues and save time in
communication between supplier and customer.

The signal integrity is also an important issue to consider regarding
electrical requirements. Generally, signal integrity is closely related to the
EMC. If a design was implemented under consideration of its physical
requirements, both fields achieve best results. As far as the enquiry resulted
in there is no particular standard respective to the signal integrity. The
signal integrity is a set of measures describing the quality of an electric
signal. Some of the main issues of concern for signal integrity are ringing,
crosstalk, ground bounce, distortion, signal loss, and power supply noise.
Today's transfer rates require a combination of simulation, modeling and
measurement in order to already avoid signal integrity issues in the design.
When integrating fast data lines, signal integrity is one of the most
important parameters at all levels of electronics packaging and assembly (from
internal connections of an IC, through the package, the printed circuit board
(PCB), the backplane, and inter-system connections) because various effects
can degrade the electrical signal to the point where errors occur and the
system or device fails.

The design of a new battery module with integrated thermal management requires
that attention is given to the safety requirements regarding the vehicles
equipped with electric power train in the event of frontal or lateral
collision, pursuant UNECE Regulations No. 94 and No. 95; thus following the
test conducted in accordance with the procedure defined in Annex 3 to
Regulation No. 94 and in Annex 4 to Regulation No. 95, the electrical power
train operating on high voltage, and the high voltage components and systems,
which are galvanically connected to the high voltage bus of the electric power
train, shall ensure that the vehicle passengers are not exposed to voltages
higher than 30 VAC or 60 VDC, or alternatively the total energy (TE) on the
high voltage buses shall be in the limits established in Annex 11 of UNECE
Regulation No. 94 or Annex 9 of UNECE Regulation No. 95.

Until 30 minutes after the impact no electrolyte from the Rechargeable Energy
Storage Systems (REESS) shall spill into the passenger compartment and no more
than 7 per cent of electrolyte shall spill from the REESS.

REESS located inside the passenger compartment shall remain in the location in
which they are installed and REESS components shall remain inside REESS
boundaries.

No part of any REESS that is located outside the passenger compartment for
electric safety reasons shall enter the passenger compartment during or after
the impact test.

Complying also with regulation No. 100 Uniform provisions concerning the
approval of vehicles with regard to specific requirements for the electric
power train, the protection DEGREE IPXXD against direct contact with high
voltage live parts should be provided and the resistance between all exposed
conductive parts and the electrical chassis shall be lower than 0.1 ohm when
there is current flow of at least 0.2 ampere.

Isolation resistance should meet the prescriptions of regulation No. 100,
besides those exposed in regulation 94, where it is measured as indicated in
Annex 4A of such abovementioned regulation.

The REESS shall overcome the tests established in Annex 8 to regulation No.
100, such as vibration test, thermal shock and cycling test; moreover, fire
resistance shall also be granted complying with regulation No. 100.

Besides, since the employment of battery cells other than those used in the
current vehicle has been planned for the prototypal battery module, external
short circuit protection, overcharge/overdischarge protection and over-
temperature protection shall also be ensured pursuant regulation No.

100\.