Live Chat
Welcome to the ESA Earth Observation Framework (EOF) website! If you have any questions about EOF, I’m here to help.
12/06/2025

ESA EO Framework (EOF) – CSC – Specifications

Reference: ESA-EOPG-EOPGC-RS-1
Version: 1.4
Author: EOP-GC
Download file:

ESA UNCLASSIFIED – For ESA Official Use Only

1 Executive summary

The overall system architecture for the Copernicus Space Component (CSC) and its evolution have been defined on the basis of user requirements coordinated by the European Commission. The Long-Term Scenario (LTS) describes the main elements of this architecture and is maintained and evolved in an iterative process in close interaction with the European Commission (COM), EUMETSAT and EU Member States and Copernicus Participating States.

ESA needs to guarantee the continuity of the on-going operations with the maximum level of performances for the flying Copernicus Sentinels while facing the technical and financial challenges to adapt to the evolutions of the CSC architecture.

The CSC Ground Segment (GS) is based on a service-based architecture and a clear set of operations management principles (management and architectural) hereafter referred as the ESA Earth Observation Framework (EOF).

The EOF encompasses all the activities necessary to successfully deliver the expected level of CSC operations entrusted to ESA (i.e. establishment and maintenance of the new baseline, procurement actions, operations management, reporting, etc.).

The EOF-CSC is documented throughout a complete package describing and specifying the applicable operational concepts as well as the architecture and procurement approach adopted for establishing and evolving the CSC operations baseline (in particular with respects to the future Expansion Missions, associated with the necessary cost information to size the proposed approach and potential trade-offs).

The EOF-CSC implementation is based on a service architecture with well-identified components that exchange data through Internet respecting defined interfaces. A service presents a simple interface to its consumer that abstracts away the underlying complexity. Combined with deployments on public cloud infrastructure, the service approach shall offer large adaptability to evolution of the operational scenarios in particular for what regards scalability.

Since the transformation process which started in 2019, the operational CSC Mission and Data management activities have been transferred to cloud based environments (in anticipation of the enlargement of the Copernicus Sentinel missions and in response to the ever-increasing demand for Copernicus data) and the service-oriented approach has been strengthened to enhance competitiveness, prevent industrial and technical lock-in and introduce the necessary operational flexibility and transparency to allow the adaptation of the Copernicus Space Component operational activities managed by ESA to future challenges.

Within this context, this document contains the specifications of the EOF for the CSC operational activities entrusted to ESA by the European Commission. The specifications establish the traceability with the current baseline of requirements issued by the European Commission. This document is planned to undergo regular revisions in accordance with possible evolutions of the LTS scenario and the Copernicus Contribution Agreement.

2 Introduction

2.1 Background

The Copernicus Space Component has been established as one of the largest and most proficient Earth Observation infrastructure in the world. With nine high-performance satellites put in orbit the system has evolved at a breath-taking pace.

The CSC operations have generated more than 90 PBytes of data. Central to the programme, the current CSC fuels the operational Copernicus Services but also provides a reliable and growing data stream for numerous new applications and services.

The current CSC has also triggered large application oriented technological developments, such as in the domain of Big Data management, as exemplified by the Data and Information Access Services (DIAS) and further evolved in the Copernicus Data Space Ecosystem (CDSE).

The intense use and increased awareness for the potential of Copernicus have generated great expectations for an evolved Copernicus system.

User and observation requirements have been identified, structured and prioritized in a continuous reflection process led by the EC. Future missions have been defined in the context of four observational capability families:

Microwave Imaging Family,

Optical Imaging Family,

Topographic Measurement Family

Spectroscopic Atmosphere Measurement Family.

Two sets of missions have emerged, that correspond respectively to the enlargement of the present measurements through the introduction of new missions (the Copernicus Expansion missions) and to a more progressive improvement of the current measurement capabilities, mostly by means of new generation of similar instrumentation compared to the ones currently deployed (the Next Generation Sentinel missions).

The CSC operations entrusted to ESA for Sentinel-1, -2, -3 A&B and Sentinel-5P deliver outstanding results, with more than 800 PB of delivered Sentinel data to registered users around the globe (2025/06).

A blue background with white circles and white circles with white circles and white text

AI-generated content may be incorrect.

Figure 1: Dissemination Statistics (May 2025)

The ESA and EUMETSAT encompass all the activities necessary to successfully deliver the expected level of entrusted CSC operations and reflect the primary goal of securing the entry into operations of the Sentinels Missions, with their unprecedented data volume and user uptake.

The ESA CSC operational activities encompass the Space Segment operations with the necessary post-launch spacecraft maintenance activities, the Flight Operations Segment services to ensure the spacecraft operations and the Mission and Data Management further addressed hereafter.

In particular, the ESA EO Framework for the CSC encompass the following families of services providing for the overall EOF-CSC needs:

Operations management services

oOverall configuration management

oEnd-to-end system & performance monitoring

oSecurity monitoring

oUser support services: helpdesk, training, tools, communication

Space segment and Flight Operations services: spacecraft operations and post-launch spacecraft engineering support for satellite maintenance and contingency management.

Mission services

oMission planning services: instrument sensing & satellite downlinks operations planning & optimization.

oAcquisition services: satellite data acquisition services (e.g. X-Band, Ka-Band, relay satellite).

oPrecise orbit determination service

Data services

oProduction and routine quality control services, encompassing different processing strategies including systematic production and reprocessing services

oLong Term Archive services, ensuring preservation of the essential mission data

oData Access services: data distribution & user interface allowing access to any mission Data Sharing Units User Level Data and complementary services for data analytics, on-demand processing, AI, etc.

oCalibration & Validation services: monitoring of instrument performance and data quality, calibration and validation, and external cal/val data provision.

oAlgorithms and data processors maintenance and evolution services

oSupport to international agreement with data access services

oAuxiliary data provision services

oData traceability services

The ESA EO Framework for the CSC also includes the implementation and operations of the interfaces with services identified through specific agreements, deriving from the collaborative programme component or upon EC request. In particular these interfaces cover:

Support to collaborative local acquisition stations

Provision of a network of data access relays

Coordination of interfaces for data and information provision from other sources and from Copernicus Services.

The operational experience gathered over the past decade of operations has demonstrated that sizing and performance are largely dependent on the user demand. Consequently, a refined approach was introduced with the Copernicus Ground Segment Transformation, in the period 2020-2022, for the management of the CSC operations. This approach is reflected in the baseline presented in this document. While ensuring a robust and highly performing solution, it introduces wider flexibility wherever the CSC operations may be impacted by the user scenario.

2.2 Scope

The ESA EO Framework documentation for the CSC is made of the following set of documents:

The EOF-CSC Operations Concept document

The EOF-CSC specifications defining the scope of the ESA Copernicus Space Component operational management, its associated performance and the traceability to the EC requirements (this document)

The EOF-CSC Architecture document describing the main functional blocks and their interfaces in particular for what concern the external interfaces,

The System Technical Budget document, providing an estimate of the expected operational load and generally operations context sizing,

The risk folder,

The cost models of EOF-CSC services operations establishing the key parameters driving the operations costs,

The High Level Roadmap, establishing the objectives for the future evolution.

The EOF-CSC documentation seeks to:

Support and document the CSC operational management, ensuring the operational capacity and performance.

Support the evolution process for the CSC operations entrusted to ESA

Devise novel schemes for missions and data management and industry involvement

Serve as an information vehicle to EU and Copernicus Participating Countries for iterative consolidation

Document the ESA - EUMETSAT coordinated technical baseline

Prepare the EOF-CSC to manage the upcoming Expansion Missions and to ensure the necessary capacity and performance (e.g. linked to increasing volume of data).

The data warehouse in charge of the provision of third-party mission data on behalf of Copernicus Services is not subject to this document even if it may benefit from the projects and services developed as part of the EOF-CSC.

2.3 Applicable and Reference documents

2.3.1 Applicable documents

[AD- 1] REGULATION (EU) No 377/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 3 April 2014 establishing the Copernicus Programme and repealing Regulation (EU) No 911/2010

[AD- 2] COMMISSION IMPLEMENTING DECISION (EU) 2018/621 of 20 April 2018 on the technical specifications for the Copernicus space component pursuant to Regulation (EU) No 377/2014 of the European Parliament and of the Council

[AD- 3] Functional Requirements for the Copernicus Distribution Services and the Data and Information Access Services (DIAS), European Commission, Ref. Ares(2016)6887639 - 09/12/2016 , 6 December 2016

[AD- 4] Copernicus Ground Segment – Functional Requirements for the acquisition, generation and archiving of Sentinel data, Revision 1.3, 1st April 2019

[AD- 5] Concept for the Cooperation of ESA and EUMETSAT regarding Copernicus Evolutions co-signed by J. Aschbacher (ESA) & A. Ratier (EUMETSAT), 2017

[AD- 6] “Copernicus Space Component (CSC) Long Term Scenario May 2025” ESA/PBEO(2025)30, 14/05/2025

2.3.2 Reference documents

[RD-1][RD-EOF-GLO] ESA EO Framework (EOF) – CSC – Glossary [ESA-EOPG-EOPGC-TN-13]

[RD-2] [RD-EOF-OCD] ESA EO Framework (EOF) – CSC –Operations Concept [ESA-EOPG-EOPGC-TN-19]

[RD-3] [RD-EOF-DASP] ESA EO Operations Framework (EOF) – CSC – Copernicus Sentinel Data Access Services Portfolio [ESA-EOPG-EOPGC-TN-57]

2.4 Acronyms and Definitions

Acronyms are expanded on first use. The full list of acronyms and definition of terminology is provided in [RD-EOF-GLO].

3 ESA EO Framework

Considering the nominal plan of evolution, the overall operational load has doubled in the current period and will more than double again in the next period. An even bigger challenge for the future CSC operations lies in the non-linear increase of the required data management effort since future operations shall ensure access to all data for all missions since the start of operations (2014).

The “ESA EO Framework (EOF)” application within the Copernicus Space Component (CSC) (i.e. all the activities to be put in place and to be performed by ESA in order to deliver the required CSC operations in the period 2022 – 2027) is therefore facing the challenges to:

Achieve a continuous efficiency increase;

Reduce the operational risks related to varying user scenarios;

Respond to the user needs for higher operations performance (quality, timeliness, completeness, reliability);

Set-up the conditions allowing full CSC data access beyond 2027;

Manage a cumulative archiving and data management load;

Support the European industry in keeping the lead in EO related activities, promoting the use of innovative technology in the services provision.

Support the European Commission to make the EU’s economy sustainable with the Green Deal plan implementation

3.1 EOF-CSC operational Scenario Assumptions

The operational scenario and associated specifications are based on the Long-Term Scenario [AD- 6].

According to the LTS, the CSC operations continue after 2027 for the Sentinel-1, Sentinel-2, Sentinel-3 and Sentinel-5P missions, with remaining Sentinel-1, Sentinel-2, Sentinel-3 recurrent satellite units to be onboarded in the EOF-CSC. .

For the sake of this document, the reference periods for the CSC operations are 2014-2021 (referred as the Previous Period), the 2022-2027 period (referred as the Present Period) and the 2028-2034 period (referred as the Next Period).

The following key operational assumptions in line with the LTS considered for the sake of this document are recalled hereafter:

The CSC operations managed under ESA responsibility after 2027 will be a continuity of the operational responsibilities for currently flying missions.

A maximum of 3 Sentinel satellite units for the same mission will be simultaneously in operated during the period covering the commissioning phase of the 3rd unit.

A maximum of 2 Sentinel satellite units for the same mission will be simultaneously in routine operations.

The specifications defined in this document are applicable to the EOF-CSC activities to be performed up to Q1 2028. Nevertheless, they provide the basis for the Sentinel Expansion mission operations to be performed after Q1 2028 (with the exception of CO2M operations planned to start in the Present Period ), to be further consolidated in future versions of this document as necessary.

3.2 Key Sentinel missions characteristics

The following table recalls the main characteristics of the Sentinel missions to be operated in the Present Period. The main characteristics of the Copernicus Expansion missions will be included in a future version of this document in line with the consolidation of the space segment design activities.

Copernicus Sentinel missions characteristics

Sentinel Mission

Main Mission Characteristics

Sentinel-1

RADAR Mission

Sun-Synchronous orbit at approximately 693 km

4 units (A, B, C, D), two units are flying in parallel for full capacity

C-Band SAR Payload with centre frequency of 5,405 GHz (4 polarisations) and 4 modes:

Strip Map mode with 80 km Swath and 5 × 5 metre spatial resolution

Interferometric Wide Swath Mode with 250 km swath and 5 × 20 metre spatial resolution

Extra-wide Swath Mode with 400 km swath and 20 × 40 m spatial resolution

Wave mode with 5 × 5 metre spatial resolution at 100 km along the orbit

Includes an Optical Communication Payload for mission data relay through EDRS.

Sentinel-2

High Resolution optical mission for land imaging

Sun-Synchronous orbit at approximately 786 km

4 units (A, B, C, D), two units are flying in parallel for full capacity

Multi Spectral Imager with 13 multispectral channels between 400 nm and 2 300 nm, spectral resolution between 1 nm and 180 nm and spatial resolutions of 10 m, 20 m and 60 m.

Includes an Optical Communication Payload for mission data relay through EDRS.

Sentinel-3

Global Ocean and Land Imaging

Sun-Synchronous orbit at approximately 814,5 km

4 units (A, B, C, D), two units are flying in parallel for full capacity

OLCI – Ocean and Land Colour Instrument with 21 bands and spatial resolution of 300 m

SLSTR – Sea and Land Surface Temperature Radiometer with 9 bands and spatial resolution of 500 m (VIS, SWIR) and 1 km (MWIR, TIR) ( 9 )

SRAL – SAR Radar Altimeter with dual CX and Ku bands

MWR – Microwave Radiometer, with an operation frequency in dual 23,8 GHz and 36,5 GHz

Sentinel-5P

Atmospheric monitoring

Sun-Synchronous orbit at approximately 824 km

TROPOMI — TROPOspheric Monitoring Instrument with 4 channels in the following spectral ranges: 270-500 nm, 675-775 nm, 2 305 -2 385 nm and spatial resolution of 7 × 5.5 km

3.3 Documentation Tree and context

The “Concept for the Cooperation of ESA and EUMETSAT regarding Copernicus Evolutions” ([AD- 5]) addresses the ESA and EUMETSAT involvement and coordination for the Copernicus missions. Based on the successful experience of developing, upgrading and managing complex systems together the respective activities are organised to maximise efficiency, mitigate risks while removing potential ambiguity from the cooperation.

The following figure provides the context for the agreements.

Picture 38

Figure 2: Copernicus EOF Document hierarchy

In

Picture 38

Figure 2 the arrangement in series of levels reflects the cascading of responsibilities and tasks. This cascading is established to coherently manage with the maximum efficiency the activities that need to be coordinated avoiding to the maximum extend unnecessary overlaps between the operational activities.

The overall documentation tree is illustrated in the figure below.

Picture 11

Figure 3: Copernicus Documentation Tree for ESA EO Framework baseline

As illustrated in the graph below, the CSC ESA EO Framework documentation is refined at mission level as necessary and represents the basis for deriving the industrial operational baseline associated to the operational services procurements organised by ESA and to the management of the operational services delivery.

Picture 80

Figure 4 : Copernicus EOF Documentation structure

4 ESA EO Framework CSC specifications

Specifications for the implementation of the various services contributing to the EOF, including operations and procurement specifications are logically organised by the following categories of services:

Flight operations

Observation Strategy implementation

Operational Management services

Mission services

Data services.

Picture 3

Figure 5: Copernicus EOF Specifications Logic

4.1 ESA EO Framework CSC Baseline Requirements

[REQ-1]The EOF-CSC shall be aligned to the ESA roles defined in the Contribution Agreement.

Families

Description

Respective ESA – EUMETSAT Roles

Microwave Imaging Family

S1

ESA Operations of 2 satellite units simultaneously in routine operations and a 3rd one in commissioning phase

Optical Imaging Family

S2

ESA Operations of 2 satellite units simultaneously in routine operations and a 3rd one in commissioning phase

Topographic Measurements Family

S3

ESA land operations of 2 satellite units simultaneously in routine operations and a 3rd one in commissioning phase

EUMETSAT FOS Operations and Marine operations of 2 satellite units simultaneously in routine operations and a 3rd one in commissioning phase

Spectroscopic Atmosphere Measurement Family

S5p

ESA Operations of 1 satellite unit

Table 2 Sentinels family, development and (high level) operational roles

The following requirements are considered for the period 2021 - 2027. ESA activities related to ESA programme and not part of the Copernicus Contribution Agreement are not covered by this document (e.g. collaborative Ground Segment).

[REQ-2]The EOF-CSC shall encompass all the necessary activities to fulfil the CSC operational tasks entrusted to ESA.

[REQ-3]The EOF-CSC shall ensure smooth operational transition and continuity of operational activities safeguarding the operational user interfaces for the two CSC reference periods 2022-2027 and 2028-2034.

User interfaces may evolve, in the case that backward compatibility is not maintained, continuity of operations of the former interface shall be operated for sufficient time to allow for operational user services the possibility to adapt for the evolution (e.g. a typical period of 6 months should be considered).

[REQ-4]The EOF-CSC shall target an operational reliability and availability better than 99% in any of its functional areas.

[REQ-5]The EOF-CSC shall request and retain the minimum set of user information necessary to fulfil the operations objectives and reporting requirements.

Any collection of user related information shall obey to the GDPR rules.

4.2 ESA EO Framework CSC Implementation

Considering the complexity of the overall operational management and the large number of services and actors contributing to the end-to-end operations, the overall coordination across services and entities is of paramount importance and it relies on specific procedures and teams ensuring this coordination.

[REQ-10]The EOF-CSC operations implementation shall document the necessary procedures to manage the operational interfaces and contingencies across the various services contributing to the EOF.

In particular, whenever trade-offs have to be established between the available level of resources and the operations performances, The EOF-CSC shall always guarantee the mission data safeguard and the maximum achievable production quality while balancing the system configuration against timeliness.

[REQ-11]The EOF-CSC implementation shall aim at the maximum operational performances (quality, timeliness, completeness, reliability) for mission exploitation.

[REQ-12]The EOF-CSC implementation shall safeguard and retain under ESA responsibility the absolute reference for quality and long-term operations, enabling ESA or any other entity designated by the European Commission to take over any service provision.

[REQ-13]The EOF-CSC implementation shall maximize the operations flexibility and scalability and also embed the necessary agility and technical capability to enable the transfer of any service delivery between different providers with no impact on the on-going operations.

[REQ-14]The EOF-CSC implementation shall be based wherever possible on the use of well-established public cloud technology and providers respecting non-disclosure of activity.

In the frame of the EOF-CSC, a cloud provider is considered a well-established public provider whenever access to the cloud service is clearly available without discrimination to any potential customer with a public price list, and the provided cloud services are well-recognised and established.

[REQ-15]The EOF-CSC implementation shall be based whenever possible on the use of open-source components and interfaces.

[REQ-16]The EOF-CSC implementation shall aim at maximising the automation of the data flows, minimise the need for manual intervention and maximise the automated and constantly updated reporting interfaces.

[REQ-17]The EOF-CSC implementation shall include the necessary security measures and procedures to maximize the protection of operations integrity, availability and confidentiality.

[REQ-18]The EOF-CSC implementation shall not rely on ESA provided CFI elements for the infrastructure.

4.3 ESA EO Framework Architecture

[REQ-30]The EOF-CSC architecture shall minimise the dependency between the various services contributing to the end-to-end operations, allowing a specific and autonomous monitoring of the performance of each individual service.

[REQ-31]The EOF-CSC architecture shall minimize the operational impact of contingencies and prevent single point of failures.

[REQ-32]The EOF-CSC architecture shall streamline the interfaces between services with a clear and documented baseline available to any potential service provider.

Data flow interfaces, for systematic data transfer between services, are based on the concept of small data cache areas, referred to as data “interface delivery points”.

4.4 ESA EO Framework Security Services

The EOF-CSC security implements the security management of the EOF-CSC for all prevention, detection, response and maintenance activities. It is composed of the different EOF-CSC services security measures complemented by a central security management function for end-to-end auditing, risk assessment, and security incident handling.

[REQ-40]All the different EOF-CSC services shall define, implement, operate and maintain a security plan to protect the service operations according to EU regulations and best practices.

The EOF-CSC ESA Project Specific Security Officer (PSSO) acts as a central EOF-CSC security reference for the EOF-CSC operations, performing the risk assessment of the EOF-CSC operations, defining the reference guidelines for all the EOF-CSC services and managing the EOF-CSC services security auditing.

[REQ-41]The EOF-CSC shall define, implement and maintain a security plan at EOF-CSC level to establish an end-to-end security defence perimeter for the EOF-CSC.

[REQ-42]The EOF-CSC shall perform a regular security risk assessment of the EOF-CSC operations and define the services security requirements accordingly.

[REQ-43]EOF-CSC services shall report any security incidents without any delay, 7 days a week and 24h/24h, to the EOF-CSC central security service in line with the applicable Services Security Incident Handling procedure.

[REQ-44]The EOF-CSC shall define a Security Incident Handling procedure and coordinate security incidents response accordingly.

[REQ-45]The EOF-CSC central security shall ensure and manage the regular security auditing of the EOF-CSC services.

4.5 ESA EO Framework Procurements

[REQ-60]The EOF-CSC procurement scheme shall seek for strong industry involvement and responsibility in the operational services delivery.

[REQ-61]The EOF-CSC procurements shall be based on large-scale service frameworks serving all Sentinels wherever possible.

A framework is considered whenever a unique procurement action may lead to several independent contracts covering the needs of the specific procurement action.

[REQ-62]The EOF-CSC procurements shall be regulated by service level agreements defining the relationship between the effectively delivered performance and the operations cost modulation (e.g. completeness, timeliness, availability).

[REQ-63]The EOF-CSC procurements shall allow benefiting from the natural market evolution to ensure that procured services are delivered at any time at the best economic conditions.

[REQ-64]The EOF-CSC procurements shall foster industrial competition and avoid lock-in with any industrial service partner or technical solution limiting the future competition.

[REQ-65]The procured EOF-CSC services shall be independent from each other.

Situation of interdependence between providers may create de facto situations of higher risk in the provision of the service. In particular data managed within one service shall not be used for the delivery of another service unless specified in the procurement.

The provision of scalable services is serving the potential adaptation to the evolution of the operational scenario, in particular wherever the service may be impacted by evolution of the user scenario. The EOF-CSC shall adapt the performances of the services to the available resources as well as manage priorities between the different interfaces. Under no circumstances, overconsumption of resources shall occur.

[REQ-66]The procured EOF-CSC services shall be responsible to adapt the consumption of resources to the agreed scenario.

In order to illustrate the above, in a scenario for which the cost of the service is impacted by the number of user requests and associated data download, the service provider is responsible for the strategy to limit any consumption of the bandwidth that would exceed the provisioned value.

Scalability shall be managed as part of the service and rely on well-established cost models. Whenever the demand exceeds the capacity the situation will be reported and further allocation may be authorised.

[REQ-67]The EOF-CSC services shall include clear cost models allowing to scale the performances in well-established scenario.

[REQ-68]The EOF-CSC services cost models shall indicate any particular constraints to implement the required scalability, in particular the time needed to adapt to the new configuration.

The following description introduces the operational scalability scenario and the interaction between the main programme stakeholders for the management of such scalability.

The operational scenario requires the interaction between the main programme stakeholders and involves the following actors:

-COM as stakeholder for the EOF-CSC CSC operations

-Industry, as service provider for the EOF-CSC operations (multiple service providers are expected)

-User, as EOF-CSC final user, interacting with the service provider

The following diagram illustrates the end-to-end process from the establishment of the available CSC operations resources, to the configuration of the operational parameters in line with the resources, the resulting user experience and the potential role of industry (as service provider) to enhance the user experience.

The CSC operations resources are established by the European Commission as part of the overall delegation process. The EOF-CSC is designed to be able to adapt the CSC operations services capacity and performance according to the available resources, through the configuration of key operational parameters. These key operational parameters are those driving the operations cost and the EOF-CSC strategy (in terms of design, procurement and implementation) allows tuning them with minimum impact to the operations implementation.

The available EOF-CSC operational resources are translated into a set of operational parameters establishing the performance of the free and open services provided by the Copernicus Programme.

The Industrial service provider may offer additional services to users, complementing or extending the free services supported by Copernicus (e.g. ad-hoc performance, tailored data access services, etc.).

Picture 1

Figure 6: Adaptation of operational configuration for free and open services to the available CSC resources

4.6 Network and GÉANT access

The interconnection with GÉANT network is considered a key element of the EOF-CSC architecture.

[REQ-80]The EOF-CSC shall maintain a GÉANT connectivity supporting the integration of the scientific and academic community access.

4.7 ESA EO Operational Framework Support to User and Third-Party Operations

4.7.1 Data acquisition

[REQ-90]The EOF-CSC shall support authorised user ground stations with a direct access to the Sentinel-1 satellite data through a listening in to the Sentinel-1 real time data downlink performed within the EOF-CSC acquisition service (within the operational constraints and capacity). Implicitly all Sentinel-1 data acquired by a user ground station is also acquired in parallel by the EOF-CSC acquisition service.

Listening ground stations or user ground stations are defined as X-Band user ground stations in geographical overlap with the EOF-CSC Sentinel-1 X-Band ground stations.

[REQ-91]The EOF-CSC shall operate a dedicated service to provide authorised X-Band user ground stations with the necessary interfaces and information to acquire Sentinel-1 pass-through data within the EOF-CSC operational constraints and capacity.

[REQ-92]The EOF-CSC shall offer an interface to provide authorised Ka-Band user ground stations with the necessary interfaces and information (including the necessary decryption keys) to acquire Sentinel-1 pass-through data downlinked via EDRS service within the CSC operational constraints and capacity.

The European Commission is authorising such access and defines the procedure for the corresponding requests.

4.7.2 Data distribution

The EOF-CSC supports data distribution to all users according to the free and open data policy. Categories of users are established by the European Commission for statistical analysis of data uptake, and in some instances, may be used to provide prioritised quota for access (e.g. Core Copernicus Services). Extended support is also provided for authorised entities as follows.

[REQ-93]The EOF-CSC shall be able to manage the following categories of users:

oCopernicus Core Services and Downstream Services

oPublic institutions

oNational users

oInternational partners

oScientific users and value adding industry

oOperational Meteorological users

oClimate Change users

oMission Calibration and Validation users

[REQ-350]The EOF-CSC shall be able to operate the data access interfaces, access rights and priorities defined in the CSC Operations – ESA Framework - Data Access Services Service Portfolio [RD-DSP].

Collaborative Users shall have free on-line access to the systematically generated core user data, and reprocessed data through an on-line data access points with access rights configuration restricted to authorised entities.

International Users, shall have free on-line access to the systematically generated core user data through an on-line data access point with access rights configuration restricted to authorised entities.

The European Commission is authorising the International access while the Collaborative access is conceived for privileged access to the EU/ESA member states and further supported directly by the ESA programme. The load of the Collaborative data access on Copernicus core operations shall not exceed the equivalent of one user retrieving all data once.

4.7.3 Data access synergetic services

Whereas the data access provides open and free-of-charge data access to all users for data download, the experience in the 2014-2020 MMF with the DIAS initiative demonstrated that ease of user exploitation of the Sentinel data can be considerably enhanced through the provision of compute resources and further customer facing value adding applications local to the data holdings. By supporting the presence of such third-party interfaces, the EOF-CSC operations provide an anchor tenancy that may contribute to the development of sustainable applications with even opportune or competitive reductions of data access operational costs. It is noted that the support to complementary applications is performed within the limit of the core operation performances on best effort basis.

[REQ-351]The EOF-CSC shall support the operation of interfaces for the development of synergetic applications including the provision of competitive, scalable, state of art, on-demand computing environment allowing users to process hosted data with high efficiency.

[REQ-352]The EOF-CSC data access services should support synergy with complementary datasets access, in compliance with any licensing, including:

Copernicus Services Information

Copernicus Contributing Mission data

In-situ data

Other earth observation or socio-economic data, ….

[REQ-353]The EOF-CSC data access services should support synergy with complementary services including:

Programming environments

Interoperable interfaces

Specialised tools

Market place,.…

[REQ-354]The EOF-CSC data access services should foster synergies and federation opportunities with other European and National initiatives

5 Observation strategy implementation

The observation scenario defines the target utilisation of the instrument operations (typically in terms of coverage, observation revisit and frequency) to fulfil the mission objectives and the user needs collected by the European Commission. The EOF-CSC converts the observation scenario into a satellite tasking and downlink activities. The associated operations specifications are defined in this section.

[REQ-100]The EOF-CSC shall implement the translation between the observation needs for each Sentinel mission and the associated instrument operations, maximising the user satisfaction within the mission operational constraints and capacity.

[REQ-101]The satellite observation scenario implemented by The EOF-CSC shall be traced to the “CSC ESA GS Operations Framework - Copernicus Sentinels Observation Strategy - Implementation”.

[REQ-102]The EOF-CSC shall be based on a predefined observation plan, ensuring coherent coverage and consistent mission archive build-up.

[REQ-103]The EOF-CSC shall allow (depending on mission objectives and capabilities) the predefined observation plan to be disrupted to implement ad-hoc observation (time-limited) needs from the Copernicus Emergency & Security Services and the International Charter for Major Disasters. N.B. For the currently operational missions, this requirement applies only to the Sentinel-1 mission.

6 Flight Operations Segment Services

The Flight Operations Segment (FOS) Services encompasses the services required for operating the satellite and ensure the satellite safety, including in particular the following services:

Satellite commanding, monitoring and control service

Telecommand security

Backup control service

Debris monitoring service

Collision avoidance service

Flight dynamics service

The following assumptions are considered in relation to the Flight Operations Segment (FOS):

The FOS cover all the necessary satellite operations to implement the observation scenario and preserve the satellite safety and its long-term performance including in particular: satellite commanding, monitoring and control, orbit maintenance, debris monitoring and collision avoidance, flight dynamics.

The FOS cover the operational satellite performance monitoring activities and the necessary industrial expertise to regularly predict/assess any performance deviations and implement possible corrective actions.

The FOS ensure the availability of the necessary industrial expertise to timely support in-flight satellite contingencies analysis and recovery.

Whenever an ESA - EUMETSAT FOS exchange of services is in place, the services shall be part of the management arrangement and the baseline described in the ESA - EUMETSAT coordinated baseline.

The ESA - EUMETSAT Coordinated Flight Operation Services are documented in the Contribution Agreements for the period 2022 - 2027.

7 EOF-CSC operational management services

[REQ-120]The EOF-CSC Operational Management shall include the end-to-end monitoring and comprehensive reporting of the on-going operations performances.

[REQ-121]The EOF-CSC Operational Management shall monitor/operate on the basis of clear interfaces between the elements and services contributing to the operations allowing the monitoring of each individual service performance.

[REQ-122]Whenever an ESA - EUMETSAT exchange of services for the CSC Operation management is in place, the services shall be part of the management arrangement and the baseline described in the ESA - EUMETSAT coordinated baseline.

The ESA-EUMETSAT Coordinated Operation Management Services are documented in the contribution agreements for the period 2022 – 2027.

7.1 EOF-CSC End to end performance monitoring services

[REQ-140]The end-to-end performance monitoring services shall provide a comprehensive and all-inclusive regular reporting of the end-to-end operations, adequately integrating the boundaries between services interfaces.

[REQ-141]The end-to-end performance monitoring services shall provide a continuously up to date view of the overall EOF-CSC status to its stakeholders, including the evolution of the operational performance and any issues impacting the delivery of services to users.

[REQ-142]The end-to-end monitoring services shall make available on-line up to date status information on the on-going operations through an operation monitoring dashboard, offering Copernicus stakeholders and users the possibility to autonomously understand the overall performances, in particular for issues impacting data availability and/or quality.

7.2 EOF-CSC Operations Coordination services

The orchestration of the operations provided by the various services involved in the EOF-CSC requires a careful management, ensuring e.g. that any anomalies across services are timely identified, that all affected services are duly notified and investigations pursued with the necessary contribution of multiple services whenever required. The Operations Coordination Services, in conjunction with the end-to-end monitoring, shall aim at ensuring the proper coordination between the operations performed by the various services.

[REQ-150]The Operations Coordination services shall ensure the operational coordination of all the services contributing to the EOF-CSC operations.

[REQ-151]The Operations Coordination services shall be operational all days of the year during nominal working hours.

[REQ-152]The Operations Coordination Service shall provide full visibility of the operations coordination activities and status through an interactive dashboard.

7.3 Benchmarking services

The EOF-CSC shall include the functions for assessing the quality, from a user perspective, of the operational services available to users as well as a measure of comparison against similar services operated by other providers.

The service performance as reported and monitored by the services provider shall be in line with the applicable Service Level Agreements. However, the performances experienced by the user at the access points may differ among users depending on a number of user parameters such as e.g. its connectivity or its effectiveness on using the available interfaces, and may differ from the quality experienced on access points offered by other providers.

The outcomes of the benchmarking services shall be used wherever relevant to identify limitations in the services available to users leading potentially to the design of improved data accessibility solutions.

[REQ-160]The benchmarking services shall provide an objective and comprehensive assessment of the user experience from an external perspective.

The benchmarking activity shall make use of the public service interface and shall not depend on any service internal design knowledge, any service internal interface or any service monitoring interface.

[REQ-161]The benchmarking service shall assess the service quality based on the most common and representative users’ behaviours and operations when accessing the provided service, including most common technological solutions adopted by the users of the service.

[REQ-162]The benchmarking services shall be factual, i.e. based on recording of actual measurements.

[REQ-163]The benchmarking service shall provide verifiable results.

This implies that the obtained results shall be made available in support to internal and external auditing (e.g. from the benchmarked service providers)

[REQ-164]The benchmarking services shall maintain and make openly available a detailed description of the benchmarking methodology (including software code) providing full visibility on how benchmarking is performed and ensuring the possibility to reproduce the results.

[REQ-165]The benchmarking services shall provide absolute state-of-the-art reference in the domain, through comparison with third party services as far as possible.

This means that external benchmarking shall be included, addressing prominent target sites that provide similar data access services.

[REQ-166]The benchmarking service shall include appropriate internal diagnostics to calibrate and validate the benchmarking results and support their interpretation in order to guarantee robust and reliable results.

Examples include decontamination from underperformances of the measuring network and/or by the effect related to the diversity of the network providers.

[REQ-167]The benchmarking services must be configurable and expandable.

[REQ-168]The benchmarking services shall provide an objective and comprehensive assessment of the user experience from a global perspective (from Europe and beyond).

7.4 Traceability services

The EOF-CSC is in charge of the operational Sentinel data production. The free and open Copernicus data policy allows potential third parties to easily setup a production chain or a distribution service in parallel to the EOF-CSC services. These complementary services support the development of applications and are encouraged; however, the EOF-CSC services cannot be held responsible for the outcome of such production. In addition, for security issues and proper management of the operations the need to maintain the knowledge of the products generated by the core services is necessary. Traditionally such service was partially implemented by maintaining the baseline of the archive content and of the disseminated production. The increase of on-demand production operations, the increasing number of processor versions, the cleaning of the archive for obsolete baselines and the possibility to transfer core services as the result of industrial competition is complexifying the operation of such service based on individual EOF-CSC service monitoring and reporting. This scenario leads to the need for a dedicated traceability service as part of the EOF-CSC operations.

The traceability service shall implement the following requirements.

[REQ-180]The traceability service shall provide the possibility to identify all user level data univocally.

The term “trace” is used to represent the information used to identify the user level data. User level data are often made of large repository of files that can be grouped into a unique package. The traceability service may provide several levels of identification.

[REQ-181]The traceability service shall allow to trace the originating services that have generated the user level data.

[REQ-182]The traceability service shall be open free of charge to any user verifying the authenticity of a given Copernicus user level data.

7.5 Reference system services

The Reference System is a key element of the EOF-CSC that mitigates the risk of industrial lock-in for the Sentinel data production and dissemination functions.

[REQ-190]The Reference System services shall provide a ready-to-use representative environment for the integration of new user level data and their pilot production phase.

[REQ-191]The Reference System services shall provide a representative EOF-CSC operational environment for the pre-launch activities related to the new Sentinel unit.

[REQ-192]The Reference System services shall provide and maintain an open-source solution, in a collaborative and publicly accessible environment, for the Sentinel production and dissemination functions.

[REQ-193]The Reference System services shall allow the configuration of systematic and on-demand production chains, for any of the Sentinel user level data types, with various degrees of scalability

[REQ-194]The Reference System services shall be operated on a public cloud.

8 Mission services

The mission specific observation scenarios are converted into an instrument tasking and a satellite downlink plan as part of the mission planning service operations, in line with the satellite operational capacity and constraints (e.g. instrument duty cycle, maximum satellite downlink time, available downlink resources, etc.) and the available ground resources.

The instrument tasking and satellite downlink plan are uplinked to the satellite by the Flight Operations Segment services, as part of the routine satellite command and control operations.

Payload and satellite housekeeping data are acquired on ground for subsequent processing and satellite monitoring and control.

Authorised Copernicus users may have the possibility to listen to the Sentinel payload data downlinks within the mission operations constraints and capabilities.

8.1 Mission planning services

The mission planning service may be considered as the origin of the operational data flow, feeding the satellite with the necessary commanding activities to perform the desired observations and ultimately generate the associated production and data delivery flows.

[REQ-210]The mission planning services shall encompass all activities necessary to translate the “ESA Copernicus Ground Segment Operation Framework - Sentinels Observation Strategy Implementation” into instrument tasking and satellite downlink requests.

[REQ-211]The mission planning services shall operate the interfaces to provide the scheduling information needed by the acquisition service, allowing an optimised delivery of the acquisition services with the maximum performance.

The mission planning has also to consider the constraints that may be derived from the acquisition service operations (Interferences between satellites, unavailability of stations, deconflicting between sentinels, ...).

[REQ-212]The mission planning services shall operate the interfaces to provide conflict free, feasible and safe instrument tasking and satellite downlink activities to the satellite commanding service with the frequency and coverage required by the specific mission operations.

For missions without a systematic or continuous instrument operations, users may need the information on the foreseen detailed observation scenario (i.e. list of the planned data takes, with associated time, duration and instrument mode).

[REQ-213]The mission planning services shall provide the flexibility to reconfigure the downlink planning to a new set of available acquisition resources within one satellite cycle.

[REQ-214]The mission planning services shall provide the flexibility to reconfigure the downlink scenario and the acquisition resources within 72h in case of contingencies.

As an example, such a situation may occur to temporarily replace an X-Band station in case of long term unavailability preventing data loss.

[REQ-215]The mission planning service shall operate the interfaces allowing the provision of an up-to-date detailed satellite tasking plan to all users.

For the S1-type of mission, the instrument duty cycle is shorter than the complete orbit and planned instrument activities may not be optimally tasked to respond to unexpected needs from the Copernicus Emergency Service and the International Charter for Major Disaster, requiring an ad-hoc modification of the existing planning.

[REQ-216]The mission planning services shall operate the interfaces to support ad-hoc modifications of the Sentinel-1 planning from authorised entities during working hours all days of the year.

Authorisation shall be provided by the EC.

8.2 Data acquisition services

All payload data resulting from the scheduled instrument observations shall be acquired on ground to allow further processing and data exploitation.

The EOF-CSC data acquisition services specifications assume that:

-The satellite operational constraints and capabilities provide sufficient flexibility to procure the data acquisition services through open competition, allowing for more than one possible combination of stations to support a target observation scenario compatible with the satellite observation capabilities and constraints.

-The necessary sizing of the acquisition services (e.g. in number of available downlink time per orbit) can be obtained by multiple combinations of acquisition stations, jointly contributing to the overall downlink resources.

The associated specifications are defined hereafter.

[REQ-230]The acquisition services capacity shall be sufficient to acquire all the Sentinel data according to the observation strategy for each satellite.

For Sentinel-1,-2,-3,5P, the downlink operations rely on a set of available acquisition resources (corresponding typically to the visibility of several X-Band stations and the available EDRS downlink sessions in case it is supported by the operated satellite) to implement the instrument tasking and downlink plan, which are procured through open competition and adjusted in capacity (e.g. by adding additional X-Band stations) in line with the evolution of downlink needs.

[REQ-231]The acquisition capacity shall be based on an optimised combination of the available downlink capabilities and resources of the satellites.

Optimisation may consider different kind of criteria including overall downlink capacity, fulfilment of sensing scenarios downlink timeliness, operational robustness, operations complexity, overall cost…).

[REQ-232]The acquisition service shall encompass all activities from data acquisition to delivery of acquired data streams to the acquisition service interface delivery point.

[REQ-233]The acquisition service interface delivery point shall be scalable to ensure the acquired data is available within the timeliness needed to achieve the systematic production service performance.

[REQ-234]Whenever applicable, the acquisition service shall provide an interface to EUMETSAT to retrieve the acquired satellite data stream provided by the X-band ground stations within the same timeliness this data stream is made available to the EOF-CSC production with no impact on the operational performances.

[REQ-235]The acquisition service shall perform a detailed and continuous monitoring of the associated operations performance, regularly report on the achieved performance and timely report on any issues affecting the service operations.

8.2.1 The X-Band acquisition services

The Sentinels First generation and a subset of the Copernicus Expansion missions rely on X-Band technology to downlink the payload data to ground. They are hereafter referred as “Copernicus X-Band Missions”.

[REQ-240]The acquisition service shall include the necessary interfaces and operations to acquire the Sentinel data in X-Band.

[REQ-241]The X-Band acquisition service shall be sized to be able to acquire all Copernicus X-Band Missions data.

[REQ-242]The X-Band acquisition service shall be procured as a unique service framework, covering all X-Band acquisition needs of the Copernicus X-Band Missions , based on a combination of geographical visibility (e.g. over Europe) and total available downlink time.

8.2.2 The Ka-Band acquisition services

The Copernicus Expansion missions will include Ka-Band data downlink to satisfy the overall payload data downlink needs. They are hereafter referred as “Copernicus Ka-Band Missions”.

[REQ-243]The acquisition service shall include the necessary interfaces and operations to acquire the Copernicus missions data in Ka-Band.

[REQ-244]The Ka-Band acquisition service shall be sized to be able to acquire all Copernicus Ka-Band Mission data.

[REQ-245]The Ka-Band acquisition service shall be procured as a unique service framework, covering all Ka-Band acquisition needs of the Copernicus Ka-Band Mission, based on a combination of geographical visibility (e.g. over Europe) and total available downlink time.

8.2.3 EDRS acquisition services

For missions embarking an optical communication payload (currently S1 and S2 missions), data downlink can be performed through Ka-Band via the EDRS Service, complementing the X-Band downlink capability.

[REQ-250]The EOF-CSC acquisition service shall include the necessary interfaces and operations to downlink the Sentinel data using the EDRS acquisition service.

[REQ-251]The EDRS acquisition service shall encompass all activities from EDRS scheduling, optical link operations, Ka-Band downlink, and data acquisition to delivery of acquired CADU & VCDU decrypted data streams to the EDRS service interface delivery point.

8.3 Precise orbit determination services

[REQ-260]The EOF-CSC shall ensure the availability of precise orbit information based on satellite telemetry for further utilisation by the Data Services.

This specification applies for missions requiring precise orbit information for the operational generation of user level data. The type of orbit information and the associated timeliness are mission dependent.

9 Data Services

Specifications for the implementation of the various data services are logically organised by the following categories of services:

Production services (incl. operations data quality monitoring)

Data preservation services

Data access services

Processing algorithms and processor maintenance services (incl. user level data specifications maintenance)

Data quality services

[REQ-270]The Data Services implementation shall allow adapting the service performance according to the user needs and available resources.

9.1 Data Preservation Services

[REQ-280]The data preservation services shall guarantee the preservation of all the acquired mission data in raw format.

Preservation of historical Level-1/2 is subject to trade-off between the resources available and the needed time for generation and availability at the user end. The decision shall be documented user level data type by user level data type.

[REQ-281]The data preservation services shall guarantee the preservation of the auxiliary data and supporting information necessary for future exploitation of the mission raw data.

[REQ-282]The data preservation services shall safeguard the mission data in raw format at least in two distinct geographical areas.

[REQ-283]The data preservation services shall enable the preservation of all acquired mission data beyond the reference operations period.

[REQ-284]The data preservation services shall trace the content of the complete archive making use of the traceability service.

[REQ-285]The data preservation services shall encompass all activities from data ingestion to delivery upon request to the preservation service interface delivery point.

[REQ-286]The data preservation service interface delivery point shall be scalable to ensure the retrieval of data is within the timeliness needed to achieve the on-demand production performances.

[REQ-287]The data preservation service shall perform a detailed and continuous monitoring of the associated operations performance, regularly reporting on the achieved performance and timely report on any issues affecting the service operations.

9.2 Production services

The production services are in charge of converting the raw data from the satellite into user level data. The production services encompass the systematic production, triggered by the availability of new data, and the data reprocessing. Large scale reprocessing is managed according to campaigns authorised with specific requirements to provide harmonised datasets with latest achievable quality. On-demand processing is addressed as part of the Data Access services.

[REQ-300]The production services shall be able to generate and make available the portfolio of user level data defined in [RD-EOF-DASP] within their quality specifications.

[REQ-301]The production services encompass all activities necessary to convert any acquired Sentinel data into user level data.

[REQ-302]The production services shall encompass all activities from data collection from the acquisition services to availability of the of the engineering and user level data on the production service interface delivery point.

[REQ-303]The production service interface delivery point shall be scalable to ensure the user level data is available within the timeliness needed to achieve the intended performances for publication towards the end-users.

[REQ-304]The production service shall rely on ESA provided CFIs for the processing software generating the L0, L1 and L2 data.

The use of ESA provided CFI elements for the generation of the L0/L1/L2 guarantees to Copernicus user a harmonised quality regardless of the potential changes in the production service provider and also in case of multiple simultaneous service providers.

[REQ-305]The production service shall trace any generated user level data available for retrieval at the interface delivery point making use of the traceability service.

[REQ-306]The production service shall be sized to cover the systematic production of all the acquired Copernicus Sentinel data.

[REQ-307]Removed (The requirement for on-demand production operations is associated to the Data Access Service).

[REQ-308]The production service shall be capable of generating any user level data with any processor version and processing context.

[REQ-309]The production service shall aim at generating the user level data with the best achievable quality by default.

[REQ-310]The production service shall systematically verify and monitor the quality of the generated user level data

The production service shall not interrupt the data delivery, the quality report and quality disclaimer are available for retrieval by end users.

[REQ-311]The production service shall perform a detailed and continuous monitoring of the associated operations performance, regularly report on the achieved performance and timely report on any issues affecting the service operations.

[REQ-312]The production service shall be procured as a unique service framework for all the Sentinels.

9.3 Data Calibration and Validation services

The Calibration and Validation services ensure the calibration and the validation of the user Level-1 and Level-2 data as defined in [RD-3].

These activities encompass the monitoring of the instrument performance and the expert quality assessment of user level data.

[REQ-313]The data Calibration services operations shall perform the necessary activities to ensure the Calibration of the User Level data and monitor their quality.

[REQ-314]The data Validation services operations shall perform the necessary activities to ensure the validation of the User Level data and monitor their quality.

9.4 Algorithms and data processors services

The algorithms and data processors services ensure the maintenance and evolutions of the mission/instrument specific scientific algorithms to convert the satellite data stream into instrument and geophysical measurements, as well as the maintenance and evolutions of the operational software implementing these algorithms for the purpose of generating engineering and user level data in line with the mission specificities and user needs.

[REQ-315]The EOF-CSC processing algorithms definition shall be openly available to users, ensuring full transparency of the scientific transformations necessary to generate the mission-specific measurements/variables.

[REQ-316]The EOF-CSC operational processing software shall be openly available to users, providing full transparency of the applied data transformations, enabling user-tailoring evolutions and supporting the development of complementary mission-derived information.

[REQ-317]The EOF-CSC algorithms and data processors shall be regularly maintained and evolved to ensure the maximum quality of the data generated by the EOF-CSC.

A regular frequency of 2 processor releases per year is foreseen to introduce algorithm evolutions, improvements and minor corrections. Additional versions may be released in case of major / urgent changes to be introduced.

9.5 Data access services

By its nature, the Data Access Services operations load and performance may be impacted by the diversity and unpredictable evolution of the user scenario in terms of data access needs and access profile (e.g. request for partial or complete user level data, etc.). The sizing of the user scenario is not only difficult to predict on average (e.g. average download volume, average active users, etc.) but presents also a high variability along time (e.g. high peaks related to sudden retrieval requests for user level data on areas impacted by catastrophic events, development of new operations or services that may require access to complete time series…).

In line with the Copernicus Regulation, the EOF-CSC shall offer a full, open and free-of-charge data access to all users, optimising the available operations resources and cost efficiency. This requires establishing an equilibrium between the resources allocated to the fast access infrastructure (e.g. volume of on-line data, available bandwidth…) and in an on-demand scenario the production capacity (e.g. computing infrastructure and feeding links…). As a matter of example, maintaining all user level data available on-line at its native resolution and compression, may not be as cost efficient as allowing for rolling-out past user level data with time and offering the possibility to retrieve them from off-line systems or even following on-demand reprocessing. Whatever would be the selected approach at any point in time, an unlimited demand cannot be satisfied with limited resources and operations shall be protected to prevent the unfair usage of the operational services (e.g. the sudden request for accessing the complete historical production would create such surge on an open system that it could overflow its capacity and block the nominal services for all other users). The protections against such a scenario need to be considered as a nominal function of the data access system (e.g. quotas, queuing of demands, …).

[REQ-318]The data access services shall provide access to historic products with a scalable and committed timeliness according to the available resources and to the user scenario.

[REQ-319]The data access service shall provide access to historic products with the timeliness defined in [RD-EOF-DASP] corresponding to serving a user request.

[REQ-320]The data access services shall be configurable to offer free access to Sentinel user level data as defined in [RD-EOF-DASP] to all users for all data acquired by the Sentinel satellites.

[REQ-321]The data access services shall be configurable to offer authorised users an ad-hoc access or a restricted access to Sentinel user level data.

Possible security restrictions are defined by the European Commission and may apply on some user level data. Restriction may apply only on availability timeliness.

[REQ-322]The data access service shall maximise the usage of available resources and secure a fair access to all users.

The term “fair access” is meant here to ensure that under all operational conditions all users are offered with an equivalent access priority.

[REQ-323]The data access service shall offer a pull retrieval interface (download) based on public internet access to all accessible user level data.

The richness of the information contained in the Sentinel user level data is such that the same user level data may be used for multiple applications requiring different components of the same user level data. The classical definition concept, with a fixed packaging and sizing, has demonstrated to be rigid for the large Sentinel volume, with users forced to download the full user level data regardless of the subset of information that would be needed for subsequent applications.

[REQ-324]The data access services shall offer on the fly user configurable transformations.

Transformations are mainly aiming at reducing the data transfer from the data access service to the end user. Transformation may be fast extraction of user level data subset.

[REQ-325]While maintaining traceability to the user level data source, the data access services shall be capable to reformat upon user request the downloaded user level data.

While the concept of user level data definition is essential to describe and characterise the user level data content (including all necessary quality annotations), a flexible organisation of the information contained would further support the development of user applications.

The timeliness of user level data availability to users depends on the user typology and on the data age. Fresh Sentinel user level data are made available to the Copernicus Services with committed timeliness and to other user typologies with target timeliness. Historical user level data are available with target timeliness to all user typologies. The migration from recent to historical user level data class may be driven by the attainment of a configurable user level data aging, which may be adjusted depending on the demand and on the available overall system resources (e.g. on-line retention time for immediate access to data may be adjusted according to the available resources).

[REQ-326]The data access services shall provide online access to all systematically generated user level data (referred to as “recent user level data”) within their timeliness specifications as per [RD-EOF-DASP].

Timeliness corresponds to the time span between data sensing by the satellite to the availability of the corresponding user level data for user download.

[REQ-327]The data access services online access shall be configurable with a “retention time” after which the user level data may have to be generated again (hereafter referred to as “historical user level data”).

[REQ-328]The data access services shall provide all the necessary interfaces and functionality to make available online any historical data (hereafter referred to as “historical user level data”) within their timeliness specifications as per [RD-DASP]NTC.

[REQ-329]The data access services shall perform a detailed and continuous monitoring of the associated operations performance, regularly report on the achieved performance and timely report on any issues affecting the service operations.

[REQ-330]The data access services shall provide transparent and public information on the data access services performance.

[REQ-331]The spatial data products and information generated within the Copernicus space component activities shall be compatible and interoperable with the data and spatial information systems provided by Member States in accordance with Directive 2007/2/EC of the European Parliament and of the Council ( 2 ) and Commission Regulations (EC) No 1205/2008 ( 3 ) , (EU) No 1089/2010 ( 4 ) and (EC) No 976/2009 ( 5 ) .

[REQ-332]The data access service shall be scalable to cover on-demand production triggered by user request.

9.6 Data support services

[REQ-340]The data support services shall provide and coordinate the following list of operational services:

User front-desk services

Training and support services

Data access tools

[REQ-341]The data support services shall make available all necessary information and documentation to exploit the user level data and operational services interfaces and to inform users on any foreseen evolutions impacting the user data and interfaces in advance.

[REQ-342]The data support services shall provide a help-desk front line for the users to raise enquiries on operations status and any issues encountered in the usage of the EOF-CSC services and user level data.

[REQ-343]The data support services shall support training sessions on mission and data access.

[REQ-344]The data support services shall provide communication means to collect and support user experience and feedbacks.

[REQ-345]The EOF-CSC shall provide open-source tools allowing the basic exploitation of user level data (e.g. catalogue, view, projections, format conversions, calibration, etc.).


Annex B - EC Requirements - ESA Specifications traceability

9.7 Traceability to Functional Requirements for the acquisition, generation and archiving of Sentinel data

Operations Management

Req. [1]

The ground segment shall be capable of acquiring, processing, archiving and distributing Sentinel data as observed by the Sentinel satellites and exploit the space infrastructure to the maximum.

The ground segment shall allow exploiting the full capacity of the Sentinels, it shall make sure that the satellite is controlled and monitored, data is acquired, downlinked, processed to user level data, archived and distributed to users, in line with user requirements and corresponding operations planning, the capacity and technical constraints of the satellite.

[REQ-1] to [REQ-4]

Req. [2]

The ground segment shall be organized in such a way that it ensures flexible and efficient operations while guaranteeing performance.

The ground segment shall build on state-off-the-art approaches in operational management such as autonomy and allow dynamic adaptation to changing user behaviour. In particular, it shall be designed in such a way that it optimizes data transfers, storage and processing needs taking into account user behaviour and needs. Operations across the different Sentinels shall be harmonized, avoiding duplication (but allowing for redundancy to create resilience). It shall be possible to upgrade and possibly re-configure the ground segment without service interruption.

[REQ-66] to [REQ-68]

Req. [3]

The ground segment shall operate with well-defined and documented specifications and performances, visible to the users. It shall be scalable and evolve to support changing demands and needs, when required.

The ground segment shall be designed with clear boundary conditions in terms of data acquired, User Level Data generated, performance and availability that respond to documented user needs. It shall be able to scale up when the need arises, minimising the risk of major architectural changes.

[REQ-10]

[REQ-142]

[REQ-66] to [REQ-68]

Req. [4]

Lock-in, with dependencies on one or more providers, shall be avoided.

The ground segment shall be designed in such a way that it avoids lock-in situations (including a lock-in across the ground segment functional elements), e.g. by maximising the possibility for open competition while recognising the need for stability of operations. Implementation shall incentivise non-proprietary solutions and compliance with performance targets.

[REQ-64]

Req. [5]

Contingency and risk management shall be part of the operations management.

Contingency management and related operational processes shall be clearly linked to failure and risk analyses and aim at restoring defined (reduced) service levels. Contingency management processes shall include appropriate and timely notification of the users.

[REQ-31]

Note#1: Dedicated Risk management is pert of the EOF-CSC project management.

Req. [6]

The high-level ground segment architecture and operations concept shall be documented.

The document shall describe all aspects of the ground segment, covering all relevant functions, as well as the operational procedures, monitoring and control aspects, interfaces, performance budgets, user management and boundary conditions. It shall include detailed specifications and requirements for each of the ground segment elements (i.e. availability, timeliness, user management). It shall ensure traceability against the requirements as set out in this document.

[REQ-10]

Security aspects

Req. [7]

All ground segment elements, facilities and their operations shall be adequately protected against security threats, including deliberate attacks.

The Copernicus ground segment components shall be protected from disruption or misdirection of the services they provide (e.g. network and computer intrusions, data corruption, malpractice by operators, physical damage). All elements must therefore include measures for protection and access control.  The Copernicus ground segment shall provide integrated end-to-end security services that do not require user configuration of individual ground segment components.

[REQ-17]

[REQ-40] to [REQ-45]

Req. [8]

A set of security requirements and recommended barriers shall be developed in line with the international standards and best practices. Sensitive information, if identified, shall be handled according to the applicable rules.

Specific detailed security requirements should be developed during the definition phase in order to provide protection of services and assets. These requirements may be generic for all elements based on common standards or best practices. They should include common security practices (e.g. regular software updates, anti-virus protection, back-up, operational awareness etc.) as well as specific requirements proper to the Copernicus ground segment. For the critical and security related elements it is recommended to perform an assessment of the threats and derive requirements for the identified countermeasures.  Copernicus ground segment elements and their operations should be developed in line with these security requirements. Sensitive information must be protected and procedures for handling of sensitive information according to their level of sensitivity must be defined.

[REQ-17]

[REQ-40] to [REQ-45]

Req. [9]

Critical and security-relevant elements shall be identified, dedicated protection including physical access and operational measures shall be developed and related information shall be appropriately protected.

Critical or security related elements in the Copernicus ground segment shall be identified and a set of explicit security countermeasures and procedures should be developed for each element. This is to ensure that these elements are adequately protected in line with their specific functions and specific risks are properly managed. This includes, when needed, data encryption, data classification, operational procedures, physical constraints for access etc.

[REQ-17]

[REQ-40] to [REQ-45]

Req. [10]

A regular risk assessment shall be performed and derived mitigations implemented. Unauthorized activity shall be continuously monitored, recorded and reported.

Regular re-evaluation of the threats and risks as well as the effectiveness of the implemented measures shall be performed during the life cycle of the Copernicus ground segment elements. When necessary, new measures should be taken or existing measures adapted in order to enhance the system security. The Copernicus ground segment elements should be constantly monitored for attacks or intrusions and intrusion management procedures should be established.

[REQ-17]

[REQ-40] to [REQ-45]

Satellite and payload operations and control

Req. [11]

The ground segment shall ensure the safe operations of the satellite and payload.

Satellite and payload shall be operated such that the design life time of the satellites will be achievable while observation capacity is guaranteed. The ground segment shall monitor and control the satellites’ and payloads’ health and behaviour. It shall furthermore include functionalities that enable the protection of the satellites against catastrophic events, potential collisions with space debris and space weather. The ground segment shall be capable to safely de-orbit the satellite at the end-of life. Clear and secure interfaces shall be designed and documented for the tasking of space resources, for the collection of relevant contributions to the operational planning process, and for flight operations.

[REQ-110] to [REQ-113]

Payload Data Acquisition

Req. [12]

The Sentinel Payload Data Acquisition (Sentinel Observation) Strategy shall ensure systematic acquisitions which shall be defined based upon user needs

The Sentinel Observation Strategy shall be traceable to user needs. It shall be documented and made available to users. Where, in exceptional cases, sensitive acquisitions are planned in deviation from the regular acquisition plan, information on such planning shall be handled according to the rules and procedures for sensitive information, as required.

[REQ-100] to [REQ-102]

Note#1: The Sentinel observation strategy is documented as part of the EOF-CSC in the “Copernicus Sentinels Observation Strategy - Implementation” document according to the current HLOP and in line with the “EC Ground Segment Functional Requirements”

Req. [13]

The ground segment shall implement the Copernicus Sentinel Observation Strategy and ensure that data observed is systematically transferred to earth for further processing

Transfer of data from the satellite to the earth shall be ensured with a time delay optimised to meet the operational needs of the users; optional encryption and “sensitivity handling” of the downlinked data shall be foreseen where technically possible.

[REQ-230]

Req. [14]

The ground segment shall implement functionalities that enable the on-demand tasking of the payload for relevant Copernicus Sentinels for which it shall establish a transparent and flexible procedure and make allowance for in the Observation Strategy.

This requirement applies to Sentinels that do not cover the full globe as part of their systematic acquisition plan and to all space resources for on-demand QRT observation (exception from routine) requests. The capacity of tasking as defined in the Observation Strategy shall be ensured. Ad-hoc observation requests by authorised users shall not compromise the regular observation scenario. When such requests are served in exceptional cases, they shall be responded to within reaction times and allowances foreseen in the Observation Strategy.

[REQ-100] to [REQ-102]

[REQ-210]

Note#1: The Sentinel observation strategy is documented as part of the EOF-CSC in the “Copernicus Sentinels Observation Strategy - Implementation” document according to the current HLOP and in line with the “EC Ground Segment Functional Requirements”

Sentinel User Level Data Generation and interfaces

Req. [15]

Data acquired by the Sentinels shall be systematically processed to generate Sentinel User Level Data

The need to generate Sentinel User Level Data shall be traceable to user requirements.

[REQ-300], [REQ-301]

Req. [16]

The Sentinel User Level Data shall be uniquely and unequivocally identifiable and shall be made available in well-documented formats, conform to applicable standards, and, with the appropriate metadata

The system or convention allowing the identification of Sentinel User Level Data shall be designed such that it is possible for other organisations to unequivocally identify their data in a coherent way. The generator of the data shall provide all metadata information pertaining to his/her action in the data generation process prior to making them available to the users

[REQ-180] to [REQ-182]

[REQ-331]

Req. [17]

Sentinel User Level Data shall be of state-of-the art quality, quality shall be operationally monitored and information regarding the quality and overall characteristics shall be available to users

Sentinel User Level Data shall be properly calibrated and validated. This includes the cross-calibration of Sentinel User Level data from different Sentinel units. Consistency across Sentinels shall be pursued to the maximum possible (i.e. Copernicus programme level ancillary data shall be used for all sentinels where it technically makes sense).

[REQ-300], [REQ-313]

Req. [18]

The Sentinel User Level Data Generation function shall be able to re-process the Sentinel data when new algorithms become available or when older versions of the Sentinel User Level data, not available in the archive, are requested by users

[REQ-308]

Req. [19]

All Sentinel User Level Data shall be made available according to documented Sentinel User Level Data Service Specifications

The conditions under which the Sentinel User Level Data are made available shall be documented in the ‘Sentinel User Level Data Service Specifications’. These conditions shall be defined for each of the Sentinel user level data and shall be based upon user requirements and include technical considerations. It shall amongst others contain service specifications regarding the timeliness of the User Level Data (time elapsed between data observation and availability of the user level data to the users), completeness (percentage of user level data available, as compared to observations, within a given time limit), availability (availability of data observed as compared to observations planned), means and conditions of access (online, archive, EUMETCast), quality information, and content. A process to modify and update the Sentinel User Level Data Service Specifications shall be defined.

[REQ-300]

Req. [20]

Users shall receive advanced notices of the modifications brought to the Sentinel User Level Data characteristics and metadata in order to anticipate modifications in their own processing chains. Modifications shall be classified according to their potential impact on users and a notice period shall be specified accordingly.

[REQ-341]

Req. [21]

The ground segment shall provide for the possibility to receive and process Copernicus third-party data where this is warranted by user requirements.

The ground segment shall include appropriate interfaces and services to ingest, process, and archive necessary reference data from in-situ networks or other reference data sources. In addition, the Ground Segment could include interfaces and services to ingest, process, archive and make available to users data from missions operated by third parties.

[REQ-60] to [REQ-68]

Sentinel Long Term Data Preservation

Req. [22]

Sentinel data and associated ancillary data, algorithms, documentation and tools necessary to generate Sentinel User Level Data shall be archived and shall be preserved without time limitation. The time needed to retrieve Sentinel User Level Data from the archive shall be specified according to user scenario’s.

Sentinel Data and associated reference data, algorithms, documentation and tools preserved without time limitation shall be accessible upon request and allow the regeneration of Sentinel User Level Data. The long-term archive of Copernicus should provide interfaces to/be integrated into a Europe-wide library of scientific and cultural heritage data that may provide complementary functionalities (e.g. EOSC). In the case of ancillary data, their curator would be the first actor of choice to support their long-term preservation. The strategy for long-term data preservation shall be aligned with best practices elaborated in Europe and documented. The strategy shall specify the timeliness, classified according to requested volumes, for retrieving Sentinel User Level data from the archive.

[REQ-]

Operations monitoring

Req. [23]

The ground segment shall ensure end-to-end monitoring and control of all ground segment operations.

The overall mission operation shall be monitored and controlled at any time in line with operational performance requirements using state of the art approaches. The end-to-end monitoring and control covers all ground segment elements, including satellite operations and control, payload data acquisition, data archiving and data access. The end-to-end monitoring function shall be able to identify the performance at each of the components and at the same time provide a comprehensive view of the performance of the entire ground segment. The end-to-end monitoring shall be able to identify the components underlying possible anomalies in the system to initiate remedial action.

[REQ-140] to [REQ-142]

Req. [24]

For each of the ground segment components availability and performance requirements shall be defined such that the Sentinel User Level Data Service can be guaranteed

The end-to-end availability shall be calculated covering all components relevant to data availability. It shall include unavailability’s due to satellite maintenance tasks, availability of payload data acquisition components, user level data production, archiving and data access interfaces. It shall however, exclude the unavailability’s of the satellite and payload due to in-orbit failures. Other requirements, such as latency and completeness shall be defined.

[REQ-62]

Req. [25]

The Sentinel User Level Data Services to users shall be monitored by means of Key Performance Indicators (KPIs).

The KPIs shall include the requirements documented in Sentinel User Level Data Service Specifications (i.e the end-to-end availability of the ground segment, latency, the availability of acquired and produced data as compared to planned acquisitions and production, timeliness) A reporting protocol shall be established and necessary tools operationalised to allow a high-level reporting including alerts to the Commission Programme Management.

[REQ-62]


9.8 Traceability to functional requirements for the Copernicus Distribution Services

The EC requirements to ESA Specification Traceability is established with the “Functional Requirements for the Copernicus Distribution Services and the Data and Information Access Services (DIAS)” Document, Final Version, 06 December 2016.

EC requirements are available under the format of tables and free text addressing the different functions or entities. Tables related to the EOF-CSC scope have been extracted and extended to allow for traceability indications and commenting. Free text similar to requirements have been extracted and is presented in a complementary table to ease future reference. It is noted that the DIAS is not part of the reference EOF-CSC scope and therefore corresponding requirements have not been extracted.

Table 2 Generic Requirements for the Copernicus Distribution Services

Copernicus Distribution Services High Level Requirements

Distribution service main functionalities

DIST- 1-01

The Copernicus distribution services shall give access to all Copernicus data and information. This includes all data and information listed in [RD2], [RD6] and in the Catalogues of the Copernicus Services (Marine, Atmosphere, Climate Change, Land, Emergency, security)

[REQ-320]

DIST- 1-02

All data and information shall be available to the users within the timeliness requirements as specified in [RD3], [RD6] and the Service Catalogues of the Copernicus Services

[REQ-320]

DIST- 1-03

The Copernicus distribution services shall have the following functionalities for all Copernicus data and information (i.e. including Long-Term Archives):

Discovery (Catalogue with Search functions);

View

Download

Restricted Access for specific user and data and information limited to specific cases;

User management and support utility.

[REQ-320] to [REQ-345]

Note#1: All user level data in the LTA can be access through the data distribution service.

Note#2: View is considered limited to user level data quick-look.

DIST- 1-04

Data and information shall be described in searchable metadata files

[REQ-331]

DIST- 1-05

The Copernicus distribution services catalogue shall, as a minimum, allow to search data or information based on the following criteria: area of interest, application field, type and date stamp

[REQ-331]

DIST- 1-06

Common ontologies shall be adopted and semantic search enabled.

Note#1: Limited semantic search is considered as part of the EOF-CSC operations.

DIST- 1-07

The Copernicus distribution services catalogue shall be user-friendly and search results shall be refined based on the user's behaviour

[REQ-3]

Note#1: User interfaces build on the experience gathered over the initial years of CSC operations.

DIST- 1-08

The Copernicus distribution services shall be documented, in particular its interfaces

[REQ-341]

Interoperability

DIST- 1-09

Services or functionalities covered by INSPIRE, including metadata content, shall be compliant with the legal obligations of the INSPIRE Directive and conformant with INSPIRE technical guidelines and good practices. If conformance with technical guidelines is shown to be incompatible with the quality of the services/functionalities required, the data or information providers and relevant stakeholders (including the INSPIRE community) shall come to an agreement of standards or implementation practices that can guarantee interoperability between the different services/platforms.

[REQ-331]

DIST- 1-10

Copernicus Data and Information compliance with INSPIRE metadata requirements will ensure their discoverability by European Open Data Portal

[REQ-331]

DIST- 1-11

The interfaces of the Copernicus distribution services shall be based on standards

[REQ-3], [REQ-331]

DIST- 1-12

The Copernicus distribution services catalogues shall be interoperable amongst each other and provide complete catalogue information to the DIAS.

[REQ-3]

Data identification, authentication and integrity

DIST- 1-13

It shall be possible to identify unequivocally, authenticate and check the integrity of Copernicus data and information distributed by the Copernicus Entrusted Entities via the Copernicus distribution services

[REQ-180], [REQ-181]

User management and registration

DIST- 1-14

User management and registration shall be coordinated across the Copernicus distribution services4

Note#1: Coordinated user management is not included in the present EOF-CSC baseline. It shall be assessed in coordination with all Copernicus entities

DIST- 1-15

No registration shall be required for the consultation of the catalogues and for viewing of data and metadata.

Note#1: Within the EOF-CSC baseline, this requirement is considered part of the lower-level service specifications defined for the industrial service procurement.

Distribution service connectivity5

Copernicus Distribution Services High Level Requirements

DIST- 1-16

The Sentinel data and service information distribution services shall connect to the GÉANT network as additional measure to increase connectivity and further serve the research community

[REQ-80]

Note#1: Connectivity to GÉANT will be pursued in line with [REQ-80]. Connectivity to GÉANT is not considered mandatory for the operations of all data distribution access points.

Distribution Services Reporting

DIST- 1-17

Regarding the Copernicus distribution services, each Entrusted Entity shall report to the European Commission on:

• Availability performance of the Distribution Functions

• Availability performance of the Distribution Services

[REQ-329], [REQ-330]

DIST- 1-18

The components of the distribution services shall report quarterly on the service usage providing meaningful statistics on the basis of information about users, user profiles, usage patterns, etc. The reports shall cover user queries through the helpdesk.

[REQ-329], [REQ-330], [REQ-5]

Note#1: In line with the GDPR, the extend of user related information in the reported statistics shall be consolidated with the

DIST- 1-19

The components of the distribution services shall report quarterly on service performance including data and information availability. The reports shall provide statistical information averaged over one month

Performance: availability, timeliness, anomalies

Distribution service information availability: volume, completeness, integrity, timeliness

Performance of helpdesk function

[REQ-329], [REQ-330]

Legal requirements

DIST- 1-20

The distribution service must comply with all the requirements of the Copernicus data and information policy [AD1 & AD2]

[REQ-320], [REQ-321], [REQ-322]

DIST- 1-21

All users shall have free, full and open access to the Copernicus data and information distributed by the Copernicus distribution services

[REQ-320], [REQ-321], [REQ-322]

DIST- 1-22

Access to Copernicus data and information shall be equal to all and non-discriminatory

[REQ-320], [REQ-321], [REQ-322]

4 Coordination should involve agreement amongst parties involved (i.e. Copernicus EE, Member States and other interested parties) on a minimum set of parameters to be required for registration and aim at a Single Sign On approach within the Copernicus IGS in the medium term.

5 The Copernicus distribution services are connected to the general use internet through the appropriate protocols

Table 3 Requirements for the Copernicus Distribution Services - Sentinel Data

Sentinel Data Distribution Services High Level Requirements

User Services

DIST-2- 01

The Sentinel data distribution service shall provide the following additional services:

Publication of observation plans for the Sentinels

Data processing service allowing to generate sub-sets of products according to user – specifications (query) of area of interest and format

Emergency service restricted to the Copernicus rapid mapping Emergency Service

[REQ-324], [REQ-215], [REQ-321]

QRT data access (raw data)

DIST-2- 02

Access functionalities to QRT data shall provide access to specific data and to well-identified users in support of critical applications (Applications needing Quasi Real Time data, e.g.: security applications). This type of access shall be available to a limited group of users to be authorised by the Commission.

Note#1: Capability to support S1 QRT observation needs exists.

Associated operations are not part of the EOF-CSC baseline.

Broadcast Service

DIST-2- 03

Some Sentinel data shall be available through broadcast service where supported by user requirements and technically feasible

[REQ-323]

Note#1: Data broadcast is not part of the default EOF-CSC operations but may be supported as required. See note attached to [REQ-323].

Availability of the services

DIST-2- 04

The Availability of each Sentinel data distribution function shall be > 99.5% per year (indicative) whereby planned maintenance shall not exceed 6 hours in any 30 day period and shall be announced at least 10 working days an advance.

[REQ-4]

DIST-2- 05

The Availability of each Sentinel data distribution service shall be > 99.5%6 per year (indicative) whereby planned maintenance shall not exceed 6 hours in any 30 day period and shall be announced at least 10 working days an advance.

[REQ-4]

Sentinel Data Distribution Services Performance – specific cases for particular user typologies

DIST-2- 06

The Sentinel data distribution service shall deliver data in line with the specified performances to the following user typologies:

• Copernicus Services

• Copernicus DIAS providers

[REQ-320]

DIST-2- 07

The Sentinel data distribution service shall deliver data targeting to meet the specified minimal performances to the following user typologies:

EU Member States and Copernicus Participating countries

International Partners

Science, industry and other users

[REQ-320]

Note#1: At this stage, no explicit requirement has been received defining different performance values per user categories.

DIST-2- 08

The Sentinel data distribution service shall, while respecting the generic timeliness requirements, ensure that data are available for user download not exceeding the following delays from the request:

For data not older than one year or data frequently requested: within seconds

For data older than one year: within one hour.

[REQ-320]

Note#1: The EOF-CSC baseline defines the timeliness from user request based on a configurable data ageing.

Note#2: Access performance is related to the system access capacity and sizing. The EOF-CSC baseline defines the timeliness associated to a sizing scenario.

6 Availability is measured from the time of ingestion of the raw data into the processing facility (time of reception at the receiving station for Earth Observation data) to data availability on the distribution service within the product timeliness requirements

Contents

Scroll to Top