GSC Sentinel-2 PDGS SRD - emits - ESA

Appendix B 

D O C U M E N T 

document title/ titre du document 

PACE 

OMPONENT 

ENTINEL AYLOAD ATA 

ROUND 

EGMENT 

YSTEM 

OCUMENT 

EQUIREMENTS 

prepared by/préparé par 

Sentinel-2 PDGS Project Team 

reference/réference 

GMES-GSEG-EOPG-RD-09-0028 

issue/édition 1 

revision/révision 

2 (draft) 

date of issue/date d’édition 25.07.2010 

status/état 

Draft 

Document type/type de document Requirements Document 

Distribution/distribution 

ESA UNCLASSIFIED – For Official Use 

© ESA 

The copyright of this document is the property of ESA. It is supplied in confidence and shall not be reproduced, copied or 

communicated to any third party without written permission from ESA.

GSC Sentinel-2 PDGS SRD 

issue 1 revision 2 (draft) - 25.07.2010 


page ii of ix 

A P P R O V A L 

Title 

Titre 

GMES Space Component - Sentinel-2 Payload Data issue 

Ground Segment (PDGS) - System Requirements 

issue 

Document (SRD) 

1 revision 

revision 

2 (draft) 

author 

Sentinel-2 PDGS Project Team 

date 

25.07.2010 

auteur 

date 

approved by 

O.Colin 

date 

approuvé par 

date 

authorised by 

E.Monjoux 

autauris’e par 

CHANGE LOG 

reason for change /raison du changement issue/issue revision/revision date/date 

Creation 1 0 21.12.2009 

Update post PDGS-SRR 1 1 25.06.2010 

Updated as per ngEO scenarios 

. 

1 2 (draft) 25.07.2010 








page v of ix 

T A B L E O F C O N T E N T S 

1 INTRODUCTION ................................................................................................10 

1.1 Purpose .......................................................................................................................10 

1.2 Background..................................................................................................................10 

2 DOCUMENTATION............................................................................................13 

2.1 Normative Reference Documents................................................................................13 

2.2 Informative Reference Documents ..............................................................................14 

2.3 Acronyms.....................................................................................................................17 

2.4 Terms and Abbreviations .............................................................................................23 

2.5 Document Overview.....................................................................................................26 

3 GMES SENTINEL-2 PDGS OVERVIEW............................................................27 

3.1 PDGS Context .............................................................................................................27 

3.2 Functional Decomposition............................................................................................29 

3.2.1 Data Management Functions................................................................................29 

3.2.2 System Control Functions.....................................................................................32 

3.2.3 Data Communication Functions............................................................................33 

4 ASSUMPTIONS & OPEN ISSUES.....................................................................35 

4.1 Assumptions ................................................................................................................35 

4.2 Open Issues.................................................................................................................37 

5 GMES SENTINEL-2 PGDS REQUIREMENTS ..................................................38 

5.1 PDGS System-Level Requirements.............................................................................38 

5.1.1 Functional Requirements......................................................................................38 

5.1.2 Performance Requirements..................................................................................49 

5.1.3 Sizing Requirements.............................................................................................50 

5.1.4 Operational Requirements....................................................................................51 

5.1.5 Interface Requirements ........................................................................................58 

5.1.6 RAMS Requirements ............................................................................................62 








page vi of ix 

5.1.7 Design & Development Requirements..................................................................63 

5.1.8 Security Requirements .........................................................................................66 

5.2 Data Reception (DRX) Requirements..........................................................................69 



5.2.3 Sizing Requirements.............................................................................................73 




5.3 Data Processing Control (DPC) Requirements............................................................77 






5.4 Instrument Data Processing (IDP) Requirements ........................................................87 






5.5 MSI Decompression Software (MDS) Requirements...................................................90 



5.6 On-Line Quality Control (OLQC) Requirements...........................................................91 






5.7 Archive & Inventory (AI) Requirements........................................................................95 









page vii of ix 

5.7.2 Performance Requirements................................................................................101 

5.7.3 Operational Requirements..................................................................................101 

5.7.4 RAMS Requirements ..........................................................................................103 

5.7.5 Design & Development Requirements................................................................104 

5.8 Long-Term Archive (LTA) Service Requirements ......................................................105 

5.8.1 Functional Requirements....................................................................................105 




5.9 Data Circulation (DC) Requirements..........................................................................107 






5.10 Precise Orbit Determination (POD) Requirements ....................................................112 






5.11 Auxiliary Data Supply (ADS) Requirements...............................................................116 






5.12 Data-Access Index (DAX) Requirements...................................................................117 












page viii of ix 


5.13 Data Access Gateway (DAG) Requirements .............................................................124 






5.14 Multi-Mission User Services (MMUS) Requirements .................................................131 



5.14.3 Sizing Requirements...........................................................................................140 




5.15 On-Line Images Browser (OLIB) Requirements ........................................................142 






5.16 Mission Configuration Control (MCC) Requirements .................................................144 






5.17 Mission Planning (MPL) Requirements......................................................................150 













page ix of ix 

5.18 Mission Performance Assessment (MPA) Requirements ..........................................164 






5.19 Reference Platform (RP) Requirements ....................................................................175 






5.20 Monitoring & Control (M&C) Requirements................................................................179 






5.21 Data Communication Requirements ..........................................................................182 





5.21.5 Network Security Requirements .........................................................................187 


APPENDIX-A PDGS REQUIREMENTS SEMANTIC AND FORMAT .....................................189 

APPENDIX-B PDGS TRACEABILITY REQUIREMENT MATRIX (TRM) ...............................192 






Issue 1 Revision 2 (draft) - 25.07.2010 


page 10 of 204 

1 INTRODUCTION 

1.1 Purpose 

The purpose of this document is to define the Sentinel-2 PDGS system requirements, which 

will be the driver for the PDGS design & implementation and will constitute the reference for 

the PDGS validation. 

The PDGS SRD constitutes the highest-level requirements document for the GMES 

Sentinel-2 PDGS, defining the parent system requirements for the specifications of the 

Sentinel-2 PDGS facilities and elements/components. PDGS centres specifications and 

operational scenarios are provided in the Sentinel-2 PDGS Operations Concept Document 

[ND-9]. 

1.2 Background 

The GMES (Global Monitoring for Environment and Security) programme is a European 

initiative for the implementation of information services dealing with environment and 

security. It is based on observation data received from Earth Observation satellites and 

ground based information. 

Within the GMES programme, the GMES Service Segment (GSS) composed over several 

GMES Service Projects (GSPs) is in charge of providing value-added data and services to 

the GMES final users, while the GMES Space Component (GSC) is responsible for 

providing to the GMES Service Segment the necessary Earth-Observation (EO) data and 

services. 

As part of the GMES Space Component Programme, ESA is responsible for developing a 

fully operational space-based capability to feed the GSS with satellite data. This capability 

will be achieved with the implementation of GMES dedicated Earth Observation Missions, 

the Sentinels missions, under development by ESA. The Sentinel-2 mission is one of this 

series of GMES EO missions, scheduled for launch by 2013. 

Access to EO data and services by the GSS shall however be ensured already before the 

Sentinel era. This is being achieved by relying on a set of EO missions capable of satisfying 

the data requirements from the GSS. These missions contributing to the GSC are 

generically referred to as GSC (or GMES) Contributing Missions (GCMs). 

The GSC Coordinated Data Access System (CDS) is the pre-operational infrastructure 

being developed by ESA for providing access to GSC data and services to the GSS before 

the GMES Sentinels are launched. Although the CDS is initially implemented for the GMES 

pre-operations phase, it is however designed to support the successive operational phase 

with the Sentinels. The Sentinels PDGS shall therefore be conceived as being part of the 

GSCDA as a fully integrated GMES mission. 

The GSCDA data and services are accessible through a portfolio of Data Sets (DSs). These 

DSs are derived from the GMES Services requirements captured in the DAP/R [RD-5], 









which after trade-off with the system available capacity are propagated in the GSC DAP, 

where GMES Services updated requirements and evolving space systems capacity are 

taken into account. The DAP Data Sets are pre-defined collections of coherent multimission 

products responding to specific different users needs and therefore with different 

characteristics. 

The CDS interfaces with the GMES Service Component for gathering data requests and 

providing coordinated data access and services, and with the Ground Segments of the 

GCM’s and the Sentinel missions for coordinating the data provision from the GCM’s in 

response to the requests. 

Figure 1-1 sketches the GSC Data Access System context, the role of the Coordinated 

Data Access System (CDS) and its interface with the GMES Service Segment (for gathering 

data requests and providing coordinated data access and services), and with the Ground 

Segment of the GCM’s and the Sentinel missions (for coordinating the data provision in 

response to the requests). The GSCDA data and services provision from the GMES 

Contributing Missions (GCMs) is regulated through specific agreements with ESA through 

the DAP Management function. Being dedicated GMES missions, the latter interface is not 

strictly necessary for the Sentinel missions. 

Long-term EO Data Requirements 

Agreements 

DAP 

Management 

GMES 

Service 

GMES 

GMES Projects 

Service 

Services 

Projects 

• Registrations 

• Data Requests 

• Subscription 

Registrations 

GSC Data Sets 

GSC Products 


• Subscription 

Requests 

Coordinated 

Data Access 

System (CDS) 

•Products 

•Reports 


• Subscription Requests 

•GCM Products 

•Reports 

GSC 


Contributing GSC 

Contributing 

Missions Contributing 

Missions 

Missions 



Sentinel 

Sentinel 

Missions GSC Sentinel 

Missions 

Missions 

GCM & Sentinel Products 

GSC Data Access 

Figure 1-1 GMES Space Component Data Access System Overview 









The Sentinel missions, as dedicated GSC missions, will be integrated with the CDS to 

contribute to the overall data provision to the GSC. The Sentinel missions will interface with 

the CDS through the Sentinel Ground Segment (GS) and particularly though the Payload 

Data Ground Segment (PDGS), as illustrated in Figure 1-2. 

Being part of the GSCDA, the Sentinel-2 PDGS shall conform to the standard GSCDA 

interfaces both towards the GMES Services and towards the GMES coordinated functions 

as detailed in [ND-22] and they shall comply as well with the GSCDA operational scenarios 

as detailed in [ND-4]. 

Figure 1-2 Sentinel-2 Mission Context 

Figure 1-2 also illustrates the Sentinels PDGSs as components of the overall Ground- 

Segment (GS) including the Flight-Operation-Segment (FOS) interfacing the PDGS on one 

side and the spacecrafts on the other for commanding and control. 









2 DOCUMENTATION 

2.1 Normative Reference Documents 

[ND-1] GMES Sentinel-2 Mission Requirements Document - 

EOP-SM/1163/MR-dr [MRD] 

[ND-2] GMES Sentinel-2 Ground Segment Requirements 

Document [GSRD] - S2.RS.ESA.SY.0094 

[ND-3] GSC Data Access Portfolio Requirements Document 

[DAP-R], GMES-PMAN-EOPGRD-08-0002, 

[ND-4] GSC Data Access System Operational Scenarios for 

GMES Contributing Missions - GMES-GSEG-EOPG-TN- 

08-0005 

[ND-5] Sentinel-2 Spacecraft Operations Concept Document 

[SOCD] - GS2.TN. ASD.SY.00010 

[ND-6] Satellite to Ground Segment Interface Control Document 

[S2GICD], GS2.ICD.ASD.SY.00006 

[ND-7] GMES Sentinel-2 PDGS Master Interface Control 

Document [MICD], GMES-GSEG-EOPG-IC-09-0032, 

[ND-8] ESA Earth Observation PDGS Requirements Document 

[EO-PDGS], PGSI-GSOP-EOPG-RD-09-0005, I 

[ND-9] GMES Sentinel 2 PDGS Operations Concept Document 

[OCD], GMES-GSEG-EOPG-TN-09-0008 

[ND-10] Sentinel-2 PDGS System Technical Budget Document 

[STBD], GMES-GSEG-EOPG-TN-09-0031 

[ND-11] Sentinel-2 PDGS Products Definition Document [PDD], 

GMES-GSEG-EOPG-TN-09-0029 

[ND-12] ECSS-E-ST-70C, Space Engineering Ground Systems 

and Operations 

Is. 2 

Rev. 1 

Is.1 

Rev. 1 

08/03/2010 

08/12/2009 

Is. 1.1 2009 

Is.1 

Rev. 1 

10/09/2008 

Is. 3 30/10/2009 

Is. 4 10/11/2009 

1.2 

(draft) 

1.1 

1.2 

(draft) 

1.2 

(draft) 

1.2 

(draft) 

25/07/2010 

25/07/2010 

25/07/2010 

25/07/2010 

[ND-13] ECSS-E-ST-40C - Space Engineering Software 

[ND-14] ECSS-E-ST-10-02C - Space Engineering Verification 

[ND-15] ECSS-Q-ST-80C, Space Product Assurance – Software 

Product Assurance 

[ND-16] ECSS-P-001B, ECSS Glossary Of Terms 









[ND-17] INSPIRE Directive 2007/03/14, 

http://inspire.jrc.ec.europa.eu/ 

[ND-18] INSPIRE Metadata Regulation 04/12/2008 

[ND-19] EC DECISION regarding INSPIRE monitoring and 

reporting 

[ND-20] GMES Fast Track Land Monitoring Core Service 

Strategic Implementation Plan 

[ND-21] GMES Fast Track Emergency Response Core Service 

Strategic Implementation Plan 

[ND-22] GSC Data Access Operational Interface Requirements 

for GCMs – GMES-GSEG-EOPG-RD-08-0003 

2.2 Informative Reference Documents 

Final 

Version 

Final 

Version 

Is.1 

Rev. 3 

05/06/2009 

24/04/2007 

24/04/2007 

06/04/2009 

[RD-1] GMES Sentinel-2 System Requirements Document - S2- 

RS-ESA-SY-0001 

[RD-2] Joint Principles for a GMES Sentinel Data Policy, 

ESA/PB-EO(2009)98 

[RD-3] GMES Sentinel-2 PDGS System Test Concept 

Document [STCD], GMES-GSEG-EOPG-TN-09-0030 

[RD-4] Sentinel-2 MSI – Level 2A Auxiliary Data Definition, 

S2PAD-VEGA-AUX-0001 

[RD-5] Data Access Portfolio Requirement Document (DAP/R) – 

GMES-PMAN-EOPG-RD-08-0002 

[RD-6] ICD SCI Coverage Reports - OSME-GSCDA-SEDA-ISS- 

09-0039 ?? GCM Coverage Report ICD (IF-GCM-SCI- 

06 2.0 24/04/09) 

[RD-7] GML 3.1.1 Application schema for Earth Observation 

products. Ref. OGC 06-080 

[RD-8] EO Products Extension Package for ebRIM (ISO/TS 

15000-3) Profile of CSW 2.0. OGC 06-131 

[RD-9] Ordering Services for Earth Observation Products, OGC 

06-141 

[RD-10] European Long-Term Data Preservation Common 

Guidelines, 

GSCB-LTDP-EOPG-GD-09-0002 

http://earth.esa.int/gscb/ltdp/EuropeanLTDPCommonGui 

delines_DraftV2.pdf 

Is. 5 

Rev. 0 

15/10/2007 

Rev.1 23/10/2009 

1.2 

(draft) 

Issue 

2.2 

Is. 1 

Rev. 1 

25/07/2010 

19/04/2010 

15/03/2009 

Draft V2 04/06/2009 





[RD-11] GMES Sentinel-2 Phases B2, C/D, E1 – Mission 

Analysis Report, GS2-RP-GMV-SY-00006 

[RD-12] EOP-G Ground segment security policy 

[RD-13] ESA Security directives (chapter 5.7, annex 2) 

[RD-14] EO Network security implementation policy 

[RD-15] Regulation EC No 45/2001 

[RD-16] EU Directive [COM(2005)_438 final)] on data retention 

[RD-17] European Data Relay Satellite System – Appendix-2 The 

ESA Data Relay Satellite Service Requirements, D- 

TIA/2008-12152/CE App2 





Issue 

2.1 

Issue 1 

rev 1 

04/02/2009 

09/10/2008 

[RD-18] Sentinel-2 Design Description, GS2.RP.ASD.SY.00024 Issue 2 11/11/2009 

[RD-19] Sentinel-2 NUC Table Uplink Scenario, 

GS2.TN.ASD.SY.00046 

[RD-20] GMES Sentinels Payload Data Downlink Simulation in X- 

Band, PE-TN-ESA-GS-0264 

[RD-21] Sentinel-2 PDGS Distributed Level-1 Data Processing 

Study, GMES-GSEG-EOPG-TN-09-0037 

[RD-22] Sentinel-2 Ground Prototype Processor - Processing 

Specification for Level 1A, 1B and 1C Production, GS2- 

ST-GSGP-40-CNES 

[RD-23] Sentinel-2 MSI - Level-2A Products Definition, S2PAD- 

VEGA-PD-0001 

[RD-24] Sentinel-2 MSI – Level 2A Ancillary and Auxiliary Data 

Definition, S2PAD-VEGA-AUX-0001 

[RD-25] Sentinel-2 MSI – Level 2A Products Algorithm 

Theoretical Basis Document - Volume A (SMAC), 

S2PAD-VEGA-ATBD-0001 

[RD-26] Sentinel-2 MSI – Level 2A Products Algorithm 

Theoretical Basis Document - Volume B (ATCOR), 

S2PAD-DLR-ATBD-0002 

[RD-27] QA4EO, “A quality assurance framework for Earth 

Observation, key guidelines”, approved by CEOS, 

http://qa4eo.org/documentation.html 

[RD-28] Standard Archive Format for Europe (SAFE), 

http://earth.esa.int/SAFE/ 

[RD-29] Network and ICT Security Requirements for the EO 

PDGS, MGT-SENE-EOPG-RS-09-0002 

Issue 1 08/05/2009 

Issue 

1.1 

Issue 

1.0 

Issue 

1.0 

Issue 

2.1 

Issue 

2.0 

Issue 

2.0 

Issue 

1.3 

19/07/2009 

21/12/2009 

10/06/2009 

06/11/2009 

06/11/2009 

09/11/2009 

06/11/2009 

Is. 1.0 28/07/2009 









[RD-30] Sentinel-2 MMFU Design Adaptations – S2-CR-ESA-SY- 

0009 

[RD-31] EDRS: The Sentinel Requirements Data Relay Services 

- GM-RS-ESA-SY-27 

[RD-32] EDRS: The Sentinel Requirements Extended Services 

Data Repatriation & Dissemination - GM-RS-ESA-SY-31 

[RD-33] EDRS: The Sentinels/EDRS Operations Constraints and 

Concept - GM-RS-ESA-SY-28 

[RD-34] Next Generation User Services for Earth Observation 

(ngEO) System Description & Operational Scenario 

[NGEO-OS] – GMES-GSEG-EOPG-TN-10-0005 

Issue 

1.0 

Issue 

1.0 

Issue 

1.0 

Issue 

1.0 

09/03/2010 

09/03/2010 

09/03/2010 

09/03/2010 

Draft 18/06/2010 









2.3 Acronyms 

AI 

ADP 

ADS 

AOCS 

AOD 

AOS 

ATCOR 

BOA 

CADU 

CCSDS 

CDAM 

CDS 

CDN 

CEOS 

CGS 

CNES 

CSM 

CSS 

CST 

CUC 

DA 

DAG 

DAIL 

DAP 

DAX 

DC 

DCN 

DDN 

DEM 

DFEP 

Archive and Inventory 

Auxiliary Data Providers 

Auxiliary Data Supply 

Attitude and Orbit Control System 

Aerosol Optical Depth 

Acquisition-Of-Signal 

Atmospheric Correction and Haze Reduction 

Bottom-Of-Atmosphere 

Channel Access Data Unit 

Consultative Committee for Space Data Systems 

Collaborative Data-Access Mirror 

GSC Coordinated Data Access System 

Content Delivery Network 

Committee on Earth Observation Satellites 

Core Ground Station 

Centre National d’Études Spatiales 

Calibration and Shutter Mechanism 

Collaboration Support Service 

Centre Spatial de Toulouse 

CCSDS Unsegmented Time Code 

Data Access 

Data-Access Gateway 

Data Access & Integration Layer 

Data Access Portfolio 

Data-Access Index 

Data Circulation 

Digital Circulation Network 

Data Dissemination Network 

Digital Elevation Model 

Demodulator & Front-End Processor 









DPC 

DPM 

DRX 

DS 

DTED 

DUE 

EDRS 

EEPROM 

ERCS 

ESA 

ESOC 

EO 

FCN 

FEE 

FEEM 

FES 

FIFO 

FOS 

FPA 

FPGA 

FTP 

FTS 

GCM 

GCP 

GEO 

GIPP 

GMES 

GMFS 

GPP 

GPS 

GRI 

GS 


GSCB 

Data Processing Control 

Data Processing Model 

Data-Reception 

Data Set 

Digital Terrain Elevation Data 

Data User Element 

European Data Relay Satellite 

Electrically Erasable and Programmable ROM 

Emergency Response Core Service 

European Space Agency 

European Space Operations Centre 

Earth Observation 

FOS Communication Network 

Front End Electronic 

Front End Electronic Module 

Front-End Services 

First-In First-Out 

Flight Operations Segment 

Focal Plane Assembly 

Field Programmable Gate Array 

File Transfer Protocol 

Fast Track Services 

GMES Contributing Mission 

Ground Control Point 

Geostationary 

Ground Image Processing Parameters 

Global Monitoring for Environment and Security 

Global Monitoring for Food Security 

Ground Prototype Processor 

Global Positioning System 

Global Reference Image 

Ground Segment 

GMES Space Component 

Ground-Segment Coordination Body 









GSCDA 

GSE 

GSP 

GSRD 

GSS 

GUI 

HKTM 

HLOP 

HMA 

HMI 

HPDI 

HR 

HW 

IAS 

ICCDB 

ICD 

ICM 

IDP 

INSPIRE 

IPF 

IPS 

IQP 

ISO 

ISP 

JPIP 

JRC 

LAN 

OCP 

LEO 

LEOP 

LES 

LGS 

LMCS 

GMES Space Component Data Access 

GMES Service Element (ESA projects) 

GMES Service Project 

Ground-Segment Requirements Document 

GMES Service Segment 

Graphic User Interface 

House Keeping Telemetry 

High-Level Operation Plan 

Heterogeneous Mission Accessibility 

Human-Machine Interface 

Heavy Product Data Item 

High Resolution 

Hardware 

Image Algorithm Software 

Instrument Calibration & Characterisation Database 

Interface Control Document 

Instrument Control Module 

Instrument Data Processing 

Infrastructure for Spatial Information in Europe 

Instrument Processing Facility 

Image processing Parameters Set 

Image Quality Processor 

International Organization for Standardization 

Instrument Source Packet 

JPEG Interactive Protocol 

Joint Research Centre 

Local Area Network 

Optical Communication Payload (formerly called Laser 

Communication Terminal, LCT) 

Low Earth Orbit 

Launch and Early Operations Phase 

Land Equipped Sites 

Local Ground-Stations 

Land Monitoring Core Service 





LPDI 

LTA 

LTDP 

LUT 

Lightweight Product Data Item 

Long-Term Archive 

Long-Term Data Preservation 

Look-Up-Table 

M&C Monitoring & Control 

MCC Mission Configuration and Control 

MCS Mission Control Service 

MCS Marine Core Service 

MCN Media Circulation Network 

MDP MSI Decompression Software Provider 

MDS MSI Decompression Software 

MMA Mission Management Authority 

MMFU Mass Memory Formatting Unit 

MMUS Multi-Mission User-Services 

MODTRAN MODerate resolution atmospheric TRANsmission 

MPA Mission Performance Assessment 

MPAC Mission Performance Assessment Centre 

MPL Mission Planning 

MRD Mission Requirements Document 

MSI Multi-Spectral Instrument 

MSIC MSI Control application (part of the Central Control Software) 

MSS Mission Scheduling System 

MT Medium Term 

MTF Modulation Transfer Function 

MTL Mission TimeLine 

NOAA National Oceanic and Atmospheric Administration 

NRT Near-Real-Time 

NUC Non-Uniformity Coefficients 

OBC On-Board Computer 

OBCD On-Board Configuration Data 

OCP Optical Communication Payload 

OGCD On-Ground Configuration Data 

OLIB On-line Image Browser 

OLQC On-Line Quality-Control 













OPS 

OSV 

PDGS 

PDHT 

PDI 

PDMC 

PDT 

POD 

POF 

POM 

PPS 

PSK 

PUS 

QC 

QI 

QL 

QR 

RAM 

ROM 

RP 

RT 

S2CP 

SAFE 

SCI 

SEC 

SECOPS 

S-FEE 

SFTP 

SMAC 

SNR 

SPOT 

SPR 

SOCD 

SRTM 

Orbit Position Schedule 

Overall System Validation 

Payload Data Ground Segment 

Payload Data Handling Transmission system 

Product Data Item 

Payload Data Management Centre 

Payload Data Transmission 

Precise Orbit Determination 

Predicted Orbit File 

PDGS Operation Manager 

Pulse Per Second 

Phase Shift Key 

Packet Utilisation Standard 

Quality-Control 

Quality Indicator 

Quick-Look 

Qualification Review 

Random Access Memory 

Read Only Memory 

Reference-Platform 

Real-Time 

Sentinel-2 Commissioning-Plan 

Standard Archive Format for Europe 

Service Coordinated Interface (GSCDA) 

Security Pilot Service 

Security Operating Procedures 

SWIR FEE 

Secure File Transfer Protocol 

Simplified Method for Atmospheric Corrections 

Signal-to-Noise Ratio 

Satellite Pour l’Observation de la Terre 

Software Problem Report 

Spacecraft Operations Concept Document 

Shuttle Radar Topographic Mission 









SSCF 

SW 

SWIR 

TBC 

TBD 

TCI 

TCM 

TCS 

TDI 

TF 

TLE 

TMA 

TMTC 

TOA 

TTO 

TWTA 

URL 

USGS 

UTM 

VCDU 

VCM 

VCN 

VCU 

VOIP 

WAN 

WICOM 

VNIR 

VPM 

WGS 

WICOM 

XBS 

Spacecraft Safety Constraint File 

Software 

Short-Wave Infrared 

To Be Confirmed 

To Be Defined 

True Colour Image 

Thermal Control Module 

Thermal Control Subsystem 

Time Delay and Integration 

Transfer-Frame (CCSDS) 

Two Line Elements 

Tree-Mirror-Anastigmat 

Telemetry and Tele-command 

Top-Of-Atmosphere 

Transfer to Operation 

Travelling Wave Tube Amplifiers 

Universal Resource Locator 

United States Geological Survey 

Universal Transverse Mercator 

Virtual Channel Data Unit 

Video Compression Module 

Voice Communication Network 

Video and Compression Unit 

Voice-Over-IP 

Wide Area Network 

Wavelet Compression Module 

Visible and Near Infrared 

Video Processing Module 

World Geodetic System 

Wavelet Image COmpression Modules 

X-Band Subsystem 









2.4 Terms and Abbreviations 

Downtime 

Scheduled 

Downtime/ 

Planned outage 

Incident 

Problem 

Resolution Time 

Scheduled 

Maintenance 

Notification Time 

Availability 

Period of time when a service is not operational or there is a packet 

loss higher than 40%. 

The Scheduled Downtime is the time required to perform necessary 

evolution and maintenance activities (e.g. upgrade on the network 

equipments to achieve a higher band-width). 

Any event which is not part of the standard operation of a service 

and which causes or may cause an interruption to or a reduced 

quality of that service. 

Service Time elapsed between a problem occurrence and the 

solving of a problem, excluding the stop-clock periods. 

The elapsed time between the time of the e-mail notification to users 

and the start of the maintenance. 

It is the availability of the service during the Service Coverage hours 

Monthly Service Time - Monthly Service Downtime 

Monthly Service Time 

IP-VPN service availability is measured between two ESA Sites 

Internet Service availability is measured between an ESA Site and 

the Providers Internet gateway that is directly connected to the 

Internet. 

Several Availability requirements (RAMS) are defined by a 

percentage ”computed over a one month time window and 

assuming a degradation of such figure for no more than one day.” 

This refers to the availability observed in average during a 30-days 

sliding time window. Within the 30-days period, a degradation of the 

availability value shall never exceed 24 hours of duration (i.e. the 

period during which the availability figure is below the monthly 

average required). 









Maintainability 

Service Downtime 

Stop-clock Periods 

MTTR 

Round Trip Delay 

Outage Lead Time 

Mission Lifetime 

PDGS Operational 

Lifetime 

The ease with which a product can be maintained in order to: 

correct defects (corrective maintenance) 

cope with a changed environment (adaptive maintenance) 

meet new requirements (perfective/improving maintenance) 

make future maintenance easier (preventive maintenance) 

Service Downtime = Downtime - Stop-clock Periods 

Stop-clock Periods are scheduled downtimes and downtimes that 

are beyond the direct control of the Operational Support, as the 

resolution of incidents in the service scope of the Internet Network 

Providers. 

Maximum Time To Repair. The MTTR starts when an outage occurs 

and is to be concluded when the service is restored. 

Round trip delay, also called propagation delay. Round trip delay is 

the amount of time it takes for a packet for being (de-) 

encapsulated, routed/switched and transmitted to the other end and 

back; i.e. it is propagation delay + transmission delay + processing 

delay. This is measured from the outside interface of the 

Contractor’s WAN border device on one site to the outside interface 

of the Contractor’s WAN border device on the other site. 

An outage is an incident during which the warranted service is not 

provided. Lead-time is the time allowed to the service operator to 

recover from the outage condition. After this lead-time, the outage is 

taken into account in the credit scheme calculations. 

The Sentinel-2 mission lifetime covers a minimum of 13.5 years with 

active space-segment operations. 

The PDGS operational lifetime covers the Mission Lifetime plus 25 

additional years to support Long Term Data Preservation (LTDP) 

activities. LTDP activities are the ones related to the maintenance 

and the exploitation of the Sentinel-2 data archives including data 

preservation, processing, cataloguing, data access, etc activities 

performed during and sustained beyond the satellite operational 

periods. 









Data-Rate units 

Megabit per second (Mbps) 

1 Mbps = 10 6 bits per second = 1.25 10 5 bytes per second 

Mebibit per second (Mib/s) 

1 Mib/s = 2 20 bits per second = 2 17 bytes per second 

Data-Volume units 

Gigabit (Gbit or Gb): 1 Gbit = 2 30 bits 

Gigabyte (GByte or GB): 1 GByte = 2 30 Bytes = 2 33 bits 

Terabyte (TByte or TB): 1 TByte = 2 40 Bytes = 2 43 bits 









2.5 Document Overview 

The present document is divided into the following chapters: 

Chapter-1: Introduction, provides document purpose and background information; 

Chapter-2: Documentation provides the list of applicable and reference documentation as 

well as definition of acronyms and terms; 

Chapter-3: GMES Sentinel-2 PDGS Overview, provides an overview of the GMES 

Sentinel-2 PDGS, its role and objectives within the Sentinel-2 Ground Segment: a 

summary of the main PDGS interactions with external entities. 

Chapter-4: Assumptions and Open Issues, provides the list of assumptions and open 

issues at PDGS system level that lead to the definition of the PDGS requirements. 

Chapter-5: GMES Sentinel-2 PDGS Requirements, provides the exhaustive list of PDGS 

system requirements as derived from the applicable documents. 

Appendix-A: Requirements Semantic and Format, describes the conventions applicable 

to the requirements identification, classification and wording. 

Appendix-B: Traceability Requirement Matrix (TRM), outlines the main sources of 

requirements leading to the definition of the PDGS requirements and lists the traceability 

records. 









3 GMES SENTINEL-2 PDGS OVERVIEW 

3.1 PDGS Context 

The Sentinel-2 Ground-Segment (GS) is composed of the FOS and the PDGS. During 

Phase-E1 of each satellite unit, the CNES centre in Toulouse (CNES/CST) will also be 

considered an integral part of the Sentinel-2 GS as providing dedicated services onground 

for commissioning the spacecrafts until the start of Phase-E2 operations. 

The FOS is responsible for all flight operations of the Sentinel-2 spacecrafts including 

satellite tasking, telecommanding and telemetry monitoring, flight dynamics monitoring 

and orbit control. It will be operated at ESA’s European Space Operations Centre (ESOC) 

in Darmstadt in Germany during the entire Sentinel-2 mission. 

The PDGS is responsible for payload and downlink planning, data acquisition and 

processing of the Sentinel-2 satellite data, while contributing to the overall monitoring of 

the payload and platform in coordination with the FOS. The PDGS is a distributed groundsystem 

including ground-stations, processing centres and embedding all additional thirdparty 

centres falling in the scope of its responsibilities for Sentinel-2 (e.g. auxiliary data 

providers). 

The GSCDA system is not considered part of the Sentinel-2 mission GS as providing 

multi-mission services within the GSC and as such is not strictly dedicated to Sentinel-2. 

To meet its objectives the Sentinel-2 PDGS interfaces with: 

○ The Sentinel-2 PDGS Operation Manager (POM) having the responsibility of the 

overall performance, operations, and configuration of the PDGS; 

○ The Sentinel-2 Users for access to and exploitation of the PDGS product archives. 

The GMES Service Projects (GSPs) are a specific class of Sentinel-2 users. 

○ Local Ground Stations (LGS) authorised through the HLOP for the Real-Time 

reception of Sentinel-2 payload data through the X-Band direct downlink interface. 

○ The Coordinated Data Access System (CDS) as the common GSC service 

interface providing coordinated data-access and reporting versus GSPs. 

○ The Sentinel-2 Flight Operations Segment (FOS) at ESA/ESOC as a working 

interface with the PDGS for mission planning as well as stakeholder for the 

operational exploitation of HKTM products generated by the PDGS. 

○ The European Data Relay System (EDRS) for the coordination of space-to-ground 

data-relay activities and ground-to-ground data broadcast interfaces to support the 

PDGS internal data circulation or external dissemination to Users. 

○ The Centre National d'Études Spatiales centre in Toulouse (CNES/CST) as a 

working interface with the PDGS during the commissioning phase of the Sentinel-2 

spacecrafts. 

○ Collaborative entities having agreed specific partnerships with the POM. In the 

frame of this document, the Collaborative entities are either third-party operated 





GSPs 





collaborative mirror centres (CDAM), or Users themselves interacting with the 

PDGS under the hosted-processing collaboration framework. 

In addition, although formally considered within the PDGS functional perimeter, the 

following interfaces to external entities that provide PDGS functional services have been 

identified: 

○ Third-party Auxiliary Data Providers (ADP) for the operational provision of Auxiliary 

Data Files to be used by the PDGS for the data-processing activities. 

○ The selected distributing entity for the Sentinel-2 MSI WICOM image 

decompression software referred as MSI Decompression Provider (MDP). 

○ Expert Cal/Val Teams supporting specific CAL/VAL functions, quality control 

activities, etc. (e.g. Off-line POD service, MSI Cal/Val specific campaigns, etc.). 

S2A/B 

EDRS 

TM/TC 

LCT 

X-Band 

signal 

Ka-Band relay 

signal 

FOS 

LGS 

EDRS Exploitation 

Segment 

PDGS Operation 

Manager (POM) 

Collaborative PDGS Entities 

Auxiliary Data 

Providers 

WICOM 

Decomp.S/W 

Expert CAL/VAL Teams 

CDS Users 

Figure 3-1 PDGS Interfaces 

CST 

The PDGS Master ICD [MICD] further identifies and details every interface and describes 

their operation context within the PDGS physical layout. 









3.2 Functional Decomposition 

The first-level of the PDGS functional decomposition discriminates between Data 

Management functions, System Control functions and Data-Communication functions. 

Whilst the first group refers to the primary core duty of the PDGS of translating the satellite 

acquired data into data-access services to the Sentinel-2 product users, the second 

regroups all functions required at system-level to control, manage and coordinate the 

overall system behaviour. Some specific functions although relevant to both groups have 

been allocated to a specific one, with the logic that they mostly apply to the specificities of 

the allocated group by their primary functionality and main drivers. 

The last group includes all physical data communication functions between or within Data- 

Management or System-Control functions. 

3.2.1 DATA MANAGEMENT FUNCTIONS 

As primary goal, the Data-Management Functions aim at reliably and systematically 

transporting the Sentinel-2 constellation data from the antenna down to its authorised 

users into elaborated user-products of controlled quality, timeliness and access 

performances. Following this logic the following primary functions are identified as 

illustrated on Figure 3-2. 

○ A Data-Reception (DRX) function responsible for data acquisition from the 

spacecrafts and front-end data-handling activities. This function aims for a 

maximum reuse of existing ground-infrastructure X-Band tracking antennas (or 

EDRS compatible Ka-Band still antennas) and a sentinel-generic Demodulator and 

Front-End Processing (DFEP) equipment; 

○ A Data Processing Control (DPC) function responsible for managing all data 

processing activities, in charge of the systematic processing of Level-0 products 

and higher-level production management through dedicated data-processors. It is 

also in charge of supervising on-line quality control activities on the performed 

production and for hosting user-provided processors fruit of third-party hostedprocessing 

collaborations. 

The DPC function aims for a rule-based data-driven management of the real-time 

dataflow, whilst offering additional on-demand processing capabilities as required 

for Data-Access. It is intended as providing most of the required parallel processing 

management and be highly scalable with computing hardware in this respect. 









Figure 3-2 PDGS Data-Management Functions 

○ An Instrument Data Processing (IDP) function responsible for implementing in 

coordination with the DPC function the data-processing algorithms of the MSI to 

generate the core Level-1 and Level-2 data-products. 

In addition, the user-provided processors resulting from hosted-processing 

collaborations will be integrated as independent IDP functions. 

○ A Sentinel-2 mission-specific MSI Decompression Software (MDS) function to be 

used by the IDP function, and more generally by any third-party entity such as the 

LGS, for handling the MSI on-board compressed data. This function aims for a 

maximum reuse of an existing component developed for the Pleiades mission and 

for its long-term maintenance (>40 years) to meet Sentinel-2 LTDP objectives. 

○ An On-Line Quality-Control (OLQC) function triggered through the DPC host 

function and responsible for systematically performing essential verification and 










stamping of the quality of all products generated before they are made available to 

their intended users; 

○ A central Archive and Inventory (AI) function closely coupling data sources and 

data sinks, in charge of storing, registering and serving the product data and 

associated inventory records to other functions; 

○ A complementary Long-Term Archive Service function (LTA) responsible for longterm 

archiving and preservation as well as bulk reprocessing of Sentinel-2 

products. It aims for an optimum reuse of existing ground-infrastructure in the LTDP 

area in synergy with other Earth-Observation missions. As such and whilst being 

procured as an external service implementing well-defined Sentinel-2 PDGS 

interfaces, it is intended to be federated within the overall PDGS through collocated 

Sentinel-2 PDGS specific functions. 

○ A Data Circulation (DC) function responsible for all product exchanges between the 

distributed PDGS archives and more generally centralising the data exchanges 

between interfaces whether internal (between co-localised sub-systems in a PDGS 

centre) or external (e.g. versus FOS and auxiliary data providers, between centres, 

etc); 

○ A Precise Orbit Determination (POD) responsible for providing precise orbital data 

for MSI data-processing via the DC and AI functions. This function aims for reuse of 

a generic multi-Sentinel POD element. For Sentinel-2, POD orbit products will be 

used as a contingency solution should the strict processing of the on-board GPS 

and AOCS data embedded in the IDP Level-1 algorithms not provide the level of 

accuracy required to meet the product geometrical quality requirements; 

○ An Auxiliary Data Supply (ADS) function in charge of generating all other auxiliary 

data required to the Level-2A MSI processing. This function is aims at being 

mapped directly to the external data-sources identified in [RD-4]. 

○ A Data-Access Index (DAX) function responsible for federating the product 

inventories spread throughout the PDGS and providing the front-end services with 

a consolidated virtual view of the archive. It is in charge of transparently 

maintaining the relationships between the product components and their physical 

remote location and serving them to the data-access elements when performing the 

actual download operations; 

○ A Data-Access Gateway (DAG) function acting as a single virtual access point to all 

PDGS data products and implementing the actual downloads. It is in charge of the 

transparent re-assembly at the user site of the final products from the granular 

product elements scattered throughout the archives; 

○ The Front-End Services (FES) responsible for answering to the end-user dataaccess 

activities include the following PDGS functions: 

o The Multi-Mission User Services (MMUS) function responsible for user 

interactions supporting catalogue queries and subsequent triggering product 

downloads based on the DAG function; 

o The On-Line Image Browser (OLIB) function responsible of the true-colour 

image (TCI) publishing service towards the general public. 








3.2.2 SYSTEM CONTROL FUNCTIONS 

As primary goal, the System Control functions aim at providing the necessary means to 

control, monitor, assess, and fine tune the PDGS towards its goals and to mature its 

evolutions. The functional breakdown regarding system-control functions is depicted on 

Figure 3-3. 

Figure 3-3: PDGS System Control Functions 

It features a main mission control loop compiling three complementary functions: 

○ A Mission Configuration and Control (MCC) function in charge of defining the 

operation scenario according to the HLOP and performing accurate control and 

coordination within the PDGS of all derived key mission configuration data and 

leverages on mission performance. It also aims at keeping a historical registry of 

mission configuration baselines associating all related operational monitoring data 

collected throughout the PDGS for performance assessment activities; 

○ A Mission Planning (MPL) function in charge of applying the mission operation 

scenario by performing recurrent planning of the payload and data downlink 

operations through the FOS and triggering accordingly the data-reception activities 

at the CGS and LGS. 










○ A Mission Performance Assessment (MPA) function in charge of measuring the 

actual PDGS performance and the mission overall quality with respect to the 

baseline, and retrofitting as relevant the necessary configuration changes to the 

MCC to meet the quality objectives. 

In addition, two complementary system-management support functions are identified: 

○ A Reference Platform (RP) function globally in charge of system-level configuration 

control, system validation and transfer to operation activities as required for 

maintenance and evolutions throughout the PDGS operational lifetime; 

○ A Monitoring and Control (M&C) function globally scattered and embedded across 

all functional domains and in charge of providing a central monitoring and control 

view in each PDGS centre over the centre processes and resources to support 

operational system-management activities; 

Finally, a Collaboration Support Service (CSS) function is provisioned for with the dual 

objective of providing technical support vis-à-vis the collaboration peers according to the 

needs of each type of collaboration, and liaising with the PDGS management for the 

definition of the collaborations and associated progress reporting during implementation. 

3.2.3 DATA COMMUNICATION FUNCTIONS 

As primary goal, the Communication functions aim at providing the necessary means to 

effectively transport data internally and externally to the PDGS. 

As such, they enclose all physical communication means ranging from digital 

communication networks to standard post mail or telephone services allowing the 

transportation of information between geographically remote entities. 

This group of functions is hence supporting all other functions requiring physical data 

exchanges across PDGS centres or towards external interfaces. The following primary 

functions are identified as illustrated on Figure 3-4: 

○ A Local Area Network (LAN) Function, responsible for all digital communications 

within every PDGS centre; 

○ A Digital Circulation Network (DCN) Function, responsible for all digital 

communications between PDGS centres and expandable to support 

communications towards collaborative entities if required. This function extends to 

the EDRS data-repatriation capability composed of TX and RX stations to 

respectively transmit and receive the data via the EDRS repatriation transponder in 

multicast; 

○ A Media Circulation Network (MCN) Function, responsible for all data 

communications via physical media between PDGS centres, and expandable to 

support communications towards collaborative entities if required. This function 

embeds the physical media transportation between remote sites, e.g. using post 

mail services; 

○ A FOS Communication Network (FCN) Function, responsible for all digital 

communications between the PDGS and the Sentinel-2 FOS located at ESA/ESOC 

in Darmstadt (Germany); 








○ A Data Dissemination Network (DDN) Function, responsible for all communications 

versus external PDGS data-product users. This function extends to the EDRS datadissemination 

capability composed of TX and RX stations to respectively transmit 

and receive the data via the EDRS dissemination transponder in broadcast; 

Figure 3-4: PDGS Data Communication Functions 

The wording Wide Area Network (WAN) globally refers to any geographically distributed 

TCP/IP based network such as Internet. 









4 ASSUMPTIONS & OPEN ISSUES 

4.1 Assumptions 

High-level assumptions taken and having an impact on the settled PDGS operation 

baseline are enumerated hereafter. 

[Assumption-01] The Sentinel-2B satellite will be identical to Sentinel-2A satellite. 

[Assumption-02] Seven (7) years of active mission operations plus a possible 5 years 

extension are considered for each Sentinel-2 satellite. 

[Assumption-03] Sentinel-2B will be launched 18-30 months after Sentinel-2A. 18 

months is the planned value (TBC) at Sentinel-2 GS PDR. 

[Assumption-04] 5.5 to 10.5 years of parallel Sentinel-2A and Sentinel-2B active mission 

operations (nominal or extended mission duration) plus 18 months 

Sentinel-2B active mission operations are envisaged. 

[Assumption-05] Twenty-Five (25) years of mission operations from archive are 

considered. 

[Assumption-06] The X/Ka-band ground stations network will be selected at a later 

stage. A minimum four X-band receiving PDGS Core Ground Stations 

baseline scenario is assumed in this document. This configuration is 

sufficient to downlink the Sentinel-2 data as per baseline scenario. The 

selection of more stations will substantially enhance the performance 

of the baseline scenario but is not strictly required for baseline 

operations. 

[Assumption-07] All data handled by the Sentinel-2 PDGS is assumed to be 

UNCLASSIFIED (according to [RD-13]). 

[Assumption-08] Sentinel-2 X-Band data will not be encrypted (according to the GSC 

Security Work Group Meeting #4, held on 30.01.2008, GM-MN-ESA- 

SY-0015) 

[Assumption-09] It will be possible to use the EDRS Programme capacity to support 

both the Sentinel-2 payload data downlink (data relay function), as well 

as PDGS data circulation and dissemination activities. 

[Assumption-10] EDRS capabilities and services will be preliminarily validated as part of 

EDRS commissioning activities which will be carried out by the EDRS 

program in coordination with the Sentinel programs. Those activities 

will make use an EDRS provided validation framework on ground that 

will not require specific PDGS hardware or pre-deployed facilities apart 

from a front-end reception equipment to perform compatibility testing of 

the data-relay multicast link. 

[Assumption-11] The OCP will, when activated in alternative or in parallel to the XBS, 

transparently carries the dual 280Mbps downlink channels via the GEO 

transponders, in turn relaying in real-time the data stream in Ka-Band 

to GEO pointing ground-stations. Specific receiving equipment, still 









procured via the EDRS program, will provide the adequate Ka-Band 

demodulation capabilities on ground and restore the dual 280Mbps 

data-streams in baseband ready for front-end processing. The dual 

280Mbps channels restored in baseband after the EDRS ground 

equipment will be clear of any encryption. 

[Assumption-12] The apportioned availability to Sentinel-2 for data-relay downlinks via 

the EDRS constellation will be pre-defined at static times phased along 

the Sentinel-2 orbit repeat cycle, following a preliminary agreement 

with the EDRS exploitation segment in coordination with Sentinel-1. 

[Assumption-13] The Sentinel-2 mission can use operationally the EDRS 230Mbps 

data-repatriation multicast link for a third of the total time. 

[Assumption-14] The operation constraints of the OCP will be later characterised by a 

well-defined operation duty-cycle and an overall limit to the overall 

number of operation switches sized for the OCP lifetime, similarly to 

the XBS. 

[Assumption-15] The MSI timeline received on-ground after downlink will be provided 

with a granularity of exactly one MSI on-board scene (corresponding to 

3.48 seconds of instrument operation and about 23km on ground 

along-track) as corresponding to the minimum indivisible packet size of 

the MSI. A playback-stop commanded while an MSI scene is being 

downlinked will effectively stop the playback and transmission only 

after the MSI scene has been entirely transmitted. 

[Assumption-16] The on-board recording of the ancillary data does not require specific 

scheduling at PDGS mission-planning level as being either entirely 

autonomous on-board or systematically triggered and maintained 

through FOS flight operation procedures. The ancillary data is 

recorded continuously including when the MSI is not operating, or 

when it is operating in standby or idle modes. 

[Assumption-17] The XBS can remain in operation mode without the necessity of a 

temporary transition to standby even when the MMFU is not feeding 

data to the XBS e.g. during the time separating two successive datadownlinks 

to ground-stations. In this case, it is assumed idle transfer 

frames are transmitted instead. 

[Assumption-18] During orbit control and in case of attitude problems, the MSI shutter 

shall be closed to protect the instrument. This constraint will be 

managed by the FOS. 

[Assumption-19] In response to potential X-Band access conflicts between Sentinels, a 

conflict-free coordination among Sentinels will result in a predefined 

allocation of downlink passes available for Sentinel-2. This allocation 

will be static to a large extent (e.g. on a six to three months basis at 

least) and will be settled after the selection of the CGS network, or inany 

case at the time of the Sentinel-2 PDGS deployment phase. 









4.2 Open Issues 

The present document includes TBD/TBC in relation to the following issues still open. 

 

 

 

 

EDRS GS and S/S technical specifications and interfaces. Technical details are 

missing regarding the interfaces between the PDGS and the EDRS GS as well as 

the PDGS functions necessary for the exploitation of the EDRS in support to the 

Sentinel-2 mission. Technical details are missing regarding the S2G ICD for the 

EDRS satellite limiting the definition/consolidation of requirements for the Ka-band 

data reception and ingestion function of the PDGS. 

Spacecraft(s) Safety Constraints File. A complete list of Sentinel-2 Spacecraft(s) 

Constraints affecting the mission planning as well as which constraints shall be 

verified by the FOS or by the PDGS is still to be defined. 

Next Generation User Services for Earth Observation (ngEO) technical 

specifications and interfaces. The ngEO system will be a new element of ESA’s 

Multi-Mission User Services (MMUS) environment reused for the Sentinel-2 PDGS. 

It is complemented with the overall MMUS by other legacy elements such as Single 

Sign-On (SSO), the Support-Desk, etc. As being a new element under design and 

development, its detailed baseline, interfaces within the Sentinel-2 PDGS, and 

detailed operation scenario with other PDGS elements are still to be defined at the 

level of Technical Specifications and ICDs. 

PDGS physical layout and interconnecting network infrastructure. The PDGS 

ground infrastructure composed of core ground stations, complementary centres 

and an interconnecting network to support the operations is still to be settled. In this 

respect, the system technical budget [STBD] (cf. [ND-10]) provides the logic and 

elements required to derive the firm PDGS technical budget once the physical 

layout is defined. 









5 GMES SENTINEL-2 PGDS REQUIREMENTS 

This chapter defines the applicable requirements to the Sentinel-2 PDGS. 

5.1 PDGS System-Level Requirements 

5.1.1 FUNCTIONAL REQUIREMENTS 

S2-PDGS-SYS-005 

The PDGS shall be able to receive all the MSI, Ancillary and HKTM data downlinked by 

the Sentinel-2 satellite(s) and to mechanically generate HKTM Level-0 products and MSI 

Level-0, -1A, -1B, -1C and TCI products in a systematic manner. 


The PDGS shall be able to receive the data downlinked from the Sentinel-2 spacecrafts by 

means of a network of Core Ground Stations (CGS) and to safeguard the raw data in realtime 

in the station local storage archive. 


The PDGS network of CGSs shall be able to receive the data downlinked from the 

Sentinel-2 satellites either: 

in X-Band directly from the spacecrafts using LEO tracking X-Band antennas; 

in Ka-Band using GEO pointing Ka-Band EDRS-compatible antennas receiving the 

satellite data transmitted by the OCP and relayed via the EDRS system in Ka-Band. 


The PDGS shall be able to serve the mission data and the associated satellite ancillary 

data from the Sentinel-2 spacecrafts to a network of third-party operated X-Band stations - 

Local Ground Stations (LGS) - under direct visibility. All the data served to the LGSs shall 

systematically be downlinked in addition to the CGS network. 


The PDGS shall ensure that the satellite ancillary data downlinked at every ground-station 

(CGS or LGS) overlaps in time with the MSI data downlinked within the same pass. 


The PDGS shall be able to process, package, and deposit at the FOS interface the X- 

Band HKTM data received at the CGS network, corresponding to the data acquired onboard 

since the last downlink. 










The PDGS shall be able to preserve in dedicated long-term archives, all the Sentinel-2 

Level-0 product data (HKTM and MSI) together with all the associated ancillary/auxiliary 

data, critical software and documentation required for higher-level processing, during the 

whole PDGS operational lifetime. 


The PDGS shall be able to preserve in the long-term archives a predefined set of 

Sentinel-2 high level products, including the related auxiliary data, during the whole PDGS 

operational lifetime. 


The PDGS shall be able to elaborate systematically all the MSI raw data into elaborated 

Level-0, Level-1 and True Colour Image (TCI) products by means of a network of 

processing centres or directly at the CGSs. 


The PDGS shall be able to generate systematically the Sentinel-2 true-colour images 

(TCI) at full spatial resolution as part of its nominal data-processing activities. The 

activation of the TCI systematic generation shall be configurable. 


The TCIs processing performed by the PDGS shall be optimised towards the generation 

of visually attractive and eye-catching images. 


The PDGS shall be able to generate systematically the Precise Orbit Determination (POD) 

products by processing the satellite on-board navigation data provided in the satellite 

ancillary data. 


The PDGS shall be able to use the POD products for processing the MSI data in case of 

contingency with the on-board navigation solution. 


The PDGS shall be able to use the Sentinel-2 MSI Decompression Software as part of 

Level-1 processing activities to decompress the MSI raw image data. 


The PDGS shall ensure, by implementing appropriate mechanisms in the MSI dataelaboration 

chain from Level-0 to Level-1 and TCI processing cascading from every 

satellite acquisition, that the elaborated data is timely available to the downstream 









functions in a FIFO manner, i.e. in the same order than that of the raw MSI data received 

from the antenna. 


The PDGS shall be able to guarantee the timely availability of all the MSI Level-0, Level-1 

and TCI data for download within three distinct timeliness classes: 

Real-Time (RT) timeliness, corresponding to data on-line availability no later than 100 

minutes after data sensing, if the MSI data was transmitted in real-time from the 

spacecrafts; 

Near-Real-Time (NRT) timeliness, corresponding to the data on-line availability no 

later than 3 hours after data sensing (matching the NRT3h timeliness denomination of 

the GSCDA) if the MSI data was prioritised on-board for NRT playback; 

Nominal timeliness, corresponding to the data on-line availability no later than 24 hours 

after data sensing (matching the Fast24h denomination of the GSCDA) for all other 

MSI data. 


The PDGS shall include a data reprocessing capability to cover: 

Significant upgrades of the data processing algorithms or of the auxiliary data justifying 

a realignment of the Level-1 dataset in totality or in parts; 

Recovery from contingencies after malfunctions of the real-time chain at a particular 

orbit. 


The PDGS shall be able to store systematically all the generated production including the 

TCI products, immediately after the processing and to maintain it in the archives for a 

configurable duration ranging between a few weeks to several years. 


The PDGS shall be able to store a configurable set of MSI products including the TCIs in 

the medium-term archives for selectable time periods (months / years). 


The PDGS shall be able to circulate the MSI and TCI product data among the 

geographically distributed PDGS archives to satisfy processing, archiving and data-access 

needs. 


The PDGS data-circulation shall be automated and performed in a systematic manner 

according to configurable circulation rules coordinating the data on-line availability 

throughout the PDGS geographically distributed archives. 











The PDGS shall be able to support the following means for data circulation across 

centres: 

terrestrial networks; 

high speed communication links via telecommunication satellites, in particular the 

EDRS data repatriation 230Mbps multicast link; 

physical media transportation. 


The PDGS shall provide the following services to Sentinel-2 users accessible via the 

public Internet: 

Overview of the available services and access to user guides and FAQ documents; 

On-line support-desk via a ticketing system; 

Periodical advertising and notifications on the available mission data, instruments and 

products documentation, including generic mission description and list of relevant 

mission products; 

Periodical publishing of mission end-to-end performance reports and quality reports on 

the Sentinel-2 products; 

Advertising of past and planned system events including instrument or system 

unavailabilities; 

User self-registration; 

User authentication for registered users; 

Access to additional services for authenticated users including: 

- Product download services supporting catalogue browsing and download of 

Sentinel-2 baseline products from preset or user-defined Data-Sets; 

- Hosted-processing services supporting the on-the-fly generation of additional 

products based on the Level-1C product such as the prototype Level-2A or other 

products issued from the hosted processing collaboration opportunities; 

- Automated subscriptions to the above services, performing the periodical and 

autonomous services triggering based on a user-defined or preset configuration; 

- Self-management of user private configurations (e.g. user authentication 

information, user-defined subscriptions, etc). 


The PDGS shall allow the configuration of different data-access profiles associating 

specific grants to registered users or group of registered users including: 

Accessibility per product type; 

Accessibility per Sentinel-2 spacecraft unit and sensing-time period; 

Accessibility based on the age of the data; 

Accessibility to specific versions of the available products discriminating amongst 

several revisions of the processing algorithms; 








Accessibility to reserved products such as calibration products or products under 

investigation after quality-control assessment activities; 

Accessibility to hosted-processing services, separately per service; 

Priority settings applicable to product download and hosted-processing activities; 


The PDGS physical archives shall be federated into a unique virtual archive accessible 

through a gateway transparently hiding the PDGS distributed nature and providing a 

single entry point for the MSI and TCI products data-access vis-à-vis downstream 

interfaces. 


The PDGS shall provide a single virtual point of access to the distributed archive of 

products providing: 

A product query capability over the archived data, responding to client-queries in a list 

of products available for download and meeting the query criteria; 

A product download method performing the effective download of products from the 

archives. 


The PDGS shall be able to systematically publish the coverage of all acquired images to 

the CDS/SCI. This functionality aims at enabling the creation at SCI level of multi-mission 

coverages based on Sentinel-2 data and complemented by other GCM data. 


The PDGS shall be able to support the following means for product data dissemination to 

end users: 

terrestrial networks; 

high speed communication links via telecommunication satellites, in particular the 

EDRS ground-to-ground data dissemination 100Mbps broadcast link. 


On contingency during the commissioning phase, the PDGS shall be able to make the 

product data available on physical media to specific user groups such as CNES/CST for 

data volumes up to 2TBytes of product-data generated during this period. 


The PDGS shall provide to the Sentinel-2 users effective query and on-line access 

capabilities to the products and TCIs available in the global PDGS archive. 


The PDGS shall support queries for archived products responding to complex criteria 

based on, at minimum: 









The time-coverage 

The data age; 

The geographical coverage 

The source spacecraft 

The cloud-cover 

Other metadata such as processor version, acquisition station, summary Quality 

Indicators (QIs), etc 


The PDGS shall support queries for TCIs responding to complex criteria based on, at 

minimum: 

The time-coverage 

The geographical coverage 

The cloud-cover 


The PDGS shall be able to deliver the MSI Level-0, -1A, -1B, -1C products in contents and 

format as defined in the Sentinel-2 Product Definition Document. 


The PDGS shall be able to deliver user-products corresponding to: 

A user-defined geographical product subset along the spacecraft orbit; 

A user-defined selection of product components (e.g. spectral bands, metadata, etc) 

and of the product packaging format from available options. 


The PDGS shall be able to deliver lightweight or heavyweight user-products embedding 

the product components with a fine granularity according to the user request. In particular 

the following elements shall be accessible independently: 

The browse image; 

The spectral bands for the image data; 

The auxiliary data; 

The ancillary data; 

The metadata within several independent classes ranging from essential to expert 

metadata. 


The PDGS shall be able to provide to specific user-groups responsible for Cal/Val or 

Quality-Control activities (including CNES/CST during commissioning phase) a privileged 

access to products hidden to general users. These products shall typically correspond to 









specific acquisitions performed for Cal/Val or degraded quality products requiring 

investigation. 


The PDGS shall provide on-line access to the product data and associated auxiliary-data 

physically stored in the archives with : 

on-line access latency implying the sole download from the archive for typically all data 

with less than one year of age; 

off-line access latency implying a preliminary restore from a long-term archive for older 

data or data not available on-line. 


The PDGS shall support access to off-line data via an asynchronous mode of operation 

whereby: 

The long-term archive is instructed to bring the requested data on-line through the 

medium term archive after a first supply request; 

The data consumer waits for the requested data to be available on-line and performs 

the download as per on-line data supplies as soon as available. 


The PDGS shall support automated Datasets subscription mechanisms whereby the data 

corresponding to a recurrent user-defined criterion is fetched automatically. 


The PDGS shall be able to optimize the data-access performance towards the user bases 

through scalable and transparent data replication and mirroring mechanisms taking into 

account the physical network connectivity and throughput between the user sites and the 

PDGS archive locations. 


The PDGS shall provide the CDS/DAIL interoperable interface service for Sentinel-2 

product catalogue access and on-line access. 


The PDGS shall be able to record the data accesses performed by every user and to 

periodically generate data access statistics. 


The PDGS shall be able to publish the collection of True-Colour Images to the general 

public via the public Internet with no access restriction. 











The PDGS shall publish the TCIs through a user-friendly GUI fostering public and 

universal access to high-resolution earth images. It shall provide simple human interaction 

mechanisms allowing intuitive browsing actions through simple zoom in/out and navigation 

capabilities. 


The PDGS shall be able to accommodate enhancements and evolutions via third-party 

collaborations including: 

Enhancement of the data-access performance, data availability and reliability by 

means of third-party operated centres replicating and mirroring PDGS provided data in 

the overall federated data-access network of centres; 

Hosted-processing capabilities whereby collaborative entities can run their proprietary 

data-processors within the PDGS infrastructure for the validation and/or operational 

production of new complementary products. 


The PDGS shall be able to integrate and run the L2A prototype processor in the PDGS as 

a hosted-processor triggered by authorised users. 


With respect to collaboration activities, the PDGS shall provide a specific service allowing 

to trigger new collaborations and monitor the status and outcome of all collaborations by 

means of appropriate reporting. 


The PDGS shall be able to control, maintain and report on the mission operational 

configuration covering the following activities: 

The definition of a mission configuration baseline in line with the HLOP (e.g. orbit 

scenario, MSI observation scenario, CGS/LGS downlink scenario, data circulation 

scenario, etc); 

The management of PDGS baseline changes driven internally as required by the 

mission performance assessment activities, software maintenance activities, or system 

evolutions (e.g. Sentinel-2B phase-in, change of downlink scenario, EDRS phase-in, 

new LGSs, etc); 

The maintenance of all operations reports generated by the PDGS sub-systems 

providing systematic traceability to relevant baseline they apply to. 


All mission configurable items shall be centrally managed and deployed throughout the 

PDGS and external interfaces (FOS, EDRS, CNES/CST, etc) from a single local 

configuration-control element. This includes: 

The MSI configuration parameter tables 









The mission operation and unavailability plans generated by the FOS and the EDRS 

exploitation segment 

All PDGS internal configuration data for mission planning, acquisition, processing, 

archiving, quality control, data-access, etc. 


The PDGS shall be able to generate conflict-free mission plans covering the imageacquisition 

(for observation and calibration) and the downlink plans cascading from the 

systematic mission scenario and allowing for on-demand image-acquisition for both 

observation and calibration purposes. 


The PDGS shall ensure that all the mission plan activities respect the operational 

restrictions defined in the Spacecraft Safety Constraints File (SSCF). In addition, the 

PDGS shall ensure the traceability for all the mission plans wrt the version of the SSCF 

used for their generation. 


The PDGS shall be able to optimise the mission plan using load-balancing techniques 

amongst the Sentinel-2 constellation satellites. 


The PDGS shall be able to determine the feasibility of the high-level mission operation 

scenario wrt the MSI observation requirements according to the available ground-station 

network. 


The PDGS shall be able to plan ad-hoc data downlinks via the OCP and EDRS for testing 

purposes without interfering (e.g. data loss) with the core mission operations. 


The PDGS shall be able to verify the impact of OCP data transmission wrt simultaneous 

MSI imaging activities. 


The PDGS shall be able to constrain the X-Band downlink opportunities available for 

Sentinel-2 based on a pre-assignment resulting from a conflict analysis with other satellite 

missions (in particular Sentinel-1 and Sentinel-3). 


The PDGS shall be able to constrain the data-relay downlink opportunities available for 

Sentinel-2 via the OCP and EDRS based on a pre-assignment resulting from a conflict 

analysis with other satellite missions (in particular Sentinel-1). 









The PDGS shall be able to constrain the opportunities of direct downlinks to the LGSs 

under direct visibility according to the satellite and ground-segment constraints. 


The PDGS shall be able to plan all the MSI nominal acquisitions and special acquisitions 

used for calibration. 


The PDGS shall be able to adapt the image-acquisition and downlink plans according to 

the planned unavailabilities of the space-segment, the FOS, the CGS, the LGS and the 

EDRS data-relay system. 


The PDGS shall be able to trigger data reception activities at CGSs and LGSs according 

to the downlink plan and the predicted satellite orbital data provided by the FOS. 


The PDGS shall be able to assess and report on the end-to-end PDGS operation 

performance and mission end-to-end performances covering the following activities: 

the overall assessment of the PDGS functioning and performance with respect to the 

plan; 

an assessment of the availability, reliability and quality of all PDGS services; 

an assessment of the product quality as cascading from processing algorithms, 

instrument and platform performances and calibration operations; 

a swift identification of the anomalies and bottlenecks in the system operations or 

design allowing to take preventive and corrective actions to solve the problems; 

a comprehensive assessment of the end-to-end mission performance including the 

PDGS, the FOS, the space segment and the EDRS system with-respect to the HLOP; 

a comprehensive monitoring of all product accesses from the mission users; 

a comprehensive recurrent reporting to the POM on the above including short-term to 

long-term trends viewpoints; 

a summary reporting to the users and to the CDS on the above. 


The PDGS shall ensure that all the generated Sentinel-2 products meet the product 

quality baseline defined in [OCD], are fully calibrated, validated and embed associated 

traceability information compliant with the CEOS/QA4EO guidelines. 










The PDGS shall be able to perform essential quality-control checks on all the MSI 

production to assess the integrity and consistency of the generated product data in terms 

of format and contents using simple algorithms. 


The essential quality-control checks shall be performed immediately following the dataprocessing 

activities and before the product data is made accessible externally. 


The PDGS shall be able to allow or prevent the distribution of the product-data to the 

general users based on the results of the essential quality control performed. 


The PDGS shall be able to report within each delivered product on the results of the 

essential quality control checks performed. 


The PDGS shall be able to autonomously generate the satellite on-board configuration 

parameters of the MSI on need basis including the NUC, the IPS, the FEE and the TCM 

tables and release them to the FOS for uplink and activation. 


The PDGS shall be able to autonomously generate or fetch all on-ground processing 

configuration data required to perform the data-processing activities including: 

All the Level-0 and Level-1 processing parameters modelled as Ground Image 

Processing Parameters (GIPP); 

All the auxiliary-data required for the MSI processing activities reusing existing 

operational data supply services (e.g. ECMWF, IERS, etc). 


The PDGS shall implement a mechanism in coordination with the FOS to synchronise the 

on-board configuration updates for upload and activation on-board. This mechanism shall 

ensure that: 

Every new on-board configuration is fed to the FOS for update with sufficient time in 

advance allowing for the uplink and the on-board activation operations; 

The PDGS can unambiguously associate the on-ground configuration parameters to 

be used according to the actual on-board configuration at a given sensing orbit. 


The PDGS shall be able to access and make use of the HKTM decoded by the FOS 

(packets and engineering value parameters) on need basis for mission performance 









assessment activities. The PDGS shall gather the needed HKTM data through the FOS 

EDDS according to the following mechanisms: 

submit batch requests for automatic HKTM data retrieval as part of cyclic monitoring 

and auxiliary data processing activities; 

interactive requests for on-demand HKTM data retrieval as part of anomaly 

investigation activities; 


The PDGS shall be able to control, maintain and report on the PDGS system (HW & SW) 

operational configuration covering the following activities: 

The configuration control of all PDGS configuration items, including hardware, software 

and their configuration, ensuring traceability to the successive PDGS system 

operational baselines; 

The maintenance of a PDGS global anomaly management database accessible from 

all PDGS centre operators providing anomaly-report ingestion, modification, query and 

statistical generation capabilities and keeping traceability between anomalies and the 

configuration items they apply to; 

The management of PDGS system baseline changes driven internally as required by 

the software maintenance activities or system evolutions 

The systematic validation of new baselines on the Reference-Platform before their 

deployment in operations; 

Systematic reporting upon the validation activities performed before operational 

transfer; 

On-request reporting upon the PDGS baseline evolutions over time, covering hardware 

items, software items and their configuration. 


The PDGS shall be able to supply the Sentinel-2 MSI Decompression Software to the 

LGSs. 


The PDGS shall provide a monitoring and control function in each centre centralising all 

resource and process status information on a unique HMI operator console and providing 

comprehensive real-time views and historical logs over all sub-systems operating in the 

centre. 

5.1.2 PERFORMANCE REQUIREMENTS 


The PDGS shall perform such as to guarantee the availability of the HKTM data at the 

FOS interface within one hour from reception at the CGS stations. 










The PDGS shall be able to process up to L1C and TCI a 20 minutes acquisition (in 

downlink time) within 120 minutes from the start of the downlink down to the availability of 

the L0/1A/1B/1C/TCI output timeline and availability at the user gateway for download. 


The PDGS shall be able to process up to L1C and TCI a 10 minutes acquisition (in 

downlink time) within 110 minutes from the start of downlink, and sustain this scenario 

during at least 10 consecutive downlinks separated by 100 minutes, with 100% 

completeness on the L0/1A/1B/1C/TCI output timeline and availability at the user gateway 

for download. 


The PDGS shall be able to process alternated S2A/S2B downlinks of 10 minutes each (in 

downlink time) up to L1C and TCI and within 60 minutes from the start of downlink, 

assuming the downlinks occur at 50 minutes interval, and sustain this scenario during at 

least 10 consecutive pairs of downlinks (i.e. 20 downlinks), with 100% completeness on 

the L0/1A/1B/1C/TCI output timeline and availability at the user gateway for download. 


The PDGS shall support the dissemination of at least 1.000.000 downloads/year of either 

Level-1C covering in average an area of 100km x 100km of MSI data comprehensive of all 

bands for a total of 400TByte per year. 


The PDGS shall be able to re-process the production generated during one day (covering 

from Level-0 to Level-1C product data) in 2 days time without affecting the nominal 

processing activities. 


The PDGS shall make the products and TCIs available to users within less than 2 minutes 

after effective archiving time. 

5.1.3 SIZING REQUIREMENTS 


The PDGS shall be sized for processing, reprocessing and archiving according to the logic 

and unitary benchmarks and volumes defined in the [STBD]. 


The PDGS CGS shall support continuous downlinks via EDRS of up to 40 minutes. 










The PDGS CGS shall support continuous downlinks via X-Band of up to 13 minutes. 


The PDGS shall support an overall downlink flow of 20 minutes per orbit in average per 

satellite. 


The PDGS shall be sized to support: 

initially, only Sentinel-2A in preparation, commissioning and operation 

subsequently, with Sentinel-2A in operation, Sentinel-2B in preparation, commissioning 

and operation 


The MPAC shall be sized for processing and archiving such as to support the dataprocessing 

operations required nominally for IPF verification activities and anomaly 

investigation activities. 


The PDGS network communications to the FOS shall support the transfer of up 20MBytes 

of HKTM data per orbit. 

5.1.4 OPERATIONAL REQUIREMENTS 


All the PDGS HMIs shall be provided with the following characteristics as a minimum: 

Ability to monitor on-going activities by progress bars or equivalent indicators able to 

provide elapsed & estimated completion times 

Ability to stop/cancel/pause/resume an on-going activity 

Preliminary syntax checks for data insertions 

Confirmation for critical commands submission (e.g. deletion) 

Multiple window display 

Random movement through fields 

Context-sensitive menus 

Context-sensitive help. 


The PDGS HMIs shall ensure that a feedback is systematically provided to the 

user/operator/administrator after initiating a transaction as a minimum indicating that a 

process has been initiated. 










The PDGS HMIs shall provide privileged operators with an interactive capability to 

execute privileged operations possibly violating constraints/rules/criteria nominally 

forbidden to other operators. 


The PDGS HMIs shall request explicit confirmation before command execution of all 

critical or time/resource consuming activities. 


All textual information displayed in PDGS HMIs shall be written in English language. 


The PDGS shall use a time synchronisation function to ensure a unique system reference 

time is used among its elements and facilities. 


The PDGS time shall be UTC with the following standard format yyyy-MMddThh:mm:ss.[nnnnnn] 

where the dash, colon, period and T characters are sub-field 

separators, and the sub-field meaning is as follows: 

yyyy: year, four digits 

MM: month, two digits, left padded with 0 (zero) 

dd: day, two digits, left padded with 0 (zero) 

hh: hours, two digits, left padded with 0 (zero) 

mm: minutes, two digits, left padded with 0 (zero) 

ss: seconds, two digits, left padded with 0 (zero) 

nnnnnn: microseconds, six digits, left padded with 0 (zero), displayed only when 

relevant 


The PDGS shall support at least the following Sentinel-2 mission phases: mission 

preparation, LEOP, Commissioning, Routine, Emergency and Disposal, assuming the 

following key durations: 

Sentinel-2A 

a. Commissioning: 3 months 

b. Nominal Operations: 7 years 

c. Extended Operations: 5 years 

Sentinel-2B 

a. Launch: 18 months after Sentinel-2A 









b. Commissioning: 3 months 

c. Nominal Operations: 7 years 

d. Extended Operations: 5 years 

e. Nominal Sentinel-2A and -2B simultaneous operations: 5-10 years (nominal and 

extended mission duration) 

Archive Operations 25 years after the end of the space segment operations 


The PDGS shall support during the Commissioning Phase (CP) at least the following 

activities and shall be manned accordingly: 

Mission Planning, according to a pre-defined observation plan in line with the 

Commissioning Plan with the possibility to support additionally on-demand or shortterm 

pre-defined observation requests from CNES/CST as necessary. 

X/Ka-band data reception, with an increasing data volume during commissioning 

phase 

Systematic operational data processing of Sentinel-2 Level-0 and gradually higher 

level products 

Off-line interactive reprocessing for troubleshooting purposes (using a stand-alone 

(flexible) version of the operational processor) 

Auxiliary data handling and configuration control 

Instrument calibration according to CNES/CST inputs and instrument performance 

monitoring 

Product quality control 

Instrument and algorithms calibration & products validation in support to CNES/CST 

teams 

Verification of the on-board & on-ground payload data handling processes 

Characterisation of instrument performance in support to CNES/CST teams 

PDGS commissioning of all operational services in particular data-access front-end 

services 


During Commissioning Phase, the PDGS shall receive and use the processing 

parameters (GIPP) and on-board MSI configuration parameters (NUC, IPS, FEE, TCM 

tables) supplied by CNES/CST. 


The PDGS shall systematically request a data-acquisition plan for the constellation to 

cover nominally: 

All land surfaces between 56deg South latitude and 84deg North latitude; 

major islands (greater than 100 km2 size), EU islands and all the other small islands 

located at less than 20km from the coastline; 





Mediterranean Sea, all inland water bodies and all closed seas; 

Specific acquisition campaigns as required. 






The PDGS shall generate and maintain the reference orbit of the Sentinel-2 satellites in 

orbit. 


The PDGS shall systematically plan the MSI calibrations according to a recurrent schema 

phased on the orbit repeat cycle and include additional calibrations requested by the 

mission performance assessment activity. 


On request of the POM, the PDGS shall plan ad-hoc OCP data transmission activities for 

the purpose of testing/verifying the OCP communications with the EDRS GEO satellite(s) 

without creating interferences to the nominal mission operations. 


The PDGS shall mechanically process all the data acquired at every CGS into HKTM 

Level-0, MSI Level-0, -1A, -1B, 1C products including quality control processing and MSI 

TCI processing, archive it and circulate it throughout the PDGS according to the 

configuration. 


The PDGS shall provide access to the complete Sentinel-2 product archive to all 

registered users via the user HMI and via the CDS/DAIL interface. 


The PDGS shall verify all system baseline updates via the Reference Platform before 

deployment. 


The PDGS shall command the downlink, receive and deposit at the FOS interface the 

HKTM data at a frequency of no less than once per orbit. 


The PDGS shall operate autonomously to the maximum feasible extent minimising the 

needs for human controlled operations. 


The PDGS shall operate such that the required human intervention is minimized and well 

identified at specific break points in the process and described with operational 

procedures, such as: 









Specific Cal/Val and product Quality Control operation steps; 

The triggering and monitoring of coordinated system configuration update procedures; 

Media loading, release and shipment procedures. 


The PDGS manned services shall be based on the availability of operators: 

at the PDGS CGS during each acquisition; 

in other centres during normal working hours only (i.e. 8 hours per day, 5 days per 

week). 


The PDGS Support-Desk shall be available via the public Internet on a 8 hours / 5 working 

days basis. 


After generation by the PDGS, the management of NUC table updates shall be entirely 

automated and require nominally no operator intervention. It shall however be possible to 

explicitly require operator acknowledgement prior to forwarding a new table to the FOS for 

uplink. 


The PDGS shall implement maintenance procedures including: 

regular back up of critical data items 

regular back up of the content of any PDGS computer hard disk 


The PDGS shall enable data reception activities at CGSs and LGSs in advance of 

acquisition autonomously. 


The PDGS shall maintain the HKTM data during typically 1 week in the CGSs after 

reception. 


The PDGS shall systematically circulate the HKTM data from the CGSs to the FOS 

through the PDMC. 


The PDGS shall maintain the MSI Level-0 product data during typically 1 month in every 

CGS. 











The PDGS shall systematically circulate from the CGSs to the PACs all generated Level-0 

product data within typically 1 week. 


The PDGS shall keep the MSI Level-1A and Level-1B product-data during typically one 

month on-line after generation. 


The PDGS shall systematically circulate all Level-1B, Level-1C and TCI product-data from 

the CGSs to the PACs within typically 1 week. 


The PDGS shall archive the MSI Level-1C product-data in the medium-term archives for 

typically 1 year for data covering Europe and cloud-free product-data elsewhere. 


The PDGS shall archive all Level-0 (including HKTM), Level-1B and Level-1C productdata 

with all Auxiliary data required to regenerate them in the long-term archives during 

the whole PDGS operational lifetime. 


The PDGS shall archive the TCIs in the medium-term archives for three months typically. 


The PDGS shall contribute to the following GMES Land Coverage Monitoring Service 

(LCMS) data sets by providing the necessary Sentinel-2 optical products as defined in 

[OCD] and supporting the related data requests and data access functionalities within the 

applicable timeliness categories: 

LMCS_001 – EEA-38 wall-to-wall coverage 

LMCS_009 – High Risk Areas 

LMCS_010 – Agro-environmental analysis 

LMCS_012a – Europe land cover of forests, HR coverage 

LMCS_003 – Seasonal/annual land change monitoring: Africa selected areas (HR) 

LMCS_006c – Selected sites for validation of MR and LR biophysical products 


The PDGS shall contribute to the following Land GSE (LGSE) data sets by providing the 

necessary Sentinel-2 optical products as defined in [OCD] and supporting the related data 

requests and data access functionalities within the applicable timeliness categories: 

LGSE_001 – Global Monitoring Food Security: Crop mapping: Africa selected areas 

(HR) 








LGSE_003 – Forest Monitoring: REDD 


The PDGS shall contribute to the following GMES Emergency Response Core Service 

(ERCS) data sets by providing the necessary Sentinel-2 optical products as defined in 

[OCD] and supporting the related data requests and data access functionalities within the 

applicable timeliness categories: 

ERSS_001a – On-line Mapping for Europe (HR) - new data 

ERSS_002a – On-line Mapping for Rest of World (HR) - new data 

ERSS_005 – Overview reference maps – small scale 

ERSS_006b – Historical assets maps medium 

ERSS_007b – Situation maps (Europe) 

ERSS_010c_LDS&SPT – Burn Scar Mapping (Landsat, SPOT) 

ERSS_010c_SPT – Burn Scar Mapping (SPOT) 

ERSS_011a - Volcanic events outside Europe 

ERSS_019 - Cross-cutting issues 

ERSS_022 – Service Validation 


The PDGS shall contribute to the following Emergency GSE (EGSE) data sets by 

providing the necessary Sentinel-2 optical products as defined in [OCD] and supporting 

the related data requests and data access functionalities within the applicable timeliness 

categories: 

EGSE_001 - Crisis and Damage Mapping – Non Charter 

EGSE_002 - Situation Mapping 

EGSE_003 - IDP (Internally Displaced People)/Refugee Support Mapping 

EGSE_004 - Thematic Mapping 

EGSE_007 - Basic Mapping – Small Scale 

EGSE_009 - Thematic Mapping – Medium Scale 

EGSE_012 - Basic Mapping – Small Scale 

EGSE_013 - Mapping of glacial lake outburst floods (GLOF) 

EGSE_014 - RESPOND Basic mapping – small scale 

EGSE_017 - Thematic mapping – medium scale 

EGSE_021 -Basic mapping – small scale 

EGSE_023 - In-Field Data Collection: small scale, large area 

EGSE_026 -Crisis and Damage Mapping – Non Charter 

EGSE_027 -Basic Mapping 

EGSE_031 UNOSAT – User Ambassador for UN users: Basic Mapping Small Scale 

EGSE_032 - Crisis and Damage Mapping 









EGSE_033 -Situation Mapping 

EGSE_035 -Thematic Mapping- Context Mapping 

EGSE_036 -Thematic Mapping- Medium Scale 

EGSE_037 - Thematic Mapping- Large Scale 

EGSE_039 – RISK-EOS: Burn Scar Mapping 


The PDGS shall contribute to the following GMES Security Service (SEC) data sets by 

providing the necessary Sentinel-2 optical products as defined in [OCD] and supporting 

the related data requests and data access functionalities within the applicable timeliness 

categories: 

SEC_002 - Crisis Indicators: Exploitation of natural resources 

SEC_002a - Crisis Indicator: Population pressure 

SEC_002b - Crisis Indicators: Land degradation 

SEC_003a – Critical assets monitoring 

SEC_003b – Critical assets event assessment 

SEC_004a – Illegal Mining 

SEC_004b – Illegal Timber Logging 

SEC_004c – Illicit Crops 

SEC_007a – Terrain analysis and mobility assessment 

SEC_008a – Damage Assessment for post conflict situation 

SEC_008b – Support reconstruction missions after conflicts 


The PDGS shall contribute to the following Marine GSE data sets by providing the 

necessary Sentinel-2 optical products as defined in [OCD] and supporting the related data 

requests and data access functionalities within the applicable timeliness categories: 

MGSE_012 – Polar View: Glacier Monitoring 

MOS_001 - EMSA - CleanSeaNet 

5.1.5 INTERFACE REQUIREMENTS 


The PDGS shall interface according to the [S2GICD] the Sentinel-2 satellites for the 

reception of the telemetry data downlinked in X-Band and including MSI, satellite ancillary 

and HKTM data. 










The PDGS shall interface the EDRS GEO Satellite(s) in Ka-Band for the reception of the 

telemetry data downlinked by the Sentinel-2 Satellites (MSI, satellite ancillary data and 

HKTM) via the OCP, and relayed to ground in Ka-band through the EDRS GEO satellites. 


As part of mission planning activities, the PDGS shall interface the EDRS Exploitation 

Segment for: 

The reception of: 

EDRS GEO Availability Segments as a near-static allocation of EDRS available 

segments for data-relay activities with Sentinel-2 satellites 

EDRS GEO Unavailability Reports dynamically constraining the mission-plan usage of 

the data-relay capacity 

EDRS GEO Pointing Information 

And for the provision of the EDRS GEO Booking Plan resulting from mission planning 

activities 


The PDGS shall interface the EDRS Exploitation Segment for the coordination, planning 

and triggering of ground-to-ground data broadcast activities in support of PDGS internal 

data-circulation and data-dissemination to end-users. 


The PDGS shall interface with external Local Ground Stations (LGS) for the provision of 

the scheduled acquisition plan and orbit information enabling their reception of Sentinel-2 

satellites RT downlinks. 


The PDGS shall interface with Auxiliary Data Providers (ADPs) for the reception of 

auxiliary data files including 

ECMWF for the reception of Level-2 Auxiliary data 

IERS for the reception of UT1-UTC correlation data; 

IGS for the reception of GPS orbits & clocks data (TBC) 


The PDGS shall interface with the selected MSI Decompression SW Provider (MDP) to 

receive the MSI raw-data decompression SW. 


The PDGS shall interface with external Expert Cal/Val Teams supporting specific Cal/Val 

functions. 










During Commissioning Phase, the PDGS shall interface with the CNES/CST for: 

The reception according to the CNES-PDGS ICD of 

Image Calibration and Processing Parameters (GIPP) and MSI on-board configuration 

parameters (e.g. NUC table) 

System Digital Elevation Model 

Global Reference Images increments 

The delivery of: 

Level-0 products; 

Precise Orbit Determination data 

Level-1 products 


The PDGS shall update as required and publish the Sentinel-2 spacecraft(s) reference 

orbit file to the FOS. 


The PDGS shall interface the FOS in the frame of mission planning activities 

to supply according to the PDGS-FOS ICD: 

The Reference Orbit File 

The Nominal Payload Planning File (NPPF) 

The EDRS GEO pointing information 

to receive according to the FOS-PDGS ICD: 

The Plan Increment File (PIF) containing the NPPF confirmed activities 

The satellite and FOS unavailability plans to constrain the mission plan 

The SSCF defining the list of spacecraft constraints to be checked by the PDGS 


The PDGS shall receive from the FOS the SSCF defining the list of spacecraft constraints 

to be checked by the PDGS 


The PDGS shall interface the FOS for the provision of MSI configuration parameter tables 

on a need basis including: 

The IPS tables (7 tables) in SPF format 

The TCM-NOM and TCM-SBY tables in SPF format 

The FEE table in SPF format 

NUC table in OBSM format 










The PDGS shall interface the FOS for the periodic supply of HKTM files in Transfer Frame 

format according to the PDGS-FOS ICD. 


The PDGS shall interface the FOS on a need basis for the provision of the HKTM 

decoded telemetry through the FOS EDDS system according to the FOS-PDGS ICD. 


The PDGS shall systematically provide to the FOS every 3 (TBC) days the EDRS GEO 

Pointing Information (i.e. GEO satellite predicted orbit characterised by the Chebyshev 

polynomial coefficients) required for the scheduling of the OCP activities. 


The PDGS shall interface the FOS according to the FOS-PDGS ICD for the recurrent 

provision of: 

predicted orbit files 

restituted orbit files 

TLE files 

manoeuvre prediction files 

manoeuvre history files 

manoeuvre scale factors files 


The PDGS shall interface with the Sentinel-2 users by means of the user access 

scenarios outlined in [NGEO-OS] complemented by the PDGS specific mechanisms for 

product download. 


The PDGS shall interface with the Sentinel-2 users via email to carry out Support-Desk 

services. 


According to TBD collaborative agreements, the PDGS shall interface external and thirdparty 

operated CDAM centres for 

the provision of: 

PDGS software and software upgrades 

operational configuration data 

Product data for local archiving and mirroring 

And for the reception of archive report updates on the data archived locally. 









5.1.6 RAMS REQUIREMENTS 


The PDGS shall provide functions to support the maintenance and configuration control of 

all PDGS software and associated documentation over its operational lifetime. 


The PDGS shall be able to deliver all generated Sentinel-2 products according to the 

expected quality requirements and within the required timeliness categories with a 

probability better than 0.990 (99.0%) as computed over one month time window and 

assuming a degradation of such figure for no more than one day over the operational 

mission life-time. 


The PDGS shall ensure the reliability of all the data transfer operations ensuring that no 

data is definitively lost in case of temporary communication problems, moreover the data 

transfer operations are resumed as soon as possible once the communication problems 

are disappeared. 


The downtime for PDGS non-critical functions due the addition of one Sentinel-2 satellite 

shall be less than 24 hours. 


The downtime for PDGS critical functions due the addition of one Sentinel-2 satellite shall 

be less than 100 minutes. 


The PDGS software maintenance shall include the following, as a minimum: 

the capability to retrieve from configuration control any PDGS SW item 

the capability to put under configuration control updated SW items 

compiling, linking, debugging capabilities for all source code and SW libraries 


The PDGS shall support re-start of operational functions after failure in the following 

modes: 

resume operations at the step where failure occurred 

re-start operations from a previously completed step before the failure 

re-start operations from a configured reset step 










The PDGS operational baseline documentation (including technical and mission 

documentation) shall be kept under configuration control. 


A failure in one of the PDGS composing element shall not cause failure of an interfacing 

element. 


No single failure/mistake of PDGS operator shall lead to critical consequences. 


The PDGS unmanned services shall be nominally available twenty-four hours/day, seven 

days/week. 


It shall be possible for each PDGS element to be maintained once related operations have 

been started without necessitating a shutdown of the complete element. 


It shall be possible to upgrade the PDGS configuration without affecting the currently ongoing 

PDGS operations and performance levels. 


It shall be possible to upgrade operational PDGS facilities through configuration and 

hardware update without any changes to the SW code or code re-compilation and without 

any PDGS critical operation interruption. 

5.1.7 DESIGN & DEVELOPMENT REQUIREMENTS 


The PDGS design shall derive from the PDGS functional and physical models described 

in the [OCD]. 


The PDGS shall be able to support independent elements and PDGS centre-level tests, 

end-to-end tests, and integration and verification activities through a dedicated Reference- 

Platform function. 










The PDGS shall be scalable in supporting an increasing number of simultaneous data 

access requests and to further improve the dissemination performance. Scalability shall 

be ensured through HW upgrade and/or reconfiguration only without SW changes. 


The PDGS shall be fully scalable with hardware to cope with increase of sizing 

requirements, particularly in terms reprocessing, archiving, circulation and dissemination. 


The PDGS design shall make use of off-the-shelf hardware designs allowing the swift 

replacement of the hardware parts demonstrating repeated or permanent failures (e.g. 

Blade technology hardware, Disk arrays, etc). 


The PDGS design and operations principles shall ensure the minimization of the 

operational costs while ensuring the mission required performances. 


The PDGS software development process shall, whenever justified, make use of off-theshelf, 

commercial or public domain, field proven, software components or software 

applications. Justifications shall result from a cost trade-off analysis considering the 

coverage of the software reuse solution with regards to the functional, performance, 

quality and maintainability requirements to be fulfilled. 


The PDGS software elements shall be designed for long-term maintainability over a period 

spanning 20 years of the PDGS operational lifetime. In this context, maintainability 

includes the preventive, corrective, adaptive, and perfective (improving) maintenance 

types, and applies to all software elements composing the PDGS including reused 

software (e.g. off-the-shelf software, commercial or public domain). 


The PDGS computer platforms shall be based on Intel based architecture and use 

compatible and well maintained Linux operating system distributions. 


The PDGS shall be designed to cope with multiple Sentinel-2 mission satellites, initially 

configured to operate with Sentinel-2A and capable to be configured in the future to 

operate with Sentinel-2A and Sentinel-2B. 











The PDGS data exchanges within a centre and across centres shall be based at the 

maximum extent on XML files. 


The PDGS design shall adopt redundancies/back-ups alternatives according to the 

availability/reliability requirements to be fulfilled. 


All the PDGS facilities/elements shall be designed in order to ensure the maximum level of 

independency in the execution of operational functions and the capability of starting them 

on local command. 


The PDGS design shall ensure that any failure in an element does not prevent its 

redundant/backup element, if any, from being used. 


The PDGS design shall guarantee internal data consistency and integrity along the whole 

mission duration. 


The PDGS design shall allow operations in a degraded mode, i.e. with some functions or 

elements being incomplete or not provided, in case of failures or disabling of a single 

element or disabling of a single service. 


The PDGS shall be designed to provide operational procedures that identify all critical 

system functions and operations. 


The PDGS shall be designed to operate in a data driven mode for all data-elaboration 

functions to the maximum feasible extent. 


The PDGS equipment technology shall be selected such that it can be easily replaceable 

with higher performance equipment when available without impacting system design and 

degrading overall system capabilities. 


The PDGS design shall be such that the accommodation of the baseline evolutions via 

collaborative partnerships does not require any additional software development nor 

additional maintenance investments on the PDGS core infrastructure. 









All PDGS elements shall be available as stand-alone systems and accessible for testing 

purposes through a well defined interface protocol and HMI. 

5.1.8 SECURITY REQUIREMENTS 

S2-PDGS-SEC-005 

The PDGS shall implement access control mechanisms to any information held inside the 

PDGS according to the access restriction applicable to the information. 


The PDGS shall be able to use secured mechanisms provided through commercial-bestpractice-technology 

to support sensible information exchange internally or among its 

distributed sites and external interfaces (e.g. with the FOS) (e.g. VPN, peer-to-peer 

encryption, https). 


The PDGS shall provide automatic tools with the capability to check the PDGS 

software/applications/data for viruses or other malicious code (including location 

identification). 


The PDGS shall include the functionality to record system activity and security relevant 

events including the relationship between user actions and system activity (logging) for 

minimum 6 months. 


The logs of all PDGS systems shall be synchronised. 


The PDGS systems shall provide security mechanisms to prevent accidental and/or 

intentional alteration to the configured versions of software and firmware, if any. 


The PDGS shall be designed to require positive confirmation of the user/operator for 

dangerous commands or the erasure of important data files. 


The PDGS shall allow the restriction of access to all its archived data based on user 

authentication and authorisation mechanisms. 










The PDGS design and configuration in terms of operating-systems and reused software or 

systems (e.g. off-the-shelf software commercial or public domain) shall be in-line with the 

CIS security guidelines. 

Comment: The CIS provides Internet security benchmarks based on recognized best 

practices for deployment, configuration, and operation of networked systems 

(http://www.cisecurity.org) 


The PDGS design shall allow adapting to software and hardware evolutions (e.g. OS 

system upgrade to minor/major release) in a controlled cost manner and without 

unacceptable negative impacts on operations during the upgrade activities. 


The PDGS design shall allow the periodic update and security patching of operating 

system and off-the-shelf software. 


The PDGS software shall run with the necessary minimum level of privileges and be 

designed to access the necessary minimum information and resources needed to its 

legitimate purpose (least privilege principle). 


The PDGS shall implement well-defined access control measures at the level of network, 

system, application and data. 


The PDGS systems shall perform preliminary consistency checks over the data received 

at their input interface before using or forwarding the data to other systems. 


The PDGS software shall not embed any hard-coded root and/or administrative 

passwords. 


The PDGS shall provide means to handle the users accounts provisioning lifecycle (from 

user creation, to deletion) allowing to swiftly update their access profiles as soon as 

requested. 


The PDGS shall provide a centralised authentication mechanism to authenticate Sentinel- 

2 users towards system/application/information enforcing secure password policies (min 8 









characters, a proper mix of letters and symbols) and re-authentication after session idletimeouts. 


The PDGS shall implement an authorisation mechanism to manage Sentinel-2 users 

access towards PDGS systems, application and data. 


The PDGS shall handle all Sentinel-2 users related information according to: 

EU directives on privacy (Regulation EC No 45/2001) 

EU Directive [COM(2005)_438 final)] on data retention 


The PDGS shall provide means to handle the provisioning lifecycle of PDGS operators 

and administrators accounts (from user creation, to deletion) allowing to swiftly update 

their access profiles as soon as requested. 


The PDGS shall implement a secure authentication policy applicable to 

operator/administrator access to PDGS systems and applications enforcing secure 

passwords (min 8 characters, a proper mix of letters and symbols), periodic password 

changes and account locking after a configurable number of failed login attempts. 


The PDGS shall include the functionality to record system activity and record security 

relevant events including the relationship between user actions and system activity 

(logging) for minimum 6 months. 


All PDGS systems exposed to the public Internet shall have enabled and configured an 

host-based firewall according to the defined and implemented network access control 

measures. 


The PDHS systems exposed to the public Internet shall have antivirus software installed, 

enabled, configured and updated as necessary. 


All PDGS operational systems shall apply a well-defined back-up strategy for operating 

system configuration, applications and data. 









5.2 Data Reception (DRX) Requirements 


S2-PDGS-DRX-005 

The PDGS/DRX function shall be able to acquire through a LEO tracking antenna all the 

Sentinel-2 spacecrafts data received via the X-Band downlink interface (i.e. the satellite 

XBS). 


The PDGS/DRX function shall be able to acquire through a GEO pointing antenna all the 

Sentinel-2 spacecrafts data received via the Ka-Band downlink interface (i.e. via the 

satellite OCP relayed by EDRS in Ka-Band). 


The PDGS/DRX function shall be able to perform real-time demodulation of the acquired 

signal and front-end processing of the CCSDS formatted bit-stream down to the ISP 

extraction. 


The PDGS/DRX function shall be able to perform temporally store all the acquired data 

(i.e. for contingency management in case of errors on the processing chain). 


The PDGS/DRX function shall be able to perform real-time supply of the acquired ISPs to 

the DPC function as required for the nominal Level-0 product generation. 


The PDGS/DRX function shall be able to manage two independent X-band downlinks 

channels and process received Sentinel-2 science data, satellite ancillary data and HKTM 

data transmitted by the Sentinel-2 satellites (i.e. S2A & S2B) according to the space-toground 

ICD. 


The PDGS/DRX function shall be able to manage (TBD) independent Ka-band downlink 

channel(s) and process received Sentinel-2 science data, satellite ancillary data and 

HKTM data transmitted by the EDRS satellite(s) according to the TBD ICD. 


The PDGS/DRX function shall be able to support the X-band downlink frequency range 

8015-8350 MHz 











The PDGS/DRX function shall support all polarisations used by the satellite(s) for X-band 

downlink assuming the same output power for each channel and an isoflux on board 

transmitting antennas. 


The PDGS/DRX function shall be able to deliver data to its clients concurrently to the data 

acquisition process. 

(Data delivery and data acquisition may be performed concurrently for different 

spacecraft). 


The PDGS/DRX function shall be able to generate the VCDUs and Instrument Source 

Packets (ISP) from the CADUs received through the two X-band downlink channels and 

from the TBD Ka-band channels. 


The PDGS/DRX function shall be able to process the VCDUs and ISPs in real-time during 

to the X-band / Ka-band downlink. 

(DRX function shall not wait until end of the pass to start with the acquired data 

processing activities). 


The PDGS/DRX function shall be able to filter out idle transfer frames sent by the satellite 

when forwarding the data to the DPC function. 


The PDGS/DRX function shall be able to supply ISP data to the configured interfaces in 

real-time during to the X-band / Ka-band downlink. 

(DRX function shall not wait until end of the pass to start with the ISP data supply 

activities). 


The PDGS/DRX function shall be able to archive acquired and decoded telemetry data 

according to the following criteria: 

Multiple files per pass of fixed maximum dimension 

VCID of packets to be archived in the files 

(All packets with same VCID are grouped in a single ordered stream before archiving). 


The PDGS/DRX function shall support four alternative delivery modes to deliver data to 

the data consumers: 









DRX initiated real-time ISP supply, where the DRX initiates the data-transfer by 

connecting to the client host to deliver the data, as soon as the acquisition starts. Data 

selection: data being acquired; Usage: nominal operations; 

Client initiated on-request ISP supply, where the client initiates the data-transfer by 

connecting to the DRX to receive the data. Data selection: data being acquired, or last 

acquired data; Usage: nominal operations; 

Client initiated deferred on-request ISP supply, where the client initiates the datatransfer 

by connecting to the DRX to receive the data. Data selection: manual, already 

acquired data; Usage: contingency/test operations; 

Client initiated file-transfer, where the client retrieves the data using the file based 

interface (see next section). Data selection: manual, already acquired data; Usage: 

contingency. 


The PDGS/DRX function for a given specific spacecraft shall be able to deliver different 

data (science data, HKTM, satellite ancillary data) to several clients simultaneously. 


The PDGS/DRX function shall make use of TCP/IP protocols to stream acquired & 

processed ISP data. 


The PDGS/DRX function shall make use of a time synchronisation function to ensure a 

unique system reference time is used among its elements. The time synchronisation 

mechanism shall allow synchronising different ground stations time reference. 


The PDGS/DRX function shall ensure absolute data integrity to the data consumers when 

delivering data in real-time ISP supply mode. 


The PDGS/DRX function when delivering data in real-time ISP supply mode, it shall keep 

the connection alive pending the reception of data relevant to the data consumer. The 

socket connection shall be terminated by DRX function at the end of the acquisition and/or 

after all pass data has been successfully received by the data consumer. 


The PDGS/DRX function shall on-request allow data consumers to specify ISP data 

supply filtering criteria (e.g. Mission ID, time window, VCID, APID, etc). 


The PDGS/DRX function shall be able to process several incoming requests concurrently 

for on-request ISP supply. 









The PDGS/DRX function shall support the delivery of data through up to 50 distinct 

streaming interfaces per spacecraft concurrently. 


The PDGS/DRX function shall provide a file-based I/F towards the data consumers. 


The PDGS/DRX function file-based interface shall be used and initiated by data 

consumers to retrieve acquisition archived data files. 


The PDGS/DRX function file-based interface shall make use of TCP/IP and standard file 

transfer protocols like FTP and / or SFTP. 


The PDGS/DRX function shall make available for file-based retrieval complete files (i.e. 

files already closed after writing operations). 


The PDGS/DRX function shall be configured to secure file-based interface exchange area. 

To secure means granting access to this area shall include granting access to other DRX 

critical elements (e.g. internal data buffer). 



The PDGS/DRX function shall comply with the X-band link budget analysis as defined in 

TBD; in particular during the visibility contact it shall guarantee the following factors: 

Effective G/T >= 33.8 dB/K (at 5 degrees of elevation, including rain losses) 

Antenna pointing loss






The PDGS/DRX function shall support for each X-band downlink channel a useful (net) 

ISPs downlink of 260 Mbps or equivalently 280 Mbps as CADU (including Reed-Solomon 

and CCSDS overheads) data rate. 


The PDGS/DRX function shall support for each X-band downlink channel a useful (net) 

ISPs downlink of 260 Mbps or equivalently 280 Mbps as CADU (including Reed-Solomon 

and CCSDS overheads) data rate. 


The PDGS/DRX function shall be able to generate a CADU bit stream at a rate equal to 

the downlink rate per each channel. 


The PDGS/DRX function shall comply with the EDRS Space to Ground communication 

link budget and performance (including Minimum Eb/No and Maximum BER) at each 

defined EDRS Ka-band core ground receiving station. 


The PDGS/DRX function shall provide for each core ground receiving station an antenna 

mechanical pointing accuracy such that the pointing loss will not exceed 0.3 dB measured 

relative to the boresight. 



The PDGS/DRX function shall be sized to support for temporary storage purposes of 

Sentinel-2 science data, HKTM and ancillary data both at VCDU and ISP level (where 

applicable) of TBD GB/day for each satellite for a minimum of 2 weeks TBC. 



The PDGS/DRX function shall be deployed and operated locally in all CGSs. 


The PDGS/DRX function shall generate synthetic operation reports along time, providing 

periodic and self-consistent updates over the recently performed acquisition activities 

(successful and failed) including detailed sampling over the downlink channels quality 

along time. The generated reports shall be systematically routed to the MCC function for 

configuration control and further processing. 










The PDGS/DRX function shall be able to reconstruct a single ordered stream of science 

data from simultaneous received VCDU data (with same VCID) from the two X-band 

physical channels (half swath on each physical channel) sorting the received transfer 

frames by the virtual channel frame count. 


The PDGS/DRX function shall be able to monitor and report on the quality of the downlink 

channels through the measurement of communication link parameters including at least 

the following: 

Antenna AOS/LOS events 

Frame Loss Rate 

Channel BER 

Signal Spectrum 

SNR 

Eb/No 

etc. 


The PDGS/DRX function shall be able to monitor and report on the acquired data 

processing activities performed: 

FEP AOS/LOS 

R/S corrected symbols 

R/S uncorrected symbols 

etc. 


The PDGS/DRX function shall autonomously connect to the DPC function for the supply of 

the current-pass ISPs. As such, the DPC function shall be able to start its processing-onflow 

activities and ensure required timeliness requirements are satisfied. 


The PDGS/DRX function shall provide to the MPA function (via the MCC function as 

proxy) the cyclic reports (e.g. daily reports) on the acquired data processing and 

transformations performed. 


The PDGS/DRX function shall be able to receive data from the two independent X-band 

links according to the following downlink centre carrier frequencies and maximum 

occupied bandwidths (145 MHz): 

8.090 MHz (Link 1) +/- 72.5 MHz 









8.260 MHz (Link 2) +/- 72.5 MHz 


The PDGS/DRX function shall support the reception of Sentinel-2 satellite(s) downlink 

data in any of the following X-band downlink scenarios: 

Scenario 1: Link 1 active only 

Scenario 2: Link 2 active only 

Scenario 3: Link 1 and Link 2 active simultaneously 


The PDGS/DRX function shall assume for data reception purposes a 5 degrees of 

minimum elevation angle for each nominal Sentinel-2 satellite(s) pass transmitted on X- 

band. 


The PDGS/DRX function shall be able to receive Sentinel-2 data through the EDRS, 

complying with the number of independent Ka-band links and according to downlink 

centre carrier frequencies and maximum occupied bandwidths and downlink frequency 

range. 


The PDGS/DRX function shall be able to perform programmed/scheduled angular tracking 

of the Sentinel-2 satellites and X-band data reception based on FOS predicted orbits 

optionally complemented by the Sentinel-2 satellites AOS and LOS times. 

(It shall be able to manage FOS predicted orbit file and two line elements, and PDGS 

planning schedule including AOS & LOS events times). 


The PDGS/DRX function shall be able to perform automatic angular tracking of the 

Sentinel-2 satellites and X-band data reception (it shall be assumed that no S-band 

downlink signal is transmitted from the space-craft). 


The PDGS/DRX function shall be able to perform programmed/scheduled front-end 

processing activities based on the provided PDGS/MPL planning. 


The PDGS/DRX function shall provide manual mode operations for supporting Sentinel-2 

satellites tracking and/or data acquisitions. 










The PDGS/DRX function shall support a reference time synchronized for its 

geographically distributed deployments and for required time-tagging activities (e.g. 

headers time-stamp, acquisition reports, etc). 



The PDGS/DRX function shall be designed to be reconfigured and operational in 30 

minutes in case of failure possibly in full or degraded mode. 


The PDGS/DRX function shall provide reception capabilities with an availability of 99.7% 

computed over one month time window and assuming a degradation of such figure for no 

more than one day. The same availability figure is required for both X-band and Ka-band 

reception chains. 


The PDGS/DRX function shall ensure that received and demodulated data, including 

related acquisition confidence data, is recorded and archived with an availability figure of 

99.7% computed over a period of 2 weeks. 



The DRX function architecture design shall be such as to ensure that the data supply 

operations acquired of one spacecraft (e.g. S2A) do not impact in any manner the data 

acquisition and/or the data supply operations possibly carried out in parallel of another 

spacecraft (e.g. S2B). 

(This may imply in particular the separation at hardware level of the specific subsystems 

responsible for data storage/delivery (e.g. storage disk, network interface, interface server, 

etc). 


It shall be possible to extend the DRX function capabilities to support additional 

spacecrafts by simple configuration and addition of the required hardware as necessary. 





5.3 Data Processing Control (DPC) Requirements 






S2-PDGS-DPC-005 

The PDGS/DPC function shall be responsible within the PDGS for generating the Level-0 

product data from the downlinked raw-data input and orchestrating all cascading upper 

level processing activities performed through the IDP & OLQC functions. 


The PDGS/DPC function shall be able process to the raw-data real-time dataflow in a 

data-driven manner according to configurable rules. 


The PDGS/DPC function shall be able to support operator-driven processing activities 

(e.g. to perform the validation of a new processor, test new auxiliary parameters, reprocessing 

campaigns definition, etc). 


The PDGS/DPC function shall be able to receive and process the S2A and S2B raw data 

supplied in real-time by the DRX function during the satellite acquisitions. 


The PDGS/DPC function shall orchestrate all the data production in a data-driven manner 

and according to a FIFO mechanism based on the order at which the MSI raw data is 

supplied from the DRX function. 


The PDGS/DPC function shall be able to receive and process the MSI raw data ISPs. 


The PDGS/DPC function shall be able to manage the overlaps introduced in the MSI data 

downlinks throughout the CGS network and coherently reconstruct a continuous and 

overlap-free product timeline for archiving. 

Comment: The Satellite MMFU will be commanded (cf. MPL function) to generate some 

data overlaps on the MSI timeline by duplication of some MSI scenes to streamline the 

processing activities on-ground without the need for data circulation between stations (cf. 

Sentinel-2 MMFU Design Adaptations – S2-CR-ESA-SY-0009). 










The PDGS/DPC function shall be able to identify the different MSI scene segments 

received during the same satellite pass according to the scenes sensing time. 


The PDGS/DPC function shall be able to receive and process the satellite ancillary data 

ISPs. 


The PDGS/DPC function shall manage the data overlaps introduced in the satellite 

ancillary data downlinks throughout the CGS network. 


The PDGS/DPC function shall be able to receive and process the X-Band HKTM Transfer 

Frames. 


The PDGS/DPC function shall generate the L0 MSI PDIs from the received mission and 

satellite ancillary data ISPs and safeguard them in the local archive through the AI 

function capabilities for further processing. 


The PDGS/DPC function shall generate and safeguard the L0 HKTM (S2HKTM) product 

data items from the received stream of X-Band HKTM Transfer Frames and safeguard 

them in the local archive through the AI function capabilities for further processing. 


The PDGS/DPC function shall generate the S2MSI0 PDIs from the received MSI and 

satellite ancillary ISPs according to the S-2 PDGS Product Definition Document (e.g. each 

S2MSI0 PDI will correspond to a single detector and single scene comprehensive of all 

bands). 


The PDGS/DPC function shall flag the MSI downlink operation mode (RT, NRT or 

nominal) within the generated S2MSI0 PDIs. 

Comment: This is required for PDGS operations timeliness monitoring. 


The PDGS/DPC function shall flag the MSI acquisition mode within the generated S2MSI0 

PDIs. As such, S2MSI0 PDIs shall be flagged as nominal observation, extended 

observation, dark signal calibration, absolute radiometric calibration, etc accordingly. 










The PDGS/DPC function shall accept incoming connection(s) from the DRX function to 

trigger the real-time reception of MSI, Satellite Ancillary and HKTM data. 


The PDGS/DPC function shall process in real-time the flows of MSI ISPs and Satellite 

Ancillary Data ISPs as part of the MSI L0 generation activities. 


The PDGS/DPC function shall process in real-time the flow of HKTM Transfer Frames as 

part of the HKTM L0 generation activities. 


The PDGS/DPC function shall provide the generated L0 PDIs (i.e. S2MSI0 & S2HKTM) 

for archiving to the AI function in real-time. 


The PDGS/DPC function shall be able to divide the input data flow into independent parts 

of a configurable size to parallelise the processing activities according to a well-defined 

parallelisation strategy. 


The PDGS/DPC function shall organize and orchestrate the execution of the different 

processing activities within a well-controlled process workflow. 


The PDGS/DPC function shall orchestrate the execution of the different tasks optimising 

the available HW resources. 


The PDGS/DPC function shall be able to manage the processing of several MSI data 

fragments in parallel. 


The PDGS/DPC function shall be able to manage the processing of several QC postprocessing 

activities in parallel. 


The PDGS/DPC function shall be able to trigger and manage the systematic execution of 

IDP processing tasks to perform L0 consolidation processing, L1 processing, and TCI 

processing workflows. 











The PDGS/DPC function shall be able to define and manage new processing tasks and 

workflows by configuration. 


The PDGS/DPC function shall be able to organize and orchestrate in a data-driven way 

the execution of the configured processing tasks based on new input data availability. 


The PDGS/DPC function shall be able to trigger different workflows depending on the MSI 

sensing mode reported in the telemetry. For instance, it shall be possible to by-pass IDP 

processing steps or quality control checks on dark-calibration images. 


The PDGS/DPC function shall be able to select the processing parameters applicable to 

the processing workflows as a function of the MSI configuration reported in the telemetry. 

For instance, it shall be possible to select the applicable GIPP configuration based on the 

NUC table identifier reported in the MSI packets. 


The PDGS/DPC function shall be able to manage simultaneously different versions of the 

same processor such that different versions of a data processor can run concurrently and 

be managed independently. 


The PDGS/DPC function shall be able to insert breakpoints in the processing workflows 

and allow interactive inspection of temporary intermediate results at the defined 

breakpoints for debugging or verification purposes. 


The PDGS/DPC function shall be able to perform bulk-reprocessing activities 

automatically after triggering by the operator. 


The PDGS/DPC function shall be able to trigger the bulk reprocessing activities in either 

ascending or descending order of sensing-orbit. 


The PDGS/DPC function shall allow the operator to trigger the contingency reprocessing 

of a satellite pass processing after a general failure occurring on the nominal processing 

workflow. It shall be possible to trigger the recovery processing either: 

from DRX deferred input in case of a contingency occurring during the real-time frontend 

processing; 








from the Level-0 data supply of the AI function in case of a contingency occurring after 

the nominal real-time safeguarding of the raw-data in the archive. 


The PDGS/DPC function shall be able to support configurable priorities for the 

management of concurrent activities (e.g. nominal, re-processing, etc). As such, the 

number of simultaneous processing jobs for every priority level shall be configurable 

according to the available HW resources. 


The PDGS/DPC function shall allow the operator to execute any of the configured 

processing activity on demand. As such, the DPC function shall provide to the operator an 

appropriate HMI to perform the required tasks required for the management of the 

processing activities (e.g. processor selection, version selection, inputs selection, etc.). 


The operator shall be able to fully command the execution of any configured processing 

activity (i.e. start, pause, resume, stop, abort, etc.) via an HMI. 


The PDGS/DPC function shall report on the current status of the different processing 

activities (i.e. running, paused, failed, success, etc.) via an HMI. The commanding actions 

the operator can trigger shall be self-consistent and constrained by the activity current 

status (e.g. no activity can be resumed if it is not in pause status). 


The PDGS/DPC function shall report in real-time the processing log messages generated 

during the execution and provide log message filtering capabilities (e.g. filtering by the 

severity, module, date, etc). 


The PDGS/DPC function shall be able to support bulk data reprocessing activities. 


The PDGS/DPC function shall provide and HMI to support the definition of bulk 

reprocessing activities (e.g. sensing times or orbits ranges and processing order, versions 

of processors, processing resources allocated, etc.). 


The PDGS/DPC function shall be able to execute the defined reprocessing activities 

automatically and autonomously. 










The PDGS/DPC function shall be able to flag/distinguish reprocessing activities execution 

from other ones. 


The PDGS/DPC function shall be able to prioritize the execution flow of the different 

processing activities by configuration and to alter the execution priorities at run-time 

through the HMI. 


The PDGS/DPC function shall impose strict and well-defined commanding & control 

rules/mechanisms for the management of the IDP processing tasks. 


The PDGS/DPC function shall make use of the query capabilities of the AI function to 

identify the data available for processing. 


The PDGS/DPC function shall make use of the data retrieval capabilities of the AI function 

to fetch the data required for the processing. 


The PDGS/DPC function shall make use of the data ingestion capabilities of the AI 

function to archive the data generated in output of the processing activities. 


The PDGS/DPC function shall be able to integrate the IDP & OLQC processing elements 

according to a well-defined DPC ICD defining commanding and control mechanisms, 

input/output interfaces, etc 


The PDGS/DPC function shall manage the overall processing hardware environment 

including: 

The management of the hardware usage and availability for accepting processing 

tasks; 

The selection/allocation of the hardware resource for executing the processing tasks; 

The necessary environment preparation steps prior to the triggering the processing 

tasks; 

The necessary post-processing activities (e.g. cleanup of temporary files, output 

management, etc) on completion of the processing tasks. 










The PDGS/DPC function shall be able to integrate additional processing or quality control 

elements in a swift manner according to the DPC ICD. 


The PDGS/DPC function shall be able to integrate additional processors provided by 

users under the hosted-processing collaboration framework. 


The PDGS/DPC function shall be able to manage the on-demand execution of hostedprocessing 

tasks remotely triggered and monitored by the DAG function. 


The PDGS/DPC function shall be able to run the prototype L2A processor as a hosted 

processor. 


The PDGS/DPC function shall be able to manage and optimise the usage of 

heterogeneous processing resources (i.e. different HW equipment with different CPUs, 

memory) and their adequate allocation to the processing activities function of their HW 

requirements. 


The PDGS/DPC function shall be able to increase its processing capabilities and 

performance by the simple addition and configuration of new HW equipment. 



The PDGS/DPC function shall be able to perform the Front-End L0 processing in real-time 

at 520Mbps effective rate at ISP level from the streamed DRX input (DFEP) down to local 

storage of the output PDIs. The Front-End L0 processing excludes the consolidation 

steps. 


The PDGS/DPC function processing performance shall scale with HW according to a 

near-linear relationship function of the number and performance of the CPU cores 

configured for the processing tasks. 











The PDGS/DPC function shall be deployed and operated locally in each centre requiring 

data reception or processing capabilities i.e. in CGSs, in PACs and in the MPAC. 


The PDGS/DPC function shall generate synthetic operation reports along time, providing 

periodic and self-consistent updates over the recently performed activities (successful and 

failed) consolidated using the processing reports generated by the IDP and OLQC 

functions. The generated reports shall be systematically routed to the MCC function for 

configuration control and further processing. 


The PDGS/DPC function shall receive the ISPs transmitted by the spacecrafts from the 

DRX/DFEP function as part of L0 data generation activities. 


The PDGS/DPC function shall process the two streams of MSI ISPs supplied by the DRX 

function (half MSI swath on each one) in parallel as part of the MSI L0 generation 

activities. 


The PDGS/DPC function shall perform the HKTM and MSI Level-0, Level-1 and TCI 

processing systematically and in a data-driven manner. 


The PDGS/DPC function shall schedule and coordinate the systematic and data-driven 

on-line quality control processing over all the generated L0 and L1 production. 


The PDGS/DPC function shall trigger and coordinate the execution of the hostedprocessing 

tasks (e.g. L2A prototype) on request of the DAG function. 


The PDGS/DPC function scheduled and orchestrated reprocessing activities shall not 

interfere with the nominal processing activities performed after each satellite pass. 


The PDGS/DPC function shall recover from a failed data processing workflow, group of 

workflows, or from a global processing contingency during a satellite pass on operator 

request. 










The PDGS/DPC function shall prioritize the nominal processing activities (new data) over 

the reprocessing ones to meet the new products timeliness requirements. 


The PDGS/DPC function shall prioritize the nominal processing activities over hostedprocessing 

activities. 


The PDGS/DPC function shall package the generated L0 PDIs in SAFE format. 


The PDGS/DPC function shall define a clear self-standing process for the swift integration 

of the third-party processors issued from the hosted-processing collaboration framework. 


The PDGS/DPC function shall supply status information over all its processes and 

resources (i.e. log information, disk volumes usage, alarms, etc.) in real-time via the M&C 

function. 



The PDGS/DPC function shall not propagate single processing contingencies (i.e. SW 

crash) to any other processing activity or globally to itself. 


The PDGS/DPC function shall ensure that processing tasks to not run indefinitely or for 

unrestrained times. 


The PDGS/DPC function shall cope dynamically with single contained HW contingencies 

(e.g. one or several processing nodes HW failures). As such, it shall be able in such 

contingencies to schedule or reschedule the execution of the processing activities on the 

HW resources left. 


The PDGS/DPC function shall ensure in a pre-emptive manner that the processing 

resources (i.e. processing node, memory, disk, etc) assigned to the execution of a 

processing activity are adequately sized and configured to complete the processing 

activity. 










The PDGS/DPC front-end processing activities from the DRX function input shall perform 

nominally for better then 99.9% of the time computed over one month time window and 

assuming a degradation of such figure for no more than one day. 


The PDGS/DPC function shall perform nominally in all contexts (nominal, contingency 

reprocessing, bulk-reprocessing or hosted-processing operations) for better then 99.7% of 

the time computed over one month time window and assuming a degradation of such 

figure for no more than one day. 



The PDGS/DPC function design shall settle a well-defined interface applicable to the data 

and commanding/control flows of the IDP and OLQC processing tasks. 


The PDGS/DPC function design shall settle a well-defined interface for the remote 

triggering and management of hosted-processing tasks through the DAG function. 


The PDGS/DPC function design shall be such that the data processing tasks uniformly 

and dynamically share a sizeable pool of generic "multi-purpose" computing hardware 

resources for processing. 


The PDGS/DPC function shall interface with the DRX function through a high-throughput 

and reliable network interface. 


The PDGS/DPC function shall be designed such as to support high input/output 

throughput and reliable data transfers with the AI function for data archive and retrieval 

operations. 


The PDGS/DPC function design shall be such that the impact of input/output operations in 

the overall time available for processing is minimised and well-controlled avoiding 

input/output bottlenecks in heavy processing load contexts. 





5.4 Instrument Data Processing (IDP) Requirements 






S2-PDGS-IDP-005 

The PDGS/IDP function shall be able to perform the processing of the MSI raw data into 

elaborated Level-1 data according to well-defined algorithms referred to as Detailed 

Processing Models (DPMs). 


The PDGS/IDP function shall be able to generate the MSI L1A, L1B, L1C and True Colour 

Images (TCI) Product-Data-Items (PDIs) according to the Sentinel-2 Products Definition 

Document. 


The PDGS/IDP function operations shall be performed according to and after triggering by 

a well-defined processing directive of the DPC function. 


The PDGS/IDP function shall make use of the provided data and parameters referred to in 

the processing directive, including e.g.: 

Source MSI image data and Ancillary data 

Auxiliary data and processing parameters (e.g. GIPPs such as the DEM, GRIs, etc) 

Output tray, temporary allocated storage, etc 


The PDGS/IDP function shall perform preliminary validation activities on the input directive 

and associated data for completeness, validity (e.g. values are within expected ranges), 

and format. 


The PDGS/IDP function shall notify the DPC function whether the required processing 

activity specified via a processing directive has succeeded, failed, partially succeeded, 

etc. 


The PDGS/IDP function shall generate MSI product data with an accuracy equal or better 

than the baseline product quality targets defined in the [OCD]. 










The PDGS/IDP function shall be able to log the progress and statuses of major processing 

events in real-time back to the DPC function for real-time monitoring. 


The PDGS/IDP function shall be able to log the result of every major functions stating its 

result whether "succeeded" or "failed". It shall be possible to understand via log inspection 

the result status of every processing step (e.g. inputs parsing, decompression, datation, 

etc). 


The PDGS/IDP function shall be able to dump the results of every major function into 

human readable file(s) as breakpoint data. 


The PDGS/IDP function shall be able to generate a report for every performed processing 

directive that summarizes main steps performed such as inputs processed, major 

processing, outputs generated, etc. 


The PDGS/IDP function shall be able to perform simultaneous data processing activities 

on the same hardware without interference. 


The PDGS/IDP function shall systematically stamp the processor version as part of the 

PDI generated metadata. 


The PDGS/IDP function shall classify the product metadata according to the Sentinel-2 

Products Definition Document in: 

"brief" metadata 

"standard" metadata 

"expertise" metadata 


The PDGS/IDP function shall provide the metadata items compliant with the EC Inspire 

metadata regulation. 











The PDGS/IDP function shall be able to perform each of the L0 consolidation and L1 

processing steps within 120% of their benchmarked performance provided in [STBD] 

Table 3 (Benchmarked bulk processing times) on a single equivalent CPU core. 


The PDGS/IDP processing performance to complete the processing of a given data 

fragment shall be predictable with a near-linear linear relationship function of the size of 

the fragment, as computed under a well-defined hardware and middleware environment 

(CPU, memory, disk, Operating System, etc) and within given hardware resource limits (in 

particular memory usage). 



The PDGS/IDP function shall generate the S2MSI1A, S2MSI1B, S2MSI1C and TCI PDIs 

according to the DPC function provided processing directives. 


The PDGS/IDP function shall generate the S2MSI2Ap prototype product. 


The PDGS/IDP function shall perform autonomously without any operator intervention 

once triggered. 


The PDGS/IDP function shall supply status information over its processes and resources 

(i.e. log information, disk volumes usage, alarms, etc.) in real-time via the M&C function. 



The PDGS/IDP function execution shall be successful for better then 99.9% of the time 

computed over one month time window and assuming a degradation of such figure for no 

more than one day. 










The PDGS/IDP function shall not propagate potential execution errors and isolate the 

different processing activities. The execution error of a given processing task shall not 

impact on others. 



The PDGS/IDP function design shall allow the simultaneous execution of different 

instances of the same task or different tasks on the same HW. 


The PDGS/IDP function shall implement the commanding and control mechanisms vis-àvis 

the DPC function according to a well-defined ICD. 


The PDGS/IDP function design shall be modular with respect to the DPM processingsteps 

implemented (i.e. each major processing shall be isolated within an independent 

function allowing easy identification and control of inputs/outputs). 


The PDGS/IDP function design shall derive from a decomposition of the algorithm 

processing steps into single SW tasks which optimises the parallelisation opportunities of 

each one when orchestrated within the global processing workflow managed by the DPC 

function. 

5.5 MSI Decompression Software (MDS) Requirements 


S2-PDGS-MDS-005 

The MDS function shall provide the Sentinel-2 Decompression software with rights to 

install and use the software (as compiled executable and library API) by ESA or any Third 

Parties without any restriction of use. 


The MDS function shall provide and maintain an installation and user manual of the 

Sentinel-2 Decompression software providing software installation and usage guidelines in 

line with the distributed software. 










The S2 Decompression Software documentation, configuration files and textual 

input/output messages (execution log, errors messages, etc) shall be provided in English 

language. 


The MDS shall provide the software compiled and validated onto several widely used 

UNIX-based computer platforms. 


The MDS shall ensure the maintenance of the Sentinel-2 Decompression software alongtime 

ensuring its validated compatibility and performance with the latest operating system 

versions while keeping the distribution of older versions running on operating systems 

deprecated since less than one year. 



The MDS shall provide upgrades of the Sentinel-2 Decompression software validated on 

new operating system versions no later than 2 months after the public availability of the 

new operating system version. 

5.6 On-Line Quality Control (OLQC) Requirements 


S2-PDGS-OLQC-005 

The PDGS/OLQC function shall be responsible within the PDGS for systematically 

verifying whether the generated product data items meet their defined structure, format, 

and semantics and have general levels of quality and accuracy in line with the quality 

targets, along the whole mission duration. 


The PDGS/OLQC function operations shall be performed according to and after triggering 

by a well-defined processing directive of the DPC function. 


The PDGS/OLQC function shall make use of the provided data and parameters referred to 

in the processing directive, including typically: 

The source PDI to inspect; 

The configuration of the quality control verifications (e.g. a GIPP); 









The list of all quality control checks to perform; 

Output tray, temporary allocated storage, etc 


The PDGS/OLQC function shall allow configuring and managing the different quality 

control checks as a set of checklists, each one defining one or more checks to be applied 

on a given product component or set of components. 


The PDGS/OLQC function shall be able to apply the checklists autonomously and 

generate output reports under the form of quality-check PDIs. 


The PDGS/OLQC function shall systematically report the version of the checklist and a 

reference to the inspected data as part of the resulting quality check PDIs. 


The quality-check PDIs generated by the PDGS/OLQC function shall systematically 

include all checks performed, each one including an identification of the check and its 

result. 


The PDGS/OLQC shall distinguish between different types of checks: 

Sample checks aiming at sampling (probing) some specific items extracted from the 

product data for off-line assessment via the MPA function. 

Informative checks aiming at characterising/measuring the quality of the data; 

Concluding checks aiming at summarising the quality of the data with a concluding 

"pass" or "fail", and at generating operator alerts in real-time in case of a failed status. 

The quality-check PDIs issued from informative or concluding checks will make part of the 

user-product structure as On-Line Quality Check metadata defined as placeholder in the 

[PDD]. 

The quality-check PDIs issued from sample checks will not be reported in the product 

structure. 


The PDGS/OLQC function shall systematically consolidate a summary pass/fail status at 

the term of each checklist processing stating whether all the configured concluding checks 

have "passed" or whether at least one has "failed". The summary status shall be 

systematically reported as part of the resulting quality-check PDI. 











The PDGS/OLQC function shall log in real-time via the M&C function all quality control 

checklists completed with a summary failed status. 


The PDGS/OLQC function shall be able to read and process any field of the Sentinel-2 

product structure to perform the quality control checks. 


The PDGS/OLQC function shall allow the flexible configuration of quality control checks by 

means of simple rules on the field formats, field value ranges, etc based on a semantic 

dictionary of the data under inspection. 


The PDGS/OLQC function shall be able to integrate specific or complex quality control 

checks provided as software "plug-ins". 


The PDGS/OLQC function shall allow the configuration of quality checks based on the 

results of other lower-level checks. 


The PDGS/OLQC function shall be able to apply identical checklists amongst different 

types of PDIs (e.g. common quality checks on the headers, data formats and range 

checks, etc) 


The PDGS/OLQC function shall be able to apply different checklists depending on the 

type of PDI under inspection. 


The PDGS/OLQC function shall allow applying one or more distinct checklists on every 

type of PDI by configuration. 


The PDGS/OLQC function shall be able to define and manage independent checklist 

configurations applicable to specific to Sentinel-2A data, to Sentinel-2B data or to both by 

configuration. 


The PDGS/OLQC function shall notify the DPC function on whether the required 

processing activity specified via the processing directive has succeeded, failed, partially 

succeeded, etc (independent from the results of the checks). 









The PDGS/OLQC function shall be able to perform simultaneous data processing 

activities issued from distinct directives on the same hardware or on different hardware 

without interference. 



The systematic operations of the PDGS/OLQC function shall impose less than a 5% 

overhead over the processing resources required to complete the global systematic data 

processing within identical timeliness constraints. 



The PDGS/OLQC function shall generate all quality control check PDIs according to the 

directives of the DPC function. 


The PDGS/OLQC function shall perform autonomously without any operator intervention 

once triggered. 


The PDGS/OLQC function shall supply status information over its processes and 


function. 



The PDGS/OLQC function operations shall ensure nominal operations unattended for 

better than 99.7% of the time computed over one month time window and assuming a 

degradation of such figure for no more than one day. 



The PDGS/OLQC function design shall allow the simultaneous execution of different 

instances of the same task or different tasks on the same HW. 










The PDGS/OLQC function shall implement the commanding and control mechanisms visà-vis 

the DPC function according to a well-defined ICD. 


An update of the Sentinel-2 Products specifications should not require an upgrade of the 

PDGS/OLQC function implementation other than re-configuration (with no need for 

software development and validation). 

5.7 Archive & Inventory (AI) Requirements 


S2-PDGS-AI-005 

The PDGS/AI function shall be in charge of archiving and registering all the Sentinel-2 

data for storage, inventory query and retrieval operations versus other PDGS functions. 


The PDGS/AI function shall be able to archive and inventory the MSI product data. 


The PDGS/AI function shall be able to archive and inventory the Sentinel-2 True Colour 

Images (TCI). 


The PDGS/AI function shall be able to archive and inventory the Sentinel-2 X-Band HKTM 

data. 


The PDGS/AI function shall be able to archive and inventory the satellite ancillary data 

associated to the MSI product data. 


The PDGS/AI function shall be able to archive and inventory all the auxiliary data required 

for the generation of Sentinel-2 products (i.e. GIPP parameters, DEMs, IERS UT1-UTC 

correlation data, ECMWF data, etc). 


The PDGS/AI function shall be able to temporarily archive and inventory any intermediate 

product data derived from the MSI processing activities such as quick-looks, cloud masks, 

etc if needed. 










The PDGS/AI function shall organize and structure the storage in a hierarchical structure 

of granular Product Data Items (PDIs) in view of flexible data storage and retrieval 

operations. 

The PDIs are composed by a set or excerpt of the following elements: 

Image data (L0 granules, L1A/1B/1C spectral band data granules, TCIs, etc) 

Image metadata 

Image quality indicators and quality checks 

Satellite ancillary data (satellite orbit position, velocity, time, attitude) 

Orbit metadata 

Auxiliary data (GIPP, etc.) 

Satellite HKTM data 

etc 


The PDIs shall be organised according to their scope and granularity e.g. at the level of 

the orbit, group of orbits, a satellite pass, a granule, a group of granules, etc while 

maintain their inner relationships within the hierarchy. In particular, the hierarchy of MSI 

PDIs modelled in the archive should mirror at best the products breakdown structure 

specified in the Product Definition Document [PDD]. 


The PDGS/AI function shall be able to identify and discriminate between different 

concurrent versions of the PDIs (except raw data PDIs) archived as consequence of data 

reprocessing activities (different processor versions, different auxiliary data usage, etc.). 



concurrent versions of the Level-1A and Level-1B granule-level PDIs according to their 

quality/completeness. 



complementary versions of the Level-1C and TCI granule-level PDIs generated and 

archived at different centres according to their effective data coverage of the granule (a 

UTM tile). 

Comment: Partial and complementary Level-1C and TCI tiles will be produced at the 

datastrip boundaries fragmented between two ground-stations downlinks. 











concurrent versions of the Level-0 PDIs and maintain only the ones with higher quality in 

case of duplication during ingestion. 

Comment: MSI raw data scenes may be acquired at different stations under different 

reception conditions. 


The PDGS/AI shall be able to register all MSI PDIs sharing the same granule property 

using a granule identifier uniquely and unambiguously referring to: 

for L0/L1A/L1B PDIs: one MSI image scene coverage by one detector 

for L1C PDIs: one geographically referenced UTM tile. 

The unique identification of every granule-based PDI in the hierarchy shall then be 

ensured by composing the granule identifier with other metadata (e.g. parent-product, 

band, software version, etc) 


The PDGS/AI function shall provide the necessary archive interface mechanisms in 

support of the PDGS processing activities for PDI archiving. 


The PDGS/AI function shall provide the necessary query and retrieval interface 

mechanisms vis-à-vis the DPC and DAG functions in support of the processing and data 

access activities. 


The PDGS/AI function shall be able to supply any auxiliary data archived to perform the 

MSI processing activities (e.g. GIPP, GRIs, DEMs, POD, etc). 


The PDGS/AI function shall be able to perform autonomous data ingestion and archiving 

activities triggered by the input data availability in a data-driven manner. 


The PDGS/AI function shall be able to support interactive data ingestion and archiving 

activities triggered by the operator. 


The PDGS/AI function shall provide functionality to filter the archived PDIs according to 

different criteria in support of data query and retrieval operations towards other functions. 

The filtering options shall include: 

time filters operating on sensing time (or applicability time from Auxiliary data), archive 

time, processing-time; 









geographical location filters; 

semantic filters such as PDI data-type, MSI acquisition mode, cloud cover threshold, 

quality checks threshold, etc; 

PDI processing baseline version 

on-line or off-line availability 

etc 


The PDGS/AI function shall support archive-to-archive data circulation mechanisms 

between several distributed archive instances my making use of the DC function for the 

actual data transportation (by electronic circulation means and/or media). 


The PDGS/AI function shall be able to define consistent archive-to-archive circulation 

rules using the PDI filtering capabilities for automatic inter-archives circulation. E.g. Level- 

1C tiles acquired over Italy with cloud cover of less than 30% are circulated systematically 

to a mirror archive. 


The PDGS/AI function shall be able to define circulation rules for single PDIs or group of 

PIDs to selected destinations for other purposes than archive-to-archive circulation. E.g. 

all HKTM PDIs are circulated to the PDMC to be forwarded to the FOS; OLQC generated 

PDIs are circulated to the MPAC for off-line assessment, etc. 


The PDGS/AI function shall support the circulation of individual PDIs between sites (e.g. 

HKTM PDIs circulation to the PDMC, OLQC PDIs to the MPAC, etc) 


The PDGS/AI function shall allow the operator to perform data selection and trigger 

circulation operations interactively via an HMI. 


The PDGS/AI function shall be able to interface with the LTA service function for 

autonomous data archiving and retrieval activities to/from long-term storage. 


The PDGS/AI function shall systematically maintain the inventory of all data physically 

archived in the LTA. 










The PDGS/AI function shall perform off-line data retrieval from the long-term archive in a 

transparent manner to the other PDGS functions, apart from the possibly increased 

access latencies compared to the retrievals from on-line storage. 


The PDGS/AI function shall allow the operator to move large volumes of data from local 

on-line storage to LTA storage or vice-versa interactively from the HMI using PDI filtering 

capabilities. 


The PDGS/AI function shall support a batch mode of operation to copy automatically large 

volumes of data from on-line local storage to LTA storage or vice-versa according to a 

configurable time schedule and PDI filtering criteria. The scheduling shall order the 

operations to be performed periodically (e.g. daily) in trunks of mission time in either 

ascending and descending order of orbits. 


The PDGS/AI function shall autonomously apply a configurable data-retention policy over 

the data archived along time defined by means of data-retention rules based on the PDI 

filtering capabilities and including: 

data clean-up operations (e.g. S2MSI1C data older than 1 month, with cloud cover 

higher than 85% and outside of Europe is physically removed). 

data copy operations from on-line storage to long-term storage through the LTA 

service function (e.g. all Level-0 data is systematically copied when 7 days old to the 

long-term archive) 


The definition of the data-retention policy shall include the flexible configuration and 

management of caching capabilities in the on-line storage such that: 

LTA restored data can be kept on-line for a configurable time after restore (e.g. when 

triggered by data-access operations) or can be managed interactively by the operator; 

The data can be maintained on-line according to its frequent/infrequent usage for 

processing or data-access operations in view of optimising the overall archive 

performance; 

The data retention on-line can be modified on individual items interactively by the 

operator. 


The PDGS/AI function shall allow the operator to query upon and visualise dynamically 

and graphically through the HMI the contents of the archive with associated statuses on its 

elements (e.g. scheduled times for retention operations, circulations performed, planned 

operations, current operations, on-line/off-line items etc). 








page 100 of 204 


The granularity of archive-to-archive circulation and data-retention management 

operations shall not go beyond the main levels of the archive hierarchy, preventing the 

dissociation of its leaf components (.e.g. single spectral band data). 


The PDGS/AI function shall be able to generate archive update reports systematically on 

every new data ingestion, modification or removal from storage and provide it to the DAX 

function for global index management and cataloguing purposes. Accordingly the archive 

update reports shall be comprehensive of all metadata required by the DAX function to: 

uniquely and unambiguously identify each item; 

identify the source archive centre where the data relies or was removed; 

characterise the on-line, off-line or unavailable availability property of the item; 

characterise the data for cataloguing and filtering purposes (e.g. product-type, 

geographical coverage, quality checks, etc) as required by the MMUS function. 


The PDGS/AI function shall provide functionality to the operator of regenerating archive 

update reports over a defined selection of orbits or over the full inventory e.g. to recover 

from contingencies of the DAX function. 


The PDGS/AI function shall allow the operator to set a local archive temporarily 

unavailable for data-access (e.g. for maintenance activities). The availability/unavailability 

status of the archive shall be systematically and immediately reported to the DAX function 

under the form of unavailability reports. 


The PDGS/AI function shall deny access to the DAG function for data retrieval operations 

during unavailability periods by acknowledging the data-access requests with an 

unavailability notification message. 


The PDGS/AI function shall archive the Level-0 PDIs in SAFE format. 


The PDGS/AI function shall be able to handle large data files greater than 2GB. 


The PDGS/AI function shall be able to perform full backups of the data inventory. 








page 101 of 204 


The PDGS/AI function shall be able to perform incremental backups from a previous full 

backup of the data inventory. 


The PDGS/AI function shall be able to restore the data inventory based on full / 

incremental backups. 


The PDGS/AI function shall be able to regenerate the full inventory based on its contents 

in case of contingencies. 


The PDGS/AI function shall raise alarms autonomously to the operator on major operation 

contingencies such as disk I/O errors, disk free space thresholds surpassed, etc. 



The PDGS/AI function shall support a sustained throughput with multiple random access 

for simultaneous data ingestion and retrieval operations over the whole archive (excluding 

LTA) versus the DPC function of at least 300Mbps input rate and 300 Mbps output rate 

to/from the archive (not applicable to LTA archive access) 


The PDGS/AI function shall support a sustained throughput with multiple random access 

over the whole archive (excluding LTA) of at least 200 Mbps of data delivery activities 

towards the DAG function. 


The PDGS/AI function shall support the necessary data throughput towards a co-located 

LTA service function to sustain the continuous archiving of all the Level-0, Level-1B, 

Level-1C and TCI data along mission-time. 



The PDGS/AI function shall be deployed and operated locally in each centre requiring 

archiving capabilities i.e. in CGSs, in PACs, and in the MPAC. 








page 102 of 204 


It shall be possible to deploy the PDGS/AI function in a collaborative CDAM centre for 

autonomous operations by a third-party. 


The PDGS/AI function shall generate synthetic operation reports along time, providing 


failed) including an inventory of the archive updates and data circulations performed. The 

generated reports shall be systematically routed to the MCC function for configuration 

control and further processing. 


The PDGS/AI function shall perform the archival and retrieval operations in a complete 

autonomous way requiring no operator intervention nominally. 


The PDGS/AI function shall perform all circulation operations systematically and 

automatically requiring no operator intervention nominally based on the configured 

circulation rules. 


The PDGS/AI function shall apply the retention policies systematically and automatically 

requiring no operator intervention nominally based on the configured retention rules. This 

includes the autonomous triggering of long-term archiving operations to the LTA service 

and caching management. 


The PDGS/AI function shall systematically generate and supply archive report updates on 

the newly archived, modified or removed data to one PDGS/DAX function instance in the 

PDMC and one additional physically redundant instance in one PAC. 


The PDGS/AI function shall be configured to circulate the HKTM PDIs to the FOS via the 

PDMC. 


The PDGS/AI function shall be configured to circulate the satellite ancillary data PDIs to 

the POD function. 


The PDGS/AI function shall be configured to circulate the archived product data across 

centres according to the operational configuration for circulation outlined in the [OCD]. 








page 103 of 204 


The PDGS/AI function shall be configured for data-retention according to the operational 

configuration for retention throughout the PDGS archives outlined in the [OCD]. 


The PDGS/AI function shall be configured in two redundant PACs for the systematic copy 

of all archived L0/1B/1C data to long-term storage. 


The PDGS/AI function shall supply status information over all its processes and resources 

(i.e. log information, disk volumes usage, alarms, etc.) in real-time via the M&C function. 


The PDGS/AI function shall generate a critical alert to the operator whenever the 

remaining on-line storage space falls below a configurable threshold. 



The PDGS/AI function shall ensure nominal availability unattended for better than 99.7% 

of the time computed over one month time window and assuming a degradation of such 



The PDGS/AI function shall provide the required autonomous data reallocation, reindexing, 

etc. capabilities that ensure no degradation on the performance requirements 

along the mission time life. 


The archive-to-archive circulation operations and retention management operations shall 

ensure consistency of the archive hierarchy and completeness of the circulation, move or 

clean-up operations such that: 

PDIs are circulated, moved or removed together in complete form of their granularity 

(e.g. MSI granules are always comprehensive of all spectral bands, associated 

metadata, etc); 

datastrip-level or orbit-level PDIs are removed only after all related lower level PDIs 

are removed; 

low-level PDIs are never moved alone without their cross-related upper-level PDIs; 

etc 








page 104 of 204 


The PDGS/AI function data circulation and clean-up operations shall include an optional 

shield ensuring PDIs are physically archived in a remote centre before they are locally 

removed. 


The PDGS/AI function shall guarantee archive / retrieval / removal / update transactions 

consistency in case of contingency (e.g. disk full, network problems, etc). It shall 

consistently resume nominal operations once the contingency is solved. 


The PDGS/AI function shall ensure that no PDI is lost during its data retention period. It 

shall provide the required data redundant mechanisms (e.g. data redundant RAID 

configurations) to cope with the unexpected HW anomalies/failures. 



The PDGS/AI function design shall allow the addition of new product models or the 

modification of existing ones (e.g. support for new product types) by configuration. 


The PDGS/AI function design shall be scalable supporting configurations from lightweight 

(several tens of TBytes), medium (several hundreds of TBytes) to massive (PByte scale) 

storage capacity in support to the different PDGS short to mid-term archive configurations. 


The PDGS/AI function shall make use of appropriate hardware architectures (e.g. Storage 

Area Networks) and/or distributed storage sharing methods (e.g. distributed file-systems 

such as Lustre, GPFS, GlusterFS, etc) to allow storage virtualisation as well as low 

latency and high input/output performance data transfers for the DPC and DAG functions 

operations with archived data. 


The PDGS/AI function shall support data caching mechanisms fostering optimised access 

performance towards DPC and DAG functional elements. 


The PDGS/AI function design shall implement the LTA service function interface and 

mechanisms for long-term data archive and retrieval operations. 





5.8 Long-Term Archive (LTA) Service Requirements 




page 105 of 204 


S2-PDGS-LTA-005 

The LTA service function shall be responsible for within the PDGS for: 

Ensuring long-term data preservation and access to all Sentinel-2 mission data; 

Providing bulk data re-processing capabilities on the long-term dataset; 


The LTA service function shall ensure mission data storage and accessibility for the whole 

duration of the Sentinel-2 missions and for 25 years after the end of the space segment 

operations. 


The LTA service function shall be able to perform bulk data reprocessing activities based 

on the local archived data-sets and to systematically mirror every resulting product in the 

AI function inventory. 


The LTA service function shall be able to archive autonomously the product data and 

auxiliary data provided by the AI function according to a well-defined interface. 


The LTA service function shall be able to restore the product data and auxiliary data to the 

AI function on request according to a well-defined interface. 



The LTA service function shall sustain the continuous archiving of all the Level-0, Level- 

1B, Level-1C and TCI data along mission-time. 


The LTA service function shall be able to supply to the AI function any product data held in 

the archive in less than 24 hours. 








page 106 of 204 



The LTA service function shall be integrated and operated in two geographically 

distributed PACs. 


The LTA service function shall implement a well-defined data preservation policy in line 

with the LTDP objectives and inter-agency guidelines. 


The LTA service function shall systematically ingest and archive all the product data 

auxiliary data provided at the AI function interface. 


The LTA service function shall perform autonomous data retrieval operations from longterm 

storage as triggered by and according to the AI function interface. 


The LTA service function shall nominally archive all the L0 data (MSI & HKTM) for the 

PDGS operational lifetime. 


The LTA service function shall nominally maintain all the MSI L1B and L1C product data 

for the PDGS operational lifetime, keeping always the most up-to-date version of every 

generated product. 


The LTA service function shall perform bulk data reprocessing operations on a need basis 

and provide the resulting inventory metadata at the AI function interface for inventory. 



The LTA service function shall provide nominal archiving and retrieval operations with a 

success probability better than 99.7% computed over one month time window and 



The LTA service function shall ensure that no archived data is lost. 








page 107 of 204 


The LTA service function shall ensure accessibility to 100% of the archived data for 

retrieval at any time. 

5.9 Data Circulation (DC) Requirements 


S2-PDGS-DC-005 

The PDGS/DC function shall be responsible within the PDGS for: 

Carrying out all the product exchanges between the distributed PDGS archives; 

Carrying out all the data exchanges between the PDGS and external interfaces (e.g. 

versus FOS, LGSs, CNES/CST, etc.) 

Centralising all file-based data exchanges between PDGS interfaces whether internal 

to a centre (between co-localised sub-systems) or external across centres. 


The PDGS/DC function shall implement data circulation actions consisting of data 

transportation from an input interface to an output interface. 


The PDGS/DC function shall support electronic interfaces (network connected) and media 

interfaces. 


The PDGS/DC function shall support all electronic data exchanges for data input and 

output across all geographically distributed sites of the ground-segment, including filebased 

exchanges, email exchanges, etc as required. 


The PDGS/DC function shall be able to interface with the EDRS ground-to-satellite 

equipment for EDRS data circulation activities (ground-to-ground). 


The PDGS/DC function shall be able to support diverse state-of-the-art media storage 

devices (e.g. USB HDDs) for the media interfaces circulation activities. 


The PDGS/DC function shall be able to identify univocally each media interface storage 

volume (e.g. labelling the storage volume name with the media interface name plus a 

sequence number to identify the circulation operation). 








page 108 of 204 


The PDGS/DC function shall be able to retrieve autonomously data from all input 

electronic interfaces according to a well-defined configuration. 


The PDGS/DC function shall be able to deliver autonomously data to all output electronic 

interfaces according to a well-defined configuration. 


The PDGS/DC shall operate autonomously in a data-driven manner based on the 

detection of new data made available by other systems at the configured interface for 

circulation to another system's interface. 


The PDGS/DC function shall allow the operator to interactively add / modify / delete the 

configuration of electronic input or output interfaces within or external to the PDGS via a 

HMI. 


The PDGS/DC function shall allow associating access methods, protocols, polling 

frequencies, etc to each electronic interface by configuration. 


The PDGS/DC function shall allow the operator to interactively add / modify / delete the 

configuration of circulation rules between electronic input and output interfaces via an 

HMI. 


The PDGS/DC function shall be able by configuration to prevent the circulation of the 

same data twice between the same interfaces. Accordingly the DC function shall keep 

track of all the circulation operations performed. 


The PDGS/DC function shall process autonomously the data from/to media interfaces 

limiting operator intervention to the sole initial media preparation (e.g. tape loading, disk 

connection, etc), media disposal (unloading, disconnection, etc) and shipment activities. 


The PDGS/DC function shall be able to perform several media interface circulation 

operations on different media in parallel. 








page 109 of 204 


Peer to peer media-circulation operations between PDGS/DC functions hosted at different 

sites shall be coordinated such that lost or partially/completely unreadable media can be 

automatically identified and requested back electronically between receiver and sender. 


The PDGS/DC shall keep track of all files delivered to a given media interface volume to 

allow recovery circulations on contingency of the nominal circulations. 


The PDGS/DC function shall make use of standard protocols such as SFTP, FTP, FTPS, 

SMTP, POP, HTTP, HTTPS, etc to perform data circulation operations according to the 

required interface mechanisms. 


Electronic circulations shall make use of password-less authentication techniques, likely 

via encryption keys, when supported by the protocol. 


The PDGS/DC function as part of the data circulation activities, shall allow on-the-fly 

simple file conversion/edition activities (e.g. renaming, textual transformation, 

compression, decompression, format conversion, etc). 



The PDGS/DC function time lag for the start of the files circulation operations shall not 

exceed 1 minute from the sources availability. 


The PDGS/DC function shall make effective use of the available network resources for its 

operations. 


The PDGS/DC function shall introduce only negligible time overhead on the data 

circulation operations to media interfaces ensuring the available writing rate according to 

the device specifications. 


The PDGS/DC function shall be able to support an overall average sustained electronic 

circulation throughput of 200 Mbps between geographically distributed sites plus 200 

Mbps of internal traffic. 








page 110 of 204 


The PDGS/DC function shall be able to support an overall average sustained circulation 

throughput via media of 200 Mbps. 



The PDGS/DC function shall be deployed and operated locally in all PDGS centres. 


It shall be possible to deploy the PDGS/DC function in a collaborative CDAM centre for 



The PDGS/DC function shall generate synthetic operation reports along time, providing 


failed) including a detailed inventory of all data circulations performed. The generated 

reports shall be systematically routed to the MCC function for configuration control and 

further processing. 


The PDGS/DC function shall supply status information over all its processes and 


function. 


The PDGS/DC function shall minimize human intervention when performing retrieval / 

delivery operations from / to media interfaces. 


The PDGS/DC function shall alert the operator by making use of the M&C function 

capabilities for all operations requiring urgent manual intervention including: 

Media loading/disposal operations; 

Contingency operations on repeated failures of circulation operations from/to media or 

electronic interfaces. 


The PDGS/DC function shall centralise all data exchanges (file-based, e-mail, productdata, 

etc) for data input and output via electronic or media interfaces between every 

PDGS centre and its remote interfaces unless, specified otherwise. 








page 111 of 204 


The PDGS/DC function shall centralise all data exchanges for input and output between 

the different PDGS sub-systems collocated within a centre, unless specified otherwise. 


The PDGS/DC function shall autonomously retrieve from the International Earth Rotation 

Service (IERS) interface the UT1-UTC time correlation data 


The PDGS/DC function shall autonomously retrieve from the European Centre Medium 

range Weather Forecast (ECMWF) the relevant auxiliary data (e.g. water vapour data). 


The PDGS/DC function shall carry out the physical circulation of all the Mission Reference 

Files (MRF) amongst the applicable interface points (internal or / and external PDGS 

interfaces) on behalf of the MCC function. 


The PDGS/DC function shall perform the sustained circulation operations of product-data 

between geographically distributed sites via digital communication networks and via media 

in support to the electronic circulation. 



The PDGS/DC function shall ensure nominal operations unattended for better than 99.7% 

of the time computed over one month time window and assuming a degradation of such 



The PDGS/DC function shall guarantee zero data loss and full consistent transfers (e.g. 

no partial file transfers) between receivers and senders. 


The PDGS/DC function shall guarantee the completeness and consistency of all 

circulation transactions in case of contingency (e.g. disk full, network problems, corrupt 

media, etc). It shall resume nominal operations once the contingency is solved (e.g. after 

a local disk/network contingency) or request reiteration of the circulation (e.g. in case of an 

unrecoverable media). 


The PDGS/DC function shall retry any failed operation on a configurable frequency basis. 

After a configurable number of repeated failures, the operator shall be alerted. 








page 112 of 204 


The PDGS/DC function shall be able to skip any missing / failed data volume and keep on 

circulation activities normally when retrieving data from a media interface. In case a media 

volume fails or is not recoverable, the operations to other disk volumes shall not be 

affected. 



The PDGS/DC function shall comply to all interface methods (e.g. servers of HTTP(S), 

FTP(S), SMTP, etc) and exchange mechanisms of all the systems to be interfaced within 

and outside the PDGS (including external legacy systems) according to their applicable 

ICDs. 


The PDGS/DC function design shall be based on widely used standards maximum reuse 

of public-domain off-the-shelf software. 


The PDGS/DC function shall make use of public-domain off-the-shelf software to perform 

the simple on-the-fly file conversion/edition operations. 


The PDGS/DC function shall be designed such that new interface mechanisms (e.g. new 

interface protocols) and file conversion/edition operations can be seamlessly integrated 

within the overall function framework via "plug-ins". The addition of new mechanisms shall 

require only the effort associated to their plug-in implementation plus minimum integration 

overhead. 

5.10 Precise Orbit Determination (POD) Requirements 


S2-PDGS-POD-005 

The PDGS/POD function shall be responsible for generating POD orbit products by 

processing satellite navigation data from the on-board GNSS receiver and the required 

auxiliary data (e.g. GPS orbits, GPS clocks). 


The PDGS/POD function shall be able to process up to 45 MB/day of GPS level-0 data 

per each spacecraft. 








page 113 of 204 


The PDGS/POD function shall be able to generate a POD predicted orbit product as 

required according to the Sentinel-2 processing timeliness requirements. 


The PDGS/POD function shall be able to generate a POD restituted orbit products as 

required according to the Sentinel-2 processing timeliness requirements. 


The PDGS/POD function shall manage potential satellite ancillary pass data overlaps. 

(Due to strategy to avoid data circulation it may be possible that same satellite PVT data is 

contained on different pass files). 


The PDGS/POD function shall manage potential satellite ancillary data gaps (e.g. data 

circulation errors, etc.). 

(Satellite ancillary data gaps of TBD time shall not prevent the generation of required POD 

products). 


The PDGS/POD function shall flag generated POD products as "degraded" in case 

required input data to meet accuracy requirements is not available. 

(This is not having enough GNSS data coverage, required auxiliary data, etc.). 


The PDGS/POD function shall generate POD products whenever it is possible according 

to its configuration, present input data, etc. 


The PDGS/POD function shall be able to analyse the on-board navigation solution with 

respect to the final orbit occurred. 


The PDGS/POD function shall be able to analyse the generated POD products with 

respect to the final orbit occurred. 



The PDGS/POD function shall generate Predicted orbit products 90 minutes before 

Sentinel-2 A/B ANX for as many orbits as the required accuracy can be ensured. 








page 114 of 204 


The PDGS/POD function shall generate Predicted orbit products with an accuracy of 10m 

on the 2D position with 3σ confidence level. 


The PDGS/POD function shall generate Restituted orbit products within 30 minutes of 

receipt of GNSS L0 products. 


The PDGS/POD function shall generate Restituted orbit products with an accuracy of 3m 

with 3σ confidence level. 



The PDGS/POD function shall be deployed and operated locally in the MPAC. 


It shall be possible to deploy the PDGS/POD function locally in the CGSs. 


The PDGS/POD function shall autonomously receive and process the FOS orbit files (e.g. 

FOS predicted & restituted orbit file, FOS manoeuvres files, etc) for comparison and 

analysis of the GPS on-board navigation solution. 


The PDGS/POD function shall autonomously receive and process the relevant FOS orbit 

files (e.g. FOS restituted orbit file, FOS manoeuvres files) for comparison and analysis of 

the POD generated products. 


The PDGS/POD function shall autonomously gather the required input data for its 

processing and quality checks activities. 


The PDGS/POD function shall be able to manage the following information for its orbit 

determination activities: 

GPS orbits & clocks data 

GPS ionospheric maps (TBC) 

FOS orbit files 

FOS manoeuvres files 








page 115 of 204 

Satellite ancillary data (GPSR TM packets, satellite PVT and attitude information) 

GPSR Instruments status reports (i.e. Instrument Unavailability Report concerning the 

GPSR delivered by FOS) 


The PDGS/POD function shall generate Predicted orbit products with a coverage of the 

next orbit plus TBD orbits wrt. to the current orbit. 

(This is at the beginning of orbit "n" to generate a predicted orbit product with coverage 

orbit [n+1, n+x] x>1). 


The PDGS/POD function shall generate Restituted orbit products with a coverage equal to 

latest PVT contained within the received satellite ancillary data that triggers such 

generation with 2 orbits (TBC) backwards. 


The PDGS/POD function shall be configured to generate Predicted orbit products in a 

schedule-driven manner (i.e. every orbit). 


The PDGS/POD function shall be configured to generate Restituted orbit products in a 

data-driven manner (i.e. in response to every received satellite ancillary data product). 


The PDGS/POD function shall autonomously supply the generated POD generated 

products. 


The PDGS/POD function shall autonomously gather the required auxiliary data (i.e. GPS 

orbits, GPS clocks, etc.) for the POD generation and analysis activities. 


The PDGS/POD function shall autonomously generate and supply the navigation solution 

quality reports. 


The PDGS/POD function shall autonomously generate and supply the POD products 

quality reports. 








page 116 of 204 



The PDGS/POD function shall be able to deliver all generated orbit products according to 

the accuracy and latency requirements with an availability figure better than 98.5% of the 

time computed over one month time window and assuming a degradation of such figure 

for no more than one day. 


The PDGS/POD function shall manage independently S2A and S2B orbit determination 

activities (i.e. inputs management, generation and orbit products supply). 


The PDGS/POD function shall isolate unexpected errors raised during the orbit 

determination activities. 

(A fatal error on the POD Predicted products generation shall not affect on the POD 

Restituted product generation activities). 



The PDGS/POD function shall be implemented to be deployed in a POSIX environment. 

5.11 Auxiliary Data Supply (ADS) Requirements 


S2-PDGS-ADS-005 

The PDGS/ADS function shall be able to autonomously generate and supply all the 

auxiliary data required by the PDGS. 


The PDGS/ADS function shall be able to autonomously generate on schedule-driven 

basis any required auxiliary data according to its timeliness and coverage definition. 


The PDGS/ADS function shall be able to autonomously in a data-driven manner based on 

the new auxiliary data availability, supply it to the configured PDGS functions. 








page 117 of 204 



The PDGS/ADS function shall supply all the required auxiliary data in advance according 

to well-defined timing schedule according to every processing need. 



The PDGS/ADS function shall generate and publish all the required auxiliary data in a 

timely and reliable manner including all Level-2 auxiliary data defined in the PDGS-PDD 

and the IERS UT1-UTC correlation data. 



The PDGS/ADS function shall ensure nominal operations unattended for better than 

99.7% of the time computed over one month time window and assuming a degradation of 

such figure for no more than one day. 



The PDGS/ADS function design shall reuse existing infrastructure (e.g. ECMWF, IERS, 

etc). 

5.12 Data-Access Index (DAX) Requirements 


S2-PDGS-DAX-005 

The PDGS/DAX function shall be responsible for federating the distributed Sentinel-2 

product inventories spread throughout the PDGS in: 

maintaining from individual inventory updates a consolidated and consistent master 

index containing the relationships between the available product components and their 

physical remote location in the PDGS centres; 

Populating consolidated catalogue updates to the front-end service functions in charge 

of the metadata catalogue and user services operations; 

Resolving data location queries on the master index for data-access operations; 









page 118 of 204 


The PDGS/DAX function shall be able to generate, manage and maintain along-time an 

index of all product data items archived in the PDGS maintaining inner relationships to 

each of their singular physical data-access points. 


The PDGS/DAX function shall be able to ingest the archive update reports provided by 

several physically distributed instances of the AI function and to consolidate them in the 

master index. 


The PDGS/DAX function shall be able to identify and manage redundant / replicated 

archived product data items that may be located on different archive centres. 


The PDGS/DAX function shall organise the master index in a hierarchy mapping the 

relationships between the parent-products (covering a complete orbit stripline in a given 

MSI mode), and their decomposition into several geographically scattered granule 

components, datastrip components, orbit components, and global components (e.g. 

auxiliary data). 


The PDGS/DAX function shall be able to discriminate amongst several versions of the 

product data items generated within different contexts (e.g. with different processor 

version, different auxiliary data, etc) and manage them as distinct items sharing common 

properties. 


The PDGS/DAX function shall be able to generate automatically asynchronous catalogue 

updates (for addition, modification or removal) mirroring the contents of the PDGS 

archives and to supply them in real-time to the Front-End service functions. 


The PDGS/DAX function shall generate the catalogue metadata items at the level of the 

product granule to allow for fine geolocation queries over the mission data catalogue. 

Each catalogue update shall be characterised at minimum by: 

a unique identifier for each distinct cataloguable item; 

the availability property (on-line, off-line, unavailable); 

the sensing and generation times; 

the native dataset association (S2MSI0, S2MSI1A, S2MSI1B, or S2MSI1C); 

a list of key metadata such as satellite identifier, dataset version (processing version), 

usage category (e.g. cal/val, general use, expert, etc), cloud cover percentage over the 

granule area, quality flags, etc; 




the geographical footprint of the data; 

the geographical footprint of the cloud-mask; 




page 119 of 204 

the parent-product identifier used for granule to product associations in the catalogue. 


The PDGS/DAX function shall prevent the repeated generation of catalogue updates for 

catalogue metadata items corresponding to several physically duplicated instances of the 

same logical item. 


The PDGS/DAX function shall be able to generate asynchronous consolidated updates of 

the Sentinel-2 preview images and provide them (or a well-defined mechanism to access 

them) to the Front-End Service functions. 


The PDGS/DAX function shall prevent the duplicated generation of preview-image 

updates to the Front-End Service functions. 


The PDGS/DAX function shall maintain and mirror in simplified catalogue updates the 

changes in the availability property of the product data (on-line, off-line, unavailable) 

reported by the singular archives in the archive update reports. 


The PDGS/DAX function shall prevent the repeated generation of catalogue updates for 

catalogue items corresponding to several physically duplicated instances of the same 

logical item. 


The PDGS/DAX function shall be able to automatically generate and supply to the 

CDS/SCI the Sentinel-2 products coverage reports based on the catalogue updates. 


The PDGS/DAX function shall provide a query interface remotely accessible and resolving 

the physical access location of the product data available for retrieval throughout the 

PDGS archives. 


The PDGS/DAX function shall be able to support simultaneous data location requests. 


The PDGS/DAX function shall be able to backup, export and restore the master index 

totally or partially according to flexible criteria (e.g. last year records). 








page 120 of 204 


The PDGS/DAX function shall minimize total backups size making use of incremental 

backup strategies. 


The PDGS/DAX function shall be able to backup, export and restore incremental data 

indexes without interruptions of its nominal operations. 


The PDGS/DAX function shall provide the necessary functionality to carry out nominal 

operations from a master instance seconded by a second geographically distributed 

instance operated in hot-redundancy to the master instance for location query processing 

and data supply autonomous operations towards other PDGS functions and external 

interfaces. 


The PDGX/DAX function shall be able to systematically ingest unavailability reports 

provided by any AI function instance stating the temporary unavailability or return to 

operations of its data access capabilities. 


The PDGS/DAX function shall consistently report an error in response to data location 

queries for unavailable items. 


The PDGX/DAX function shall allow the operator to manually change the temporary 

availability status of any archive of the federated PDGS. 


The PDGS/DAX function shall ignore the master index records corresponding to data held 

in archive instances temporarily unavailable when processing data location queries. In 

case a queried item is held in unavailable archives only, the PDGS/DAX function shall 

report an error stating the temporary unavailability of the data. 


The PDGS/DAX function shall allow the operator to set any federated PDGS archive from 

a temporary unavailability status to a permanent unavailability status. Consequently it 

shall mirror the unavailability of all its previous contents in the master index and trigger as 

relevant the catalogue updates to the MMUS and OLIB functions. 








page 121 of 204 



The PDGS/DAX function shall be able to perform the ingestion of archive reports for new 

MSI product granules and the generation of the corresponding catalogue updates and 

CDS coverage reports at a sustained rate of no less than four granules per second in 

average. 


The PDGS/DAX function shall complete every product location query within less than half 

a second. 


The PDGS/DAX function shall support product location queries at a rate of one Level-1B 

or Level-1C square product per second, considering a square product coverage of about 

300km x 300km. 


The PDGS/DAX function shall be able to complete in less than 10 seconds the parallel 

processing of 10 simultaneous data location requests corresponding to all Level-1C 

products of the Sentinel-2 constellation covering Europe during one month. 


The number of simultaneous data location requests which can be supported in parallel 

with the defined performance shall be linearly scalable with hardware. 



The PDGS/DAX function shall be deployed and operated locally in the PDMC and in one 

PAC as hot-redundant backup. 


The PDGS/DAX function shall supply status information over all its processes and 


function. 


The PDGS/DAX function shall systematically ingest all archive update reports provided by 

all geographically distributed AI function instances in a data-driven manner. 








page 122 of 204 


The PDGS/DAX function shall systematically generate the catalogue update reports for all 

Sentinel-2 products and the preview-image updates and provide them to the MMUS 

functions in a data-driven manner. 


The PDGS/DAX function shall systematically generate the catalogue update reports 

applicable to the TCI images and provide them to the OLIB functions in a data-driven 

manner. 


The PDGS/DAX function shall systematically generate Sentinel-2 products CDS/SCI 

coverage reports and provide them to the CDS in a data-driven manner. 


In case of contingency on the master index, the PDGS/DAX function shall perform index 

restore operations from backup or bulk re-ingestion of the archive update reports should 

the restore from backup fail. 


The PDGS/DAX function shall systematically reply to the data location requests submitted 

through the PDGS/DAG functions autonomously. 


The PDGS/DAX function shall generate synthetic operation reports along time, providing 


failed) including an inventory of all index updates performed. The generated reports shall 

be systematically routed to the MCC function for configuration control and further 

processing. 



The PDGS/DAX function shall perform in hot redundancy between two geographically 

distributed instances. 


The PDGS/DAX function shall ensure nominal operations in hot-redundant configuration 

unattended for better than 99.9% of the time computed over one month time window and 


Comment : This implies the definition of a way for measuring the availability figure. 








page 123 of 204 


The PDGS/DAX function shall ensure 100% completeness of the ingestion processing in 

each hot-redundant instance. 


The PDGS/DAX function shall ensure 100% completeness of the catalogue update, 

preview-image update, and CDS coverage report generation processing and supply to 

output interfaces. 



The PDGS/DAX function remote query interface shall be clearly documented in an ICD. 


The PDGS/DAX function remote query interface shall make use of standard network 

protocols (e.g. HTTP, SOAP, etc). 


The PDGS/DAX function shall optimise the index and index hierarchy by using the specific 

properties of the Sentinel-2 mission and product decomposition such as: 

The shared granule property amongst the level-0, level-1A and level-1B products and 

its unique identification throughout mission time (as based on unique detector and MSI 

scene identifiers); 

The granule property of Level-1C granules in an invariant set of geographical tiles; 

etc 


The PDGS/DAX function shall comply with the MMUS function defined interface for the 

supply of the catalogue updates. 


The PDGS/DAX function shall comply with the MMUS function defined interface for the 

supply of the preview-images updates. 


The PDGS/DAX function shall comply with the CDS/SCI applicable interface for the supply 

of the coverage reports. 





5.13 Data Access Gateway (DAG) Requirements 




page 124 of 204 


S2-PDGS-DAG-005 

The PDGS/DAG function shall be responsible for: 

Managing the download operations of all MSI user-products and TCIs based on the 

product data available throughout the PDGS, as commanded by the users through the 

MMUS or OLIB function interfaces; 

Managing the hosted-processing operations according to the processing system 

interface capabilities, when commanded by the users through the MMUS function 

interfaces. 


The PDGS/DAG function shall provide vis-à-vis the MMUS function a single virtual point of 

access to all Sentinel-2 PDGS products for downloads no matter the physical location of 

the product elements. 


The PDGS/DAG function shall provide vis-à-vis the OLIB function a single virtual point of 

access to all Sentinel-2 TCIs for download no matter the physical location of the images. 


The PDGS/DAG function shall provide vis-à-vis the MMUS function a single virtual point of 

access for commanding and control of hosted-processing activities throughout the PDGS. 


The operations performed through the PDGS/DAG function shall be based on a clientserver 

protocol operating between the PDGS core infrastructure elements acting as 

servers and the user base platforms acting as clients separated by a digital network. 


The PDGS/DAG function shall provide a management function federating all physically 

distributed servers and acting transparently as proxy/router of all transactions with other 

functions. 


The PDGS/DAG management function be able to run in hot-redundancy between 

geographically distributed sites. 









page 125 of 204 


The PDGS/DAG function shall be able on request by the MMUS function to perform the 

end-to-end product download operations by identifying via the DAX function the location of 

the various product components across the various distributed archives, retrieve them, 

and assemble them into comprehensive User-Products automatically. 


The PDGS/DAG function shall authenticate each product (non TCI) download request or 

my making use of the MMUS function authentication service. It shall be possible to bypass 

the authentication step by configuration (e.g. for testing campaigns). 


The PDGS/DAG management function shall authorise each product (non TCI) download 

request immediately preceding the effective download my making use of the MMUS 

function authorisation service. It shall be possible to by-pass the authorisation step by 

configuration (e.g. for testing campaigns). 


The PDGS/DAG function shall identify the location of the requested product components 

throughout the archive centres by making use of the location query capabilities of the DAX 

function. 


The PDGS/DAG function shall make use of the PDI query and supply capabilities of the AI 

function to retrieve the PDIs satisfying the data download requests. 


The PDGS/DAG function shall assemble the User-Products in structure and format as 

specified in the [PDD] as part of download operations. 


The PDGS/DAG function shall be able to assemble the User-Products according to the 

download options provided in the MMUS requests complemented or supplemented by 

pre-configured default user-defined preferences. 


The PDGS/DAG function shall allow the user to configure its own preferences regarding 

default product assembly and formatting options. 


The PDGS/DAG function shall assemble in the User-Products a user-defined list of 

product components specified as download-options, including auxiliary-data, bandseparate 

image data, metadata, quality indicator data, etc as independent components. 







page 126 of 204 


The PDGS/DAG function shall, when requested as a download-option, include a previewimage 

in the User-Products downloaded. 


The PDGS/DAG function shall package the User-Products in DIMAP or SAFE format as 

specified via a download-option. 


The PDGS/DAG function shall, when requested as a download-option, merge the granule 

data and metadata of Level-0, -1A or -1B products along the satellite track direction into 

12 across-track granules as part of the download. 


The PDGS/DAG function shall, unless requested otherwise as a download-option, merge 

together partial and complementary UTM tiles of a Level-1C product into single complete 

tiles as part of the download. 

Comment: Partial and complementary tiles will be produced at the datastrip boundaries 

fragmented between two ground-stations downlinks. 


The PDGS/DAG function shall compile in the S2MSI0 User-Products the best available 

raw-data granules by discriminating on the quality/completeness of the granule in case of 

duplication across PDGS archives. 

Comment: Duplicated MSI raw-data scenes will be produced at the datastrip boundaries 

fragmented between two ground-stations downlinks. 


The PDGS/DAG function shall compile in the S2MSI1A and S2MSI1B User-Products the 

best available image granules by discriminating on the quality/completeness of the 

granule in case of duplication across PDGS archives. 

Comment: Duplicated granules may be produced at the datastrip boundaries fragmented 

between two ground-stations downlinks. 


The PDGS/DAG function shall generate consistent product metadata, function of the 

elements effectively assembled in the product hierarchy. 


The PDGS/DAG function shall systematically and dynamically generate the product-level 

quality control checks metadata consolidated over the full assembled product including: 

check of the overall product consistency; 








page 127 of 204 

summary product-level quality checks consolidated from the granule-level or datastriplevel 

quality checks. 


The PDGS/DAG function shall perform TCI downloads as singular tile downloads. 


The PDGS/DAG function shall, when relevant, merge together several partial and 

complementary TCI PDI tiles, each one covering in parts the tile area, and provide a 

single consolidated TCI tile in output. 

Comment: Partial and complementary TCI tiles will be produced at the datastrip 

boundaries fragmented between two ground-stations downlinks. 


The PDGS/DAG function shall support parallel downloads from the same source server 

and from different source servers in response to a single download request. 


The PDGS/DAG function shall optimise the download performance taking benefit of the 

scattering of the data in several centres and considering the communication performance 

between users and servers. 


The PDGS/DAG function shall, in optimising the download performance, be able to track 

and account for the amount of data downloaded by each user and globally on every 

server. 


The PDGS/DAG function shall allow to queue the download requests while keeping under 

a configurable limit the number of download operations performed in parallel at each 

centre based on the centre's outbound network resource bandwidth. 


The PDGS/DAG function shall prioritise the access to the download resources according 

to the user priority setting qualified in the authorisation acknowledgment provided by the 

MMUS function. 


The PDGS/DAG function shall apportion the usage of the network resources by public 

users for TCI downloads by means of a download priority setting assigned to TCI 

downloads configurable per centre. 








page 128 of 204 


The PDGS/DAG function shall be able to accept and manage hosted-processing requests 

submitted by the users from the MMUS function using the local processing capabilities 

and data available in each PDGS centre. 


The PDGS/DAG function shall be able to route the hosted processing requests in an 

optimal way amongst the distributed DPC function instances available for processing 

considering the data locally available for processing at each centre. 


The PDGS/DAG function shall support the simultaneous management of several hostedprocessing 

transactions and several product download transactions performed in parallel. 



The PDGS/DAG function shall complete the download of a product assembling 9 Level-1C 

tiles (300km x 300km) comprehensive of all bands within less than 1 second over the time 

required to transfer all product components through the network via the standard FTP 

protocol. 


The PDGS/DAG function shall complete the download of a full swath MSI Level-0 product 

and of 6640 km along-track comprehensive of all bands within less than 5 seconds over 

the time required to transfer all product components through the network via the standard 

FTP protocol. 


The PDGS/DAG function shall support the parallel processing of at least 100 product 

download requests from a single archive centre. 


The PDGS/DAG function shall support the parallel management of at least 100 hostedprocessing 

requests versus a single processing centre. 



The PDGS/DAG function shall be deployed and operated locally in CGSs and PACs 

acting as local data download and/or hosted-processing servers. 








page 129 of 204 


It shall be possible to deploy and operate the PDGS/DAG function in a collaborative 

CDAM centre acting as local download server. 


The PDGS/DAG management function shall be deployed and operated locally in the 

PDMC acting as central physical point of access supported by at least on PAC instance 

configured as hot-redundant backup for this function. 


The PDGS/DAG function shall supply status information over all its local processes and 

resources (i.e. log information, disk volumes usage, alarms, etc.) in real-time via the 

collocated M&C function. 


The PDGS/DAG function shall operate autonomously and mechanically as triggered by 

download requests and hosted-processing requests. 


The PDGS/DAG function shall systematically notify the MMUS function of the 

successful/unsuccessful completion of a product download request. 


The PDGS/DAG function shall systematically provide a summary report to the MMUS 

function on completion of every download including the volumes of data downloaded, the 

time to serve the request, etc, or qualifying the source of the problem in a human 

understandable message for failed downloads. 



The PDGS/DAG function shall ensure nominal operations in hot-redundant configuration 

unattended for better than 99.7% of the time computed over one month time window and 



The PDGS/DAG function shall ensure that the User-Products delivered are consistent and 

complete of all data. 








page 130 of 204 



The PDGS/DAG function shall be designed following a client/server paradigm in which the 

client is hosted at the user site and the servers are hosted at the PDGS CGS/PAC centres 

and CDAM centres. 


The design of the PDGS/DAG function shall be such as to prevent misuse of its intended 

functionality in gaining unauthorized access to the PDGS resources or to user information 

(e.g. via common hacking techniques). 


The PDGS/DAG function client software shall be portable to a wide range of client 

computer platforms (HW+OS) including Microsoft Windows, Apple Macintosh MacOS-X 

and commonly used UNIX based workstations. 


The PDGS/DAG function client side software shall be implemented in a low-level 

language (e.g. Java, C++, etc) excluding the use of proprietary software libraries or 

languages requiring a non free-of-charge run-time license. 


The PDGS/DAG function shall interface with the DAX function to locate the data available 

for download. 


The PDGS/DAG function shall interface with the AI function to gather the data required for 

the download operations. 


The PDGS/DAG function shall interface with the MMUS function on one end and to the 

DPC and AI functions on the other for managing the dataflow of the hosted-processing 

operations. 


The PDGS/DAG function interface to the MMUS function shall comply to the MMUS 

ICD(s) for the triggering and management of the product download requests. 


The PDGS/DAG function design shall comply to the MMUS ICD(s) for the commanding 

and control of the hosted-processing activities. 








page 131 of 204 

5.14 Multi-Mission User Services (MMUS) Requirements 


S2-PDGS-MMUS-005 

The MMUS function shall offer the following services to the Sentinel-2 Users: 

Login & Authentication; 

Centralised user authentication and authorisation (catalogue search, products browse, 

product download); 

Access to complete and comprehensive information about the GMES Sentinel-2 

mission and products (e.g. Quality, etc.) their availability and mechanism to access 

them; 

Advertising of available mission, instruments and products documentation, including 

generic mission description and list of relevant mission products; 

Periodical provision of quality updated information on the available Sentinel-2 

products, past and planned instrument unavailabilities; 

General support information on the available services 

Mission Data Online Catalogues Browsing providing query & download capability for 

mission data products; 

Advertising of preset data subscriptions; 

On-line data products download services, via catalogue view, and status check; 

Automation on the products download activities according to the users subscribed 

datasets; 

Enhanced on-line data-access supporting user-triggered hosted-processing requests 

and management; 

Generating statistics and reports on the most demanded catalogue search requests, 

products requested for download, etc; 

Content publishing management according to available mission documentation 

including Frequently Asked Questions (FAQ); 

Support-Desk available during normal working hours (i.e. 5 days per week and 8 hours 

per day or according to national legislations); 


The MMUS function shall offer anonymous users access to have access to a limited and 

configurable amount of services and information, including the following ones: 

Self-registration capabilities; 

Mission Data Online Catalogues Browsing providing visibility capability according to 

public datasets defined by the HLOP; 

Access to complete and comprehensive information about the Sentinel-2 mission and 

products (e.g. Quality, etc.); 





Advertising of available mission, instruments and products documentation; 




page 132 of 204 

Advertising of available datasets; 

Contact point for Support-Desk, available during normal working hours (i.e. 5 days per 

week and 8 hours per day or according to national legislations) providing information 

for registration services. 


The MMUS function shall allow unregistered users to submit online registration as an 

individual and/or organization nominally without the assistance of any operator. 

(Contact point for Support-Desk will be anyway provided during the registration process to 

handle & support the registration process, if needed). 


The MMUS function shall allow the registered user to login after his/her account has been 

activated and to access all those PDGS services for his/her user type with personalized 

web pages. 


The MMUS function shall allow the operator for user account management purposes, to 

manage and support the handling of the following registered Sentinel-2 Users information: 

Application categories and Project Account typology 

Country and region of the world the user belongs to 

Project Accounts (i.e. typology, status, nationality, eventual remarks, quota, etc) 

Users information (e.g. name, preferred language, etc), including addresses. 

Organization addresses: stores an official organization address (e.g. company, 

university) replicated then for all users belonging to that Organization as a model to 

avoid different wording of the same address 

A user may have more than one address. The addresses are used for mailing/shipment. 


The MMUS function shall allow the operator, for user account management purposes, to 

access to the following functions: 

User Profiles Generation/Updating; 

User Creation (i.e. according to specified/existing profiles); 

User Account Updating (i.e. including profiles updates); 

User Account Deletion; 

Contact registered user by e-mail and/or phone; 

Sending of information to registered user groups through a mailing list service. 








page 133 of 204 


The MMUS function shall allow the operator, in the frame of Support-Desk operations, to 

access the following functionalities: 

Search for similar Sentinel-2 support requests; 

Create a new Support-Desk ticket; 

Route the support request to the Sentinel-2 2nd line expert Support-Desk by email and 

receives its feedback; 

Tracking of Support-Desk calls; 

Searching for Support-Desk Ticket; 

Modifying a Support-Desk Ticket status; 

Resolving a Support-Desk Ticket. 


The MMUS function shall contribute to the GSCDA/CDS advertisement system by 

providing relevant information to the CDS. The needed information shall cover as a 

minimum: 

Generic mission description (i.e. a free text description/abstract covering the main 

features of the satellite mission); 

Summary information about products and instrument; 

Relevant instrument and products documentation (e.g. available products handbooks 

and products description); 

Relevant previews and graphics for illustrating mission products; 

Relevant logos for GCM; 

List of relevant mission products; 

URL of relevant WEB pages (i.e. the address of "definitive" technical Web-site for the 

mission, plus other relevant links). 


The MMUS function shall catalogue all the Sentinel-2 products systematically generated 

and available to users .i.e. S2MSI0, S2MSI1A, S2MSI1B and S2MSI1C. The catalogue 

shall mirror the breakdown of the Sentinel-2 product data in several geographical 

components hereafter referred to as product granules. 


The MMUS function shall be able to populate its catalogue from asynchronous catalogue 

updates (addition or removal) provided by the DAX function and mirroring all the product 

granules available for query and download throughout the PDGS. 


The MMUS function shall be able to populate its catalogue from asynchronous catalogue 

updates (for addition, modification or removal) provided by the DAX function and mirroring 








page 134 of 204 

the contents of the PDGS archives in real-time. The DAX catalogue updates will 

characterise: 

a unique identifier for the granule item to be catalogued 

the availability property on-line, off-line or unavailable (removed) 

the sensing and generation times 

the native dataset association (S2MSI0, S2MSI1A, S2MSI1B, or S2MSI1C) 

a list of key metadata such as satellite identifier, dataset version (processing version), 

usage category (e.g. cal/val, general use, expert, etc), cloud cover percentage over the 

granule area, quality check metadata, etc; 

the geographical footprint of the data; 

the geographical footprint of the cloud-mask; 

the parent-product identifier used for granule to product associations; 


The MMUS function shall be able to process simplified asynchronous catalogue updates 

modifying solely the availability property of the granules (on-line, off-line, unavailable). 


the MMUS function shall be able to ingest Sentinel-2 preview images provided 

asynchronously from the DAX function in geocoded form, time-stamped along the 

Sentinel-2 orbits, and associated globally to all Sentinel-2 datasets (regardless of the 

product-type and granule decomposition). 


The MMUS function shall autonomously compile all ingested preview-image updates in a 

global repository managed via a standard OpenGIS Web Map Server (WMS) with time 

extension. 


The MMUS shall systematically tag the ingestion time of each catalogue entry (granule) in 

the catalogue database. 


The MMUS function shall be able to associate preview-images to the Sentinel-2 granules 

catalogued. 


The MMUS function shall be able to display the preview image relevant to each granule 

over the granule geographical coverage. 









page 135 of 204 


The MMUS function shall allow the operator to configure preset logical datasets 

characterised by a filter on the catalogue data based on: 

product type 

satellite identifier 

sensing date range, including recurring intervals (e.g. summer period) 

age of the data (e.g. older than one day, less than 3 hours, etc) 

geographical region 

average cloud cover 

usage-category (general, expert, cal/val, etc) 

quality control checks (e.g. products showing quality problems can be excluded from 

datasets intended for general users) 

on-line/off-line availability 

dataset version (processing version) 

etc 


The MMUS function shall allow the operator to configure user-dataset associations 

defining for each dataset the users or group of users authorised for access based on their 

user profiles. 


The MMUS function shall allow the authorised users to reuse the authorised preset 

datasets and to customise their own private datasets from the preset ones by specifying a 

second level filter based on: 

satellite identifier 

sensing date range, including recurring intervals (e.g. summer period) 

age of the data (since last day, since last week, etc) 

geographical region 

average cloud cover 

usage-category (general, expert, cal/val, etc) 

quality control checks (e.g. the quality-control operator can monitor the products 

showing quality problems) 

on-line/off-line availability 

dataset version (processing version) 

etc 


The MMUS function shall allow the users to import Area Of Interest (AOI) files to support 

the definition of a geographical region definition for a given product search and download. 








page 136 of 204 

Accordingly it shall be able to import/manage well-supported AOI file formats (typically 

KML polygons, ESRI shape file, etc). 


The MMUS function shall allow the authorised users to navigate inside the catalogue 

through the authorised datasets, narrowing the scope step-wise by selecting filters while 

always being informed about the remaining catalogue population for all not yet selected 

filters. 


The MMUS function shall allow the users to easily discriminate (e.g. visually using a 

colour code) the data available on-line from the data-available with off-line latency. 


The MMUS function shall allow the authorised users to navigate inside the catalogue 

through the authorised datasets and perform Sentinel-2 products pre-visualisation 

activities by display of the corresponding preview images. 


The MMUS function shall support queries on the product(s) availability based on a 

maximum cloud cover percentage of its constituent components (i.e. product granules). 


The MMUS function shall support queries on the product(s) availability based on a 

maximum cloud cover percentage aggregated over the product intersecting the user AOI 

(uncovered portions of the AOI by the product shall be assumed 100% cloudy). 


The MMUS function shall provide functionality to construct optimised cloud-free product 

selections defined by the minimum set of products required to cover a given user area 

within a given maximum cloud-cover threshold and a given time period. 


The MMUS function shall allow the users to download Sentinel-2 products selected in a 

shop-cart from authorised datasets in a selection of product granules listed in groups of 

downloadable user-products. 


The MMUS function shall provide functionality to recover the preview image 

corresponding to the geographical coverage of every product to be downloaded. 


The MMUS function shall allow the users to define product download options including: 







page 137 of 204 

a selection of product components (e.g. spectral bands, standard/expert metadata, 

preview image, auxiliary data, etc) 

a selection of the output format (SAFE or DIMAP) 

an optional extension of the granule selection such that the downloaded products 

contain either (1) the sole granules selected, (2) all granules across the 290km MSI 

swath overlapping the AOI or (3) the full parent product (orbit stripline). 


The MMUS function shall execute the download operations by triggering the Sentinel-2 

specific DAG function client software hosted on the user computer, characterising for each 

download operation: 

the user authentication information (e.g. user credential); 

the parent-product identifier; 

the list of granules to compile; 

the download options (list of product components & format); 

a URL to the preview image or the preview image itself. 


The MMUS function shall allow the users to subscribe to the authorised datasets for 

automatic product(s) download at the user-base. The user shall be able to subscribe from 

one-to-n authorised datasets and be able to receive the products from different 

subscriptions at different sink interfaces. 


The MMUS function shall be able to authorise every product download operation 

performed by the DAG function via an authorisation service invoked at the effective 

download time and to return the user priority for download assigned in the user profile; 


The MMUS function shall systematically record the qualified status provided by the DAG 

function on completion of every download request (volumes downloaded, download 

performance, etc) to allow the periodic generation of data-access statistics. 


The MMUS function shall allow authorised users to trigger hosted-processing requests. 

Accordingly it shall allow the user to define the processing parameters, trigger the 

processing, follow-up the status of the request since the submission until completion, and 

perform the resulting product download. 


The MMUS function shall allow authorised users to trigger, monitor and manage hostedprocessing 

requests via an HMI. 








page 138 of 204 


The MMUS function shall allow the administrator to define and configure new hostedprocessing 

services including their specific HMI using: 

existing functional components (e.g. a catalogue widget for data selection), 

a range of other input fields and widgets (e.g. menus, date/time fields, check boxes, 

etc), 

a widely used and supported programming language (e.g. Ajax, Javascript, etc) to glue 

all items together, create the hosted-processing request based on the input 

parameters, and submit it for execution. 


The MMUS function shall allow the users to subscribe to the authorised hosted-processing 

services for automatic product(s) generation and download at the user-base . 


The MMUS function shall support automated data-driven subscription downloads implying 

that the product download (resp. the hosted-processing service) is triggered automatically 

based on the availability of new products for download (resp. for processing), and 

download options (resp. processing parameters). 


The MMUS function shall support automated time-driven subscription downloads implying 

that the product download (resp. the hosted-processing service) is triggered automatically 

based on a sliding-time window of sensing-time applicable to the selection of new 

products to download (resp. to process), and download options (resp. processing 

parameters). 


The MMUS function shall implement the coordinated GSCDA/CDS catalogue services. As 

such it shall publish the catalogue of PDGS products by implementing the product 

catalogue service mechanisms described in to the CDS/DAIL ICD. 


The MMUS function shall implement the coordinated GSCDA/CDS on-line access 

services. As such it shall provide access to the available production by implementing the 

on-line access service mechanisms described in the CDS/DAIL ICD. 


The MMUS function shall be able to backup totally or partially the Sentinel-2 catalogue 

database according to flexible criteria (e.g. last year catalogued data). 








page 139 of 204 



The MMUS function shall be able to perform the ingestion of catalogue updates for new 

Sentinel-2 product granules at a sustained rate of no less than four granule inserts per 

second in average. 


The MMUS function shall be able to complete within 2 seconds the parallel processing of 

10 simultaneous catalogue requests for the coverage in Level-1B of any area equivalent 

to Europe acquired during one day by the constellation including the time to display the 

query results on the user HMIs. The performance shall be ensured regardless of the 

selected day and the load of the catalogue. 



10 simultaneous catalogue requests for the coverage in Level-1C of any area equivalent 

to Europe acquired during one day by the constellation including the time to display the 

query results on the user HMIs. The performance shall be ensured regardless of the 

selected day and the load of the catalogue. 



10 simultaneous catalogue requests for the coverage in Level-1C of any area equivalent 

to Europe acquired during one month by the constellation including the time to display the 

query results on the user HMIs. 


The MMUS shall be able to complete within 1 minute the parallel processing of 10 

simultaneous catalogue requests corresponding to the cloud free optimised Level-1C 

product selection data over Europe using one month of Sentinel-2A and -2B acquisitions. 


The number of simultaneous catalogue requests which can be supported in parallel with 

the defined performance shall scale linearly by adding additional hardware. 


The MMUS function shall complete within 5 second the parallel processing of 100 

requests for a preview image at 300m resolution, each one covering a different part of the 

earth over an area of 300 km x 300km. 








page 140 of 204 


The MMUS function shall complete within 1 second the parallel processing of 50 different 

product download authorisations. 



The MMUS shall systematically catalogue all the Sentinel-2 product granules generated 

along the mission life-time by the PDGS for the S2A and S2B units. 



The MMUS function shall be deployed and operated locally in the PDMC only. 


The MMUS function shall operate the PDGS first-line Support-Desk and invoke the PDGS 

second-line Support-Desk as needed in support to user enquiries. 


The MMUS function shall systematically ingest and process all catalogue updates 

provided by the DAX function in an unattended and data-driven manner. 


The MMUS function shall provide its nominal services to Sentinel-2 users for the whole 

Sentinel-2 missions lifetimes and for 25 years after the end of the space segment 

operations. 


The MMUS function shall operate autonomously for all catalogue access and automated 

data download operations vis-à-vis the users. 


The MMUS function shall autonomously retry the download operations after failure 

according to a configurable policy (e.g. wait for a configurable amount of time before retry 

and for a configurable maximum number of times). 


The MMUS function shall allow the user to re-attempt one or several failed download 

operations manually. 








page 141 of 204 


The MMUS function shall systematically notify the users on repeated unsuccessful 

download operations providing consistent human understandable messages on the 

source of the problem. 


The MMUS shall generate periodic statistics and reports on the catalogue search 

requests, products requested for download, hosted-processing requests, volumes of data 

delivered, download performance, etc providing a comprehensive view over the dataaccess 

operations performed from the user side. 



The MMUS function shall ensure nominal operations unattended for better than 99.9% of 

the time computed over one month time window and assuming a degradation of such 




The MMUS function shall interface with the PDGS/DAG function according to a welldefined 

ICD to execute product downloads from the PDGS archives down to the userbase. 


The MMUS function shall interface with the PDGS/DAG function according to a welldefined 

ICD to trigger, monitor and control the hosted-processing requests in the PDGS 

infrastructure. 


The MMUS function shall implement a specific service for authorising the download 

operations performed by the DAG function according to the access grants of the user 

effectively triggering the download. 





5.15 On-Line Images Browser (OLIB) Requirements 




page 142 of 204 


S2-PDGS-OLIB-005 

The PDGS/OLIB function shall be responsible for providing on-line and unrestricted user 

access to the collection of True Colour Images (TCI) generated by the PDGS. 


The PDGS/OLIB function shall be able to catalogue all TCIs generated based on the 

catalogue updates provided by the DAX function. 


The PDGS/OLIB function shall be able to download the TCIs from the archive centres by 

making use of the DAG function capabilities. 


The PDGS/OLIB function shall minimize the data-transfer operations to the archives by 

implementing common cache mechanisms. 


The PDGS/OLIB function shall publish the collection of TCI images via a user-friendly 

web-GUI implementing simple human interactions mechanisms allowing intuitive browsing 

actions through simple zoom in/out and navigation capabilities. 


The PDGS/OLIB function shall provide basic filtering capabilities on the data presented for 

visualisation including: 

swift navigation to countries or cities through an simple search index; 

time navigation e.g. though a time slider; 

fast access to cloud-free images according to a cloud threshold. 


The PDGS/OLIB function shall display the geo-location coordinates (latitude and 

longitude) of the images in response to image navigation events (e.g. mouse move, click 

on navigation tool-bar, etc). 


The PDGS/OLIB function shall provide functionality to export images into physical files 

(i.e. JPEG) from a snapshot of the viewing window down to 10 meters spatial resolution. 








page 143 of 204 


The PDGS/OLIB function shall ensure the swift navigation through the visualised images 

with different user-controlled and rapidly changing zoom levels (e.g. by using data 

buffering techniques). 


The PDGS/OLIB function shall allow the users to "navigate in time" over a user-defined 

area showing images in sequence according to sensing time. 


The PDGS/OLIB function shall be able to provide optimised access to the last 3 months of 

Sentinel-2 TCI images scalable with hardware. 



The PDGS/OLIB function shall be able to serve at least 50 independent user sessions in 

parallel. 


The PDGS/OLIB function shall be scalable versus the number of simultaneous users and 

amount of data to be handled in parallel. 



The PDGS/OLIB function application shall be deployed and operated locally in the PDMC, 

accessible remotely by general users via the public internet. 


The PDGS/OLIB function systematically ingest all TCI metadata generated by the DAX 

function to populate the TCI image catalogue. 


The PDGS/OLIB function shall be open to the general public via the WEB and provide all 

the relevant instructions for installation and usage of the service (e.g. internet browser 

plug-ins, client application, user manuals, etc). 


The PDGS/OLIB function shall operate autonomously as triggered by user accesses 

without requiring any operator supervision. 








page 144 of 204 



The PDGS/OLIB function shall ensure nominal operations unattended for better than 





The PDGS/OLIB function shall be designed following a client/server paradigm in which: 

the client side supports the user HMI interactions (world navigation through TCIs 

streaming, TCIs download, filtering by time and location, etc); 

the server side interfaces with the PDGS relevant functions in support of the TCI 

downloads. 


The PDGS/OLIB function client side shall interface with the DAG function to trigger the 

TCI download activities. 


The PDGS/OLIB function server side shall interface with the DAX function to receive the 

TCI catalogue updates. 

5.16 Mission Configuration Control (MCC) Requirements 


S2-PDGS-MCC-005 

The PDGS/MCC function shall centralise all mission configuration control activities of the 

PDGS, covering: 

the definition of configuration files applicable throughout the PDGS; 

the accurate configuration control of all key mission configuration data and operation 

reports hereafter referred to as MRF (Mission Reference Files); 

the conversion of all third-party generated MRFs into a common harmonised format for 

use throughout the PDGS; 

the coordinated release of new or updated MRFs throughout the PDGS and/or external 

interfaces; 

the maintenance along time of the mission configuration and configuration changes. 









page 145 of 204 


The PDGS/MCC function shall be able to keep and maintain under a controlled 

environment all MRFs into a central repository along the mission life-time. 


The PDGS/MCC function shall be able to generate MRF files using ergonomic file edition 

capabilities. 


The PDGS/MCC function shall be able to ingest autonomously and systematically all 

MRFs into the central repository. 


The PDGS/MCC function shall provide archive support for text and binary files. 


The PDGS/MCC function shall systematically extract and tag a reference mission time 

period to all ingested files corresponding to their applicability period along the mission 

timeline. 


The PDGS/MCC function shall systematically tag the time of every MRF file ingestion into 

the repository. 


The PDGS/MCC function shall be able manage the release of MRF updates to all PDGS 

internal and external interfaces (all CGSs, PACs, the FOS, CNES/CST, LGSs, etc) 


The PDGS/MCC function shall classify every type of MRF according to either of two 

release mechanism defined by configuration: 

Mission Reference - Coordinated release (MR-C) 

Mission Reference - Uncoordinated release (MR-U) 

The files configured for MR-C release shall require the operator intervention/approval prior 

to their release (synchronous release). 

The files configured MR-U release shall be released automatically without the operator 

intervention/approval (asynchronous release). 


The PDGS/MCC function shall be able to manage and release the MRFs to a configurable 

list of destination interfaces according to the MRF file type and associated satellite 

identifier when relevant. 







page 146 of 204 


The PDGS/MCC function shall systematically release all MR-U files without operator 

intervention as soon as inventoried. 


The PDGS/MCC function shall allow the operator to release the MR-C files interactively 

through an HMI. 


The PDGS/MCC shall allow the operator to override the reference mission time period of 

the files configured for coordinated release. 


The PDGS/MCC function shall keep track of the release-time of every release in the MRF 

database. 


The PDGS/MCC function shall allow to perform automatic and configurable on-the-fly 

simple processing on the MRF at ingestion time before the file is stored and/or at release 

time. 


The file processing operations to be applied at ingestion and/or release time shall be 

configurable independently by file-type and satellite identifier when relevant and allow: 

file conversion/edition operations such as file renaming, textual transformation, 

compression, decompression, format conversion, repackaging, etc 

basic validation checks, flagging of a validation status in the database and raising of 

alerts to the operator on unsuccessful validations. 


The PDGS/MCC function shall prevent the release of invalidated files. The PDGS/MCC 

shall allow the operator to override this protection. 


The PDGS/MCC function shall prevent the operator from releasing the same MR-C file 

twice. The PDGS/MCC shall allow the operator to override this protection. 


The PDGS/MCC function shall prevent the duplicated release of MR-U files. The 

PDGS/MCC shall allow the operator to override this protection and manually select MR-U 

managed files to be released again. 








page 147 of 204 


The PDGS/MCC function shall identify expired files (i.e. files whose end of its applicability 

is in the past). These files shall be flagged as deprecated. 


The PDGS/MCC shall optionally generate a check-list file on every MR-C release. The 

check-list file shall contain: 

a list of the new files released (sorted by reference time) 

a list of current applicable files (sorted by reference time) 

a list of deprecated files (cancelled or expired ones) (sorted by reference time) 


The PDGS/MCC function shall allow the operator to release any file for tests / contingency 

management to specific interfaces. All selected files shall be released no matter whether 

they would have been delivered previously or deprecated. 


The PDGS/MCC function shall provide query capabilities on the MRF database via an 

HMI allowing to select the MRFs with ingestion/applicability/release times overlapping a 

given time-period with additional filters on the key information maintained in the database 

(validation status, deprecated status, etc) 


The PDGS/MCC function shall be able to generate synthetic reports over user-defined 

time periods on the applicability and release of mission reference files. Reports shall 

provide MRF database extracts with ingestion/applicability/release timings in textual and 

graphical format e.g. a Gantt chart. 


The PDGS/MCC function shall allow the operator to alter the configuration interactively via 

an HMI including: 

The addition of output interfaces (e.g. a new CGS) or file types, or the 

modification/deletion of existing ones; 

The file associations for deployment and deployment policy; 

The configuration of the preliminary processing to be performed at ingestion and/or 

release time. 


The PDGS/MCC function shall make use of a collocated DC function to manage the 

physical transport of the MRF files between their source and their destination interfaces. 








page 148 of 204 



The PDGS/MCC function introduced lag for the ingestion and release activities shall not 

exceed 1 minute from the file availability at the input interface including the time required 

for the optional processing steps during ingestion and/or release. 



The PDGS/MCC function shall be deployed and operated locally in the PDMC only. 


The PDGS/MCC function shall supply status information over all its processes and 


function. 


The PDGS/MCC function shall generate via the operator interface all static or near-static 

PDGS operational configuration data (mission planning configuration, archive retention 

rules, data circulation rules, data-access configurations, QC configurations, POD 

configuration, etc) except the MMUS configurations. 


The PDGS/MCC function shall systematically process all MRFs including: 

all OBCD (MSI configuration parameter tables) released for official use, 

all OGCD (GIPPs, ECMWF auxiliary data, POD products, etc) released for official use, 

all FOS Auxiliary Data (orbit files, manoeuvre files, etc), 

the EDRS GEO pointing information, 

the mission operation plans generated by FOS, PDGS and the EDRS exploitation 

segment (Reference Orbit File, NPPF, PIF, EDRS availability/booking plans, etc), 

all unavailability plans and reports (from EDRS, FOS, ground stations, etc), 

all PDGS configuration data (data circulation rules, data retention rules, data-access 

configurations, etc), 

all operation reports generated throughout the PDGS including unavailability reports, 

the MSI decompression Software, 

etc 








page 149 of 204 


The PDGS/MCC function shall, using its configurable file processing capabilities, 

systematically convert on input all MRFs to be used within the PDGS into ESA's Earth 

Explorer file format for uniform usage within the PDGS. 


The PDGS/MCC function shall autonomously generate a Special Operation Request 

(SOR) form upon release of every OBCD update to the FOS using its configurable file 

processing capabilities. 


The PDGS/MCC function shall receive and process from the FOS the Special Operation 

Request (SOR) confirmation form. The operator shall be alerted at ingestion time in case 

of a rejection by the FOS. 


By default, the PDGS/MCC function shall release all MRFs as MR-U data except all 

critical configuration updates such as the OBCD updates, and configuration items updated 

following major PDGS reconfiguration requiring a coordinated release (e.g. major change 

of operation scenario). 


The PDGS/MCC function shall systematically release to the FOS the NPPF and EDRS 

GEO pointing information (i.e. EDRS GEO predicted orbit characterised by the Chebyshev 

polynomial coefficients). 


By default, the PDGS/MCC function shall release all mission operation plans, 

unavailability plans, unavailability reports and all PDGS operation reports to the MPA 

function for end-to-end mission monitoring and performance assessment. 


The PDGS/MCC function shall generate reports on-demand to the POM on the MRF 

current and historical applicable mission configurations. 



The PDGS/MCC function shall ensure nominal operations unattended for better than 










page 150 of 204 


The PDGS/MCC function shall guarantee the consistency of all ingestion and release 

transactions in case of contingency (e.g. disk full, etc) and restore nominal operations 

once the contingency is solved. 



The PDGS/MCC function shall make use of the PDGS/DC function for the effective 

transportation MRF data between source and destination interfaces. 


The PDGS/MCC function shall make use of widely used public-domain off-the-shelf 

software to perform the on-the-fly file processing operations. 

5.17 Mission Planning (MPL) Requirements 


S2-PDGS-MPL-005 

The PDGS/MPL function shall be responsible for the generation of the Sentinel-2 Mission- 

Plan including the following elements: 

the Image-Acquisition-Plan 

the Downlink-Plan 

the Acquisition-Schedule-Plan (for the ground-stations) 

the EDRS Booking-Plan 


The PDGS/MPL function shall be able to generate a consistent and conflict-free Mission- 

Plans according to: 

the defined observation and calibration activities with associated timeliness constraints 

satellite and payload operation constraints 

on-ground resources 


The PDGS/MPL function shall generate and maintain the reference orbit file for the S2A 

and S2B spacecrafts. 








page 151 of 204 


The PDGS/MPL function shall be responsible of the generation of the ground-stations 

Acquisition-Schedule-Plan (CGS & LGS scheduling for the X-band & Ka-band downlink 

acquisition activities) according the confirmed Mission Plan and final schedule performed 

by the FOS. 


The PDGS/MPL function shall be responsible of the generation of the EDRS Booking-Plan 

according to the OCP operations scheduled by the FOS. 


The Mission-Plans generated by the PDGS/MPL function shall be complete by definition 

of all the satellite and the payload operations required over the planning period. 


the PDGS/MPL function shall be able to optimize the Image-Acquisition-Plan and the 

Downlink-Plan according to the constellation capabilities and available on-ground 

resources. 


The PDGS/MPL function shall be able to generate the complete Mission-Plan 

automatically according to a recurrent configurable schedule (typically every two weeks). 


The PDGS/MPL function shall be able to generate a Mission-Plan with a configurable time 

coverage (e.g. from 24 hours to 60 days). The plan coverage shall be automatically 

extended if required to comply to the constraints defined in the FOS-PDGS ICD. 


The PDGS/MPL function, as part of the Image-Acquisition-Plan generation, shall 

command the MSI and the MMFU (recording activities) according to the operation 

constraints described in the [SOCD] and the operational SSCF provided by the FOS. 


The PDGS/MPL function shall schedule the MSI imaging activities and associated MMFU 

mission data recording activities as part of the Image-Acquisition-Plan generation. 


The PDGS/MPL function shall generate a conflict-free Downlink-Plan wrt the other 

Sentinel Missions. Accordingly it shall be able to manage across Sentinel Missions shared 

resources such as the CGSs, LGSs and the EDRS GEO. 








page 152 of 204 


The conflict-free Downlink-Plan shall plan (OCP) data relay activities to the EDRS GEO 

according to the assigned communication segments to the Sentinel-2 Mission. 


The PDGS/MPL function, as part of the Downlink-Plan generation, shall command the 

MMFU (playback activities), the XBS and the OCP according to the operation constraints 

described in the [SOCD]. 


The PDGS/MPL function, optionally, shall be able to constrain the OCP usage within the 

Downlink-Plan wrt the MSI imaging requests contained Image-Acquisition-Plan. 

Accordingly, when this option is active, it shall not plan any OCP operations during 

planned MSI imaging operations. 


The PDGS/MPL function, optionally shall be able to downlink the same data 

simultaneously through the XBS and OCP systems. 


The PDGS/MPL function shall be able to plan on predefined segments OCP data 

transmission activities without deletion on memory. In order to verify the OCP operations, 

it shall be possible to not delete on the memory the data transmitted. 


The PDGS/MPL function shall be able to plan on predefined segments OCP data 

transmission activities with simultaneous MSI imaging operations. It shall be possible to 

verify the impact (micro vibrations) of OCP operations wrt MSI imaging activities. 


The PDGS/MPL function shall minimise the number of XBS switching cycles when 

generating the Downlink-Plan according to the XBS duty-cycle defined in the [SOCD]. 


The PDGS/MPL function shall schedule the required MMFU playback activities of the MSI, 

satellite ancillary and HKTM data as part of the Downlink-Plan generation. 


The PDGS/MPL function shall characterise all spacecraft/payload operation constraints 

described in the [SOCD] and the operations restrictions that are applicable to the PDGS 

(e.g. on-board systems duty cycles, etc) into the Spacecraft Safety Constraints File. 








page 153 of 204 


The PDGS/MPL function shall ensure a consistent conflict-free Mission-Plan by complying 

with the operation restrictions/constraints provided in the [SOCD] and further detailed in 

the SSCF (e.g. MSI duty cycle, XBS duty cycle, eclipse constraints, etc.). 


The PDGS/MPL function shall alert the operator on any safety constraint violated as part 

of the Mission-Planning generation activities. 


The PDGS/MPL function shall allow the operator to manually configure the SSCF identifier 

to be reported in every Mission-Plan. 


It shall be possible to trace-back the SSCF version used during the Mission-Plan 

generation. 


The PDGS/MPL function shall provide functionality to generate test-plans of any coverage 

(from 24 hours to 60 days) without involving the FOS (e.g. to derive the assessment 

statistics or for investigation). 


The PDGS/MPL function shall be able to generate the Mission-Plan activities referenced 

using Orbit Position Schedule (OPS) time tags nominally. The use of Mission Timeline 

(MTL) time tags shall be possible for specific and seldom TBD requests. 


The PDGS/MPL function shall ensure that all data acquired by the spacecrafts is received 

on ground to at least one ground-station of the defined CGS network. 


The PDGS/MPL function shall ensure that all data downlink operations to ground 

correspond to an effective reception opportunity to a CGS or LGS station using the 

configured azimuth/elevation mask of the ground-stations. 


The Downlink-Plan computed by the PDGS/MPL function shall: 

systematically include a full ancillary data playback at the term of every downlink pass 

to a CGS; 

systematically include a full HKTM playback in parallel to the ancillary data playback 

over CGSs according to the defined Coarse Downlink Budget granted for HKTM 

downlinks. 








page 154 of 204 

playback the priority RT data over coinciding CGSs as driven by the Image- 

Acquisition-Plan; 

use the remaining downlink capacity to playback the non RT data buffered on-board; 

systematically playback the NRT before the nominal data partitions at CGS downlink 

contact segments granted for the reception of NRT data; 

maximise the usage of the CGS downlink budget available to playback the on-board 

recorded data within spacecraft capabilities; 

systematically minimize the age of the MSI data at the time it is received on ground 

considering the above priorities. 


The PDGS/MPL function shall be able to process the Mission-Plan response provided by 

the FOS to acknowledge the scheduling of the requested activities. In case of any 

discrepancy, the MPL function shall alert to the operator accordingly. 


The PDGS/MPL function for the Mission-Plan generation activities shall make use of a 

simplified satellite operation model for data-handling configurable separately per 

spacecraft through the following parameters at minimum: 

the effective MSI data supply rate of each detector after WICOM compression 

the MSI detectors activated 

the MSI data handling granularity 

the sizes of the MMFU MSI packet store, the ancillary packet store and the HKTM 

packet store, 

the X-band and OCP effective downlink rates per each channel 

the S-band effective uplink rate (to estimate the uplink time) (TBC) 


The PDGS/MPL function shall be able to generate the ground-stations (CGS & LGS) 

Acquisition-Schedule-Plan according to the acknowledged Mission-Plan. 


The PDGS/MPL function shall be to notify in advance to every ground station the list of 

required downlink passes according to the Acquisition-Schedule-Plan. 


The PDGS/MPL function shall be able to generate the EDRS Booking-Plan according to 

the acknowledged Mission-Plan. 








page 155 of 204 


It shall be possible to constrain the Mission-Plan generated by the PDGS/MPL function 

according to the following minimum set of parameters configurable separately per 

spacecraft: 

the MSI sensing segment minimum length 

the MSI duty cycle 

the XBS duty cycles 

the OCP duty cycle 

etc 


The PDGS/MPL function shall generate the ground-stations Acquisition-Schedule-Plan 

including recent (daily) orbit information (i.e. predicted orbit file, TLE, etc.) , and time 

segments applicable to the antenna reception and the required front-end processing 

activities. 


The PDGS/MPL function, as part of the Acquisition-Schedule-Plan generation, shall be 

able to manage overlapping CGSs avoiding / minimizing the amount of data duplicated on 

them. 


As part of the Mission-Plan generation activities, the PDGS/MPL function shall make use 

of the spacecraft model to derive the on-board memory usage along the orbit through 

including: 

the sensor data stream volume (compressed or not) deriving from the imaging plan 

and detector/compression configuration 

the MMFU occupation / usage (for nominal and NRT entries, FIFO logic) according to 

the imaging plan and Downlink-Plan 

the MMFU occupation / usage for the HKTM data according to the Downlink-Plan 

the MMFU occupation / usage for the Ancillary data according to the Downlink-Plan 


The PDGS/MPL function shall be able to optimise the Downlink-Plan by delaying when 

appropriate the start of the MSI downlink in order to maximize the volume of data 

transmitted to the ground during the visibility window. This functionality shall be activated 

as an option. 


The PDGS/MPL function shall be able to generate the EDRS effective booking plan to be 

forwarded to the EDRS user-segment according to the acknowledged Mission-Plans. 








page 156 of 204 


The PDGS/MPL function shall be able to characterise the MSI observation/calibration 

campaigns based on the definition and ranking of templates propagated along the 

Mission-Plan time coverage period. 


The MSI observation and calibration request templates shall typically include the following 

parameters: 

rank level (priority) 

a spacecraft unit 

a zone identifier (by daylight or night-time separately) from a zones-database (*) 

a specific MSI acquisition mode as required for calibration activities 

a packet store assignation as RT, NRT or nominal FIFO data 

frequency/repeat cycle 

(*) The zones-database shall associate a shape (polygon, circle) to every zone identifier. 


The PDGS/MPL function shall be able to define the activation frequency for an 

observation/calibration request and propagate it along the orbit repeat cycle. Typical 

activation frequencies supported shall be 'always', 'once/day', 'once/week', 'once/cycle', 

etc. 


The PDGS/MPL function shall be able to automatically constrain the Image-Acquisition- 

Plan to ensure all MSI daylight images are acquired within a configurable seasonal Sun 

Zenith Angle range at the ground target. 


The PDGS/MPL function shall be able to constrain the Mission-Plan activities by the 

processing of the Satellite/Payload unavailability plan. 


The PDGS/MPL function shall be able to constrain the Mission-Plan activities by the 

processing of the EDRS GEO unavailability plan. 


The PDGS/MPL function shall be able to constrain the Mission-Plan and the ground 

stations Acquisition-Schedule-Plan activities by the processing of the ground stations 

(CGS & LGS) unavailability plan. 









page 157 of 204 


The PDGS/MPL function shall be able to apply the required margins to every MSI sensing 

segment ensuring the zone to be imaged is effectively acquired through all spectral bands 

of the MSI detectors, as part of the Image-Acquisition-Plan generation activities. 


The PDGS/MPL function shall support the SPF-PIF planning protocol according to the 

applicable ICDs. 


The PDGS/MPL function shall be able to generate a Mission-Plan with the required 

commanding activities, syntax and semantics according to the applicable ICD settled with 

the FOS. 


The PDGS/MPL function shall be able to generate the EDRS Booking-Plan with the 

required activities, syntax and semantics according to the applicable ICD settled with the 

EDRS exploitation segment. 


The PDGS/MPL function shall allow the operator to characterise the CGS/LGS resources 

allocated for the Sentinel-2 Mission. The CGS/LGS Resources Characterisation file shall 

contain at least for each X-Band and Ka-Band station: 

S2 spacecraft (S2A, S2B or both) 

location 

visibility mask 

precedence order 

reception roles (Nominal, NRT, RT, HKTM, etc) 

etc. 


The PDGS/MPL function shall be able to ingest two distinct databases of constraints 

applicable to the X-Band usage of each satellite and including: 

A list of X-Band Silent Segments: a static pattern of time segments with an N-cycles 

repeatability during which the XBS shall not be operating due to conflicting RF 

simultaneous operations with other Sentinel satellites; 

A list of Station Unavailability Segments: a static pattern of time segments with an N- 

cycles repeatability during which downlink activities to a given ground-station are not 

permitted due to conflicting acquisitions by other Sentinel satellites requiring the station 

resources (e.g. antenna) simultaneously; 

Both databases shall be an external static configuration input to the MPL function 

according to a TBD ICD. 








page 158 of 204 


The PDGS/MPL shall allow the operator to ingest a database of EDRS Availability 

Segments defining the pre-defined availability of the EDRS GEO spacecrafts to relay 

Sentinel-2 OCP downlinks. This database shall be an external static configuration input to 

the MPL function according to a [TBD} ICD. 


The PDGS/MPL function shall be able, as triggered by the operator, to generate the 

Coarse Downlink Budget file for each spacecraft based on the CGS/LGS Characterisation 

file. 


The PDGS/MPL function shall constrain the X-Band usage of the Sentinel-2 satellites 

according to the X-Band Silent Segments database defined for each Sentinel-2 satellite. 


The PDGS/MPL function shall constrain the available ground stations contact segments 

according to the Station Unavailability Segments database defined for each Sentinel-2 

satellite. 


The PDGS/MPL function shall constrain the available OCP-EDRS/GEO contact segments 

according to EDRS Availability Segments database defined for Sentinel-2 satellite. 


The PDGS/MPL function shall be able, as part of mission planning activities, to avoid the 

usage of X-Band station contact with an overall duration below a configurable threshold. 


The PDGS/MPL function shall be able, as part of mission planning activities, to avoid the 

usage of OCP/EDRS contact segments with an overall duration below a configurable 

threshold. 


The PDGS/MPL function shall allow the operator to manually modify the Coarse Downlink 

Budget as desired (e.g. remove some contact segments at the beginning of the day on a 

given CGS or LGS ground-station, etc.) and/or balance the downlink passes associated to 

each spacecraft unit. 


The PDGS/MPL function shall be able to generate relevant summary statistics 

interactively (e.g. min, max, average contact segment length by day/week/cycle) on the 

Coarse Downlink Budget to assess its capabilities and compare it with others. 







page 159 of 204 


The PDGS/MPL function shall be able to command the MMFU ancillary circular packet 

store (re)sizing on-board by configuration. 

(Default satellite ancillary PS sizing may be reduced according to the defined downlink 

strategy). 


The PDGS/MPL function shall be able to command the MMFU HKTM data circular packet 

store (re)sizing on-board by configuration. 

(Default HKTM data PS sizing may be increased/reduced according to the activation of 

HKTM parameters, likely POD ones). 


The PDGS/MPL function shall be able to command the MMFU mission data packet store 

(re)sizing on-board by configuration. 

(Default mission data PS sizing may be modified according to other PS size 

modifications). 


The PDGS/MPL shall define in the NPPF the required on-board platform configuration 

parameters including (TBC): 

MMFU mission data packet store size; 

MMFU satellite ancillary data packet store size; 

MMFU HKTM packet store size. 


The PDGS/MPL function shall be able to generate relevant summary statistics 

interactively (e.g. min, max, average data latency by day/week/cycle, etc.) on the 

generated Mission-Plan allowing the operator to assess every configured Coarse 

Downlink Budget and compare it with others. 


The PDGS/MPL function shall allow the operator to select any valid pre-configured Coarse 

Downlink Budget as input to the manual generation of the Mission-Plan. 


The PDGS/MPL function shall automatically select the configured nominal Coarse 

Downlink Budget for the automatic generation of the Mission-Plan according to its defined 

applicability. 


Imaging request templates managed by the PDGS/MPL function shall be associated to 

either: 








page 160 of 204 

Systematic coverage 

Repetitive coverage by the configuration of acquisition patterns along time (e.g. 

alternate orbits, once/day, once/cycle, just once, etc.). 


It shall be possible to defined or modify relative priorities between imaging requests by 

configuration to give precedence to one with respect to another in case of conflicting 

requests. 


The PDGS/MPL function shall be able to accommodate LGS real-time downlinks in the 

Downlink-Plan according to the following rules: 

After the preliminary Downlink-Plan to the CGS network has been settled, 

opportunities for real-time transmission to LGSs shall be computed for the configured 

LGSs and within the available downlink budget constrained by spacecraft capabilities; 

An ancillary data playback shall systematically be appended at the term of each LGS 

RT downlink operation; 


The PDGS/MPL function shall be able to accommodate LGS real-time downlinks 

optimising the number of LGSs that can be served in parallel. 


The PDGS/MPL function shall be able to balance the real-time downlinks amongst the 

different LGSs following a round-robin strategy. 



The PDGS/MPL function shall be able to generate one Image-Acquisition-Plan for 1 orbit 

cycle (i.e. 10 days/143 orbits) in less than 5 minutes (assuming full land and water 

inbodies acquisition according to the [MRD]). 


The PDGS/MPL function shall be able to generate one Downlink-Plan for 1 orbit cycle (i.e. 

10 days/143 orbits) in less than 15 minutes (assuming 4 CGS and 2 LGS active plus one 

EDRS downlink per orbit). 


The PDGS/MPL function shall be able to generate the complete Mission-Plan (i.e. Image- 

Acquisition-Plan, Downlink-Plan) for 1 orbit cycle (i.e. 10 days/143 orbits) in less than 30 

minutes. 








page 161 of 204 


The PDGS/MPL function shall be able to generate the ground stations daily schedule plan 

to all LGSs and CGSs in less than 2 minutes. 



The PDGS/MPL function shall be deployed and operated locally in the PDMC only. 


The PDGS/MPL function shall supply status information over all its processes and 


function. 


The PDGS/MPL function shall activate and make use of the applicable Mission Reference 

Files received from the MCC function for the operational mission-planning generation 

activities as described in the [OCD] (e.g. EDRS GEO pointing parameters, TLE, Predicted 

Orbits, PIF, etc). 


The PDGS/MPL function shall supply to the MCC the own generated Mission Reference 

Files (e.g. reference orbit file) required by other PDGS elements or external interfaces. 


The PDGS/MPL function shall generate the reference orbit file for S2A and S2B satellites 

according to the Mission File Format. 


The PDGS/MPL function shall supply the reference orbit file for S2A and S2B satellites to 

the MCC for its official release across the federated centres. 


The PDGS/MPL function shall automatically generate the ground station Acquisition- 

Schedule-Plan of every CGS or LGS configured typically every day in advance of the first 

acquisition of the day. 


The PDGS/MPL function shall automatically notify in advance to every ground station the 

list of required downlink passes. The notification time shall be configurable per each 

ground station according to its operations needs. 








page 162 of 204 


The PDGS/MPL function shall automatically generate the Downlink-Plan, and then the 

EDRS Booking-Plan, according to the static EDRS Availability Segments assigned to the 

Sentinel-2 Mission. 


The PDGS/MPL function shall ingest the static EDRS Availability Segments assigned to 

the Sentinel-2 Mission. Note that the EDRS Availability Segments shall be an external 

static configuration input to the MPL function according to a TBD ICD. 


The operator shall be able to switch the PDGS/MPL function at any moment into manual 

mode to perform extra activities (e.g. modify an existing plan, add an ad-hoc calibration) or 

in case of unresolved conflict(s) or a impossible scenario. 


The PDGS/MPL function shall typically plan the downlink of the HKTM data PS whole 

content with on-board memory freed once every orbit according to the downlink template. 

(Typically HKTM downlink shall be assigned to the S-2 European polar stations). 


The PDGS/MPL function shall typically plan the downlink of the satellite ancillary data PS 

whole content without on-board deletion at every opportunity. 


The mission-plan shall typically cover effective 15 days and be generated every two 

weeks. 


The mission-plan shall optionally by configuration include an overlap margin with respect 

to the previous plan of typically 1 day. Accordingly, the mission plan shall cover effective 

15 days plus 1 day back in the past. 


The PDGS/MPL function shall generate and deliver the Mission-Plan at least 3 working 

days before the first activity of the plan according to the PDGS-FOS ICD. 


The PDGS/MPL function shall re-generate and deliver a Mission-Plan in case of 

contingency during the commissioning phase at least 1 working day before the first activity 

of the plan according to the PDGS-FOS ICD. 








page 163 of 204 


The PDGS/MPL function shall constrain the Downlink-Plan activities by the X-Band & 

ground stations time slots assigned to other Sentinels Missions. The S-2 PDGS shall be 

able to share common ground-station resources with the other Sentinel Missions. 


The PDGS/MPL function shall constrain the Downlink-Plan activities by the EDRS GEO 

Availability Segments assigned to the Sentinel-2 Mission. 


The PDGS/MPL function shall provide the Mission-Plan (i.e. the image plan and the 

Downlink-Plan) in a single physical file according to the PDGS-FOS ICD. 


The PDGS/MPL function shall generate the ground station schedule plan using the most 

accurate orbit information available. 


The PDGS/MPL function shall generate the ground stations schedule plan (data reception 

and processing events) individually per each involved ground station. 

(AOS, LOS, FEP start processing, FEP stop processing events, etc. shall be separated 

per each involved station). 


The PDGS/MPL function shall generate a local report on every manual or automatic 

planning activity triggered. 


The PDGS/MPL function shall alert the operator on the failed automatic plan generation 

activities through M&C capabilities. 



The PDGS/MPL function shall ensure nominal operations unattended for better than 




The PDGS/MPL function shall ensure that the all the satellite / payload commanding 

activities are fulfilling the Spacecraft Operations Constraints defined in [SOCD]. 








page 164 of 204 



The PDGS/MPL function shall make use of ESA's "Mission CFI" for all the required orbit, 

visibilities, pointing, etc, computations. 


The PDGS/MPL function shall make use of the DC function for all file transfer 

communications versus other elements (i.e. MCC function). 

5.18 Mission Performance Assessment (MPA) Requirements 


S2-PDGS-MPA-005 

The PDGS/MPA function shall be responsible within the PDGS for monitoring if mission 

requirements are being fulfilled by the PDGS and to trigger corrective actions in case of 

anomaly. The PDGS/MPA function shall covers the following activities: 

Calibration and Validation 

Off-line Quality Control 

End-to-end System Performance Monitoring 

Instrument Data and Quality Control Processors Verification 


The PDGS/MPA function shall be able to perform Calibration and Validation (Cal/Val) 

activities with the multiple scope of: 

update the MSI on-board configuration (e.g. NUC table); 

update the MSI on-ground processing (e.g. GIPP) configuration; 

identify the need of new MSI calibration requests (e.g. vicarious calibration); 


The PDGS/MPA function shall be able to identify the MSI production generated as part of 

calibration requests (e.g. absolute radiometric, vicarious calibration, etc.) to assess the 

MSI performance and identify the potential need of new calibration requests. 


The PDGS/MPA function shall be able to perform Off-line QC activities with the multiple 

scope of 

monitoring if product quality requirements are being met along the mission life-time; 

monitor the MSI and platform performance throughout the mission life-time; 








page 165 of 204 

calculate the MSI performance and accuracy trends based on the production quality 

indicators and quality checks; 

identify the need of new Cal/Val activities; 


The PDGS/MPA function shall be able to perform End-to-End System Performance 

monitoring and report accordingly with the multiple scope of: 

assessing the effectiveness of the mission plan with respect to coverage revisit targets 

(e.g. cloud-free coverages) 

monitoring and assessing the PDGS performances with respect to well-defined service 

quality targets; 

highlighting the PDGS dysfunctions and characterising their impact on the PDGS 

performance; 

monitoring and assessing the overall end-to-end mission performance; 

highlighting the overall Sentinel-2 system dysfunctions at space and ground-segment 

levels and characterising their impact on the mission performance. 


The PDGS/MPA function shall be able to receive, ingest and process all the data 

circulated from the distributed PDGS centres to perform its tasks. This includes: 

product-data covering image data or metadata (e.g. QIs, quality-checks, etc) 

generated either via the IDP or OLQC functions; 

all operation reports generated throughout the various PDGS functions applicable to 

end-to-end performance assessment e.g. processing reports (from the DPC, IDP or 

OLQC functions), archiving reports (AI function), data-circulation reports (DC function), 

DAX reports, etc. 


The PDGS/MPA function shall be able to verify the IDP processors from the functional, 

quality and processing performance viewpoints and verify compliance with the applicable 

DPM. 


The PDGS/MPA function shall be able to verify the OLQC processors from the functional, 

quality and processing performance viewpoints. 


The PDGS/MPA function shall be able to define the OLQC function configuration in terms 

of the different checklist definitions and quality control checks to be applied on the 

production. 









page 166 of 204 


The PDGS/MPA function shall be able to provide comprehensible quality reports on the 

outcome of all Cal/Val, Off-line QC and End-to-End System Performance activities. 


The PDGS/MPA function activities and reporting shall be focussed towards minimising the 

time to investigate and recover from anomalies. 


The PDGS/MPA function shall be able to generate status reports that summarize the 

overall performance of the PDGS System and every individual function covering a user 

defined time-window and generated with regular frequencies (i.e. daily, N-day cyclic) and 

by on-demand triggering. 


Whenever possible, the PDGS/MPA function shall include in the quality-reports a 

proposed solution for correcting anomalies identified (e.g. trigger Cal/Val activities to 

update on-ground configuration parameters or to perform the verification of a new IPF 

version). 


The generated reports shall present a consistent and coherent structure providing a 

harmonised look & feel to ease the reading and comprehension. In addition, according to 

configuration, they shall be generated in the respective format(s) adequate for the on-line 

publishing, distribution and local visualisation and printing (e.g. on-line HTML page, 

downloadable PDF, etc). 


The PDGS/MPA function shall be able log all the automated activities (i.e. activities 

performed without the presence of the operator) via the PDGS/M&C function). 


The PDGS/MPA function shall be able to generate quality-reports with contents and 

format compliant with the applicable CDS/SCI interface, providing comprehensive 

information on the overall quality of the Sentinel-2 products and Data-Sets. 


The PDGS/MPA function shall be able to generate a processor verification report and/or 

anomaly reports in output of all IDP function verification activities. 


The PDGS/MPA function shall implement clear interfaces with human operators for all notautomatic 

tasks. 







page 167 of 204 


The PDGS/MPA function shall be able to manage a multi-satellite configuration (2A, 2B, 

etc). 



The PDGS/MPA Cal/Val function shall be able to generate the entire payload on-board 

and on-ground processing calibration parameters within 1 working-day. 


The PDGS/MPA Off-Line Quality Control function shall generate the complete daily report 

related to the last 24 hours processed production within less than 3 hours. 


The PDGS/MPA Off-Line Quality Control function shall generate the N-cyclic reports 

(covering 6 months – 18 cycles) in less than one day. The quality control checks and the 

analysis activities performed for the N-cyclic reports shall be mainly based on the 

summary of the daily quality reports. 


The PDGS/MPA function shall generate the end-to-end system daily performance report, 

which summarises the last 24 hours of the PDGS operations, in less than one hour. 



The PDGS/MPA function shall be deployed and operated locally in the MPAC and 

supported by remote or collocated Expert Cal/Val teams for specific functions. 


The PDGS/MPA function shall operate the PDGS second-line expert Support-Desk in 

support to the first line Support-Desk and responsible for answering to specific 

investigations on the product quality and PDGS overall performance. 


The PDGS/MPA function shall receive from the Off-Line POD Service the POD precise 

orbit products and POD reports. 


The PDGS/MPA function forward the OBCD and OGCD configuration updates for 

coordinated deployment throughout the PDGS and to the FOS via the MCC function. 








page 168 of 204 


The PDGS/MPA function shall communicate to the MPL function all specific instrument 

operations required to perform Cal/Val activities (calibration requests). 


The PDGS/MPA function shall automate as far as possible the performed operations. 

Operator interaction shall be reserved to system maintenance, configuration and to 

specific tasks requiring expert interaction, or to a very specific analysis. 


The PDGS/MPA function shall perform all not-automatic tasks related to Cal/Val activities 

and requiring specific expertise via the services of Cal/Val Expert teams. 


The PDGS/MPA function shall perform all automatic Cal/Val tasks in a systematic and 

data-driven manner as cascading from the specific image acquisitions commanded on the 

instrument via the MPL function. 


The PDGS/MPA function shall automatically check the correctness of all the auxiliary data 

required by the processing chain (e.g. the GIPPs including DEM and GRI). 


The PDGS/MPA function shall update on need basis the on-ground processing 

configuration as result of the performed Cal/Val activities. The level-0/1 processors 

configuration such as the GIPPs (e.g. GRIs, DEM, configuration, etc) shall be fine tuned 

according to the Cal/Val activities. 


The PDGS/MPA function shall update on need basis the satellite/payload on-board 

configuration as result of the performed Cal/Val activities, including: 

IPS (7) 

TCM-SBY 

TCM-NOM 

NUC 

FEE 


The PDGS/MPA function shall ensure the coherency between the on-board configuration 

(OBCD) and the on-ground configuration (OGCD) with respect to processing baseline. 








page 169 of 204 


The PDGS/MPA shall deliver the following satellite/payload on-board configuration as 

complete tables in SPF format according to the syntax and semantics defined in the 

applicable ICD settled with the FOS: 

IPS 

TCM-SBY 

TCM-NOM 

FEE 


The PDGS/MPA function shall manage all the IPS tables allocated on-board, one per 

each MSI imaging mode. 


The PDGS/MPA function shall deliver the NUC as the complete table in OBSM format 

according to the syntax and semantics defined in the applicable ICD settled with the FOS. 


The PDGS/MPA function shall deliver the updated MSI on-board configuration to the MCC 

for its official release. The MSI on-board tables shall be provided to the MCC with the 

desired activation time. 


The PDGS/MPA function shall gather and manage the entire payload on-ground and onboard 

configuration updates generated externally to the MPAC by either: 

CNES/CST during the phase-E1 of the missions according to the CNES-PDGS ICD, 

Expert Cal/Val Teams (e.g. post launch office, space segment industry, MSI experts, 

etc) as required during phase-E1 and phase-E2 of the missions. 

Accordingly it shall perform the required format conversion activities, if any, to adapt the 

received configuration to the formats used in the ground-segment, and forward them when 

needed to the MCC function for configuration control and deployment. 


The PDGS/MPA function shall acknowledge the expected on-board uplink/activation time 

to verify the effects of the updated configuration. 


The PDGS/MPA function shall be able to perform interactive requests for HKTM data 

retrieval (packets or engineering parameters) to the FOS EDDS. In case of anomalies and 

problem investigation activities, the operator shall be able to perform interactive requests 

for the HKTM data required (web based access provided by the EDDS). 








page 170 of 204 


The PDGS/MPA function shall be able to submit batch requests for HKTM data retrieval 

(packets or engineering parameters) to the FOS EDDS. HKTM parameters needed for the 

Cal/Val, end-to-end performance, auxiliary processing activities, etc shall be requested for 

batch delivery from the EDDS. In such manner the data obtained shall be automatically 

included in the input data flows of the previous named activities. 


The PDGS/MPA function shall be able to analyse the on-board MMFU memory usage 

evolution wrt to the planning cycle definition. According to the analyse results, it shall be 

possible to optimise the packet store sizes of the mission data, ancillary data and HKTM. 

The MPA shall rely on the EDDS for the retrieval of the required memory usage 

parameters contained in the HKTM. 


The PDGS/MPA function shall perform all automatic Off-line QC and End-to-End 

Performance Monitoring activities in a systematic manner. 


The PDGS/MPA function shall systematically forward to the MCC function the updated onground 

or/and on-board configuration parameters resulting from the Cal/Val activities. 


The PDGS/MPA function shall supply valid auxiliary data needed for the processing 

activities including any auxiliary data gathered from outside the PDGS (e.g. GRIs supplied 

by a Cal/Val centre). Accordingly all the auxiliary data shall be checked wrt to the 

applicable format. 


The PDGS/MPA function shall make use of a local processing infrastructure including AI, 

DPC, IDP and OLQC functions to perform all IPF verification or anomaly investigation 

tasks. 


The PDGS/MPA function shall access the MMUS function for product data-access 

activities as required by Cal/Val or QC activities. 


The PDGS/MPA function shall mechanically perform Off-line QC activities at regular 

configurable intervals such as to guarantee the timely identification of any instrument or 

product quality anomaly. 









page 171 of 204 


The PDGS/MPA function shall support the expert teams on the specific QC analysis 

activities and as such providing the necessary image visualisation, manipulation and 

transformation tools. 


The PDGS/MPA function shall mechanically perform End-to-End System Performance 

monitoring activities daily to guarantee the timely identification of any anomaly in the 

PDGS functioning, performance or configuration. 


The PDGS/MPA function shall accept investigation requests from the POM, carry out the 

investigation, and systematically return back an investigation report in response. 


The PDGS/MPA function shall accept updates of the mission quality targets from the POM 

and adapt the QC and Cal/Val operations accordingly. 


The PDGS/MPA function shall provide quality-reports to the POM regularly. 

(recurrent quality control reports include: (1) Daily cyclic quality reports, (2) N-day cyclic 

reports) 


The PDGS/MPA function shall provide quality-reports to the CDS/SCI regularly via the 

MCC function in electronic format according to the applicable CDS/SCI interface. 

(recurrent quality control reports include: (1) Daily cyclic quality reports, (2) N-day cyclic 

reports) 


The PDGS/MPA function shall regularly provide quality-reports to the PDGS first-line 

Support-Desk operated by the MMUS function for on-line publishing to the users. 

Recurrent quality control reports include: (1) Daily cyclic quality reports, (2) N-day cyclic 

reports, (3) specific announcements. 


The PDGS/MPA function shall accept anomaly investigation requests from the MMUS 

function or the CDS/SCI Support-Desks, performing the verification activities and 

systematically return back an investigation report for each accepted request. 


The PDGS/MPA function shall accept processor verification requests from the RP 

function, perform the verification activities and systematically return a processor 







page 172 of 204 

verification report to the RP function stating its readiness for operational usage in the 

PDGS, and/or anomaly reports. 


The PDGS/MPA function shall autonomously gather and manage quality reports 

generated by the POD function (i.e. the on-board navigation solution accuracy reports, 

POD products, etc.) and incorporate them into the mission end-to-end reports. 


The PDGS/MPA function shall monitor the PDGS end-to-end performance providing a 

complete and comprehensive view at system level over the performed activities and 

detected malfunctions. 


The PDGS/MPA function shall monitor the performance of the mission planning chain. It 

shall compare the MSI requested activities for observation and calibration contained in the 

mission plan wrt the scheduled activities by the FOS. Accordingly it shall highlight any 

rejection. 


The PDGS/MPA function shall monitor the performance of the Sentinel-2 PDGS X-Band 

acquisition chain. It shall compare the acquired data time coverage wrt to the scheduled 

data downlink and detect potential gaps on the received and reconstructed data. 


The PDGS/MPA function shall monitor the performance of the PDGS production chain in 

order to detect potential anomalies on the mission data processors (L0,L1A,L1B,L1C). 

Accordingly it shall detect potential gaps in the production by comparing the expected and 

generated production timeline. 


The PDGS/MPA function shall monitor all the data circulation activities amongst every 

PDGS centre and towards the external interfaces. Accordingly it shall monitor the 

availability and connectivity of every electronic interface configured in the PDGS. 


The PDGS/MPA function shall monitor the on-ground configuration and associated 

auxiliary data circulation, their availability at every PDGS centre and verify the usage of 

the applicable version(s) for the related PDGS activities. 


The PDGS/MPA function shall monitor the proper applicability and activation of the onboard 

and on-ground configuration. Accordingly it shall check the on-board and on-ground 








page 173 of 204 

configuration coherency used during the MSI sensing and product generation activities 

and alert on any miss-alignment. 


The PDGS/MPA function shall monitor the PDGS archive completeness and performance. 

Accordingly it shall compare the generated production wrt the archived production and 

detect potential inconsistencies. 


The PDGS/MPA function shall monitor the production availability and accessibility to the 

users. Accordingly it shall compare the archived production wrt the available production 

offered to the users through the CDS/DAIL and MMUS function. 


The PDGS/MPA function shall monitor the production availability and accessibility 

timeliness wrt the sensing time and the downlink mode (nominal, NRT and RT). 

Accordingly it shall check whether the production was available according to the 

timeliness required. 


The PDGS/MPA function shall monitor the MSI SWIR detectors performance wrt expected 

accuracy and established quality thresholds for the generated production. Such monitoring 

shall allow the expert teams to understand the need to activate the MSI decontamination. 


The PDGS/MPA function shall identify the MSI data acquired simultaneously to OCP 

operations and accordingly assess the quality of the generated production. The MPA shall 

support the potential qualification of MSI and OCP simultaneous operations by the 

assessment of the micro vibrations effects on the geometric accuracy. 


The PDGS/MPA function shall recognize and identify the images acquired during eclipse 

to avoid unnecessary alerts on the generated production. 



The PDGS/MPA function shall ensure the coherency and integrity of all the payload 

configuration parameters generated and delivered as result of the performed QC and 

calibration activities. 








page 174 of 204 


The PDGS/MPA function for all the automatic and systematic performed activities shall 

ensure nominal operations unattended for better than 99.0% of the time computed over 

one month time window and assuming a degradation of such figure for no more than one 

day. 



The PDGS/MPA function shall maximize the automation of recurrent tasks. Operator 

interaction shall be reserved typically to system maintenance, configuration, specific 

expert analysis, etc. 


The PDGS/MPA function shall for non Sentinel-2 specific functions (e.g. End-to-End 

System Performance Monitoring) be based on reusable elements to the maximum extent 

to minimize development, training and transfer to operations effort. 


The PDGS/MPA function shall cope with any update on the Sentinel-2 Products 

specifications without the need of any system upgrade beyond re-configuration. 


The PDGS/MPA function shall be designed to be expandable via plug-ins to a core 

automated infrastructure. The core infrastructure shall provide a set of core services 

including data ingestion, data management, data processing, plotting, report formatting 

and overall process automation. Accordingly it shall be possible to integrate new plug-ins 

making use of the core services according to a well-defined ICD. 


The PDGS/MPA function shall be able to integrate new analysis functions with limited 

effort. 


The PDGS/MPA function shall be based when possible on open and free COTS (e.g. 

existing image manipulator and transformation, plots generation, format converters, etc). 


The PDGS/MPA function shall be conceived to minimize the number and costs of 

commercial licenses required in operation (e.g. IDL, Matlab, etc.). 








page 175 of 204 

5.19 Reference Platform (RP) Requirements 


S2-PDGS-RP-005 

The PDGS/RP function shall be able to simulate the PDGS behaviours in parts or as a 

whole by way of a simplified local instance acting as a reference image of the deployed 

PDGS instance. As such, it shall be equipped and manned specifically in order to: 

Support the IV&V Phases of the PDGS; 

Support problem investigations during OSV, Phase-E1 and Phase-E2 of the 

spacecrafts as required by the corrective-maintenance activity; 

Support the qualification phase of all PDGS system upgrades before deployment as 

required by maintenance or evolution activities; 

Support the PDGS deployment phases of the initial and upgraded versions in 

configuring and assembling the deployed-configuration elements to be deployed. 


The PDGS/RP function shall be able to demonstrate the successful implementation of all 

the PDGS individual functions and their correct integration to compound the PDGS as a 

complete System. 


The PDGS/RP function shall be able to manage the PDGS hardware and software 

configuration control, system anomaly management, system validation and transfer to 

operation activities as required for maintenance and evolutions along the mission lifetime. 


The PDGS/RP function shall be able to simulate the PDGS behaviours in parts or as a 

whole by way of a simplified local instance acting as a reference image of the whole 

PDGS System. 


The PDGS/RP function according to its role shall provide and make use of appropriate 

system management tools: 

A hardware inventory system for registering and ad-hoc reporting on the hardware 

configuration of all PDGS distributed centres; 

A software configuration and control environment for managing all PDGS sub-system 

software (i.e. source code repository, SW version maps for each centre, SW packages 

installers creation, etc.); 

A repository for the different sub-systems (i.e. virtualised images) that compose the 

different PDGS versions/centres; 








page 176 of 204 

A documentation management system for maintaining all operation and maintenance 

documentation such as user and installation manuals, test plans, operational 

procedures, training documents, etc; 

A system anomaly management tool for registering all problem occurrences at System 

level and managing their accurate propagation to sub-system maintenance actions and 

ensuring backtracking capabilities down to system requirements. 


The PDGS/RP function shall be able to integrate all PDGS sub-systems (but excluding the 

specific non replicable ones such as antennas) and shall be capable of swift configuration 

into their actual physical implementation in centre layouts, simulating all operational 

interfaces between centres and external interfaces, such as the FOS, the CDS, LGS, etc. 


The PDGS/RP function shall be able to cope with the fact that a given sub-system can be 

deployed in different centres. As such, the RP function shall be able to manage different 

configurations when mirroring a given centre. 


The PDGS/RP function shall be able to run simultaneously in two distinct configurations 

(each configuration corresponding to different versions of the PDGS). 


The PDGS/RP function shall be transportable to any European location, and as such it 

shall be clearly qualify and quantify the associated site installation requirements (e.g. 

required power resources, cooling, workplace, connectivity requirements, etc). Then, the 

RP function shall be taken into account for the HW and SW items inventory and a specific 

Installation Manual shall be provided. 


It shall be possible to remotely operate the PDGS/RP function from any authorised sites 

(e.g. ESRIN). 


The PDGS/RP shall be provided with all necessary tools and log capabilities to perform 

anomaly detection and investigation. 


The PDGS/RP shall be able to support the generation of pseudo-automatic test execution 

records, their storage and management for later on investigation activities. The RP 

function shall provide the necessary mechanisms and tools to analyze the results of the 

performed tests (tests records and sub-system outcomes). 








page 177 of 204 


The PDGS/RP shall be able to trace the test execution records by means of a Test 

Analyser, and then accordingly provide statistics about completion of tests and the 

references to the items to be tested. 


The PDGS/RP shall be able to support PDGS end-to-end integration, verification and 

validation test campaigns (e.g. prior to deployment). 



The PDGS/RP shall be able to reconfigure the Reference Platform in any centre 

configuration in not more than half a day of work. 



The PDGS/RP shall be able to provide the historical reporting on the system baselines 

changes, traceability with reported/corrected anomalies (and possibly to the affected 

system requirements) as well as traceability along time of the configuration changes 

throughout system baseline evolutions. 


The PDGS/RP shall support the training of the PDGS operations teams taking advantage 

of its simulation and operational rehearsal capabilities. 


The PDGS/RP shall allow the configuration manager to perform the required hardware, 

software, documents, anomalies, etc. inventory activities (e.g. register/retrieve hardware 

configuration). 


The PDGS/RP shall support the preliminary activities to the following OSV activities: 

Compatibility tests 

Integration tests 


It shall be possible to reconfigure the PDGS/RP function by receiving from the operational 

PDGS Mission Control Configuration (MCC) function the mission configuration required as 

reference for testing and validation activities. 








page 178 of 204 


The PDGS/RP documentation management function shall keep under configuration and 

control all the PDGS operations, testing and maintenance documentation such as user 

manuals, installation manuals, test plans, operational procedures, training documents, etc. 


The PDGS/RP function shall make the PDGS documentation easily accessible to distant 

operators located in the PDGS operational centres. 


The PDGS/RP function anomaly management system shall host all problem and non 

conformity occurrences, managing their accurate propagation to sub-system maintenance 

actions and ensuring backtracking capabilities down to system requirement. 


The PDGS/RP function shall be used to deliver verified and validated PDGS releases as 

System and related sub-systems to every PDGS centre. 


The PDGS/RP function shall be able to interface with the PDGS centres, for 

troubleshooting, test data exchange and software deployment activities, by using a secure 

network access (e.g. SSH, SFTP). 



The RP function shall ensure that all releases of PDGS software/applications/data are free 

from viruses or other malicious code. 



The PDGS/RP function shall optimise the required hardware and infrastructure needs 

while allowing assessing the deployed PDGS performances by extrapolation. 


The PDGS/RP function shall make use of virtualisation techniques to reduce the number 

required HW platforms and ease the deployment and configuration activities. Accordingly 

the different virtualised images mapping to the different sub-systems shall be kept under 

configuration management. 








page 179 of 204 


The PDGS/RP function shall allow an incremental and gradual build-up, by integrating 

new versions of the PDGS subsystems when they become available, including elements 

provided as CFI. As such, HW resources allocated to the RP function shall be added and 

integrated when required. 


The PDGS/RP function shall rely on the MCC function from the maintenance and ad-hoc 

supply of the mission reference configuration to configure the platform and run the tests. 


The PDGS/RP function shall composed by hardware items identical or compatible to a 

large extent with the ones of the operational PDGS including middleware configurations. 

The RP hardware shall allow extrapolating the deployed operational performances. 


The PDGS/RP function shall be designed and conceived to reuse at the maximum extent 

widely market solutions for all system management support functions dedicated to system 

inventory, repository control system (e.g. GIT, SVN, CVS, etc), documentation 

management (e.g. InfoTrove, KnowledgeTree, etc) and system anomaly management 

(e.g. Jira, Mantis, Bugzilla, RedMine, etc). 


The PDGS/RP function support elements (i.e. system inventory, repository control system, 

etc.) shall be based on the open-source widely used and well proven solutions when 

possible and as such minimizing the licenses costs associated. 

5.20 Monitoring & Control (M&C) Requirements 


S2-PDGS-M&C-005 

The PDGS/M&C function shall be able to monitor the PDGS physical resources (i.e. HW, 

network links, etc.) correct behaviour according to expected threshold ranges (e.g. free 

disk space thresholds). 


The PDGS/M&C function shall be able to monitor the execution of other PDGS functions, 

as such monitoring their key processes to assess in real time their working status. 









page 180 of 204 


The PDGS/M&C function shall be able to provide the operator with real-time monitoring 

information over the PDGS centre and its sub-systems functioning, in terms of hardware 

resources available (e.g. network, CPU, memory, disk space, etc.), key processes 

running, and overall activity status of every sub-system. 


The PDGS/M&C function shall be able to monitor the execution of the other PDGS 

functions, as such monitoring their key processes to assess in real time their working 

status. 


The PDGS/M&C function shall be able to provide to the operator a central log 

management and visualisation capability gathering all log messages from other PDGS 

functions (i.e. M&C log console). 


The PDGS/M&C function gathered / delivered logging messages fields shall fully qualify 

the source process, severity of the message, date of event, etc. 


The PDGS/M&C function shall provide the operator with log messages viewing 

(configurable display/hiding of log fields) and filtering (by field values) capabilities (i.e. 

M&C log console shall provide various filtering capabilities operating on the different log 

message fields). 


The PDGS/M&C function shall provide the operator with log message filtering, sorting and 

grouping capabilities for log visualisation activities (e.g. M&C log console shall be able to 

sort the messages by the source PDGS function). 


The PDGS/M&C function shall provide the operator with a comprehensive control panel 

that allows clear understanding on monitored items status (e.g. network links connectivity, 

CPU usage, etc.). 


The PDGS/M&C function shall provide a comprehensive control panel that allows clear 

understanding on deployed PDGS functions status. 


The PDGS/M&C function shall provide the mechanisms and methods to the other PDGS 

functions to raise alarms in case of fatal errors. 







page 181 of 204 


The PDGS/M&C function shall notify alarms to the operator by different configurable 

means (e.g. by email, SMS, etc). 


The PDGS/M&C function shall autonomously derive and maintain statistics on the 

monitored items observed parameters (e.g. total downtime, average downtime, etc). 


The PDGS/M&C function shall provide functionality to generate cyclic reports based on 

the generated statistics (e.g. weekly reports on network downtime events, disk usage 

evolution on the last 5 days, etc). 


The PDGS/M&C function shall make use of standard protocols for data exchange 

purposes (e.g. SNMP, SMTP, SSH, HTTP, SMS, etc.). 



The PDGS/M&C function artefacts and provided elements (e.g. log messages library) 

deployed in support of the other PDGS functions shall never consume more than 1% of 

the CPU and memory resources available. 



The PDGS/M&C function shall be deployed and operated locally in all PDGS centres. 


It shall be possible to deploy the PDGS/M&C function in a collaborative CDAM centre for 



The PDGS/M&C function shall minimize operator manual intervention to sole critical event 

acknowledge. 








page 182 of 204 



The PDGS/M&C function shall ensure availability better than 99.7% computed over one 

month time window and assuming a degradation of such figure for no more than one day. 

Availability is applicable to all M&C components (i.e. agents, console, etc). 



The PDGS/M&C function shall be designed to allow effortless integration of the M&C 

agents within other PDGS functions. (Capacity to deploy M&C agents in different 

platforms, logging services to other PDGS function shall be supported in different 

platforms, etc.). 


The PDGS/M&C function shall support all the PDGS functions for monitoring information 

gathering and log reporting. Accordingly it shall supply the client logs management 

libraries to the other PDGS functions designs. 


The PDGS/M&C function design solution shall allow swift configuration, customisation on 

the desired information displayed and associated visualisation widgets (e.g. memory 

consumption evolution shall be displayed in a 2-D graphical X-Y widget). 


The PDGS/M&C shall reuse extensively existing well proven open-source solutions for 

each performed activity (e.g. log4j logs libraries, chainsaw log console, others). 


The PDGS/M&C shall provide log messages supply mechanisms for usage and 

integration within other PDGS functions (i.e. log messages management libraries). 

5.21 Data Communication Requirements 


S2-PDGS-NET-005 

The PDGS shall embed Data Communications functions in support to all other functions. 

This includes: 









page 183 of 204 

Local connectivity systems/hosts located within each centre/facility (Local Area 

Network, LAN) 

Geographical connectivity between all the PDGS centres (Data Circulation Network, 

DCN) 

Geographical connectivity between the PDMC (PDGS Data Management Centre) and 

the FOS located at ESA/ESOC in Darmstadt (Germany) (FOS Circulation Network, 

FCN) 

Geographical connectivity between some PDGS centres and the final users for data 

dissemination purposes (Data Dissemination Network, DDN) 

Geographical transportation of physical media between PDGS centres, including 

media procurement shipment and recycling between centres (Media Circulation 

Network , MCN) 

Voice communication facilities across PDGS centres (Voice Communication Network, 

VCN). 

The LAN, DCN, FCN, and DDN are hereafter referred to as the PDGS Network. 


The PDGS Network shall rely on commercial-of-the-shelf (COTS) devices. compliant with 

the following standards: 

IEEE 802.3-2008 

TCP/IP protocol suite as standardised by IETF. 


The LAN shall support 100/1000 Base T interfaces and 10 Gigabit Ethernet interfaces for 

special cases (in compliancy with the current Ethernet standard IEEE 802.3-2008). 


The DCN shall provide additional connectivity via the EDRS data-repatriation multicast link 

and as such comply to its applicable TX and RX interfaces. 


The DDN shall provide additional connectivity via the EDRS data-dissemination broadcast 

link and as such comply to its applicable TX and RX interfaces. 


The DCN, FCN and DDN network functions shall be able to support Quality of Service 

techniques for differentiating and prioritizing high-priority traffic. 


The PDGS Network functions shall provide a set of auxiliary ICT network services aimed 

to ensure the necessary connectivity and security services, such as: 







page 184 of 204 

Email service 

NTP service 

Proxy service 

DNS. 


The PDGS Network functions shall provide a centralized and integrated Network service 

support, consisting of: 

Service desk 

Network monitoring 

Problem resolution 

Change management and implementation 

Maintenance 

Permanent on-call operational service 

Reporting (to be detailed) 

HW/SW maintenance with a minimum time of intervention of 4 hours in main EU cities, 

during the working days (TBC) 


The PDGS Network functions shall provide appropriate means for monitoring and control 

in order to quickly identify any problems, which may arise in the network. 


The PDGS Network functions shall allow monitoring of physical network activities and 

manage incident cases, if any. 


The PDGS Network functions shall allow monitoring of ongoing operations, system status, 

load and performance of each site, providing real-time and historical monitoring tools. 



The LAN shall provide the following Performance figures: 

Throughput: TBD 

Packet jitter: TBD 

Packet loss: TBD 

Latency: TBD 

Round trip delay: TBD 






The DCN shall provide the following Performance figures: 

Throughput: TBD 

Packet jitter: TBD 

Packet loss: < 10-4 over a 24-hour period (TBC) 

Latency:




page 186 of 204 


The MCN operations shall be operated on a 8 hours / 5 working days basis (TBC) 


The PDGS Network and VCN communications shall perform autonomously on a 24 hours 

/ 7 working days basis. 


The PDGS Network functions shall perform the real-time and historical monitoring of the 

status, load and performance of the physical network infrastructure in the different centres 

and across centres, including the analysis of source of non-authorised traffic. 



The LAN shall provide the following Availability and reliability figures: 

Availability: 99,95% (TBC) 

Max Time To Repair: TBD 

Mean time between failures: TBD 

Comment: the evaluation is based on the assumption that the Sentinel 2 PDGS network 

delivers a minimum of 99.5% availability end-to-end measured over a period of one year. 


The DCN, FCN and DDN shall provide the following Availability and reliability figures: 

Availability: 99.6% (TBC) 

Max Time To Repair:




page 187 of 204 

5.21.5 NETWORK SECURITY REQUIREMENTS 


The PDGS LAN, DCN, and FCN functions shall be secured against unauthorized access 

from the public Internet. 


The PDGS WAN function shall ensure that remote external access to a selected pool of 

PDGS elements is possible for warranty support or maintenance purposes only. 


The PDGS WAN function shall ensure that it is possible to deactivate external access 

used for warranty support or maintenance purposes when not required for warranty, 

maintenance or diagnosis purposes. 



The DCN and DDN network topology shall be designed as an IP Full-Meshed or partially 

meshed Network. 


All PDGS Data Communication functions shall be based on public or private off-the-shelf 

services. 


The design of the PDGS Data Communication functions shall allow an upgrade of the 

WAN link infrastructure (e.g. change of network operator) within the operational lifetime of 

the PDGS, with impact limited to network static configuration. 


The design of the PDGS Data Communication functions shall prevent the quality of 

service brought by a given communication function of being degraded by the traffic 

handled by the other communication functions. 


The PDGS Network shall be upgradeable to offer full redundancy/diverse routing at least 

for the links between the PDGS X-Band Core Ground Stations and the PDGS centre(s) 

within 1 month. 








page 188 of 204 


Where redundancy is required for data-communications, the PDGS Network function shall 

meet all requirements with selection of either the prime or redundant paths. 


The design of the PDGS Network infrastructure shall minimize the operational costs of the 

WAN links. 








page 189 of 204 

APPENDIX-A PDGS REQUIREMENTS SEMANTIC AND 

FORMAT 

The PDGS requirements are presented through the following convention: 

 

 

Requirement Identifier under the form S2-PDGS-FFF-NNN, where 

FFF is a sub-class of requirements (e.g. the function Acronym); 

NNN is a three digits progressive number inside each sub-class. 

Requirement Description: Free text 

The following language definitions are used to specify a GMES Sentinel-2 PDGS 

requirement: 

 

 

 

 

SHALL is used to indicate a mandatory requirement 

SHOULD indicate a preferred alternative, but it is not mandatory 

MAY indicate an option 

WILL indicates a statement of fact or intention 

The verification method by TEST shall be preferred, unless one of the other methods can 

be established at acceptable level of confidence while being cost and schedule effective. 

The requirements are organized in different categories or classes according to the 

following table. 

Requirement Category / Class 

Description 

This requirement class describe WHAT the PDGS shall 

perform to satisfy its objectives. 

Functional 

In this sense the functional requirements capture the 

intended behaviour of the PDGS system. This behaviour 

may be expressed as services, tasks or functions the 

system is required to perform 

Performance 

This requirement class describe those PDGS 

requirements that typically quantify the operational value 

of other (functional) requirements. Performance 

requirements are often a numeric value assigned to the 

requirement, or even more typically have a relationship 

between two or more requirements 








page 190 of 204 


Operational 

Description 

This requirement class includes those entire PDGS 

requirements that describe HOW the PDGS shall 

perform each previously identified functionalities (e.g. via 

dedicated interfaces, automatically, through specific 

operating modes and states, etc). In this sense these 

requirements shall define how the operability of the 

PDGS shall be. 

This requirements class refers to those PDGS 

requirements that shall define: 

Reliability, Availability, 

Maintainability and Safety 

(RAMS) 

Sizing 

Interface 

• How long must a PDGS system function under 

normal and abnormal conditions? Minimum times 

(Minutes, hours, days) should be specified as to 

how long the system should operate before 

incurring downtime, reboots, or going off-line 

(RELIABILITY) 

• Length of time the PDGS system should be ready 

for use is in-service, or operational. Often it is 

specified as a percentage of time during a given 

interval. Can also specify or point to what actions 

to take if the time or percentage drops below that 

level (call maintenance, issue a report, etc.) 

(AVAILABILITY) 

• Types and level of maintenance (User, Level 1, 

Field, preventative, and manufacture) should be 

defined as well as distribution method for 

updates, who will perform the maintenance, and 

any documentation required (related to 

documentation requirements). Others include time 

between repairs, time to repair, and any warranty 

information (MAINTENANCE) 

• Those qualities the system must have to ensure 

safety of the PDGS system. These include 

rounded edges, grounding, hazardous materials, 

noise levels, and all the hazards and faults that 

could threaten PDGS safety (SAFETY) 


requirements that impose on the PDGS design & 

capabilities sizing constraints (e.g. volume of data to be 

stored, acquired along mission lifetime, etc. etc.) 


requirements that provides specifications for each 

identified interface the PDGS may have towards the 

external world. 








page 191 of 204 


Security 

Design and Development 

Description 


requirements that identify security issues the PDGS shall 

cope with during the design, development and 

operational phase. 


requirements that define the design constraints the 

PDGS shall comply with during the design and 

development phase 

Table 5-1 PDGS Requirements Classes 








page 192 of 204 

APPENDIX-B PDGS TRACEABILITY REQUIREMENT MATRIX 

(TRM) 

The sources of requirements for the PDGS System Requirements Document (SRD) are 

highlighted in the following figure. 

GMES 

EOP-G 

Sentinel-2 

Project 

GSC G/S 

Phase-B 

DAP/R 

INSPIRE 

EO 

PDGS 

reqs 

MRD 

SPACE SEGMENT 

SRD 

GSRD 

PDHT 

ICD 

MMFU 

ICD 

MSI 

ICD 

PUS 

(…) 

FOMs 

GMES 

Product 

Harmonisa 

tion 

Guidelines 

GPP 

Specifications 

S2G 

ICD 

SOCD 

DPMs 

Product 

Def 

GIPP 

Def 

Budgets 

Mission 

Analysis 

Report 

Sentinel-2 

Product 

Definition 

Guideline 

s 

NORMATIVE 

Sentinel-2 PDGS 

INFORMATIVE 

Level-2 

Prototype 

SRD 

OCD 

MICD 

PDD 

STBD 

STCD 

L2 

Product 

Def 

L2A 

ATBD 

L2 

Auxiliary 

Data Def 


Figure 5-1: sources of the SRD requirements 

This appendix provides the GMES Sentinel-2 PDGS Traceability Requirement Matrix to 

the following applicable requirement documents: 

○ GMES Sentinel-2 Mission Requirements Document [ND-1] 

○ DAP-R Requirements [ND-3] 

○ GMES Sentinel-2 GSRD [ND-2] 

○ EO-PDGS Requirements [ND-8] 







page 193 of 204 

SRD Requirement MRD DAP-R GSRD EO-PDGS 

S2-PDGS-SYS-005 MR-S2-23 GSR-PDGS-GEN-010 

GSR-PDGS-ACQ-010 

GSR-PDGS-PRO-010 





PDGS-FUN-0095 


S2-PDGS-SYS-010 GSR-PDGS-SIZ-040 PDGS-FUN-0105 



S2-PDGS-SYS-015 GSR-PDGS-MPL-080 PDGS-FUN-0105 







GSR-PDGS-MPL-080 


GSR-PDGS-PER-050 

GSR-PDGS-GEN-010 


GSR-PDGS-SIZ-040 












S2-PDGS-SYS-080 MR-S2-12 GSR-PDGS-PER-100 PDGS-FUN-0065 







S2-PDGS-SYS-100 GSR-PDGS-GEN-010 PDGS-FUN-0155 



GSR-PDGS-INT-040 

















page 194 of 204 


S2-PDGS-SYS-130 GSR-PDGS-SIZ-052 PDGS-FUN-0070 




S2-PDGS-SYS-140 GSR-PDGS-DIS-011 PDGS-FUN-0070 



S2-PDGS-SYS-165 MR-S2-23 GSR-PDGS-GEN-010 












GSR-PDGS-ORD-030 









S2-PDGS-SYS-205 GSR-PDGS-DIS-010 PDGS-FUN-0045 
















PDGS-ILS-0005 












page 195 of 204 










GSR-PDGS-MON-120 









MR-S2-15 

MR-S2-16 

MR-S2-17 

MR-S2-19 

MR-S2-21 

MR-S2-22 








S2-PDGS-SYS-320 GSR-PDGS-MON-100 PDGS-FUN-0195 
















S2-PDGS-SYS-370 GSR-PDGS-GEN-010 PDGS-FUN-0085 





















page 196 of 204 









GSR-PDGS-RPR-020 

GSR-PDGS-ARC-020 










PDGS-HFR-0010 

PDGS-OPS-0025 

S2-PDGS-SYS-480 GSR-PDGS-GEN-020 PDGS-OPS-0015 









S2-PDGS-SYS-495 MR-S2-13 GSR-PDGS-SIZ-010 PDGS-FUN-0170 

S2-PDGS-SYS-505 MR-S2-09 GSR-PDGS-SIZ-010 PDGS-FUN-0200 
















PDGS-HFR-0005 










page 197 of 204 


S2-PDGS-SYS-615 MR-S2-02 LMCS_001 

LMCS_009 

LMCS_010 

LMCS_012a 

LMCS_003 

LMCS_006c 

S2-PDGS-SYS-620 MR-S2-02 LGSE_001 

LGSE_003 



ERSS_001a 

ERSS_002a 

ERSS_005 

ERSS_006b 

ERSS_007b 

ERSS_010c_ 

LDS&SPT 

ERSS_010c_ 

SPT 

ERSS_011a 

ERSS_019 

ERSS_022 

EGSE_001 

EGSE_002 

EGSE_003 

EGSE_004 

EGSE_007 

EGSE_009 

EGSE_012 

EGSE_013 

EGSE_014 

EGSE_017 

EGSE_021 

EGSE_023 

EGSE_026 

EGSE_027 

EGSE_031 

EGSE_032 

EGSE_033 

EGSE_035 

EGSE_036 

EGSE_037 

EGSE_039 








page 198 of 204 




SEC_002 

SEC_002a 

SEC_002b 

SEC_003a 

SEC_003b 

SEC_004a 

SEC_004b 

SEC_004c 

SEC_007a 

SEC_008a 

SEC_008b 

MGSE_012 

MOS_001 































PDGS-INT-0005 










page 199 of 204 
























S2-PDGS-SYS-670 GSR-PDGS-INT-010 PDGS-FUN-0165 























S2-PDGS-SYS-750 MR-S2-03 GSR-PDGS-RAM-010 PDGS-PAS-0005 




PDGS-PAS-0020 








page 200 of 204 




























GSR-PDGS-SEC-010 


















GSR-PDGS-RAM-011 















page 201 of 204 






















































GSR-PDGS-CIR-010 








page 202 of 204 




















GSR-PDGS-CIR-010 



























MR-S2-11 















page 203 of 204 






























































page 204 of 204 














































END-OF-DOCUMENT

GSC Sentinel-2 PDGS SRD - emits - ESA

Create successful ePaper yourself

Delete template?

Save as template?