/ EUROPEAN COMMISSION
ENTERPRISE AND INDUSTRY DIRECTORATE-GENERAL
Aerospace, Maritime, Security and Defence Industries
Copernicus : Services

Guidance document for proposers of Horizon 2020 projects in support of EO service activities (downstream or Copernicus service evolution)

The Horizon 2020 Work Programme calls for a number of topics which are in support of the Europe’s capacities to provide services in the context of Earth Observation and the Copernicus Programme (previously called GMES – Global Monitoring for Environment and Security). Such activities may address downstream service opportunities (addressing national/regional/specific market niche) or may aim at evolution of EO products for future Copernicus service evolution.

In order to provide support to proposers, this guidance document has been prepared to communicate lessons learnt from Framework Programme 7, and best practices recognised to be valuable.

It has repeatedly been recognised that research and development activities strivingto build up pre-operational delivery capabilities for Copernicus or downstream servicesorinnovative exploitation of European space data need to take into account the user community they intend to serve, and the exploitation environment they will have to operate in after completion of their activities. Hence proposals must demonstrate:

  • A structural capacity for providing a sustainable service on an operational basis (preferably supported througha proven record).
  • A clear focus on the operationalisation of services, and thus sustainability of the service during subsequent operations, by defining and further consolidating the economic model for service provision (e.g. through a business plan).

A number of elements will therefore be considered as appropriate in the evaluation of such project proposals as listed below.

  • A demonstration of a user-driven approach, including for instance:

– A user representation appropriate to the targetedproducts and user communities, as well as a suitable mechanism to interact with these (participation of users as project's partners would be favourably considered or, as a second preferred option, the set-up of service level agreements could be considered[1]).

–A process for elaborating requirements closely with the users, including:

  • The specification of quality requirements and tolerance levels (explicit and well-defined precision, reliability, availability and integrity requirements for the products/service).
  • An unambiguous, detailed and realistic list of products to be delivered to the users: product description, time period and geographical coverage, delivery dates.

–A process for monitoring how activities (of research, development, demonstration, system implementation, service validation and data provision) trace back to the user requirements.

–A process for feedback from and assessment of the service by relevant end-users, which demonstrates both the acceptance level of the products, the prototypical service, as well as a strategy for integration into the users’workflows and resulting decision-making processes.

  • A description of the organisation and service architecture, including interface / coordination to be assured with the Copernicus services providers if relevant.
  • A description of procedures for collection of observation data (satellite, in-situ)and delivery, under consideration of both organisational aspects, as well as technical solutions offered by state-of-the-art communication methods (via terrestrial or satellite communication channels). Account should be taken of possible mechanisms of coordinated data delivery.
  • A description of selected methods for data validation and fusion from multiple sources; techniques for data assimilation into models, validation of space derived products by means of in-situ data.
  • A preliminary analysis of the added value of products.
  • A preliminary version of a clear and scientifically sound validation plan including detailed methods for measuring quality of products, their viability[2], and describing the test sites and their selection criteria.
  • A description of the approach for achieving interoperability and interconnection of the data processing and delivery systems, taking into account harmonisation policies, directives such as INSPIRE, and standardisation initiatives (when demonstrating interoperability capabilities, gaps and shortcomings in on-going INSPIRE effortsmay also be identified; the impact of harmonisation and the INSPIRE implementation on the sustainability of the services could also be examined). To facilitate efficient acquisition and exploitation by both service providers and users, activities will have to include R&D[3] for:

-improved accessibility to long-term data archives, implementation of meta-data standards, actions to facilitate information retrieval and dissemination;

-improved accessibility to in-situ systems;

-adoption of open standards for data documentation, data models and services;

-integration of tools and services allowing anybody to query, view, access and exchangethe information held by distributed public and private bodies;

-establishment of a data policy and appropriate security framework.

  • A project commitment to disseminate software results for the benefit of Copernicus programme, allowing all Copernicus follow-on activities to potentially benefit from results. While recognising the IPR rules in Horizon 2020, it is considered that the open source route can also be part of a business strategy to promote the software and have a larger audience with associated benefits. Proposers should thus consider making their software available for instance under the European Union Public Licence (EUPL).

(For details please refer to )

  • A project commitment to apply a free, full and open data policy for the benefit of users of the Copernicus programme, allowing also follow-on activities to potentially benefit from results. While recognising the necessity to respect third party data and information policies, the project should provide free, full and open access to derived data and information results. The objectives and principles expressed in Commission Delegated Regulation (EU) No 1159/2013 (GMES/Copernicus data and information policy) should be referred to for further information.[4]A project exploitation plan to continue with the implemented methodology on a self-sustained basis for a minimum duration of 2 years in case of successful outcome.
  • Projects should include activities aiming at disseminating knowledge and increasing public awareness of the benefitsachieved through the integration of space technology and in-situ observation systems. Project output could also include an assessment of the type of data and level of spectral, spatial and time resolution expected from the next generation of satellites and in-situ data sources.

Space-based observation data necessary for the development of each project will have to be detailed in the proposal. In particular, the proposal should highlight the Earth Observation Data expected to be made available through the EU funded data access mechanisms via ESA[5] (from Copernicus contributing missions and/or Sentinel data). Concerning the data expectations from the EU funded data warehouse via ESA,proposals should provide an overview of resources needed for space-based observation data, as data requirements beyond the existing agreement between the Commission and ESA will have to be covered by the budget of the project.

With regard toin-situ data necessary to the development of each service, the proposals will have to foresee dedicated efforts for their provision, allowing for an interface with coordination activities of the European Environment Agency (EEA) in this respect[6].

In general in-situ data could include:

(i)data collected by networks of sensors deployed on land, sea, water and in the atmosphere aimed at measuring and providing a complete description of the Earth system.

(ii)surveys aimed at collecting socio-economic data, land cover and land-use data, geology, soil conditions, bio-diversity information and other topographic or geographical data such as elevation, administrative boundaries, transport and utility networks etc.

(iii)

In particular in-situ data should meet the immediate needs of the specific proposed service and should cover, inter alia, the following requirements:

  • Timeliness, in function of the service requirements;
  • The provision schemes and their corresponding delivery interfaces (FTP, other internet protocols, dedicated communication schemes).

Specific needs for dedicated in-situ data for the development of each service should be detailed in the proposals. The proposals should provide an overview of in-situ data requirements and if specific data will have to be covered by the budget of the project.

Annex 1: Service Level Agreement (SLA)

Some project partners, the Service Providers, will during the project deliver products and services to end-user organisations (who might be formal project partners or not). A Service Level Agreement (SLA) should be signed between each end-user organisation (the User) and the corresponding Service Provider, and be attached to the project proposal. It is a committing agreement between the two parties which specifies the quality, quantity and terms of access for the products and services to be delivered to the User, as well as other obligations for the Service Provider and for the User respectively. Other relevant terms and conditions should be included if useful.

A successful outcome of the project is dependent upon timely and correct performance by the Service Provider and by the User of a number of key actions. The SLA helps ensuring this by listing very clearly these actions as obligations of the Service Provider or of the User respectively, in a concise and agreed document.

It also ensures realistic expectations from both sides from the start of the project, thus avoiding deceptions and conflicts based on misunderstandings.

The SLA is an important input document for the validation procedure where compliance of the generated and delivered services with the users' requirements has to be verified.

Finally, an SLA also provides a mechanism for bringing in new users during the project duration by formalising their involvement without the need for any amendment to the grant agreement with the EC.

A template for an SLA, to be adapted to the specific project, is provided on the next two pages.

SERVICE LEVEL AGREEMENT RELATED TO THE ….. PROJECT

This agreement is concluded between ….., hereafter referred to as the Service Provider, and ….., hereafter referred to as the User for the duration of ….. [at least one year] starting from the project kick-off date. The agreement will be applicable only if the project proposal results in a grant agreement with the EC. In case of conflict between this Service Level Agreement and the project grant agreement with the EC, the latter will apply.

This Service Level Agreement specifies in transparent and measurable terms the services to be provided, including quality requirements, and the obligations of the Service Provider and of the User respectively.

1. Service description

[Short description of the service]

2. Obligations of the Service Provider:

  • The Service Provider agrees to provide the User with the service according to the Detailed Service Specifications below.
  • The Service Provider agrees to ensure adequate quality control is performed.
  • The Service Provider agrees toensure validation is performed according to the agreed Validation Plan.
  • The Service Provider agrees to ensure that needed technical support to the User to fully utilise the service will be provided within reasonable limits.

3. Obligations of the User:

  • The User agrees to fully participate in the assessment/consolidation of user requirements.
  • The User agrees to integrate the service within his operational mandate as far as practically possible.
  • The User agrees to fully participate in the assessment of the utility of the service.
  • [If applicable: Support the validation beyond the utility assessment, e.g. taking part in accuracy assessments]
  • [If applicable: Provide access to user-owned or -operated data gathering infrastructure, other equipment or software]
  • [If applicable: In-kind contribution from the user including lobbying support to access third party funding, promotion of service capabilities and utility to collaborating organisations within the same demand sector and operation and maintenance of in-situ data gathering networks and service support infrastructure (e.g. data warehouses)].

4. Detailed Service Specifications

The service to be delivered by the Service Provider to the User has the following contents and characteristics:

Products:

[Exhaustive list of products.]

Service Area

[Precise geographical area to be covered by Service. If the area to be mapped or monitored will by the nature of the service depend on events like forest fires, storms or other types of damage, an estimation of the expected minimum, average and maximum mapping area is required.]

Other Deliverables

[Training, installation, maintenance, …]

Service Delivery Mode

[FTP, Web-based, DVD by express mail, …]

Delivery Schedule

[E.g. 24hr response; 2-day turnaround; annual delivery at specified dates (or "e.g. within 6 months after project start"). To be specified for all products and for other deliverables.]

Product Specifications

[Detailed specifications of each product, including quality and accuracy specifications and related acceptance thresholds, as well as applicable standards. E.g. for a map product, it should include e.g. map projection / reference system, class definitions, scale or minimum mapping unit, targeted and acceptable geometric accuracy, targeted and acceptable classification accuracy (overall and user/producer accuracy per class).]

Target Service Delivery Model

[Outsourced service or User in-house service (the Service Provider performs development and technology transfer / user capacity building in the project and plans for future revenues from maintenance and/or further development of the processing chain)]

5. Other terms

  • [Restrictions on use of the products and services delivered or of the items provided by the user to the Service Provider; credits / copyright statements; other terms of access, …]
  • [Licensing and maintenance agreements for service generation and delivery infrastructure provided by the service network where service generation is undertaken in-house];
  • [Service performance levels, back-up provisions and recovery procedures and timescales];

Service Level Agreement signed by:

On behalf of ……. (the Service Provider)On behalf of …….. (the User)

[name and position][name and position]

………………………..……………………….

1

[1] A template is attached in annex to this document.

[2] It should be noted that activities designed to prove the viability of new technologies that offer a potential economic advantage, even if they cannot be commercialised directly, may correspond to “Innovation” activities rather than “Research and Innovation” activities in the Framework Programme. Proposals should therefore provide a careful separation of these two types of activities in their work plan.

[3] It should be noted that specific development and research on ICT for environmental management as well as mechanisms for rapid adoption of standards, protocols and open architectures have been undertaken in FP7 theme 3 “Information and Communication Technologies” under Challenge 6 “ICT for Mobility and Environmental Sustainability”, and are part of the specific challenges inHorizon 2020 under LEIT-ICT and Societal Challenge 'Climate action, environment, resource efficiency and raw materials'

[4] OJ L309, Volume 56, p1, of 19 November 2013; see

[5] Data Warehouse Requirements Document v1.9 dated 18/03/2013

[6] FP7 project 249327, GMES In-Situ Coordination (GISC) as well as follow-on activities of the Copernicus programme via EEA