GSC Sentinel-2 PDGS OCD - Emits - ESA

document title/ titre du document 

PACE 

OMPONENT 

ENTINEL AYLOAD ATA 

ROUND 

EGMENT 

PERATIONS 

OCUMENT 

ONCEPT 

prepared by/préparé par 

Sentinel-2 PDGS Project Team 

reference/réference 

GMES-GSEG-EOPG-TN-09-0008 

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 TN 

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 OCD 

issue 1 revision 2 (draft) - 25.07.2010 


page ii of xxii 

A P P R O V A L 

Title 

Titre 

GMES Space Component - Sentinel-2 Payload Data issue 

Ground Segment (PDGS) - Operations Concept 

issue 

Document (OCD) 

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 of the document implementing the 1 1 25.06.2010 

PDGS-SRD RIDs. 

Updated baseline as per ngEO operation 1 2 (draft) 25.07.2010 

scenarios 








page vii of xxii 

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

1 INTRODUCTION ................................................................................................30 

1.1 Purpose ...........................................................................................................................30 

1.2 Background......................................................................................................................30 

1.3 Scope...............................................................................................................................32 

2 DOCUMENTATION............................................................................................35 

2.1 Normative Reference Documents....................................................................................35 

2.2 Informative Reference Documents ..................................................................................35 

2.3 Acronyms.........................................................................................................................38 

2.4 Definitions ........................................................................................................................45 

2.5 Document Overview.........................................................................................................46 

3 SENTINEL-2 MISSION OVERVIEW ..................................................................47 

3.1 Mission Objectives...........................................................................................................47 

3.2 Mission Data Users..........................................................................................................48 

3.3 Sentinel-2 Constellation and Mission Lifetime .................................................................48 

3.4 Orbit Characteristics ........................................................................................................49 

3.5 Space Segment ...............................................................................................................50 

3.5.1 Sentinel-2 Spacecraft Overview................................................................................50 

3.5.2 Multi-Spectral Instrument Characteristics .................................................................51 

3.5.2.1 Spectral Performance Characteristics ...............................................................51 

3.5.2.2 Measurement Geometry....................................................................................52 

3.5.2.3 Measurement Data Handling.............................................................................54 

3.5.2.3.1 Data-Rate and On-Board Data Compression.................................................54 

3.5.2.3.2 Scene Packaging ...........................................................................................55 

3.5.2.3.3 Measurement Datation ...................................................................................55 

3.5.2.4 On-Board Configuration.....................................................................................55 

3.5.2.5 Calibration Shutter Mechanism..........................................................................56 

3.5.3 Positioning, Attitude and Measurement Datation......................................................56 








page viii of xxii 

3.5.4 Data Recording and Downlink Characteristics..........................................................56 

3.5.4.1 Data Downlink in X-Band...................................................................................56 

3.5.4.2 Data Downlink via EDRS/OCP ..........................................................................57 

3.5.4.3 Data Recording and Playback ...........................................................................57 

3.5.5 Scheduling................................................................................................................58 

3.5.6 Commanding and Control.........................................................................................58 

3.6 Ground-Segment .............................................................................................................59 

3.7 Mission Evolution with EDRS...........................................................................................59 

3.7.1 Review of EDRS Planned Services for GMES .........................................................59 

3.7.2 Expected EDRS Usage for Sentinel-2 Mission Evolution .........................................60 

3.8 Management....................................................................................................................62 

4 PDGS OPERATION BASELINE ........................................................................64 

4.1 Assumptions ....................................................................................................................64 

4.2 Operation Context............................................................................................................66 

4.2.1 Management.............................................................................................................66 

4.2.1.1 HLOP Implementation .......................................................................................66 

4.2.1.2 Data-Access Management ................................................................................67 

4.2.2 Interfaces..................................................................................................................67 

4.2.3 GMES Space Component Data-Access (GSCDA) ...................................................69 

4.2.4 Sentinel-2 Flight Operation Segment (FOS) .............................................................69 

4.2.5 Centre National d’Études Spatiales (CNES).............................................................70 

4.2.6 Core and Collaborative PDGS..................................................................................71 

4.2.7 Local Stations ...........................................................................................................71 

4.3 Operation Constraints and Drivers...................................................................................71 

4.3.1 General Mission Operation Constraints ....................................................................72 

4.3.1.1 Mission Data Products.......................................................................................72 

4.3.1.2 Mission Data Volumes.......................................................................................72 

4.3.1.3 Data Policy ........................................................................................................72 

4.3.2 Programmatic Drivers & Constraints.........................................................................73 

4.3.2.1 Commissioning Phase.......................................................................................73 

4.3.2.2 Mission Evolutions.............................................................................................74 








page ix of xxii 

4.3.2.2.1 Spacecraft Phase-in .......................................................................................74 

4.3.2.2.2 EDRS Phase-in ..............................................................................................74 

4.3.2.3 PDGS Physical Layout and Evolutions..............................................................75 

4.3.2.4 Evolutions through Third-Party Collaborations ..................................................75 

4.3.2.5 Local Station Network........................................................................................75 

4.3.3 GMES-Driven Operation Constraints........................................................................76 

4.3.4 GSCDA Operation Constraints .................................................................................76 

4.3.5 Lessons Learnt .........................................................................................................77 

4.3.5.1 General Returns of Experience .........................................................................77 

4.3.5.2 Long-Term Data Preservation ...........................................................................77 

4.3.5.3 Landsat On-Line Data-Access Experience at USGS.........................................77 

4.3.5.4 G-POD Experience at ESA................................................................................78 

4.3.6 Technology Evolution Drivers ...................................................................................79 

4.3.7 FOS Operation Constraints ......................................................................................81 

4.3.7.1 Mission Schedule Uplink and Mission Planning Loop........................................81 

4.3.7.2 MSI Parameter Tables Uplink............................................................................82 

4.3.7.3 HKTM Delivery Constraints ...............................................................................82 

4.3.8 Spacecraft Operation Constraints.............................................................................82 

4.3.8.1 MSI Detectors Parallax......................................................................................83 

4.3.8.2 MSI Data Downlink Discontinuities ....................................................................83 

4.3.8.3 MSI Duty Cycle..................................................................................................85 

4.3.8.4 X-Band Operation Constraints...........................................................................85 

4.3.8.5 Asynchronous Management of Ancillary and MSI Data.....................................85 

4.3.8.6 OCP Operation Constraints...............................................................................86 

4.3.8.7 Constraints not implemented by the PDGS .......................................................86 

4.3.9 MSI Data Processing Constraints.............................................................................86 

4.3.9.1 Radiometry Processing Constraints ..................................................................86 

4.3.9.2 Geometry Processing Constraints .....................................................................87 

4.3.9.2.1 Image Datation ...............................................................................................87 

4.3.9.2.2 Band Co-Registration Constraints ..................................................................88 

4.3.9.2.3 Spatial Registration ........................................................................................88 








page x of xxii 

4.3.9.2.4 Resampling ....................................................................................................89 

4.3.9.2.5 Digital Elevation Model...................................................................................89 

4.3.9.3 Data Compression versus Data Quality Trade-Off Constraints .........................90 

4.3.10 Constraints and Dependencies driven by the CGS network .....................................90 

4.3.10.1 Near-Real-Time Data Timeliness ......................................................................90 

4.3.10.2 Real-Time Data Timeliness ...............................................................................92 

4.3.10.3 Data Accessibility ..............................................................................................93 

4.3.10.4 X-Band Downlink Conflicts between Sentinel Missions .....................................94 

4.3.10.5 Contact Overlap Management Constraints........................................................95 

4.3.11 Constraints and Dependencies driven by the EDRS Exploitation Segment..............95 

4.4 Data Products ..................................................................................................................96 

4.4.1 Product Portfolio .......................................................................................................96 

4.4.2 User Product Concept ..............................................................................................98 

4.4.3 Data-Set Subscription Concept ................................................................................99 

4.4.4 Product Quality .......................................................................................................100 

4.4.4.1 Level-1C Quality Baseline ...............................................................................100 

4.4.4.2 Prototype Level-2A Quality Baseline ...............................................................101 

4.4.5 Product Timeliness .................................................................................................101 

4.4.6 Product Retrieval Latency.......................................................................................102 

4.5 Mission Operation Concepts..........................................................................................104 

4.5.1 High-Level Concepts ..............................................................................................104 

4.5.1.1 Multi-Spacecraft Operations ............................................................................104 

4.5.1.2 Systematic and Data-Driven PDGS Operations ..............................................104 

4.5.1.3 PDGS Automation ...........................................................................................104 

4.5.1.4 Centre Operation Autonomy and Federative Data-Access Concept................105 

4.5.1.5 Scalability and Flexibility regarding Data-Timeliness.......................................107 

4.5.1.6 Long-Term Data Preservation .........................................................................108 

4.5.1.7 Operational Redundancy and Contingency Handling Concepts......................108 

4.5.2 Data Access Concepts ...........................................................................................109 

4.5.2.1 Product Data Handling and Data-Access Strategy ..........................................109 

4.5.2.2 Data-Access Interfaces ...................................................................................111 








page xi of xxii 

4.5.2.2.1 ESA’s Multi-Mission User Services (MMUS) Portal......................................111 

4.5.2.2.2 CDS/DAIL Interface......................................................................................112 

4.5.2.2.3 On-Line Public Access to Sentinel-2 True Colour Images............................112 

4.5.2.2.4 DAG Interface...............................................................................................113 

4.5.2.3 Registration & Access Grants..........................................................................114 

4.5.2.4 Support Desk...................................................................................................115 

4.5.3 Mission Support Operations ...................................................................................115 

4.5.3.1 Mission Planning and Scheduling....................................................................115 

4.5.3.1.1 Mission Planning & Scheduling Loop with the FOS......................................115 

4.5.3.1.2 EDRS/OCP Scheduling................................................................................116 

4.5.3.1.3 PDGS Downstream Planning and Scheduling Operations ...........................117 

4.5.3.2 Mission Performance Monitoring and Control Operations ...............................117 

4.5.3.3 Mission Configuration Control Operations .......................................................118 

4.5.3.3.1 General Principles ........................................................................................118 

4.5.3.3.2 Coordinated MSI Configuration Control........................................................119 

4.5.4 Core Mission Operations ........................................................................................119 

4.5.4.1 On-Board Sensor Acquisition ..........................................................................119 

4.5.4.1.1 MSI Acquisition.............................................................................................119 

4.5.4.1.2 Ancillary Data Acquisitions ...........................................................................122 

4.5.4.2 Core Mission Data-Recovery On-Ground........................................................122 

4.5.4.2.1 Problem Logic ..............................................................................................123 

4.5.4.2.2 MSI Packet-Store Management ...................................................................126 

4.5.4.2.3 Ancillary-Data Packet-Store Management ...................................................132 

4.5.4.2.4 On-Ground Data Reception..........................................................................132 

4.5.4.3 Real-Time Data Downlinks to Local Stations...................................................133 

4.5.4.3.1 Planning Strategy .........................................................................................133 

4.5.4.3.2 LGS Scheduling ...........................................................................................134 

4.5.4.4 Level-0 Data Processing Operations ...............................................................135 

4.5.4.5 Level-0 Consolidation and Level-1 Data Processing Operations.....................135 

4.5.4.5.1 Level-0 Consolidation and Level-1 Processing Logic ...................................136 

4.5.4.5.2 Level-1 Processing Context and Datastrip Processing.................................140 








page xii of xxii 

4.5.4.5.3 Level-1A and Level-1B Processing ..............................................................141 

4.5.4.5.4 Level-1C Processing ....................................................................................144 

4.5.4.6 Level-2 Data Processing Operations ...............................................................147 

4.5.4.7 On-Line Quality Control Operations.................................................................147 

4.5.4.8 Reprocessing Operations ................................................................................148 

4.5.4.8.1 Reprocessing Campaign Scenario ...............................................................148 

4.5.4.8.2 Reprocessing after Nominal Processing Contingency..................................149 

4.5.4.9 Data Archiving and Circulation Operations......................................................149 

4.5.4.9.1 Data Archiving Operations............................................................................150 

4.5.4.9.2 Data Circulation Operations .........................................................................150 

4.5.4.10 Cal/Val Operations ..........................................................................................151 

4.5.4.10.1 MSI Decontamination .................................................................................151 

4.5.4.10.2 Level-1 Radiometry Cal/Val Operations .....................................................152 

4.5.4.10.3 Level-1 Geometry Cal/Val Operations........................................................156 

4.5.4.10.4 Level-2 Cal/Val Operations.........................................................................157 

4.5.5 X-Band HKTM Mission Operations.........................................................................158 

4.5.6 PDGS End-to-End Operations................................................................................159 

4.6 System Maintenance and Evolution Concepts...............................................................160 

4.6.1 Reference-Platform.................................................................................................160 

4.6.2 System States and Configurations..........................................................................161 

4.6.2.1 System States .................................................................................................161 

4.6.2.2 System Configurations ....................................................................................162 

4.6.3 Operational Transfer Baseline Approach................................................................163 

4.6.4 Sentinel Units Phase-In Approach..........................................................................163 

4.6.5 EDRS Phase-In ......................................................................................................165 

4.6.5.1 Commissioning of EDRS Capabilities with Sentinel-2 .....................................165 

4.6.5.1.1 Data-Relay Link............................................................................................166 

4.6.5.1.2 Data-Repatriation Link..................................................................................166 

4.6.5.1.3 Data-Dissemination Link...............................................................................167 

4.6.5.2 Operational Transfer........................................................................................167 

4.7 Network and Security Concepts.....................................................................................167 








page xiii of xxii 

4.7.1 Security...................................................................................................................167 

4.7.2 Network Infrastructure ............................................................................................168 

4.8 Collaborative PDGS Concepts.......................................................................................169 

4.8.1.1 Collaborative Data-Access Mirroring Centres..................................................170 

4.8.1.2 Hosted Processing Collaboration Opportunity.................................................170 

4.9 PDGS Operation Layouts ..............................................................................................173 

4.9.1 Baseline Operation Layout .....................................................................................174 

4.9.2 Enhanced Operation Layout with EDRS.................................................................175 

4.9.3 Alternative Operation Layouts with EDRS ..............................................................178 

4.10 PDGS Services Portfolio................................................................................................179 

4.10.1 Services to PDGS Stakeholders.............................................................................179 

4.10.1.1 Sentinel-2 User Services .................................................................................179 

4.10.1.1.1 Service Users .............................................................................................179 

4.10.1.1.2 Service Characteristics...............................................................................180 

4.10.1.1.3 Service Dependencies and Constraints .....................................................182 

4.10.1.1.4 Triggering Mechanism and Interface ..........................................................182 

4.10.1.2 Interface Service to CDS/DAIL ........................................................................182 

4.10.1.2.1 Service Users .............................................................................................182 




4.10.1.3 Coverage Interface Service to CDS/SCI..........................................................183 

4.10.1.3.1 Service Users .............................................................................................183 




4.10.1.4 Performance Reporting Service to CDS/CQC .................................................183 

4.10.1.4.1 Service Users .............................................................................................184 











page xiv of xxii 

4.10.1.5 Sentinel-2 X-Band Real Time Data Access Service ........................................184 

4.10.1.5.1 Service Users .............................................................................................184 




4.10.1.6 Sentinel-2 True Colour Images On-Line Publishing Service............................185 

4.10.1.6.1 Service Users .............................................................................................185 




4.10.1.7 Housekeeping Data Distribution Service to FOS.............................................185 

4.10.1.7.1 Service Users .............................................................................................185 




4.10.2 Sentinel-2 Collaborative PDGS Services................................................................186 

4.10.2.1 Collaborative Data Mirroring Centre Integration Service .................................186 

4.10.2.1.1 Service Users .............................................................................................186 




4.10.2.2 Hosted Processing Service..............................................................................187 

4.10.2.2.1 Service Users .............................................................................................187 




4.10.3 Sentinel-2 Mission Support Services ......................................................................191 

4.10.3.1 Data Access Control Service...........................................................................191 

4.10.3.2 Mission Control Service...................................................................................191 

4.10.3.2.1 Mission Configuration and Planning ...........................................................192 

4.10.3.2.2 PDGS HW/SW Maintenance & Configuration Control................................192 








page xv of xxii 

4.10.3.2.3 Mission Performance Assessment .............................................................193 

4.10.3.2.4 Collaborative PDGS Management Support Service ...................................193 

4.10.3.3 Data Factory Operations Service.....................................................................193 

4.10.3.4 Long-Term Data Preservation Service ............................................................194 

5 PDGS DESIGN.................................................................................................195 

5.1 Overall Design Logic......................................................................................................195 

5.2 Functional Model ...........................................................................................................196 

5.2.1 Design Logic...........................................................................................................196 

5.2.2 Functional Breakdown ............................................................................................196 

5.2.2.1 Data Management Functions...........................................................................197 

5.2.2.1.1 Core Objective..............................................................................................197 

5.2.2.1.2 Design Drivers..............................................................................................197 

5.2.2.1.3 Breakdown ...................................................................................................199 

5.2.2.2 System Control Functions................................................................................202 



5.2.2.2.3 Breakdown ...................................................................................................203 

5.2.2.3 Data Communication Functions.......................................................................205 



5.2.2.3.3 Breakdown ...................................................................................................206 

5.2.3 Data Management Functions..................................................................................207 

5.2.3.1 Data Reception (DRX) Function ......................................................................207 

5.2.3.1.1 Function Objectives and High-Level Description ..........................................207 

5.2.3.1.2 Design Drivers and Constraints....................................................................207 

5.2.3.1.3 Function Interfaces.......................................................................................208 

5.2.3.2 Data Processing Control (DPC) Function ........................................................208 




5.2.3.3 Instrument Data Processing (IDP) Function ....................................................210 








page xvi of xxii 




5.2.3.4 MSI Decompression Software (MDS) Function ...............................................211 




5.2.3.5 On-Line Quality Control (OLQC) Function.......................................................211 




5.2.3.6 Archive & Inventory (AI) Function ....................................................................212 




5.2.3.7 Long-Term Archive (LTA) Service Function.....................................................214 




5.2.3.8 Data Circulation (DC) Function........................................................................215 




5.2.3.9 Precise Orbit Determination (POD) Function...................................................216 




5.2.3.10 Auxiliary Data Supply (ADS) function ..............................................................217 

5.2.3.10.1 Function Objectives and High-Level Description ........................................217 

5.2.3.10.2 Design Drivers and Constraints..................................................................217 

5.2.3.10.3 Function Interfaces.....................................................................................217 








page xvii of xxii 

5.2.3.11 Data-Access Index (DAX) Function .................................................................217 




5.2.3.12 Data Access Gateway (DAG) Function ...........................................................219 




5.2.3.13 Multi-Mission User Services (MMUS) Function ...............................................220 




5.2.3.14 On-Line Image Browser (OLIB) Function ........................................................222 


5.2.3.14.2 Design Drivers............................................................................................222 


5.2.4 System Control Functions.......................................................................................223 

5.2.4.1 Mission Configuration Control (MCC) Function ...............................................223 




5.2.4.2 Mission Planning (MPL) Function ....................................................................224 




5.2.4.3 Mission Performance Assessment (MPA) Function.........................................226 

5.2.4.3.1 Function Objectives......................................................................................226 



5.2.4.4 Monitoring & Control (M&C) Function..............................................................227 









page xviii of xxii 



5.2.4.5 Reference Platform (RP) Function...................................................................228 




5.2.4.6 Collaboration Support Service (CSS) Function................................................230 




5.2.5 Data Communication Functions..............................................................................232 

5.2.5.1 Local Area Network (LAN) Function ................................................................232 




5.2.5.2 Digital Circulation Network (DCN) Function.....................................................233 




5.2.5.3 Media Circulation Network (MCN) Function.....................................................234 




5.2.5.4 FOS Communication Network (FCN) Function................................................234 




5.2.5.5 Data Dissemination Network (DDN) Function..................................................235 











page xix of xxii 

5.2.5.6 Voice Communication Network (VCN) Function..............................................236 




5.3 Physical Model...............................................................................................................237 

5.3.1 Design Logic...........................................................................................................237 

5.3.2 Centre Design.........................................................................................................237 

5.3.2.1 Core Ground Stations (CGS)...........................................................................238 

5.3.2.2 Processing/Archiving Centres (PAC)...............................................................239 

5.3.2.3 Mission Performance Assessment Centre (MPAC) .........................................240 

5.3.2.4 Payload Data Management Centre (PDMC)....................................................242 

5.3.2.5 Auxiliary Centres .............................................................................................243 

5.3.3 Collaborative/User Sites Layouts............................................................................244 

5.3.3.1 Collaborative Data-Access Mirror (CDAM) ......................................................244 

5.3.3.2 User Sites Layouts for Data Access ................................................................244 

5.4 Baseline Operation Layout.............................................................................................245 

6 DETAILED OPERATIONS CONCEPTS ..........................................................247 

6.1 Data Reception (DRX) Operations.................................................................................247 

6.1.1 Operation Constraints.............................................................................................247 

6.1.1.1 Multi-Sentinels X-band Data Reception Conflicts ............................................247 

6.1.1.2 Sentinel-2 S/C Constellation Concurrent Operations.......................................247 

6.1.2 Operation Scenarios ...............................................................................................248 

6.1.2.1 Data Reception Configuration..........................................................................248 

6.1.2.2 Load of the Acquisition Schedule ....................................................................249 

6.1.2.3 Current Pass Data-Reception and Real-Time ISP Supply...............................249 

6.1.2.4 On Demand ISP Supply ..................................................................................250 

6.1.2.5 Simulated Scheduled ISP Supply ....................................................................251 

6.1.2.6 Archive Interface Operations ...........................................................................251 

6.1.2.7 Reporting on the Operations............................................................................251 

6.2 Data Processing Control (DPC) Operations...................................................................252 

6.2.1 Principles ................................................................................................................252 








page xx of xxii 

6.2.1.1 Processing On-The-Flow Concept...................................................................252 



6.3 Instrument Data Processing (IDP) Operations...............................................................255 

6.3.1 Principles ................................................................................................................255 



6.4 On-line Quality Control (OLQC) Operations...................................................................258 

6.4.1 Principles ................................................................................................................258 

6.4.1.1 Systematic Quality Control Concept ................................................................258 

6.4.1.2 Quality Indicators (QI) Generation & Usage ....................................................258 

6.4.1.3 Quality Indicators (QI) Scope...........................................................................258 



6.4.3.1 Definition & Configuration of the Quality Control Checks ................................259 

6.4.3.2 Systematic Quality Control Checks .................................................................259 

6.5 Data Circulation (DC) Operations ..................................................................................260 

6.5.1 Principles ................................................................................................................260 

6.5.1.1 Data Circulation Concepts...............................................................................260 

6.5.1.2 Horizontal Support to other PDGS functions ...................................................260 



6.5.3.1 Data Circulation Configuration.........................................................................261 

6.5.3.2 Electronic Data Circulation ..............................................................................262 

6.5.3.3 Data Circulation via Media...............................................................................262 

6.6 Auxiliary Data Supply (ADS) Operations........................................................................263 

6.6.1 Principles ................................................................................................................263 



6.6.3.1 Auxiliary Data Supply ......................................................................................263 

6.7 Precise Orbit Determination (POD) Operations .............................................................264 








page xxi of xxii 

6.7.1 Principles ................................................................................................................264 

6.7.1.1 NRT-POD ........................................................................................................264 

6.7.1.2 Off-Line POD Service ......................................................................................264 



6.7.3.1 POD Configuration ..........................................................................................265 

6.7.3.2 Input Data Gathering .......................................................................................266 

6.7.3.3 Sentinel-2 Restituted POD Product Supply .....................................................266 

6.7.3.4 Sentinel-2 Predicted POD Product Supply ......................................................267 

6.7.3.5 Monitoring of the On-Board Navigation Accuracy............................................267 

6.8 Archive & Inventory (AI) Operations ..............................................................................268 

6.8.1 Principles ................................................................................................................268 

6.8.1.1 PDGS Archive Concept ...................................................................................268 

6.8.1.2 PDGS Archive Federated & Collaborative Concept.........................................268 

6.8.1.2.1 Core PDGS Archive .....................................................................................268 

6.8.1.2.2 Collaborative Centre Archive........................................................................268 

6.8.1.3 Archived Elements...........................................................................................268 



6.8.3.1 Archive & Inventory Configuration ...................................................................269 

6.8.3.2 Data Archive & Inventory.................................................................................270 

6.8.3.3 Discovery of Archived Data .............................................................................270 

6.8.3.4 Archived Data Retrieval...................................................................................271 

6.8.3.5 Archived Data Retention & Clean-up...............................................................272 

6.8.3.6 Data-Driven Archive-to-Archive Data Circulation.............................................272 

6.8.3.7 On-Demand Archive-to-Archive Data Circulation ............................................272 

6.8.3.8 Bulk Archived-Data / Inventoried-Metadata Export..........................................273 

6.8.3.9 Maintenance....................................................................................................273 

6.9 Data-Access Index (DAX) Operations............................................................................273 

6.9.1 Principles ................................................................................................................273 

6.9.1.1 Centralised Data Index ....................................................................................273 








page xxii of xxii 

6.9.1.2 Data Index Composition ..................................................................................274 



6.9.3.2 Population of the Data Indexes........................................................................275 

6.9.3.3 Consolidation of the Data Indexes...................................................................275 

6.9.3.4 Coverage Reports Supply to the CDS/SCI ......................................................276 

6.9.3.5 Product Data Location Requests .....................................................................276 

6.9.3.6 Bulk Metadata Harvesting and Indexes Re-Generation...................................276 

6.9.3.7 Maintenance....................................................................................................277 

6.10 Data-Access Gateway (DAG) Operations......................................................................277 

6.10.1 Principles ................................................................................................................277 

6.10.1.1 Single Data-Access Point towards the Users ..................................................277 

6.10.1.2 Client/Server Approach ...................................................................................277 

6.10.1.3 Interfaces to the Front-End Services ...............................................................278 



6.11 Multi-Mission User Services (MMUS) Operations..........................................................280 

6.11.1 Principles ................................................................................................................280 



6.12 Multi-Mission User Services (OLIB) Operations.............................................................285 

6.12.1 Principles ................................................................................................................285 



6.12.3.1 True Colour Images Database Build-Up/Update .............................................286 

6.12.3.2 True Colour Images Streaming........................................................................286 

6.12.3.3 True Colour Images Download ........................................................................286 

6.13 Long-Term Archive (LTA) Operations............................................................................287 

6.13.1 Principles ................................................................................................................287 










page xxiii of xxii 

6.13.3.1 Data Archive & Inventory.................................................................................287 

6.13.3.2 Archived Data Retrieval...................................................................................288 

6.13.3.3 Bulk Data Re-processing.................................................................................288 

6.14 Mission Configuration Control (MCC) Operations..........................................................288 

6.14.1 Principles ................................................................................................................288 

6.14.1.1 Mission Configuration Control Concepts .........................................................288 

6.14.1.2 Function Managed Data ..................................................................................289 

6.14.1.2.1 Configuration Files .....................................................................................289 

6.14.1.2.2 Operation Files ...........................................................................................290 

6.14.1.3 Mission Reference Files Management ............................................................290 

6.14.1.3.1 Applicability Time .......................................................................................290 

6.14.1.3.2 Release Concept........................................................................................290 

6.14.1.3.3 Support to FOS Special Operation Request...............................................291 



6.14.3.1 Definition of the MRF Configuration Rules ......................................................292 

6.14.3.2 Registration of new Mission Reference Files...................................................292 

6.14.3.3 Coordinated Release.......................................................................................293 

6.14.3.4 Uncoordinated Release ...................................................................................293 

6.14.3.5 Configuration Reporting & Query Capabilities .................................................294 

6.15 Mission Planning (MPL) Operations ..............................................................................295 

6.15.1 Principles ................................................................................................................295 

6.15.1.1 Global Mission & Systematic Planning ............................................................295 

6.15.1.2 PDGS Planning Scope ....................................................................................295 

6.15.1.3 Multi-spacecraft Management .........................................................................296 

6.15.1.4 SPF-PIF Protocol.............................................................................................296 



6.15.3.1 Planning Configuration ....................................................................................297 

6.15.3.2 Manual Mission Plan Generation.....................................................................298 

6.15.3.3 Automatic Mission Plan Generation.................................................................299 








page xxiv of xxii 

6.15.3.4 Planning Loop Closure ....................................................................................299 

6.15.3.5 Automatic Ground Stations Scheduling ...........................................................300 

6.15.3.6 Planning Statistics Visualisation ......................................................................300 

6.16 Mission Performance Assessment (MPA) Operations ...................................................301 

6.16.1 Principles ................................................................................................................301 

6.16.1.1 MPA Decomposition ........................................................................................301 

6.16.1.2 Off-line Quality Control ....................................................................................301 

6.16.1.3 Calibration and Validation................................................................................302 

6.16.1.4 Instrument Data and Quality Control Processors Verification..........................303 

6.16.1.5 End-to-End System Performance Monitoring ..................................................304 


6.16.3 Operation Scenarios – Off-line Quality Control.......................................................304 

6.16.3.1 Configuration of the Quality Control Reporting ................................................304 

6.16.3.2 Generation of Quality Control Daily Reports....................................................305 

6.16.3.3 Generation of Quality Control N-Day Cyclic Reports .......................................305 

6.16.3.4 Second-Line Support-Desk .............................................................................306 

6.16.3.5 Auxiliary Data Conformity Control....................................................................306 

6.16.3.6 Expert Teams Reports Integration...................................................................307 

6.16.3.7 Access to the HKTM Data Decoded by the FOS.............................................307 

6.16.4 Operation Scenarios – Calibration and Validation ..................................................307 

6.16.4.1 Generation of Level-0/1 On-Ground Configuration Data .................................307 

6.16.4.2 Generation of Level-2 On-Ground Configuration Data ....................................308 

6.16.4.3 Generation of the On-Board Configuration Data Updates ...............................308 

6.16.4.4 Submission of MSI Calibration Requests ........................................................308 

6.16.5 Operation Scenarios – Verification of the Instrument Data and Quality Control 

Processors............................................................................................................................309 

6.16.5.1 New Processor Version Verification ................................................................309 

6.16.5.2 Investigation of Anomalies on the Processing Chain.......................................309 

6.16.6 Operation Scenarios – End-to-End System Performance Monitoring.....................309 

6.16.6.1 Interactive Monitoring ......................................................................................309 

6.16.6.2 Automated Monitoring & Reporting..................................................................310 








page xxv of xxii 

6.16.6.3 Service Performance Reports to the CDS/CQC ..............................................311 

6.17 Monitoring & Control (M&C) Operations ........................................................................311 

6.17.1 Principles ................................................................................................................311 

6.17.1.1 M&C Centre Scope..........................................................................................311 

6.17.1.2 Horizontal Support to other PDGS functions ...................................................312 

6.17.1.3 Client-Server Paradigm ...................................................................................312 



6.17.3.1 M&C Artefacts Configuration ...........................................................................312 

6.17.3.2 Coordination with Data Communication Operations ........................................313 

6.17.3.3 Monitoring & Reporting on the Execution Environment ...................................313 

6.17.3.4 Logs Visualisation............................................................................................314 

6.18 Reference Platform (RP) Operations .............................................................................315 

6.18.1 Principles ................................................................................................................315 

6.18.1.1 Hardware Inventory Activities ..........................................................................315 

6.18.1.2 Software Configuration Control Activities: .......................................................316 

6.18.1.3 System Anomaly Management Activities.........................................................316 

6.18.1.4 System-Level Testing ......................................................................................317 

6.18.1.5 Sub-System Level Testing...............................................................................318 



6.18.3.1 System Anomaly Management........................................................................319 

6.18.3.2 System Updates Management ........................................................................319 

6.18.3.3 Hardware Replacement/Deployment...............................................................320 

6.18.3.4 Mission Configuration Validation .....................................................................321 

6.18.3.5 System Configuration Reporting......................................................................321 

6.18.3.6 Training and Rehearsal ...................................................................................322 

6.19 MSI Decompression Supply (MDS) Operations.............................................................322 

6.19.1 Principles ................................................................................................................322 










page xxvi of xxii 

6.19.3.1 Periodical / Scheduled New Version Delivery..................................................323 

6.19.3.2 Patch / Corrective Delivery ..............................................................................323 

6.20 Network Communication Operations .............................................................................324 

6.20.1 Principles ................................................................................................................324 



APPENDIX-A GMES PRODUCT REQUIREMENT ANALYSIS FOR SENTINEL-2................325 

A.1 Introduction ....................................................................................................................325 

A.2 DAP-R Analysis Logic....................................................................................................325 

A.3 GMES Services Requirements Overview ......................................................................326 

A.3.1 Land Services.........................................................................................................326 

A.3.2 Emergency Services...............................................................................................328 

A.3.3 Security Services....................................................................................................331 

A.3.4 Marine and Coastal Water Services .......................................................................332 

A.4 Data Volume Estimate according to the DAP-R requirements.......................................334 

A.5 Open Data Policy and the of Landsat Experience .........................................................336 

A.6 DAP-R Analysis Table ...................................................................................................339 

APPENDIX-B MSI SCENES OVERLAP ANALYSIS ..............................................................348 








page xxvii of xxii 

L I S T O F F I G U R E S 

Figure 1-1 GMES Space Component Data Access System Overview...........................................31 

Figure 1-2 Sentinel-2 Mission Context ...........................................................................................32 

Figure 3-1 Sentinel-2 Mission Schedule.........................................................................................49 

Figure 3-2 Sentinel-2 Spacecraft....................................................................................................50 

Figure 3-3 MSI Spectral-Bands versus Spatial Resolution.............................................................51 

Figure 3-4 MSI internal configuration .............................................................................................53 

Figure 3-5 Staggered detector configuration and inter-detector / inter-band parallax angles 

(parallax figures derived from MSI instrument documentation cf. [RD-40])....................54 

Figure 3-6 MSI Calibration using the CSM in sun-diffuser position ................................................56 

Figure 3-7 Best-case daily OCP visibilities.....................................................................................62 

Figure 4-1 PDGS Interfaces...........................................................................................................68 

Figure 4-2 Illustration of the G-POD FAIRE Service .....................................................................79 

Figure 4-3 Sentinel-2 Schedule Uplink Opportunities via S-Band .................................................81 

Figure 4-4: Sentinel-2 MSI footprint ...............................................................................................83 

Figure 4-5: MSI Timeline Discontinuities after Downlink ................................................................84 

Figure 4-6 Average age of the sensor data (in hours) at the time of acquisition on-ground at a CGS 

network composed of Kiruna, Svalbard, Maslapomas, and Prince-Albert stations ........91 

Figure 4-7 Summer distribution of the data-age at the time of acquisition on-ground with Europe 

promoted for availability with NRT-compatible timeliness..............................................91 

Figure 4-8 Simulated global NRT-compatible data-age on-ground using a CGS network composed 

of Kiruna, Svalbard, Maslapomas, Prince-Albert, Matera and Gatineau stations...........92 

Figure 4-9 Real-Time Land Cover over Europe using one X-Band CGS .......................................93 

Figure 4-10 MSI Product Granule Concept – Level-1C products aggregate one or several UTM 

tiles of 100km x 100km ..................................................................................................98 

Figure 4-11 User-Product Concept ................................................................................................99 

Figure 4-12 Data Access latency versus data retention in archives.............................................103 

Figure 4-13 Federative PDGS Model ...........................................................................................106 

Figure 4-14 PDGS Product Data-Handling Strategy ....................................................................110 

Figure 4-15 Mock-up of the MMUS/ngEO Web-Portal Interface ..................................................112 

Figure 4-16 Envisat/MIRAVI Client Screenshot............................................................................113 

Figure 4-17 Land Coverage by the MSI .......................................................................................120 

Figure 4-18 Coverage time over Europe and Africa in summer with 2 satellites (considering 

clouds) .........................................................................................................................121 

Figure 4-19: MMFU Baseline Commanding Scenario for MSI .....................................................128 

Figure 4-20: MMFU Scenes Duplication Cases ...........................................................................129 

Figure 4-21: MSI Playback Commanding within Station contact time ..........................................131 








page xxviii of xxii 

Figure 4-22: RT Downlink over one CGS and several coinciding LGSs.......................................134 

Figure 4-23 Level-1 Processing Workflow (Doted boxes indicate optional processing steps)......139 

Figure 4-24 Sub-Orbit Datastrips .................................................................................................140 

Figure 4-25 MSI level 1 continuous processing timeline ..............................................................141 

Figure 4-26 Independent Geometric Refinement .........................................................................143 

Figure 4-27 Level-1C Tiling Concept in UTM ...............................................................................145 

Figure 4-28 Tile Processing .........................................................................................................146 

Figure 4-29 Suitable calibration orbits for Dark-Signal Calibration in winter.................................154 

Figure 4-30 Suitable calibration orbits over Dome-C within winter repeat-cycles.........................156 

Figure 4-31 Schematic of the EO G-POD CAT-1 Collaborative Workflow ...................................172 

Figure 4-32 Baseline Mission Operation Layout...........................................................................175 

Figure 4-33 Enhanced PDGS Operation Layout with EDRS........................................................177 

Figure 4-34 Alternative PDGS Operation Layout with EDRS .......................................................178 

Figure 5-1: PDGS Data-Management Functions..........................................................................200 

Figure 5-2: PDGS System Control Functions...............................................................................204 

Figure 5-3: PDGS Data Communication Functions......................................................................206 

Figure 5-4 CGS Configurations ....................................................................................................238 

Figure 5-5 Processing/Archiving Centre (PAC)............................................................................240 

Figure 5-6 Mission Performance Assessment Centre Configuration (MPAC) ..............................241 

Figure 5-7 Payload Data Management Centre configuration (PDMC) .........................................242 

Figure 5-8 PDGS Auxiliary Centres (ADP and MDP) ...................................................................243 

Figure 5-9 Collaborative Data-Access Mirror Configuration (CDAM) ...........................................244 

Figure 5-10 User Sites Layouts....................................................................................................245 

Figure 6-1 Parallelisation in the Processing “on-the-flow” Concept..............................................252 

Figure A-1 CGS/LGS Usage Characterisation parameters ..........................................................298 

Figure 6-2 IPF Evolution Cycle.....................................................................................................303 

Figure A-1 Natural Disasters Reported in the last 35 years .........................................................334 

Figure A-2 Overall Nominal/NRT Data foreseen ..........................................................................335 

Figure A-3 Yearly Data Volume Estimates derived from DAP-R..................................................336 

Figure A-4 ETM+ Standard L1T Downloads ................................................................................337 

Figure A-5 ETM+ On-Demand Orders .........................................................................................337 

Figure A-6 L1T Product age Downloads ......................................................................................338 








page xxix of xxii 

L I S T O F T A B L E S 

Table 3-1 Sentinel-2 Orbit Characteristics .....................................................................................49 

Table 3-2 MSI Spectral Bands Characteristics and Specified Performance...................................52 

Table 4-1 Datation Accuracy Budgets............................................................................................87 

Table 4-2 Sentinel-2 Product list and product main characteristics................................................96 

Table 4-3 Sentinel-2 Product Granularity .......................................................................................97 

Table 4-4 Sentinel-2 Data-Set Subscriptions per product-type ....................................................100 

Table 4-5 Radiometric image quality requirements. .....................................................................101 

Table 4-6 Geometric image quality requirements.........................................................................101 

Table 4-7 Product retrieval baseline strategy per product-type....................................................103 

Table 4-8 MSI Image Modes for Radiometric Calibration.............................................................152 

Table 4-9 Sentinel-2 Spacecraft Units Phase-In Scenario within the PDGS ................................164 

Table 4-10 Sentinel-2 user-defined criteria for product selection .................................................181 

Table 5-1 Baseline Operation Layout Configuration.....................................................................246 






Issue 1 Revision 2 (draft) - 25.07.2010 


page 30 of 350 

1 INTRODUCTION 

1.1 Purpose 

The purpose of this document is to describe the Sentinel-2 Payload Data Ground Segment 

Operations Concept, satisfying the data and services requirements from the GMES Services, 

the projection of these requirements for the GSC operations phase from 2013 onwards and 

the expected National and scientific requirements. 

1.2 Background 

The Global Monitoring for Environment and Security programme (GMES) 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 preoperations 

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 GSC Data 

Access system (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-11], 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 multi-mission products 

responding to specific different users needs and therefore with different characteristics. 



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.





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 [RD-02] and they shall comply as well with the GSCDA operational scenarios as 

detailed in [AD-02]. 

Figure 1-2 Sentinel-2 Mission Context 

Figure 1-2 also illustrates the Sentinels PDGS 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. 

1.3 Scope 

This document defines the operation concepts of the Sentinel-2 PDGS for performing its 

dedicated role within the overall GSC starting at phase-E1 of the Sentinel-2A mission. 

Concepts are defined with an end-to-end view of the PDGS system offering operational 

services vis-à-vis its external interfaces (e.g. Sentinel-2 FOS, GSCDA, GSC collaborative 

elements, etc), and are detailed down to the operations required on its inner components to 

carry out those end-to-end services. 









In this respect, the perimeter of the Sentinel-2 PDGS system within the overall GSC is 

delimited as follows: 

○ On one side, it is delimited as a sub-system of the Sentinel-2 system responsible for 

payload 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 Sentinel-2 FOS. 

○ On the other side, it is delimited as a component of the GSC ground infrastructure, 

responsible for feeding Sentinel-2 data to the GSS as required by the DAP through the 

GSCDA similarly to any GCM. In addition to its strict role vis-à-vis the GSS, the scope 

of the Sentinel-2 PDGS is enlarged for the provision of Sentinel-2 data to the Users 

following the Sentinel-2 Data Policy. 

With respect to the GSCDA as and its sub-systems such as the CDS, the Sentinel-2 

PDGS is considered as a GCM infrastructure. As such, the PDGS contributes to the 

GSCDA by implementing its applicable interfaces vis-à-vis GCMs as relevant to 

Sentinel-2. 

On another side, the PDGS integrates ESA’s Multi-Mission User-Services (MMUS) for 

data cataloguing and access for the general User support services. 

Starting at Phase-E1 of Sentinel-2A, the PDGS will assume different operational roles in time 

as driven by the launch of the Sentinel-2 units and their respective commissioning phases: 

○ Following Sentinel-2A Launch and Early Operations Phase (LEOP) and payload switchon 

activities, the PDGS will start operating its services vis-à-vis the Sentinel-2 system 

according to the Commissioning Phase requirements. During this phase, the PDGS 

services vis-à-vis downstream entities such as the GSCDA will not be considered 

operational. 

○ Following successful commissioning phase of the Sentinel-2A unit (assumed 3 months 

after launch), the PDGS will start full operations vis-à-vis the GSC with one-spacecraft. 

○ Following Sentinel-2B LEOP and payload switch-on activities, the PDGS will, in parallel 

to its operational role vis-à-vis Sentinel-2A, support the commissioning activities of the 

additional unit. During this phase, the PDGS services vis-à-vis downstream entities 

such as the GSCDA are considered operational for Sentinel-2A only. 

○ Following successful commissioning phase of the Sentinel-2B unit, the PDGS will reach 

its final operational phase vis-à-vis the Sentinel-2 constellation. 

In this respect, the scope of the document includes the operation concepts applicable to all 

four of the above phases. The applicability of the PDGS services and operations specific to 

Phase-E1 or Phase-E2 of each spacecraft unit will be clarified in the relevant sections. 

In particular, a specific interface of the Sentinel-2 PDGS with CNES (Centre National d’Etudes 

Spatiales) in Toulouse will be activated during the commissioning periods of Sentinel-2A and 

Sentinel-2B as required in the Sentinel-2 Ground-Segment Requirements Document [GSRD] 

[RD-03]. 









The Sentinel-2 PDGS offered services, provided functions and their operations have been 

driven by: 

○ Sentinel-2 Mission Requirements stated in the Mission Requirements Document [MRD] 

[AD-01]; 

○ Sentinel-2 Satellites capabilities and constraints stated in the Sentinel-2 Spacecraft 

Operations Concept Document [SOCD] [AD-03]; 

○ GSCDA applicable operational scenarios and interfaces [AD-02]; 

○ GMES Service requirements characterised in the GMES Data Access Portfolio 

requirement document [RD-11]; 

○ Sentinel-2 Ground Segment Requirements [RD-03]; 

○ ESA Earth Observation generic PDGS requirements consequence of requirements 

rationalisation across different ESA EO Missions [RD-17]. 









2 DOCUMENTATION 

2.1 Normative Reference Documents 

[AD-01] GMES Sentinel-2 Mission Requirements Document 

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

[AD-02] GSC Data Access System Operational Scenarios for 

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

08-0005 

[AD-03] Sentinel-2 Spacecraft Operations Concept Document 

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

Issue 2.1 08/03/2010 

Issue 1.1 10/09/2008 

Issue 3 30/10/2009 

2.2 Informative Reference Documents 

[RD-01] GMES Sentinel-2 System Requirements Document - 

S2-RS-ESA-SY-0001 

[RD-02] GSC Data Access Operational Interface Requirements 

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

[RD-03] GMES Sentinel-2 Ground Segment Requirements 

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

[RD-04] GSC Sentinel-2 PDGS System Requirements Document 

[SRD], GMES-GSEG-EOPG-RD-09-0028 

[RD-05] GSC Sentinel-2 PDGS System Technical Budget 

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

[RD-06] GSC Sentinel-2 PDGS Master Interface Control 

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

[RD-07] GSC Sentinel-2 PDGS Products Definition Document, 

[PDD] GMES-GSEG-EOPG-TN-09-0029 

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

ESA/PB-EO(2009)98 

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

S2PAD-VEGA-AUX-0001 

[RD-10] GMES Data Access Portfolio V1.0 [DAP], GMES- 

PMAN-EOPG-TN-07-0003 

[RD-11] Data Access Portfolio Requirement Document [DAP-R] 

– GMES-PMAN-EOPG-RD-08-0002 

[RD-12] GSC Data Access System ICD for GCMs, GMES- 

GSEG-EOPG-RD-08-0003 

Issue 5.0 15/10/2007 

Issue 1.3 06/04/2009 

Issue 1.1 08/12/2009 

Issue 1.2 

(draft) 

Issue 1.2 

(draft) 

Issue 1.2 

(draft) 

Issue 1.2 

(draft) 

25/07/2010 

25/07/2010 

25/07/2010 

25/07/2010 

Rev.1 23/10/2009 

Issue 2.2 19/04/2010 

Issue 1.0 09/09/2009 

Issue 1.1 15/03/2009 

Issue 1.3 06/04/2009 





[RD-13] GCM Coverage Report ICD, OSME-GSCDA-SEDA-IS- 

09-0039 

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

products. Ref. OGC 06-080 

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

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

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

06-141 

[RD-17] ESA Earth Observation PDGS Requirements 

Document, PGSI-GSOP-EOPG-RD-09-0005 

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

Guidelines, GSCB-LTDP-EOPG-GD-09-0002 

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

idelines_DraftV2.pdf 

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

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

[RD-20] ESA/EOP-G Ground segment security policy 





Issue 2.1 30/09/2009 

Issue 1.1 31/03/2009 

Draft V2 04/06/2009 

Issue 2.1 04/02/2009 

[RD-21] ESA Security directives (chapter 1.4 and 5.7, annex 2) 20/10/2008 

[RD-22] Implementation of the EO Network Security Policy Issue 1.1.3 14/11/2007 

[RD-23] Regulation EC No 45/2001 18/12/2000 

[RD-24] EU Directive [COM(2005)_438 final)] on data retention 21/09/2005 

[RD-25] ODAD-NS service description Issue 2.6 14/07/2009 

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

The ESA Data Relay Satellite Service Requirements, D- 

TIA/2008-12152/CE App2 

Issue 1.1 09/10/2008 

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

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

GS2.TN.ASD.SY.00046 

[RD-29] GMES Sentinels Payload Data Downlink Simulation in 

X-Band, PE-TN-ESA-GS-0264 

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

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

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

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

ST-GSGP-40-CNES 

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

VEGA-PD-0001 

Issue 1 08/05/2009 

Issue 2.0 15/03/2010 

Issue 1.0 21/12/2009 

Issue 1.0 10/06/2009 

Issue 2.1 06/11/2009 





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

Definition, S2PAD-VEGA-AUX-0001 

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

Theoretical Basis Document - Volume A (SMAC), 

S2PAD-VEGA-ATBD-0001 

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

Theoretical Basis Document - Volume B (ATCOR), 

S2PAD-DLR-ATBD-0002 

[RD-36] The G-POD CAT-1 Opportunity, ENVI-DTEX-EOPS-TN- 

07-0010 [http://eopi.esa.int/G-POD] 

[RD-37] Guidelines for Application Compatibility and Integration 

in G-POD, GRID-GODS-EOPG-TN-06-0003 

[http://eopi.esa.int/G-POD] 

[RD-38] GCM Quality Information Item – SPR-CQC ICD, OSME- 

GSCDA-SEDA-IS-09-0036 

[RD-39] GMES Sentinel-2 Mission Operation Concept Document 

- S2.RS.ESA.SY.0095 





Issue 2.0 06/11/2009 

Issue 2.0 09/11/2009 

Issue 1.3 06/11/2009 

Issue 1.0 13/07/2007 

Issue 2.0 13/07/2007 

Issue 2.1 30/09/2009 

Issue 1.0 18/12/2009 

[RD-40] MSI Technical Description - GS2.RP.ASF.MSI.00006 Issue 3.0 19/19/2008 

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

SY-0009 

Issue 1.0 09/03/2010 

[RD-42] EDDS – External User Interface Control Document Issue 1.0 13/04/2007 

[RD-43] Assumptions for the Ground Segment - 

GS2.TN.ASF.MSI.00074 

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

(ngEO) System Description & Operational Scenario – 


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

- GM-RS-ESA-SY-27 

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

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

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

Concept - GM-RS-ESA-SY-28 

Issue 2.0 10/03/2009 

Draft 18/06/2010 

Issue 1.0 09/03/2010 

Issue 1.0 09/03/2010 

Issue 1.0 09/03/2010 









2.3 Acronyms 

AI 

ADP 

ADS 

AOCS 

AOD 

AOS 

ATCOR 

BOA 

CADU 

CCSDS 

CDAM 

CDS 

CDS-SPR 

CDN 

CEOS 

CGS 

CNES 

CP 

CQC 

CSM 

CSS 

CST 

CUC 

DA 

DAG 

DAIL 

DAP 

DAX 

DC 

DCN 

DDN 

DEM 

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 

CDS Service Performance Report 

Content Delivery Network 

Committee on Earth Observation Satellites 

Core Ground Station 

Centre National d’Études Spatiales 

PDGS Commissioning Plan 

Coordinated Quality Control 

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 

Digital Dissemination Network 

Digital Elevation Model 









DFEP 

DPC 

DPM 

DRX 

DS 

DTED 

DUE 

ECMWF 

EDDS 

EDRS 

EEPROM 

ERCS 

ESA 

ESOC 

EO 

FCN 

FDS 

FEE 

FEEM 

FES 

FIFO 

FOS 

FPA 

FPGA 

FTS 

GCM 

GCP 

GEO 

GIPP 

GMES 

GMFS 

GPP 

GPS 

GRI 

Demodulator & Front-End Processor 

Data Processing Control 

Detailed Processing Model 

Data-Reception 

Data Set 

Digital Terrain Elevation Data 

Data User Element 

European Centre for Medium-range Weather Forecasts 

EGOS Data Dissemination System 

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 

Flight Dynamics System 

Front End Electronic 

Front End Electronic Module 

Front-End Services 

First-In First-Out 

Flight Operations Segment 

Focal Plane Assembly 

Field Programmable Gate Array 

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 Images 









GS 


GSCB 

GSCDA 

GSE 

GSP 

GSRD 

GSS 

GUI 

HKTM 

HLOP 

HMA 

HMI 

HR 

HW 

IAS 

ICCDB 

ICD 

ICM 

IDP 

IERS 

INSPIRE 

IPF 

IPS 

IQP 

ISO 

ISP 

JPIP 

JRC 

LAN 

LCT 

LEO 

LEOP 

Ground Segment 

GMES Space Component 

Ground-Segment Coordination Body 

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 

High Resolution 

Hardware 

Image Algorithm Software 

Instrument Calibration & Characterisation Database 

Interface Control Document 

Instrument Control Module 

Instrument Data Processing 

International Earth Rotation Service 

Infrastructure for Spatial Information in Europe 

Instrument Processing Facility 

Image processing Parameters Set 

Image Quality Processor 

International Organization for Standardization 

Instrument Source Packet (CCSDS) 

JPEG Interactive Protocol 

Joint Research Centre 

Local Area Network 

Laser Communication Terminal (former name for the Optical 

Communication Payload) 

Low Earth Orbit 

Launch and Early Operations Phase 





LES 

LGS 

Land Equipped Sites 

Local Ground-Stations 

LMCS Land Monitoring Core Service 

LTA Long-Term Archive 

LTDP Long-Term Data Preservation 

LUT 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 

MICD Master Interface Control Document 

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 

MRF Mission Reference Files 

MSI Multi-Spectral Instrument 

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

MSS Mission Scheduling System 

MT Medium Term 

MTBF Mean Time Between Failures 

MTF Modulation Transfer Function 

MTL Mission TimeLine 

ngEO Next Generation User Services for Earth Observation 

NOAA National Oceanic and Atmospheric Administration 

NRT Near-Real-Time 

NUC Non-Uniformity Coefficients 













OBC 

OBCD 

OGC 

OCP 

OFQC 

OGCD 

OLIB 

OLQC 

OPS 

OSV 

PAC 

PDGS 

PDHT 

PDI 

PDMC 

PDT 

POD 

POF 

POM 

PPS 

PQL 

PSK 

PUS 

PVI 

QC 

QI 

QR 

RAM 

RF 

ROM 

RP 

RT 

S2CP 

SAFE 

On-Board Computer 

On-Board Configuration Data 

Open Geospatial Consortium 

Optical Communication Payload 

Off-line Quality Control 

On-Ground Configuration Data 

On-line Image Browser 

On-Line Quality Control 

Orbit Position Schedule 

Overall System Validation 

Processing/Archiving Centre 

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 

Preliminary Quick-Look 

Phase Shift Key 

Packet Utilisation Standard 

Preview Image 

Quality-Control 

Quality Indicator 

Qualification Review 

Random Access Memory 

Radio Frequency 

Read Only Memory 

Reference-Platform 

Real-Time 

Sentinel-2 Commissioning-Plan 

Standard Archive Format for Europe 









SSCF 

SCI 

SEC 

S-FEE 

SMAC 

SNR 

SPOT 

SPR 

SOCD 

SOR 

SRTM 

SSO 

SW 

SWIR 

TBC 

TBD 

TCI 

TCM 

TCS 

TDI 

TF 

TLE 

TMA 

TMTC 

TOA 

TTO 

TWTA 

URL 

USGS 

UTM 

VCDU 

VCM 

VCN 

VCU 

Spacecraft Safety Constraints File 

Service Coordinated Interface (GSCDA) 

Security Pilot Service 

SWIR FEE 

Simplified Method for Atmospheric Corrections 

Signal-to-Noise Ratio 

Satellite Pour l’Observation de la Terre 

Software Problem Report 

Spacecraft Operations Concept Document 

Special Operation Request 

Shuttle Radar Topographic Mission 

Single Sign On 

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 









VOIP 

WAN 

WICOM 

VNIR 

VPM 

WAN 

WGS 

WICOM 

XBS 

Voice-Over-IP 

Wide Area Network 

Wavelet Compression Module 

Visible and Near Infrared 

Video Processing Module 

Wide Area Network 

World Geodetic System 

Wavelet Image COmpression Modules 

X-Band Subsystem 









2.4 Definitions 

Term 

Description 

Granule Cf. section 4.4.1 

User-Product Cf. section 4.4.2 

Product Data Item Cf. section 4.4.2 

Orbit 

Unless specifically expressed otherwise, the 

terminology “orbit” commonly refers to a specific 

Sentinel-2 spacecraft orbit, such that Sentinel-2A and 

Sentinel-2B orbits are unambiguously considered as 

distinct orbits. 

Data Strip Cf. section 4.5.4.5.2. 

Global Reference 

Image 

Quality Indicator 

Cal/Val 

The Global Reference Image is generated and used 

by the PDGS to refine the geometric accuracy of 

Sentinel-2 product. It consists in a set of Sentinel-2 

mono-spectral Level-1B products covering all land 

regions within the acquisition plan. 

Mean to provide the user of a dataset the required 

information to assess its suitability for a certain 

use/application 

Calibration is defined as the process of quantitatively 

defining the system responses to known and 

controlled signal inputs. 

Validation as the process of assessing, by 

independent means, the quality of the data products 

derived from the system outputs. 

The Calibration and Validation (Cal/Val) is the 

process of updating and validating the on-board and 

on-ground sensor and algorithmic parameters in order 

to meet product data quality requirements. 









2.5 Document Overview 

The present document is divided into the following chapters: 

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

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

well as definition of acronyms and terms; 

Chapter-3: Sentinel-2 Mission Overview, provides high level description of the Sentinel-2 

mission and satellite characteristics; 

Chapter-4: PDGS Operation Baseline, defines the system-level operational baseline context 

and scope of the PDGS in terms of interfaces, services, and data-products delivered. 

Assumptions on the operation baseline are enumerated; 

Chapter-5: PDGS Design, provides a rationale overview of the design rationale, and a 

description of the derived functional decomposition and physical layout in centres; 

Chapter-6: Detailed Operations Concepts, defines the operations concepts at a lower-level 

as applicable to each PDGS primary functional component; 

Appendix-A: GMES Product Requirement Analysis for Sentinel-2, describes the source 

requirement for Sentinel-2 product supplied as derived from the DAP-R 

Appendix-B: MSI Scenes Overlap Analysis provides a technical justification for the number 

of MSI scenes required to overlap between ground-station downlinks. 









3 SENTINEL-2 MISSION OVERVIEW 

3.1 Mission Objectives 

Sentinel-2 is an earth polar-orbiting satellite constellation designed to feed the GMES system 

with continuous and operational high-resolution imagery for the global and sustained 

monitoring of Earth land and coastal areas. 

As an enhanced follow-on to high-resolution optical missions such as SPOT and Landsat, the 

Sentinel-2 constellation will provide imagery for the sustained generation of higher-level 

operational products such as land-cover maps, land-change detection maps, and geophysical 

variables (e.g. leaf area index, leaf chlorophyll content or fraction of absorbed photosynthetically 

active radiation). 

The analysis of mission requirements [AD-01] has led to design the Sentinel-2 system based 

on the concurrent operations of two identical satellites flying on a single orbit plane, each 

hosting a Multi-Spectral Instrument (MSI) covering from the visible to the shortwave infrared 

spectral range and delivering high spatial resolution imagery at global scale and with a high 

revisit frequency. 

Sentinel-2 mission will ensure optical data supply continuity while introducing enhancements 

with respect to the current high-resolution optical systems to satisfy requirements defined in 

the Sentinel-2 MRD, current requirements from GMES Core Services and Downstream 

services, the projection of these requirements for the GSC operations phase from 2013 

onwards and the expected National and scientific requirements. 

The Sentinel-2 mission objectives include the operational supply of data, with adequate revisit 

frequency, coverage, timeliness and reliability, for services such as: 

○ Risk Management (floods and forest fires, subsidence and land slides) 

○ European Land Use/Land Cover State and Changes 

○ Forest Monitoring 

○ Food Security/Early Warning Systems 

○ Water Management and Soil Protection 

○ Urban Mapping 

○ Natural Hazards 

○ Terrestrial Mapping for Humanitarian Aid and Development 

Mission requirements are expected to evolve with the downstream services currently being 

under evaluation and they will be further enhanced by national requirements and 

requirements from the scientific community. 

Sentinel-2 mission objectives and operational requirements present a new challenge requiring 

sufficient space and ground segment resources in terms of: 









○ Temporal coverage, which translated into the need for a short orbit repeat cycle (10- 

days) and for a dual spacecraft operations in twin configuration providing a 5-days 

revisit frequency; 

○ Large spatial coverage and high coverage frequency, which translated into the need 

for a with wide swath coverage (290 km) with capabilities of global land masses 

acquisitions; 

○ High operation time during the daylight portion of the orbit; 

○ Wide spectrum optical range (visible to short-wave infrared) including 13 spectral 

bands; 

○ Data accessibility to the large Sentinel-2 data volume. 

The operational character of the Sentinel-2 mission implies the “provision of services in a 

routine, long-term and continuous fashion, with a consistent quality and a very high 

level of availability”. 

As a result of this operational character of the Sentinel-2 mission, the Sentinel-2 PDGS is 

expected to: 

• Be continuously available and robust with back up systems in case of failure; 

• Be able to ensure timely delivery of products to the users; 

• Ensure a high level of quality and stability of the products delivered. 

3.2 Mission Data Users 

Mission data users include: 

○ GMES Service Projects (GSPs) and European adding value industry 

○ National users 

○ Scientific users 

○ Operational Meteorological users 

○ ESA Climate Change Initiative Programme users 

○ Sentinel-2 calibration and validation users 

○ International partners with granted access to Sentinel-2 real-time data downlinks 

○ Other users supported by the ESA data policy 

Mission interfaces, access grants and priorities may be different for different classes of users. 

3.3 Sentinel-2 Constellation and Mission Lifetime 

In order to satisfy the large coverage and high revisit requirements, the Sentinel-2 mission is 

designed as a constellation of two identical satellites, Sentinel-2A and Sentinel-2B. 









When both in orbit, the two spacecraft units will fly on the same orbit and will be placed in twin 

configuration.180 degrees apart on the orbital plane. 

Sentinel-2A is scheduled for launch in May 2013 and it is planned to be operational after a 3 

months commissioning phase. 

The Sentinel-2B unit is planned to be launched 18 months after the Sentinel-2A launch. Both 

Sentinel-2A and 2B are designed for a nominal life-time of 7 years extensible to 12 years. 

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 

2021 2022 2023 

2024 2025 

2026 

S-2A development 

S-2A Launch 

Sentinel-2A IOT 

Sentinel-2A Operations 

Extended Operations 

S-2B development 

S-2B Launch 

Sentinel-2B IOT 

Sentinel-2B Operations 

Extended Operations 

Figure 3-1 Sentinel-2 Mission Schedule 

3.4 Orbit Characteristics 

Each satellite will operate in a reference orbit with a repeat cycle of 10 days for the overall 

duration of the mission. 

The Sentinel-2A orbit characteristics are summarised in Table 3-1. Sentinel-2B will be in the 

same orbit, but with a mean anomaly shifted by 180 degrees with respect to Sentinel-2B, 

leading to a ground-track revisit frequency of 5 days for the dual-spacecraft constellation. 

Orbit Type 

Near-Polar Sun-Synchronous at 786km altitude 

Mean Local Solar Time at 10:30 AM 

Descending Node (LTDN) 

Repeat Cycle 

10 days 

Cycle Length 

143 orbits 

Semi-Major Axis 

7164.25677316046 km 

Eccentricity 0.00115840619180778 

Inclination 

98.4985203399458 deg 

Argument of Perigee 

90.7445419264928 deg 

Table 3-1 Sentinel-2 Orbit Characteristics 

The Sentinel-2 spacecrafts will ensure that the ground track of each satellite will be within ± 2 

km at 3 σ confidence level (cf. [RD-01] requirement MIS-ORB-045). 









3.5 Space Segment 

3.5.1 SENTINEL-2 SPACECRAFT OVERVIEW 

The Sentinel-2 spacecraft depicted on Figure 3-2 is a 3-axis stabilised earth polar-orbiting 

satellite weighting 1.2 tons. It features an accurate Attitude and Orbit Control System (AOCS) 

based on a multi-head star-tracker and fibre optic gyroscopes, as well as a dual frequency 

GPS receiver to provide precise on-board determination of the satellite position. 

It carries on-board the Multi-Spectral Instrument (MSI) payload of 280kg and about 1m 3 

volume hosting the attitude sensors in order to minimise the thermo-elastic perturbations to 

the attitude measurements. 

Figure 3-2 Sentinel-2 Spacecraft 

The payload data, GPS & AOCS ancillary data and spacecraft housekeeping telemetry data 

(HKTM) can be buffered on board into a 2.4 Tbits mass storage system before being 

downlinked to ground receiving stations using an X-Band data distribution equipment 

featuring two concurrently operating 280 Mbps Travelling Wave Tube Amplifiers (TWTA) for 

an overall effective downlink rate capacity of 520Mpbs for payload-data. Alternatively, the X- 

Band distribution system can be used to transmit the payload data in real-time to groundstations 

while buffering the same data for later playback to other stations. 

The current satellite design, mass and power budgets currently make provision for future 

integration of a Optical Communication Payload (OCP) to be procured through the European 

Data Relay Satellite (EDRS) ESA program to allow transmission of the same mission data via 

EDRS provided geo-stationary data-relay satellites, hence substantially augmenting the datadownlink 

capacity of the mission through still EDRS-pointing ground Ka-Band antennas. 

The spacecraft operations are controlled from ground via a Telemetry and Tele-command 

(TMTC) subsystem operating in S-Band and interfacing the On-board Computer (OBC). 

The OBC software includes an on-board scheduler supporting both the MTL-based 

scheduling (Mission Timeline based on UTC), and the GPS coupled OPS (Orbit Position 

Schedule) scheduling capability allowing for long periods (>15 days) autonomy of the 

spacecraft operations. 





3.5.2 MULTI-SPECTRAL INSTRUMENT CHARACTERISTICS 





The MSI instrument has been designed with enhanced spectral range and performance as 

well as a larger swath compared to previous multi-spectral optical imaging missions. The 

following paragraphs detail the specific characteristics if the instrument, its design and 

specified performance. 

3.5.2.1 Spectral Performance Characteristics 

The MSI aims at measuring the earth reflected radiance through the atmosphere in 13 

spectral bands spanning from the Visible and Near Infra-Red (VNIR) to the Short Wave Infra- 

Red (SWIR), as depicted on Figure 3-3 and featuring: 

○ 4 bands at 10m: blue (490nm), green (560nm), red (665nm) and near infrared 

(842nm). 

○ 6 bands at 20m: 4 narrow bands for vegetation characterisation (705nm, 740nm, 

783nm and 865nm) and 2 larger SWIR bands (1610nm and 2190nm) for applications 

such as snow/ice/cloud detection or vegetation moisture stress assessment. 

○ 3 bands at 60m mainly for cloud screening and atmospheric corrections (443nm for 

aerosols, 945 for water vapour and 1375nm for cirrus detection). 

The specified spectral band characteristics and performance are summarised in Table 3-2. 

VNIR 

SWIR 

VIS NIR SWIR 

Visible 

B1 

B9 

B10 

60 m 

Aerosols Water-vapour Cirrus 

B5 B7 B8a 

Snow / ice / cloud discrimination 

20 m 

Vegetation 

Red-edge 

B6 

B11 

B12 

10 m 

400 

nm 

B2 B3 B4 B8 

600 

nm 

800 

nm 

1000 

nm 

1200 

nm 

1400 

nm 

1600 

nm 

1800 

nm 

2000 

nm 

2200 

nm 

2400 

nm 

Figure 3-3 MSI Spectral-Bands versus Spatial Resolution 





Band 

number 

Pixel 

resolution 

(m) 

Central wavelength 

(nm) 

Bandwidth 

(nm) 

Radiance sensibility 

range 

L min < L ref < L max 

(W.m -2 .sr -1 .m -1) 





SNR 

Specification 

(at L ref ) 

1 60 443 20 16 < 129 < 588 129 

2 10 490 65 11.5 < 128 < 615.5 154 

3 10 560 35 6.5 < 128 < 559 168 

4 10 665 30 3.5 < 108 < 484 142 

5 20 705 15 2.5 < 74.5 < 449.5 117 

6 20 740 15 2 < 68 < 413 89 

7 20 783 20 1.5 < 67 < 387 105 

8 10 842 115 1 < 103 < 308 174 

8a 20 865 20 1 < 52.5 < 308 72 

9 60 945 20 0.5 < 9 < 233 114 

10 60 1375 30 0.05 < 6 < 45 50 

11 20 1610 90 0.5 < 4 < 70 100 

12 20 2190 180 0.1 < 1.5 < 24.5 100 

Table 3-2 MSI Spectral Bands Characteristics and Specified Performance 

3.5.2.2 Measurement Geometry 

The MSI instrument design has been driven by the large swath requirements together with 

the high geometrical and spectral performance of the measurements. 

It is based on a push-broom concept, featuring a Tree-Mirror-Anastigmat (TMA) telescope 

feeding two focal planes spectrally separated by a dichroic filter. 

Figure 3-4 depicts the internal configuration of the MSI showing the TMA telescope 

configuration and its optical path construction to the SWIR/VNIR splitter and focal planes. 

Two distinct arrays of 12 optical detectors mounted on each focal plane cover respectively the 

Visible and Near Infra Red (VNIR) and Short Wavelength Infra Red (SWIR) channels. 

The 12 detectors on each focal plane are staggered-mounted to cover altogether the 20.6º 

instrument field of view resulting in a compound swath width of 290km on the ground-track. 









M1 

M3 

M2 

splitter 

VNIR 

channels 

SWIR 

channels 

Figure 3-4 MSI internal configuration 

As described on Figure 3-5, because of the staggered positioning of the detectors on the 

focal planes, a parallax angle between the two alternating odd and even clusters of detectors 

is induced on the measurements resulting in a shift along-track of about 46km (maximum) 

inter-detector. Likewise, the hardware design of both the VNIR and SWIR detectors imposes 

a relative displacement of each spectral channel sensor within the detector resulting in an 

inter-band measurement parallax amounting to a maximum along-track displacement of about 

14km. 









Overlapping area=98 pixels 20m 

10 bands 

VNIR 

Nb pixels/det module: 

2592 (10m), 1296 (20-60m) 

B/H cross-detector 

B/H cross-band 

B/H=0.018 

B/H=0.010 

Band 

2 

8 

3 

4 

5 

6 

7 

8a 

1 

9 

10 

11 

12 

Odd/even detector 

parallax 

angle (B/H) 

0,022 

0,026 

0,030 

0,034 

0,038 

0,042 

0,046 

0,051 

0,055 

0,059 0,030 0,040 

0,050 

10m 

20m 

60m 

VNIR 

SWIR 

Figure 3-5 Staggered detector configuration and inter-detector / inter-band parallax angles 

(parallax figures derived from MSI instrument documentation cf. [RD-40]) 

3.5.2.3 Measurement Data Handling 

3.5.2.3.1 Data-Rate and On-Board Data Compression 

The MSI image data is compressed on-board through specific WICOM compression 

hardware units, applying a compression algorithm to the detector output pixels based on 

wavelet transform. This allows reducing the MSI output data rate to around one third of the 

raw output bit-rate of the sensor, hence reducing the record and downlink requirements 

without jeopardizing the image quality after decompression on ground. 

Six WICOM units are operated in parallel, each one handling the data of a pair of detectors. 

Image data compression is systematically carried out in blocks of 16 lines of image data 

hereafter referred to as “compressed blocks”. Depending on the spectral band, the number of 

pixels aggregated in a measurement line per detector is respectively 2592 for the 10m bands 

and 1296 corresponding to the 20m and 60m bands. Each image pixel radiometry response 

is coded into 12bits words irrespectively of the spectral band. 

Whilst the compression ratio implemented by the WICOMs can be fine-tuned in-flight 

independently and optimally for each spectral band, the compound bit-rate currently assumed 

as the optimal trade-off between image quality and output data-rate leads to a nominal 

compressed data supply rate from MSI of 490 Mbps. 









3.5.2.3.2 Scene Packaging 

The on-board mission data is packaged in “Scenes” ensuring the consistency of a selfcontained 

data set including all data from the 12 detectors and the 13 spectral bands. 

A “Scene” is composed of 13 scene channels (one scene channel corresponds to one 

spectral band), each one compiling the compressed data aggregated along a distance of 

approximately 23km along-track by the 12 detectors. 

The 23 km along-track is synchronised between channels of different relative pixel sizes by 

an appropriate selection of the number of compressed blocks aggregated per scene channel. 

This results into 144 blocks (resp. 72 and 24) for the 10m (resp. 20m and 60m) channel. 

Considering 12 bits per pixel, the volume of each scene will amount to 4Gbits of 

uncompressed data leading to about 1.4 Gbits after compression. 

Overall, each compressed block inside one scene will be packaged into one CCSDS 

Instrument Source Packet (ISP), resulting into a scene assembly of exactly 12960 packets. 

3.5.2.3.3 Measurement Datation 

The satellite clock, synchronised by the GPS measurements at 1Hz (TBC), in turn enslaves 

the master-clock of the MSI. Within the MSI, an accurate datation process strongly linked to 

the data generation process is then carried-out down to the actual time-stamping in the 

generated ISPs. This process is summarised as follows: 

○ At the start of acquisition of a new scene, the mater-clock time is stored. During the 

processing period, this time information is reported in all source packets of the scene 

(referred to as the CUCM_s tag); 

○ During the scene acquisition period, the master-clock drift is estimated and a 

correction value (referred to as Δ_s) is reported in all ISPs of the scene. 

3.5.2.4 On-Board Configuration 

The MSI imaging characteristics are configurable by way of parameter tables held on-board 

and which can be altered by ground commanding. The SOCD [AD-03] details the contents of 

each table and associated uplink strategy. 

These tables allow the configuration of: 

○ Image processing parameter sets (IPS), allowing to swiftly switch instrument imaging 

characteristics along the orbit from seven different configurations. Those configurations 

will be mapped to each operational mode of the instrument including nominal imaging 

or specific calibration modes required for performance assessment and Cal/Val 

activities. In particular the WICOM compression ratios are configurable though the IPS 

tables; 

○ The Non-Uniformity Coefficients (NUC), allowing the detector responses to be 

equalised independently at pixel-level before on-board compression of the image. NUC 

equalisation can be deactivated for calibration activities by way of an IPS switch; 

○ Thermal Control Module (TCM) configuration data, allowing to fine-tune the thermal 

control of the instrument; 









○ Front-End Electronics (FEE) parameters, allowing in particular the management of 

defective pixels; 

○ MSI global operation settings driving above all the activation of redundant units. 

3.5.2.5 Calibration Shutter Mechanism 

The instrument features a Calibration and Shutter Mechanism (CSM) which can be 

commanded in-flight such as to expose to sun-light the complete sensor field of view to allow 

for absolute calibration and non-uniformity calibration of the detector modules (see Figure 

3-6). 

Figure 3-6 MSI Calibration using the CSM in sun-diffuser position 

3.5.3 POSITIONING, ATTITUDE AND MEASUREMENT DATATION 

The accurate on-board determination of the satellite position and the absolute dating are 

supplied by a dual frequency GPS receiver. The knowledge of the satellite fine attitude is 

provided by the hybridization of the measurements performed by an inertial measurement unit 

involving gyroscopes and 3 star trackers; these sensors are mounted on the MSI instrument 

structure so as to reduce thermo-elastic deformations between their reference frames and the 

line of sight. This information is sent with the instrument telemetry for further precise 

geometric processing on ground. The satellite is steered around the yaw axis so as to 

balance the earth rotation. 

3.5.4 DATA RECORDING AND DOWNLINK CHARACTERISTICS 

3.5.4.1 Data Downlink in X-Band 

The X-Band subsystem (XBS) of Sentinel-2 features 2 concurrently operating channels at 280 

Mbps information rate each, based on 8PSK modulation scheme and providing a compound 

effective output data rate of 520 Mbps available for space-to-ground data transmissions. 









3.5.4.2 Data Downlink via EDRS/OCP 

Additionally to its data-transmission capability at nadir in X-Band, Sentinel-2 features an 

Optical Communication Payload (OCP) procured through the EDRS programme which will 

allow space-to-ground communications relayed via geo-stationary (GEO) EDRS spacecrafts. 

It is assumed that the LCT will, when activated in alternative to the X-Band transmission, 

transparently carry 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 programme, will provide the adequate Ka- 

Band demodulation capabilities on ground and restore the dual 280Mbps data-streams in 

baseband ready for front-end processing. 

It is currently envisaged to secure the Ka-Band broadcast transmission via data encryption. In 

this respect, it is further assumed the dual 280Mbps channels restored in baseband after the 

EDRS ground equipment will be clear of any encryption. 

3.5.4.3 Data Recording and Playback 

The satellite generated data is managed on-board independently for MSI data and HKTM 

data by the Mass Memory Formatting Unit (MMFU) sub-system. Additionally, a separate and 

independently managed Ancillary data store of MMFU handles all non-MSI data required for 

image processing activities on-ground such as GPS and datation data. 

The on-board mass memory of 2.4 Tbits is sized to hold respectively 20 Gbits of HKTM, 20 

Gbits of Ancillary data and 2360 Gbits of MSI data, the relative partition sizes being 

configurable in-flight. 

On opportunity of a data downlink, each data partition can be played back and transmitted to 

ground using the dual 280Mpbs channel capability. While the MSI data downlink will 

systematically use the compound 520Mbps effective capacity, HKTM and Ancillary data 

partitions may be downlinked simultaneously one on each channel or separately. Playback 

operations may be paused and later resumed to allow for data downlinks onto successive but 

non-overlapping ground stations. 

After each playback operation, the data partition may be either erased, or retained and 

managed in a circular buffer in case repeated or overlapping transmissions over distinct 

ground-stations are required. 

Alternatively, an MSI Real-Time (RT) downlink may be commanded so as to forward the MSI 

real-time 490 Mbps data stream directly to the transmission system. The MSI data may then 

be optionally buffered on-board at the same time to allow for a repeated downlink by playback 

at a later stage. 

In addition and to respond to mission requirements pertinent to data timeliness, the MSI data 

recorded on-board may be prioritised as Near-Real-Time (NRT) data into the playback queue 

so as to ensure it is downlinked as early as possible, rather than following the regular First-In 

First-Out (FIFO) approach. The data segments classified with NRT or Nominal priority may 

then be downlinked separately or in an automated first-NRT-then-Nominal sequence. 

To simplify the management of the discontinuous MSI data fragments resulting on ground 

due to the segmented recording and playback operations, the MMFU allows via appropriate 









commanding, to artificially append a margin of three imaging scenes covering the 

discontinuity boundaries (cf. [RD-41]). 

3.5.5 SCHEDULING 

The Sentinel-2 mission aims for a high autonomy with enhanced pre-programming, so that 

the nominal spacecraft operations will execute according to a sequence of commands 

uploaded from ground typically once every 14 days. 

Two schedule references are supported: 

- The Mission Timeline (MTL) based on a time-code referenced on the on-board clock; 

- The Orbit Position Schedule (OPS). 

To a large extent, spacecraft scheduling will require that the sensor measurements or 

downlink events to ground-stations precisely correspond to their on-ground related features 

such as the sensor overflying a specific area on earth or the satellite being effectively visible 

within a given ground-station mask. On the other hand, the varying nature of the spacecraft 

low earth orbit, as perturbed through atmospheric-drag and geo-gravitational forces, induces 

that spacecraft positioning cannot be predicted with the required precision in the long-term. 

The OPS scheduling approach precisely answers to the varying geo-positioning paradigm 

outlined above in that it allows commands to execute relatively to the spacecraft position 

within the orbit, the accurate positioning being measured autonomously on-board through the 

GPS embedded hardware. 

Hence, whilst the classical MTL-based scheduling will allow for accurate commanding of onboard 

operations at specific times, it is not well adapted to long-term operation schedules for 

which the OPS approach will generally be preferred. 

3.5.6 COMMANDING AND CONTROL 

For commanding and control, the Sentinel-2 satellites are interfaced from ground via the S- 

Band channel activated by schedule during pre-defined S-Band ground-station contact 

periods, primarily using the TMTC and ranging ground-station at Kiruna (Sweden). 

During those periods, commanding can be performed (TC) and telemetry (TM) is received 

with an apportioned data-rate on the S-Band link of 64kbps for uplink and 128kbps or 

2048kbps configurable for downlink. 

In particular, the TC link is used for providing schedule increments to the spacecraft (cf. 

3.5.5), upload on-board software patches or configuration parameters (cf. 3.5.2.4) and overall 

control of the spacecraft in-orbit (e.g. manoeuvre commanding). 

The TM link is used for TC acknowledge, general spacecraft monitoring, downlink of on-board 

software configuration, and basic satellite orbit ranging and datation activities. 

S-Band communication with the spacecraft is made following the CCSDS Packet Utilisation 

Standard (PUS) services. 









3.6 Ground-Segment 

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 on-ground 

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

CNES/CST during commissioning phase is detailed in section 4.2.5. 

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. FOS responsibilities are further detailed in 

section 4.2.4. 

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 ground-system including 

ground-stations, processing centres and embedding all additional third-party 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 multimission 

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

3.7 Mission Evolution with EDRS 

3.7.1 REVIEW OF EDRS PLANNED SERVICES FOR GMES 

The current plan for EDRS services provisions for: 

○ An initial data-relay capacity to be reached with a piggyback EDRS payload carried 

on-board a non dedicated satellite to be launched in 2013, 

○ A second data-relay capacity, equivalent and complementing the first one, by the 

launch of an EDRS-dedicated spacecraft in 2015. 

Both missions aim for a 15 years lifetime such that a dual EDRS capacity would be available 

between 2015 and 2028, and a single one in the periods 2013-2015 and 2028-2030. 

As stated in [RD-26], the GMES Sentinels missions are intended as one of the main 

customers of EDRS services. Similarly to Sentinel-2, the Sentinel-1 spacecrafts will carry a 

OCP enabling data-relay communications from space. Sentinel-3 will not carry an OCP. The 

data-relay capacity will be sized to carry at least 50% of each of the Sentinel-1 and Sentinel-2 

missions generated data, considering two spacecraft units operating contemporaneously for 

each mission. 

Besides data-relay capabilities provided as part of baseline services, the EDRS service 

envelope provisions for extended services with dual objectives: 

○ Repatriation services, providing a shared capacity to be used within to the GSC 

Sentinels PDGSs for ground-to-ground multicast data communications, for instance to 









repatriate data from remote X-Band ground-stations to other centres in Europe. This 

shared capacity is currently sized to 230Mbps multicast data-rate (cf. [RD-46]). 

○ Dissemination services, providing a shared capacity for ground-to-ground broadcast 

data-transmissions of GSC products to end-users. This service requires that datareception 

at the end-user sites can be enabled through relatively low-priced Ku-Band 

or Ka-Band antenna hardware (





In complement, the 230Mbps repatriation capability will be used for an equivalent daily 

throughput of about 74Mbps to bring the data acquired at polar-stations to processing 

centres located throughout Europe and closer to the data consumers, still taking 

advantage of the multicast capability to provide for flexibility and reliability through 

redundancy, and possibly in near-real-time. 

○ Broadcast Data-Dissemination 

EDRS dissemination capabilities via broadcast will be used to transmit final products to 

end users, in particular the ones that cannot be served efficiently through groundnetworks. 

To this end, the usage of C-Band instead of Ka-Band or Ku-Band would be 

preferred to enlarge the downlink coverage of the dissemination service beyond 

Europe such as to reach some African or Middle-East regions. 

Concerning data-relay communications, it is here considered that, provided OCP usage is not 

constrained, contacts through EDRS will provide the right complement to polar-station 

downlinks at nearly every orbit. Figure 3-7 extracted from [RD-19] (OCP Scenario 3C as bestcase) 

depicts a typical day of the Sentinel-2 repeat cycle showing in light-blue the visibility 

segments of OCP and in dark-blue the ones provided through X-Band to Kiruna or Svalbard 

stations (Maspalomas and Prince-Albert have been artificially masked-out in light grey in the 

image). 

It shows that apart from the second orbit in the day (or third depending on the day) which is 

poorly served through EDRS, all other orbits provide long contact segments outside of X- 

Band visibilities providing for the adequate complement with the required flexibility for EDRS 

usage among Sentinels. 









Figure 3-7 Best-case daily OCP visibilities 

It is however stressed that this level of EDRS usage via the OCP is at this stage totally 

hypothetical as highly dependent on actual OCP capabilities with Sentinel-2 which are 

currently being analysed. As currently stated in [RD-27], “The Sentinel-2 Laser 

Communications Terminal 1 is a secondary payload for the evaluation of high speed data 

communications by means of a laser link using a geostationary satellite as relay”. The 

effective OCP capabilities, in particular regarding its operation constraints vis-à-vis MSI 

operations, will be evaluated in-flight from which workable scenarios will derived and 

potentially used operationally. 

Nevertheless, specific mission operation scenarios have been derived based on the optimal 

anticipated performance of OCP and EDRS in-flight. 

3.8 Management 

The overall management of the Sentinel-2 mission, including the space segment gradually 

including Sentinel-2A then Sentinel-2B and the ground-segment including the FOS and the 

PDGS will be led by the Sentinel-2 Mission Management Authority (MMA). As such, the MMA 

will be globally responsible for the achievements of the overall mission requirements. 

Regarding its relationship with the GSC and in particular vis-à-vis the DAP, it is assumed the 

MMA represents a uniformed authority with the GSCDA on Sentinel-2 matters. 

The MMA will centralise all decisions covering: 

○ The definition and management of the High-Level Operation Plan (HLOP). During the 

commissioning-phase of each spacecraft, the HLOP is superseded by the Sentinel-2 

Commissioning-Plan (S2CP) defined for that spacecraft. 

○ The fulfilment of the Data-Policy applicable to the Sentinel-2 mission data; 

○ The coordinated management with the GSC authority of the DAP and its evolutions as 

regarding Sentinel-2 contributions; 

○ The definition and management of agreements with potential third-party operated 

Local Ground-Stations (LGS) entitled to receive Sentinel-2 X-Band real-time data and 

mirroring in the HLOP. 

○ The definition of mission performance and quality baseline targets with respect to all 

mission stakeholders. 

Before the formal start of Phase-E2 of each Sentinel-2 spacecraft unit and in particular during 

their commissioning-phase, the PDGS will be considered pre-operational only (cf. section 

4.6.2) and will be dedicated to serving operationally the FOS and other specific stakeholders 

according to the commissioning-plan requirements. The commissioning-plan relevant to the 

Phase-E1 of one spacecraft unit will entirely supersede HLOP applicability for all mission 

operations linked to that spacecraft during this phase. 

1 Recently renamed Optical Communication Payload (OCP) 









In particular, it is assumed that the PDGS services towards GSPs, general users, LGS, and 

Collaborative PDGS entities will be commissioned during those periods according to the 

PDGS commissioning plan and enter full operations not before than at Phase-E2 of each 

spacecraft. 









4 PDGS OPERATION BASELINE 

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 such as the one 

defined in [RD-01]. 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-21]). 

[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 (cf. [RD-47]). 

[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 datarelay 

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 ready 

for front-end processing. The dual 280Mbps channels restored 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 datarepatriation 

multicast link for a third of the total time (cf. [RD-46]). 

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

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 data-downlinks 

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 in-any case at the 

time of the Sentinel-2 PDGS deployment phase. 









4.2 Operation Context 

4.2.1 MANAGEMENT 

In general and throughout this document and all associated PDGS documentation of 

technical content such as the SRD, the terminology “PDGS Operation Manager” (POM) (e.g. 

when used as an interface to the PDGS) does not strictly relate to any specific body or person 

but rather symbolises the management authority required at any level of the PDGS end-toend 

operations to decide on its main leverages and to get appropriate visibility on the mission 

performance in return enabling management. 

4.2.1.1 HLOP Implementation 

Based on the mission HLOP provided by the MMA, the POM will be responsible for deriving 

PDGS operation plans and ensuring their related implementation covering the planning of 

payload acquisition and recovery on-ground, EDRS usage, production plans, archive plans, 

etc. The HLOP is hence considered an applicable to the POM. 

During the commissioning-phase of each spacecraft, the HLOP is superseded by the S2CP 

defined for that spacecraft. 

Vis-à-vis the PDGS, the HLOP will define: 

○ The mission operation scenario applicable to the Sentinel-2 constellation covering all 

global mission operation parameters such as: 

o Orbital definitions for the satellite constellation; 

o Definitions of the PDGS CGS network and associated operational constraints 

(e.g. priorities, inter-sentinel conflict management, etc); 

o MSI nominal data acquisition and recovery rules at the PDGS CGS including 

the definition of priority zones promoted for NRT timeliness as reply to the DAP 

and specific balancing between the constellation spacecrafts; 

o The definition of specific acquisitions campaigns and their assimilation within 

the nominal mission plan; 

o Definition of the Sentinel-2 LGS network and associated planning rules vis-à-vis 

LGS entitled to X-Band real-time data reception; 

o The definition of the usage of EDRS provided capabilities for data recovery 

from the spacecrafts via the OCP; 

○ The PDGS data-processing, circulation and archiving plans as responding to the 

GSC/DAP or the commissioning phase requirements and within the PDGS capabilities 

and available resources spread in the ground-stations and centres network; 

○ The list of PDGS interfaces and services to be activated during the mission phase 

applicable to the plans; 

○ The definition of high-level PDGS performance targets and product quality in-line with 

the capabilities of the mission. 









4.2.1.2 Data-Access Management 

Regarding access to Sentinel-2 data, associated services and the management of 

authorisations in this respect, the POM will: 

○ Register GSPs authorised through the GSCDA/DAP for access to Sentinel-2 data and 

cascade all associated PDGS configuration in this respect; 

○ Apply the HLOP enabling the real-time data reception in direct-downlink from the 

spacecrafts to third-party LGS according to the agreed national and international 

cooperation agreements endorsed by the MMA in this respect; 

○ Apply the data-policy in place for access to Sentinel-2 imagery by the Users; 

○ Define, manage and implement collaboration agreements with potential Collaborative 

PDGS entities for Sentinel-2 (cf. section 4.2.6); 

4.2.2 INTERFACES 

As described in the previous section, the Sentinel-2 PDGS will be globally controlled by the 

POM. As such, the POM acts as a PDGS external interface exercising operational control and 

receiving feedback assessments on the PDGS and mission overall performance. 

Vis-a-vis external stakeholders, the following PDGS interfaces have been identified: 

○ The Sentinel-2 users as listed in section 3.2 as primary stakeholders for the 

exploitation of the Sentinel-2 data-access services and products provided by the 

PDGS. The GSPs are specific priority users; 

○ The GSCDA/CDS as interacting with the PDGS for GSC coordinated data-access 

services and reporting; 

○ LGSs authorised through the HLOP for RT reception of Sentinel-2 payload data 

through the X-Band direct downlink interface; 

○ The Sentinel-2 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 CNES centre in Toulouse as a working interface with the PDGS during the 

commissioning phase of the Sentinel-2 spacecrafts and stakeholder for the timely 

reception of Level-0 data acquired at the PDGS ground-stations to perform 

commissioning activities; 

○ Collaborative entities having agreed a partnership with the Sentinel-2 POM as further 

outlined in section 4.2.6. 

As far as Sentinel-2 mission data feeding to the PDGS is concerned, two interfaces have 

been identified: 

○ The Sentinel-2 spacecrafts data downlink interface in X-Band; 









○ The Sentinel-2 spacecrafts data downlink interface via the OCP and relayed by EDRS 

geo-stationary spacecrafts in Ka-Band. 

Interfaces to the EDRS exploitation segment are identified for: 

○ Mission planning coordination of space-to-ground data-relay availability segments for 

the Sentinel-2 constellation; 

○ Ground-to-ground data broadcast interfaces, provisionally identified to potentially 

support PDGS internal data-circulation capabilities as well as data-distribution 

capabilities to end-users. 

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

following interfaces to external entities that will provide PDGS functional services are 

identified: 

○ Third-party auxiliary data providers for the operational provision of Auxiliary Data Files 

(ADFs) to be embedded in the PDGS products to allow for for e.g. Level-2 dataprocessing; 

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

software; 

○ Sentinel-2 expert services supporting specific Cal/Val functions that cannot be 

automated through the PDGS. 

S2A/B 

EDRS 

TM/TC 

LCT 

X-Band 

signal 

Ka-Band relay 

signal 

FOS 

LGS 

EDRS Exploitation 

Segment 

Auxiliary Data 

Providers 

WICOM 

Decomp.S/W 

Collaborative PDGS Entities 

Expert CAL/VAL Teams 

CDS Users 

Figure 4-1 PDGS Interfaces 

CST 









The PDGS Master ICD [MICD] [RD-06] further identifies and details every interface and 

describes their operation context within the PDGS physical layout. 

4.2.3 GMES SPACE COMPONENT DATA-ACCESS (GSCDA) 

Recalling the background principles introduced in section 1.2, the Sentinel-2 PDGS, as part of 

the Sentinel-2 overall system, will act as a GCM vis-à-vis the GSCDA in that it makes the 

Sentinel-2 data available to the GSCDA/CDS, following the operational scenarios defined in 

[AD-02]. 

Between the Sentinel-2 PDGS and the GSCDA/CDS, the general subsidiarity principle 

defined by the GSCDA versus any GCM will apply, in that any function provided by the 

Sentinel-2 PDGS will not be duplicated in the CDS whenever the function is Sentinel-2 

specific. 

4.2.4 SENTINEL-2 FLIGHT OPERATION SEGMENT (FOS) 

The Sentinel-2 FOS will be operated at ESA’s European Space Operations Centre (ESOC) in 

Darmstadt in Germany during the entire Sentinel-2 mission. The FOS will take care of all flight 

operations of the Sentinel-2 spacecrafts including satellite tasking, telecommanding and 

telemetry monitoring, flight dynamics monitoring and orbit control. 

All above tasks will have close and direct relationships with PDGS counterpart operations as 

follows: 

○ Satellite tasking activities will be performed through the FOS Mission Planning System 

(FOS/MPS) – which is part of the FOS Mission Control System (MCS). The FOS/MPS 

will recurrently schedule the satellite operations according to the specific payload data 

acquisition and downlink activities expressed by the PDGS (as translated from the 

HLOP) while ensuring satellite critical safety requirements among other tasks. An 

operational mission planning loop between PDGS and FOS is hence accounted for 

starting after LEOP and initial payload switch-on activities and for the whole mission 

lifetime, which is expected to be specifically intensified during Phase-E1 of each 

spacecraft. 

○ Telecommanding and telemetry monitoring activities will be performed through the 

FOS Mission Control System (FOS/MCS). Those activities have their counterparts at 

PDGS-level in two areas: 

o To allow monitoring of spacecraft operations and safety during the complete 

orbit, the spacecraft housekeeping telemetry (HKTM) will be continuously 

recorded on-board and systematically downlinked in X-Band to the PDGS 

ground station network while also being real-time downlinked in S-Band when 

the satellites are visible from FOS operated ground-station. On reception, the 

PDGS will be tasked to operationally supply the acquired telemetry to the FOS 

within one hour following reception. 

o In counterpart, the FOS/MCS will operationally provide the PDGS with: 

• Spacecraft operation reports, stating in particular the deviations of the 

effective operations with respect to the plan such as the contingency 









operations performed, or the on-board systems unavailability 

occurrences with their associated recovery operations. 

• On-demand or automated extractions of HKTM data through the EGOS 

Data Dissemination System (EDDS). 

○ Flight dynamics monitoring and orbit-control activities will be performed through the 

FOS Flight-Dynamics System component (FDS). FOS FDS operational activities are 

related to PDGS ones in two main areas: 

o As driving the X-Band tracking capabilities at PDGS ground-stations to enable 

data reception, the FOS FDS will operationally provide the PDGS with satellite 

positioning information such as the Predicted Orbit File and Two Line Elements 

(TLE). 

o As potentially impacting on product quality, the FOS/FDS will operationally 

provide the PDGS with the plan of spacecraft manoeuvres (both in-plane and 

out-of-plane), together with their resulting performance and interference. 

Following each spacecraft manoeuvre, the updated satellite mass property will 

be forwarded to the PDGS as required for precise orbit determination (POD) 

activities. 

4.2.5 CENTRE NATIONAL D’ÉTUDES SPATIALES (CNES) 

To maximise the reuse of European expertise gained in the area of spaceborne high spatialresolution 

optical sensors through missions such as the SPOT series, and to foster continuity 

and enhancement of operational applications, ESA and CNES have signed a collaboration 

agreement for the Phases C/D and E1 of the Sentinel-2 mission. This collaboration 

agreement materialises at technical-level into the implementation of ESA-CNES joint teams in 

the space-segment and ground-segment domains primarily focusing on the data-processing 

and image-quality areas. 

In this framework, CNES and more precisely the Centre Spatial de Toulouse (CST) will hold 

an operational role vis-à-vis the PDGS during the commissioning phases of the Sentinel-2 

spacecrafts. As forerunner to recurrent mission performance assessment activities that will be 

taken over by the PDGS during the operational phase, CNES will carry out in-flight instrument 

commissioning activities with counterpart tasks on ground for the validation of the processing 

algorithm and PDGS processing chain. 

These tasks will be driven by the Sentinel-2 Commissioning Plan (S2CP) and will be 

performed through the complementary use of: 

○ The Ground Processor Prototype (GPP) developed jointly by ESA/CNES and 

operated at CNES/CST for the generation of Level-1 data. This algorithm to be 

documented as a series of Detail Processing Models (DPM) will be the basis for the 

implementation of Level 1 operational processors. 

○ The Image Quality Processor (IQP) system procured and operated by CNES for the 

characterisation and calibration of the sensor in-flight, and configuration and 

assessment of the ground processing algorithm implemented by the GPP and the 

PDGS. The GPP and PDGS processors will be jointly configured and tuned by Ground 










Image Processing Parameters (GIPP) generated by the IQP out of its characterisation 

and calibration activities. 

○ The PDGS for the generation and delivery to CNES/CST of nominal Level-0 products 

and preliminary Level-1 products as required by the above tasks. 

In addition, the PDGS will act as physical interface between the IQP (at CNES/CST) 

and the Sentinel-2 FOS (at ESA/ESOC) for the uplink of on-board configuration 

parameter tables. 

To support the above scenarios, CNES/CST is an integral part of the PDGS operation context 

during Phase-E1 of each spacecraft. 

4.2.6 CORE AND COLLABORATIVE PDGS 

To provision for long-term evolutions of the GSC, optimise the exploitation of its resources, 

and provide for flexibility in incorporating National contributions, the GSC operations concept 

includes the notion of a core GSC complemented by “collaborative” elements. 

The core GSC, centrally managed, aims at supplying the GMES core services as basis. In 

complement, the collaborative part aims through National or third-party contributors at 

improving the quality of the overall GSC services in performance (e.g. data-access 

timeliness) or in the range of data-supply services provided (e.g. other products). 

The PDGS operations concepts cover the core PDGS operations enabling the above 

collaborations. 

4.2.7 LOCAL STATIONS 

The Sentinel-2 system requirements [RD-01] provision for the capability to downlink real-time 

MSI acquired data directly from the Sentinel-2 spacecrafts X-Band interface to a network of 

Local Ground Stations (LGS) owned, managed and operated outside of the GSC framework. 

The Sentinel-2 satellite design accounts for such capability in its downlink budget and 

commanding capability such that real-time Sentinel-2 data downlinks can be commanded 

outside of the periods used for recovering via playback the memory recorded payload data to 

a PDGS Core Ground Station (CGS). 

Hence, the opportunities offered to LGSs for real-time data downlink will depend on the 

operational CGS network, and will be constrained by the applicable data recovery scenario 

and associated downlink budget constraints imposed by the spacecraft thermal and power 

budgets. 

In response, the Sentinel-2 PDGS will provide functionality to accommodate real-time 

downlink opportunities within the above mentioned constraints while ensuring a consistent 

data recovery scenario to the GSC Sentinels CGS network. 

4.3 Operation Constraints and Drivers 

This section reviews the major constraints having a direct impact on the PDGS operation 

concepts. It comprehensively forms the main justification reference to the overall operation 

concepts described in subsequent sections and chapters. Each constraining factor is briefly 








introduced making emphasis on its impact on PDGS operations. In turn, the derived operation 

concepts will make backward reference to each specific item as relevant. 

4.3.1 GENERAL MISSION OPERATION CONSTRAINTS 

4.3.1.1 Mission Data Products 

The Sentinel-2 mission has been defined [AD-01] after a careful analysis of the GMES user 

requirements and leading to the specifications of a global monitoring optical mission to derive 

ortho-rectified Top-Of-Atmosphere (TOA) reflectance (Level-1C) and Bottom-of-Atmosphere 

(BOA) reflectance (Level-2A) geophysical products. 

A consolidation of these requirements based on the DAP-R is provided in Appendix-A. It 

confirms the requirement for a systematic land and coastal coverage up to Level-1C. The 

requirement for the Level-2A generation is seldom and could be fulfilled by a specific 

atmospheric correction function to translate on-demand the Level-1C dataset into BOA 

reflectances. 

The satellite and MSI designs have imposed further constraints on the quality of the 

measurements in term of radiometric and geometric accuracy as described in [RD-01]. 

The above are taken as basis for the definition of the PDGS product list and characteristics. 

4.3.1.2 Mission Data Volumes 

The Sentinel-2 mission requirements [AD-01] have led to the design an unprecedented high 

spatial-resolution and multi-spectral imaging satellite system. The combination of the large 

swath (290km), spectral range (13 bands from the visible to the short-wave infrared), spatial 

resolution (10/20/60m), coupled with the global and continuous acquisition requirement with 

high-revisit frequency (2 satellites), leads to the daily generation of 1.6TBytes of compressed 

raw image data from the constellation. This corresponds to an average continuously 

sustained raw-data supply rate of 160Mbps. 

Although featuring high throughput downlink capabilities (half a Gigabit per second effective 

downlink rate), the recovery of this data on-ground will require in average 2 X-Band groundstation 

contacts per satellite and per orbit (100 minutes) (cf. [RD-19]), each one receiving in 

average half of the data acquired throughout one spacecraft revolution. 

The handling of such data rates on-ground will impose wide-ranging constraints in the 

elaboration chain to sustain the data processing, archiving and distribution to end-users in a 

reliable and timely manner. The scattering of the data into several ground-stations will add 

specific complexity to meet the seamless transportation to the user bases. 

4.3.1.3 Data Policy 

The data-policy regulating the eligibility and overall approach for distribution of the GMES 

Sentinels mission data was recently defined [RD-08] and primarily features: 









○ Open and free on-line access with no difference made between public, commercial 

and scientific use and in between European or non-European users, regulated via a 

simple user-registration process; 

○ Free of charge licensing of all data generated by the Sentinel sensors only subject to 

the conclusion of dedicated agreements regulating direct-downlink access beyond the 

GSC framework. 

This open data-policy, especially when compared to the customary approach followed in the 

past for EO data-access in Europe, represents a big step and associated challenge to meet 

user expectations. 

As regarding Sentinel-2 data in particular, it is anticipated that the on-line access to high 

spatial resolution multi-spectral images covering nearly all regions of the globe and available 

in short time after acquisition with a 5 days revisit will stimulate a very high and ever growing 

demand in particular from the general public. In this respect, the present experience of the 

United States Geological Survey institute following a similar approach for on-line open access 

to the Landsat mission archives (cf. section 4.3.5.3 as reported from Appendix-A) is recalled 

as truthful reference to extrapolate this growth of the data demand that the Sentinel-2 mission 

will trigger. 

Overall and coupled with the high data volumes estimated in section 4.3.1.2, the efficient , 

sustained and reliable Sentinel-2 data accessibility to a wide and growing user community is 

considered the main driver and constraint applicable to the PDGS design and operation 

concepts. 

4.3.2 PROGRAMMATIC DRIVERS & CONSTRAINTS 

4.3.2.1 Commissioning Phase 

The GMES Sentinel-2 Commissioning Phase is defined to have a maximum duration of three 

months after the launch of Sentinel-2A and to be repeated after the successive launches of 

each of the recurrent units. It includes LEOP, payload switch-on as well as all spacecraft and 

payload commissioning activities. 

During this phase, the GMES Sentinel-2 Commissioning Plan (S2CP) will define the overall 

commissioning phase activities at mission level (cf. [RD-03]) applicable to the spacecraft 

under commissioning. The S2CP will define the operation requirements applicable to the 

Sentinel-2 mission GS (cf. 3.6) including the FOS, the PDGS, the CNES/CST, and the EDRS 

data-relay system (if and when available) leading to the validation of the satellite for 

operations. 

As cascading from the S2CP, the PDGS Commissioning Plan (CP) will regulate the specific 

operations to be performed by the PDGS during this phase. 

For Sentinel-2A, the CP will comprehensively cover the operations required by the S2CP and 

the ones required for commissioning the PDGS services towards GSPs, general users, LGS, 

and Collaborative PDGS entities. Although applied on the actual dataflow, these interfaces 

will be simulated during this phase. 









For Sentinel-2B and future replacement units, the CP will cover S2CP requirements and 

coordinate the overall PDGS operations considering its operational state within the GSC 

versus the satellites in the operational constellation. 

EDRS data-repatriation and dissemination system interfaces will be commissioned separately 

when the respective EDRS capabilities are available. 

As applied to the spacecraft under commissioning, it is anticipated that the PDGS operations 

cascading from S2CP will require in particular: 

○ A fast planning and re-planning loop with the FOS to schedule the spacecraft 

according to the plan and deviations from the plan in case of contingencies; 

○ The operational supply of Level-0 and Level-1 data-products to the CNES/CST to carry 

out instrument in-flight characterisation and calibration; 

○ The operational supply of X-Band HKTM data to the FOS; 

○ The coordination of payload and ground processor configuration changes from CNES 

input, associated configuration control and upload as required to the satellite via the 

FOS nominal interface; 

○ The coordination with the EDRS exploitation segment for the effective planning of data 

downlinks via the OCP and the EDRS data-relay transponder; 

○ The independent assessment of the mission performance. 

4.3.2.2 Mission Evolutions 

4.3.2.2.1 Spacecraft Phase-in 

The Sentinel-2 mission program includes the gradual phase-in of spacecraft units in the 

constellation, starting with the launch of Sentinel-2B 18-30 months after Sentinel-2A 

[Assumption-03], and subsequently followed by the recurrent launches of replacement units. 

This imposes a number of constraints to sustain the operational services particularly at the 

transitory phases from the launch of a new spacecraft until its successful commissioning in 

operations. 

4.3.2.2.2 EDRS Phase-in 

The GMES Sentinels program includes the future complementary usage of the EDRS 

capacities (cf. section 3.7) starting in the 2013 timeframe as from the current plan. This 

planned rendezvous, although coinciding well in time with the availability of Sentinel-2A does 

not lead to setting-off the Sentinel-2 operational services with EDRS, and an X-Band only 

CGS network is taken as baseline. 

This programmatic constraint imposes that the PDGS operation concepts are designed with 

embedded flexibility and scalability to be able to swiftly accommodate the substantial 

enhancements brought in by EDRS for data relay, multicast repatriation and broadcast 

dissemination capabilities in the future operation baseline (cf. [RD-47]). It also imposes that 

the PDGS operations account for a significant operation baseline change while the PDGS is 

already providing its operational services based on the initial baseline. 










Other constraints related to EDRS, the OCP and their overall operability for the Sentinels has 

led to setting up a number of assumptions (cf. section 4.1) and derived constraints (cf. 

sections 4.3.8.6 and 4.3.11). 

4.3.2.3 PDGS Physical Layout and Evolutions 

As a matter of fact, the CGS network and complementary centres that will support the PDGS 

operations is at this stage not settled. 

The non a-priori knowledge at the time of design of the ground-infrastructure that will be 

selected to support PDGS operations imposes a highly flexible, modular and scalable solution 

to be used on-time considering its settled effective characteristics (e.g. CGS network and 

accessibility via networks, ground network bandwidth, major user sites, etc) and allowing for 

future evolutions. 

The operation constraints specifically related to the future choice of the CGS network are 

described separately in paragraph 4.3.10. They highlight the impacts of the CGS network 

selection and sizing on the mission performance regarding data timeliness. 

An initial CGS network will be settled according to the effective timeliness required. 

Regarding evolutions of these requirements, it is expected that the phase-in of EDRS will 

alleviate most constraints in this respect. As a backup solution, the PDGS shall have the 

required flexibility to accommodate additional X-Band ground-stations or to modify the initial 

setting to match the new requirements. 

Regarding networking and data-transportation, specific drivers directed by technology 

evolutions have been highlighted in section 4.3.6 for consideration and trade-off; 

In addition, strategic drivers are highlighted such as the maximum reuse of existing European 

infrastructure in the LTDP area, to exploit synergy with the long-term archiving already 

performed for other EO missions. 

4.3.2.4 Evolutions through Third-Party Collaborations 

As introduced in section 4.2.7, the GSC operation concepts foresee the operations of a core 

PDGS supported by collaborative entities operated separately and in harmony with the core 

system towards the common objectives of the GSC. In this extended framework, collaborative 

partners outside of the GSC framework will contribute to enhancing the global system 

performance. 

Although out of the strict scope of the PDGS, the enabling of such collaborative opportunities 

for Sentinel-2 shall be considered within the perimeter of the PDGS operation concepts as 

possible evolutions. 

4.3.2.5 Local Station Network 

As introduced in section 4.2.7, the mission calls for the capability to downlink real-time MSI 

data directly from the Sentinel-2 spacecrafts X-Band interface to a network of LGSs owned, 

managed and operated outside of the GSC framework. At this time, this local station network 

is unknown as depending on dedicated agreements to be set-up between partner 

organisations and the Sentinel-2 MMA. 








Coupled with the spacecraft operation constraints outlined in section 4.3.8 and the ones 

related to the yet undefined CGS network (cf. 4.3.2.3 and 4.3.10), opportunities of 

accommodating direct downlinks to LGSs shall be optimised within the downlink budget 

available from the spacecrafts and in compatibility with to the operational CGS layout. 

Reversely, it is highlighted (cf. section 4.3.10.2) that services to potential LGSs could be 

optimised taking advantage of some CGS placed in nearby areas and operated in parallel to 

provide Sentinel-2 RT regional data-access within the PDGS core framework. 

4.3.3 GMES-DRIVEN OPERATION CONSTRAINTS 

As a specific and dedicated mission of the GMES program, the Sentinel-2 mission inherits 

general operation constraints derived from the specific role that the GSC will hold versus 

GMES operational services. Hence, the operation concepts of the GSC globally apply to the 

Sentinel-2 mission operations and in particular to the PDGS acting as front-end to the GSC 

operational interfaces regarding access to Sentinel-2 data. 

To this end, the PDGS operations will aim for: 

○ High availability, reliability and quality of service versus the GSS and in particular the 

GSPs entitled as GSC consumers and primary users of Sentinel-2 data. This implies 

continuous and “guaranteed” data access services available to GSPs to enable the 

operational exploitation of Sentinel-2 data for downstream operations; 

○ Robustness vis-à-vis maintenance and upgrade activities (e.g. for new spacecraft 

phase-in) inducing no impact on the service provision by degrading the baseline 

operational performances; 

○ Compliance with the European INSPIRE directive for services definitions; 

○ Sustainability, requiring minimal operational effort to run and maintain the baseline 

quality of service; 

○ Flexibility and scalability towards mission operation evolutions potentially required by 

the GMES program in the long-term, such as to integrate complementary services for 

evolving GSP requirements (e.g. extension to downstream services); 

○ A long-term outlook to ensure availability of the mission data and associated services 

in the future, considering the extended lifetime for spacecraft operations (cf. section 

3.3), the gradual phase-in of replacement units and the required sustaining of 

operations on the mission archives well beyond initial operations. 

4.3.4 GSCDA OPERATION CONSTRAINTS 

As any GCM versus the CSGDA, the Sentinel-2 PDGS operations must comply with the 

defined GSCDA operational scenarios and constraints defined in [AD-02]. This implies in 

particular the offering of operational interface services vis-à-vis the GSCDA operated systems 

with well-defined mechanisms. 









4.3.5 LESSONS LEARNT 

4.3.5.1 General Returns of Experience 

General returns of experience are maintained by ESA in a strategic document [RD-17] 

relevant to PDGS designs and operation concepts. As part of the general practices 

recommended, a “data-driven” approach for data-handling is advocated to best match to the 

indeterminist and complex nature of EO satellite missions and adapt to their generated dataflow 

in a reliable and scalable manner. 

This approach is particularly applicable to the Sentinel-2 mission which despite the overall 

systematic nature of the sensor acquisition plan, imposes that the data effectively acquired 

and recovered on ground is geographically scattered in ground-stations depending on varying 

factors such as target illumination conditions, timeliness constraints, and other mission 

operation features impacting on the effective dataflow (e.g. manoeuvres, calibration 

requirements, etc). This constraint is considered a primary driver to reach reliable PDGS 

operations and a scalable design. 

4.3.5.2 Long-Term Data Preservation 

The Ground-Segment Coordination Body (GSCB) has recently issued draft coordinated 

European guidelines [RD-18] in the Long-Term Data Preservation (LTDP) area, to ensure 

availability of EO data along the years, based on synergy and coordinated procedures 

interoperable among the various EO mission actors. 

Those guidelines are considered as reference practices relevant in the large part to 

preserving the Sentinel-2 mission data along time as required by the GMES program (cf. 

4.3.2). 

It is further highlighted that the collaborative opportunity provisioning for interoperable data 

mirroring through third-party operated centres (cf. sections 4.2.6 and 4.3.2.4) could further 

contribute to the LTDP objective. 

4.3.5.3 Landsat On-Line Data-Access Experience at USGS 

The Sentinel-2 PDGS will generate an unprecedented amount of data and distribute it under 

a very open Data-Policy [RD-08]. As compared to the present supply of high spatial resolution 

multi-spectral data in Europe, Sentinel-2 will offer free-access, on-line, global and continuous 

earth coverage. 

This year, the United States Geological Survey (USGS) has faced a similar challenge after 

opening to the public the Landsat archive at no charge. It was stated by USGS: 

“Since the USGS opened its full Landsat archive to user access at no charge last October, 

the response from across the nation and around the globe has grown exponentially. “ 

It can thus be anticipated an at least equivalent demand for Sentinel-2 products and even a 

higher order of magnitude considering the unprecedented product data volumes generated by 

the Sentinel-2 constellation. Section A.5 in Appendix-A summarises a few facts on the 









Landsat experience and they are extrapolated for Sentinel-2, leading to a first estimate of 

400Tbytes as yearly supply requirement. 

In this respect, the ability of the PDGS to scale adequately to this short-term to long-term 

evolution, planned or unplanned, is considered a major PDGS driver to meet the Sentinel-2 

mission objectives in the long-term. In this sense, scalability is focusing on the accessibility to 

data down to the download from the user base. 

4.3.5.4 G-POD Experience at ESA 

Since 2007, ESA is running a collaboration opportunity for conducting Earth Science research 

activities through the use of ESA’s Earth Observation Grid Processing-on-Demand (G-POD) 

environment [http://gpod.eo.esa.int], called the G-POD CAT-1 Opportunity [RD-36]. This 

opportunity, performed in partnership with end-users, has the main purpose of stimulating the 

use of global EO mission archives, offering attached computing infrastructure and tools with 

on-line access to data to assist the generation of scientific added-value products. 

Since then, wide-ranging projects are supported under this collaboration framework whereby 

the scientific or institutional partners run their own data-processors in the shared G-POD 

environment and process large amounts of data while tailoring it to their specific needs, 

including: 

○ The prototyping, development and validation of new algorithms requiring large 

amounts of long-term data and processing resources; 

○ The timely extraction of long-term time series of lightweight data from Terabytes of 

mission archived data; 

○ The swift on-demand pre-processing of new or past EO data in direct response to 

urgent data supply needs. 

As combining the dual roles of an on-line investigation laboratory and a powerful operational 

production system, the G-POD opportunity tends to extend to supporting more and more 

sustainable services and productions. The following outcomes are highlighted in particular: 

○ A large number of Level-2 or Level-3 products from Envisat, ERS or third-party 

missions are operationally hosted on G-POD as derived from the G-POD CAT-1 

opportunities and other ESA projects; 

○ New Level-2 products resulting from the G-POD collaboration opportunities are being 

sustained in production and take part to the operational data-supply services of the 

GSC/DAP (DAP_MG3_02 Data-Set [RD-10]). 

○ G-POD hosts since October 2009 the on-demand service for emergency response 

called FAIRE (Fast Access to Imagery for Rapid Exploitation) supporting the 

preparation of crisis mapping data (spatially registered and ortho-rectified time series 

of ERS/Envisat SAR images) for the Internal Charter Space and Major Disasters 

[http://www.disasterscharter.org]. 










Figure 4-2 Illustration of the G-POD FAIRE Service 

The hosted-processing approach recently demonstrated on G-POD brings the following 

benefits regarding the enhancement of GSC services by means of third-party collaborations 

outlined in section 4.2.6 for Sentinel-2: 

○ It allows the tight coupling of third-party provided processors within an operational 

production system hence allowing for operational sustainability of service 

enhancements; 

○ It eases the test-bedding and thorough validation of new complementary Sentinel-2 

value-added products (e.g. Level-2B) on large datasets before operational transfer, 

while avoiding bulk product transportation operations commonly required for algorithm 

development; 

○ It enables the development of high-performance downstream services in collaboration 

with GSPs whereby the GSP-proprietary value-added processors can be remotely 

operated in the PDGS either on-demand or systematically being hooked on the 

incoming Sentinel-2 data-flow. 

Since it is expected that most information products likely to be developed by GSPs 

from Sentinel-2 data will be substantially reduced in size compared to the base 

products (e.g. land classification maps, flood extents, etc), this approach will contribute 

to solving data-access issues (and associated large-bandwidth network demands) by 

transporting the user processors close to the data source instead of the opposite. 

○ It eases the management of Intellectual Property Rights (IPR) associated to the 

operational deployment of new GMES products and services while allowing for a well 

balanced sharing of a common GSC infrastructure. 

It is also highlighted from the G-POD experience that dedicated support is required on the 

GSC side to enable the collaborations. At present, G-POD hosted-processing collaborations 

follow the collaborative model described in [RD-37] defining the respective roles on both sides 

of the partnership and an outline of the collaboration workflow. 

4.3.6 TECHNOLOGY EVOLUTION DRIVERS 

Whilst spacecraft design and operations is primarily constrained by the available space 

systems technology, PDGS designs are primarily based on common data-handling 

technology which evolves at a much higher rate thanks to other application actors and wide 

ranging businesses involved in driving technology evolutions. In particular, the recent and 

ever developing advances in the handling of digital media over the Internet down to home 








computers are important drivers to take into account as gradually releasing the constraints 

imposed for data management and transportation. In particular, the following technology 

areas are considered as particularly relevant to the definition of the PDGS: 

○ The ever growing throughput capacity of digital communication networks, their access 

costs, and reaching of end-user bases throughout developed and less developed 

countries; 

○ The ever growing capacity of physical media for digital data storage, their affordability, 

reliability and plug-and-play capabilities into wide-ranging hosting hardware; 

○ The ever growing performance of CPUs and their high-performance coupled solutions 

with mass storage systems (e.g. Storage Area Networks), and the new flexibility and 

reliability offered through blade technologies for overall limited investments; 

○ The every growing availability and maturity of Internet based services related to on-line 

data storage, publishing and computing (e.g. e.g. Content Delivery Networks, “Cloud- 

Computing”, etc); 

○ The overall maturing standardisation and interoperability of all digital media 

management components in terms of hardware, software and services. 

Although the capacity of communication networks is expected to grow substantially with the 

years, it will also be required to support the parallel transportation of more and more media. It 

is hence expected that the share of public or private networks to transport earth-observation 

data will not necessarily gain remarkable growth to sustain an exponentially growing demand 

at reasonable costs (cf. 4.3.5.3). On the other hand, specific solutions are advertised by 

Internet carriers in their development trends in that the effective bandwidth of digital-data 

transportation can be optimised by replication and localisation of the data close to the 

consumers (e.g. P4P technology, GoogleEarth, etc). 

The maturing opportunities offered through Content Delivery Network (CDN) services to 

match highly non-deterministic and growing demands of data from the general public is 

highlighted as an interesting prospect relevant to the publishing of Sentinel-2 images via 

Internet with the required scalability. The use of this technology is widely used in particular at 

ESA for web-publishing as providing guaranteed scalable solutions via well-defined service 

level agreements. 

The opportunities currently emerging under the labelling “cloud-computing” are also of 

interest as fostering the remote access “as a service” to storage and processing resources 

provided over the network. This technology will potentially bring cost-effective trade-off 

solutions to maintenance and swift scalability of data-management infrastructures (e.g. for 

bulk data reprocessing). Nevertheless, these services are currently impaired by the 

preliminary data uploads required to the remote “cloud” infrastructures, a pre-requisite to take 

benefit of the services whilst creating a direct bottleneck for high-volume demanding 

applications such as EO data processing and publishing. The lack of standardisation and 

interoperability between suppliers in this area can also be considered a non negligible risk, of 

being constrained in operations with a particular supplier after the upload investment. 









4.3.7 FOS OPERATION CONSTRAINTS 

4.3.7.1 Mission Schedule Uplink and Mission Planning Loop 

Whilst the PDGS will be responsible for generating the satellite plan including payload and 

downlink activities, the FOS will be in-charge of translating it into a spacecraft understandable 

schedule and to uplink the derived schedule to the spacecraft in advance of operations using 

the S-Band channel operated from the TMTC station in Kiruna (Sweden). As such both PDGS 

and FOS work-flows for mission planning and scheduling will have to be coordinated. 

The mission planning operations to be performed by the PDGS will be constrained by the 

FOS operation concepts themselves cascading from spacecraft capabilities and constraints 

regarding scheduling and uplink. 

The FOS will support two complementary operation scenarios for schedule uplink: 

○ A nominal uplink scenario, activated recurrently every two weeks to increment the onboard 

plan with the 15 subsequent days of autonomous on-board operation; 

○ An unplanned uplink scenario, to be used for re-planning, activated on-request and 

allowing altering the on-board plan in parts or as a whole down to a couple of days 

before its execution on-board. 

The S-Band uplink opportunities are constrained to be performed during working-days and at 

specific Kiruna passes pre-allocated for Sentinel-2 as depicted on Figure 4-3. Two uplink 

opportunities are pre-booked for each Sentinel-2 spacecraft, one nominal pass and one 

backup pass to provision for contingency at FOS level. 

Figure 4-3 Sentinel-2 Schedule Uplink Opportunities via S-Band 









Before uplink-time, the FOS requires the PDGS to provide the mission planning input in 

advance of actual operations with typically 3 working-days margin to allow for contingency 

handling on the mission-planning loop if needed. This margin may be reduced down to one 

working day in case of required spontaneous re-planning as for instance during the 

commissioning phases. 

4.3.7.2 MSI Parameter Tables Uplink 

Some MSI parameter tables (cf. section 3.5.2.4) driving the instrument performance will be 

managed under controlled configuration in the PDGS. In counterpart, the FOS will be in 

charge of the uplink and activation operations whenever a change on the MSI configuration is 

needed e.g. after PDGS Cal/Val activities. 

For table uplink, the FOS will apply the mechanisms reflected in [AD-03]. Depending on the 

table, uplink operations will be carried out either via specific telecommanding, or through the 

generic patch functionality of the OBC (PUS service 6). In all cases, uplink will be performed 

through the S-Band 64kbps TC channel (cf. 3.5.6) using the appropriate PUS services and at 

the specific S-Band contact opportunities dedicated to Sentinel-2 as presented in the previous 

paragraph. 

While most parameter tables are expected to be of relatively limited size and be associated 

with very seldom required updates, the NUC table will weight about 2 Mbytes and is expected 

to need recurrent fine-tuning at a frequency ranging from two weeks to several months to 

maintain the quality of the measurements over time. Due to the size of the table, a specific 

uplink scenario is defined in [RD-28] which will require delta-uplink functionalities provided 

through the PUS service 6, as well as an accurate coordinated planning between PDGS and 

FOS embedding automation to the maximum feasible extent. 

4.3.7.3 HKTM Delivery Constraints 

As introduced in paragraph 3.5.4.3 and detailed in SOCD [AD-03], the HKTM data is 

systematically recorded on-board and can be downlinked independently from MSI data trough 

one of the 280Mbps X-Band channels to PDGS-managed ground-stations. 

To allow for spacecraft operation and safety monitoring during the complete orbit, the FOS 

requires that this data be systematically supplied by the PDGS. It further requires that HKTM 

data increments be provided with an update frequency of no less than once per orbit and 

delivered at a defined FOS interface within maximum one hour from data-reception at the 

PDGS. 

4.3.8 SPACECRAFT OPERATION CONSTRAINTS 

The Sentinel-2 PDGS operations concept is highly driven by the satellite capabilities and 

constraints described in [AD-03]. This section reviews the one having a direct impact on the 

PDGS operation concepts. Details on each of the introduced factors are provided in specific 

sections making emphasis on the impact on PDGS operations, mostly at mission-planning 

level. 









4.3.8.1 MSI Detectors Parallax 

As outlined in section 3.5.2.2, the MSI includes two distinct arrays of 12 detectors mounted on 

different focal-planes (VNIR & SWIR) each one distributing the detectors onto two alternate 

lines on the focal-plane. This design makes the sensing footprint on the start and end of each 

acquisition not homogeneous between the spectral bands and detector modules. 

This derives into an operation constraint for the MSI acquisition planning such that previous 

data to the area of interest (data around to the “advanced switch-on” showed in the figure 

below) and next adjacent data (next to the “delayed switch-off”) will be required to avoid gaps 

in the PDGS production timeline due to the sensor different viewing conditions. 

Figure 4-4: Sentinel-2 MSI footprint 

4.3.8.2 MSI Data Downlink Discontinuities 

RT direct-downlinks to core stations or the NRT prioritisation of the MSI data takes in the 

MMFU data-store, together with the need for several X-Band station visibilities (nominally two 

per orbit revolution) to recover the data on-ground, will after playback generate discontinuities 

on the timeline received at the CGSs. 

Figure 4-5 depicts a typical MSI acquisition timeline with several continuous imaging 

segments and the MSI packet store playback timeline onto two distinct ground-stations where 

some MSI data-takes are transmitted in RT and others have been prioritised for NRT 

downlink. 









Orbit N-1 descending part 

Orbit N descending part 

`CGS-A 

CGS-B 

MMFU MSI packet store playback timeline 

Explicit playback 

interruptions 

MSI imaging timeline 

NRT NRT Nominal 

ocean 

NRT 

RT 

CGS-A 

CGS-B 

Spurious data discontinuities 

introduced in the station RX timeline 

Figure 4-5: MSI Timeline Discontinuities after Downlink 

It shows that as seen from the two distinct timelines received at each ground-station three 

kinds of discontinuities have been added to the overall MSI acquisition timeline: 

○ Discontinuities introduced due to the playback being explicitly suspended at the term of 

CGS-A and CGS-B visibilities at orbit N (green bullets). 

To be noted that is not always the case as it may happen that the packet store is 

actually emptied at the end of a station pass in which case the playback is stopped 

naturally and no artificial discontinuity is introduced; 

○ Discontinuities introduced by the NRT partitioning leaving orphan segments and 

corresponding gaps in the MSI timeline (orange bullets); 

○ Discontinuities introduced by the RT direct-downlink segments having similar impact 

(red bullets). 

It is assumed that the discontinuities will be introduced with a granularity of exactly one MSI 

on-board scene acquisition (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. 

These discontinuities coupled with the MSI observation parallax described in the previous 

paragraph would induce a specific complexity in the timeline reconstruction required onground 

to ensure band co-registration in the final products. 










As introduced in section 3.5.4.3 and in order to simplify the PDGS operations, the MMFU 

supports through appropriate commanding (cf. [RD-41]), the functionality of appending a 

margin of three imaging scenes at the discontinuity boundaries. This enhanced functionality 

shall be used by the PDGS mission planning element such that data circulation on ground 

between processing stations or centres, which otherwise would be required for dataprocessing, 

is avoided. 

4.3.8.3 MSI Duty Cycle 

It is anticipated [AD-03] that the MSI shall not stay longer than 50 min [TBC] continuously in 

idle mode or any measurement mode during an orbit for derating reasons. This constraint is 

at present TBC and will be better qualified at a later stage. 

4.3.8.4 X-Band Operation Constraints 

Two main constraints are highlighted for the X-Band subsystem operations as per [AD-03]: 

○ Duty-Cycle: As per the current baseline, the satellite thermal and power/energy 

accommodation of the X-Band System is capable of at least 24 minutes of continuous 

downlink per orbit. 

This limit figure will be better qualified at a later stage and it is already expected that 30 

minutes should be achievable after characterisation and tuning of system parameters 

(e.g. Albedo factor, operational temperature range of the modulators, X-Band OPS- 

STDBY duty cycles). 

○ Lifetime Number of Cycles: The X-Band system is specified for an overall number of 

operation cycles (from standby to operation and back) equal to 100000 (one hundred 

thousand) for the mission lifetime. Considering the extended lifetime of 12 years, this 

figure derives into an average number of continuous X-Band transmissions per orbit of 

about one and two third (1.6). 

Within the above duty-cycle constraint, it is assumed 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 during the time separating two successive data-downlinks to groundstations. 

In this case, it is assumed the carrier will be automatically switched off. 

This approach is aimed at minimising the number of XBS switches during nominal operations 

that will generally require two station contacts per orbit. The X-Band ground reception system 

will hence be constrained such that it is as a whole narrowed to some extent within 24 

minutes of satellite over-fly time for one third of the orbits, with a margin allowing for one 

additional operation cycle to reach station contact beyond the 24 minutes for the remaining 

orbits. 

The above constraints will be considered in particular for the selection of the CGS network to 

be operated for Sentinel-2 and for the further accommodation of LGS opportunities. 

4.3.8.5 Asynchronous Management of Ancillary and MSI Data 

As outlined in paragraph 3.5.4.3, the satellite ancillary data is required to perform MSI dataprocessing 

on-ground. This data is continuously recorded on-board into a dedicated packet- 








store managed independently and asynchronously with respect to the one holding the MSI 

generated data. 

To enable MSI processing activities, the PDGS will have to ensure, that the ancillary data 

coinciding in time with the MSI data downlinked at a specific CGS or LGS is systematically 

appended to the downlink. This synchronisation will be possible with adequate planning 

taking into account the specific operation constraints and capabilities of the on-board MMFU 

defined in [AD-03]. 

4.3.8.6 OCP Operation Constraints 

The spacecraft operation constraints related to the use of the OCP are currently being 

qualified and quantified. 

Similarly to the XBS, it is assumed that 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. 

Also, it is anticipated that micro-vibrations induced by the movement of the OCP in tracking 

the GEO spacecrafts in-flight may constrain the parallel operations of the MSI. Such 

constraints will be better quantified at the QR of the OCP currently assumed at a TBD date. 

4.3.8.7 Constraints not implemented by the PDGS 

During orbit control and in case of attitude problems, the MSI shutter shall be closed to 

protect the instrument. It is assumed this constraint will be managed autonomously by the 

spacecraft in case of attitude problems and by the FOS otherwise. 

4.3.9 MSI DATA PROCESSING CONSTRAINTS 

As briefly outlined in section 4.2.5, the CNES in collaboration with ESA has consolidated the 

specifications of the Sentinel-2 Ground Processing Prototype (GPP). The GPP on-going 

activity will be used as basis for the definition and validation of the PDGS operational Level-1 

processing. In particular, it includes the definition of the Sentinel-2 Level-1 data processing 

algorithms as Data-Processing Models (DPM) which will describe in details all algorithmic 

steps and workflows required to derive the Level-1 data from the raw instrument data 

received from the satellites. It will also provide reference data from which the PDGS 

generated Level-1 products will be validated before and during the commissioning phase. 

Building on the Level-1 algorithm outline specified for the GPP, this section recalls the main 

constraints imposed by the algorithms, with specific focus on the ones considered as main 

drivers to the definition of the processing flow to be implemented operationally by the PDGS 

from data reception to product delivery. 

4.3.9.1 Radiometry Processing Constraints 

For Level-1 production, the radiometric processing mainly consists in decompressing the 

mission source packets (Level-1A processing) and then applying the appropriate radiometric 

corrections (part of Level-1B processing). 









Those processing steps are theoretically applied on a continuous input image flow 

corresponding to the data generation process performed on-board. As such, they require 

small portions of image data acquired along-track before and after the data to be processed 

hereafter referred to as “radiometric processing margins”. 

The overall processing margin is computed by adding up the different contributions needed 

corresponding to slightly more than 10% of a scene as reported in [RD-30]: 

○ For the decompression step (Level-1A), 32 lines of each band are required before and 

after. The worst-case corresponds to 1/12 th of a scene for 60m bands. 

○ For the deconvolution of 10m bands (Level-1B) 50 image lines are required before and 

after. This corresponds to slightly less than 1/46 th of a scene. 

4.3.9.2 Geometry Processing Constraints 

4.3.9.2.1 Image Datation 

The image datation model is a key element for the geolocation accuracy of the final products. 

Referring to the datation process performed on-board as summarised in paragraph 3.5.2.3.3, 

a global error-budget was computed (cf. Table 4-1 below) based on Bias (B) and Rate (R) 

error-budget figures inherited from the instrument design. 

The first column represents the overall accuracy obtained with raw time stamp information 

(CUCM_s), and the second one represents the one corrected though the MSI internal 

correction (Δ_s). 

Contributor Type Budget based on MSI CUC time taking 

into account internal time correction (Δ s) 

Scene start time B 

R 

+/- 0.119 µs 

+/- 0.09 µs 

Scene duration B 

R 

+/- 0.428 µs 

+/- 0.06 µs 

Integration period B 

R 

+/- 0.001 µs 

+/- 0.01 µs 

Total 

B 

R 

+/- 0.548 µs 

+/- 0.109 µs 

B+R +/- 0.657 µs 

Table 4-1 Datation Accuracy Budgets 

This ±0.657μs datation error resulting from the enhanced time correction performed on-board 

is expected to contribute to less than 0.5 cm on-ground when reported on the geolocation 

error budget, which is negligible. 

As return of experience from previous missions, a refinement of the datation model was 

nevertheless recommended and will be implemented in the GPP as an optional processing 









step. This method is commonly used to correct potential noise (jitter and/or drift) on the time 

stamp delivered by the on board clock and inserted in the image data. It consists in an 

adjustment of the time stamp of each image line (thanks to root mean square method) 

computed over the overall imaging orbit. This processing option will be activated during 

commissioning phase to validate the above figures in-flight by GPP. 

4.3.9.2.2 Band Co-Registration Constraints 

As described in section 3.5.2.2, the instrument focal plane staggered configuration induces an 

inter-band and inter detector parallax (also referred to as the B/H stereoscopic effect). 

Similarly to the radiometric corrections, fore and aft processing margins hereafter referred to 

as the “geometric processing margin” will be required to reconstruct the inter-band coregistration. 

Depending on the geometric processing performed, the fore and aft processing 

margins will be different: 

○ As applied to one single detector processing, the processing margin will correspond to 

the maximum inter-band parallax equal to 14km along-track hence corresponding to 

about 2/3 rd of a scene. 

○ If applied to all detectors at once for the entire MSI swath reconstruction across-track, 

the processing margin would correspond to the maximum inter-detector parallax equal 

to 46km along-track (maximised for band B9) hence corresponding to two MSI 

scenes. 

4.3.9.2.3 Spatial Registration 

The stringent requirements of multi temporal registration (less than 0.3 pixels for 10m bands, 

cf. section 4.4.4.1) lead to improving the location accuracy though the refinement of the 

geometric model based on automatic registration with ground control points (GCPs) using an 

reference image. 

This geometric refinement process will correct perturbations which are not detected by the 

AOCS sensors (star trackers, GPS, gyros) by estimating the perturbations on the image itself 

and modelling polynomial corrections derived from the measured GCPs. 

To be optimised, this refinement shall be applied on the largest possible number of GCPs, 

ideally extracted from the complete imaging orbit. Expected perturbations of this correction 

possibly induced by refining the geometry using smaller image portions is reported in [RD-30]. 

In particular, it was concluded that spatial registration will be achieved with sufficient accuracy 

if applied on a continuous segment of image data of no less than 60km along-track over the 

full swath. 

In addition, it is anticipated that although spatially co-registered over the same image 

reference, the stitching of two images registered independently using different sets of GCPs 

could introduce visual discontinuities at the sewing boundary (at sub-pixel level). 

Whereas the geolocation error budgets of the spacecrafts theoretically allow for a polynomial 

based refinement model as currently specified, it is anticipated that potential thermo-elastic 

effects of the MSI could add local perturbations to the measurements which could in turn 

induce small discontinuities between the geometric models constrained independently. 









To remove this effect it is recommended to introduce small image overlaps in the GCP 

extraction step such that GCPs located in the overlap portion will constrain both geometric 

models together hence minimising potential discontinuities after refinement. The sizing of the 

required overlaps is in the order of 25-50km, i.e. of one or two MSI scenes. 

4.3.9.2.4 Resampling 

The spatial resolution of the MSI sensor measurements ranges from 60 meters down to 10 

meters on-ground. To adapt the native geometry of the sensor acquisitions to a final image 

usable by Sentinel-2 product users, the MSI Level-1 algorithm features an orthorectification 

step together with a resampling step mapping the instrument pixels into the final geocoded 

space. 

The resampling step is performed for each spectral band using a resampling grid and an 

interpolation filter. This transformation, if not correctly applied, will impair the quality of the 

final image due to the aliasing effect induced by the geometric transformations performed in 

the discrete (non continuous) pixel space. To avoid this perturbation, driving 

recommendations for the choice of the interpolation filter and resampling grid spatial 

resolution relatively to the MSI native resolution are provided in [RD-30]. 

4.3.9.2.5 Digital Elevation Model 

MSI Level-1C processing will require a fine spatial resolution Digital Elevation Model (DEM) of 

DTED1 class (resolution of 3 arcsec i.e. about 90 meters). Three DEM based on SRTM 

(Shuttle Radar Topographic Mission) data (http://edc.usgs.gov/products/elevation.html) are 

highlighted as appropriate candidates: 

o An SRTM-filtered DEM from JRC (http://srtm.csi.cgiar.org/); 

o An SRTM-filtered DEM from CNES; 

o ACE2 DEM from ESA which combines SRTM and radar altimetry data 

(http://tethys.eaprs.cse.dmu.ac.uk/ACE2/). 

SRTM DEM has an absolute horizontal accuracy (90% circular error) of 20 meters and an 

absolute vertical accuracy (90% linear error) of 16 meters. Considering the maximum view 

zenith angle of Sentinel-2 (10.26° at the edges of the swath), the vertical error of the DEM will 

translate in an absolute geolocation uncertainty of about 2.9m (90% linear error) which is not 

a dominant contribution within the overall absolute Sentinel-2 geolocation uncertainty budget. 

As being based on SRTM data, the first two DEMs do not cover the entire globe and only 

span between 60° North and 60° South latitudes (i.e. about 80% of all land areas). 

ACE2 DEM has been created by synergistically combining Satellite Radar Altimetry data with 

SRTM data within the region bounded by ±60 degrees latitude. Over the areas lying outside 

the SRTMs latitude limits, other sources have been used such as including GLOBE and the 

original ACE DEM, together with new matrices derived from reprocessing ERS-1 Geodetic 

Mission dataset with an enhanced retracking system, and the inclusion of data from other 

satellites. The quality of ACE2 DEM is slightly better than SRTM especially over steep 

mountainous regions. 









Over oceans or open seas, the WGS84 geoid altitude is considered. Presently WGS 84 uses 

the 1996 Earth Gravitational Model (EGM96) geoid, revised in 2004. Over land and inland 

waters, the altitude information is given with respect to the geoid altitude reference EGM96. 

4.3.9.3 Data Compression versus Data Quality Trade-Off Constraints 

An average acquisition of 6640 km along the Sentinel-2 orbit will amount to about 60GBytes 

of on-board compressed raw instrument data. Therefore the daily amount of compressed data 

received on-ground will result to about 887GB per satellite. Besides issues related to data 

processing and storage, these large volumes raise a non-negligible constraint for the efficient 

dissemination of final products to end users. Indeed, it was computed that a Sentinel-2 

square image of 290km x 290km comprehensive of all spectral bands will weight around 7.4 

GBytes without any compression. 

Hence, a data-compression step is provisioned for at the term of the MSI processing cycle. 

Nevertheless, data-compression shall be controlled such as to avoid jeopardizing image 

quality. To this end, a preliminary trade-off analysis based on the standard JPEG2000 

compression algorithm is reported in [RD-30] to support the optimal selection of this 

compression step. 

4.3.10 CONSTRAINTS AND DEPENDENCIES DRIVEN BY THE CGS 

NETWORK 

As a matter of fact, the CGS network that will support the PDGS operations is at this stage 

not settled. This section reviews the constraints and dependencies associated. 

4.3.10.1 Near-Real-Time Data Timeliness 

The large MSI mission data-rate and global acquisition plan coupled with the available CGS 

network selected to recover the payload data on-ground will constrain the amount and data 

that can be provided with NRT timeliness, while ensuring that all data can be provided within 

a day. 

Based on [AD-03], it is assumed that about 25% of the globally acquired data by one 

spacecraft can be downlinked with NRT-compatible timeliness when using a suitable CGS 

network of 4 stations. It was also calculated that a payload data recovery plan leading to 

100% of NRT-compatible timeliness can be obtained using a network of about 6 

complementary ground-stations. 

Figure 4-6 extracted from [RD-19] depicts the distribution of the age of the data at the time it 

is acquired on-ground, without zone prioritization for NRT playback, and considering a CGS 

network composed of the Kiruna, Svalbard, Maslapomas, and Prince-Albert stations. In this 

simulation, the globally averaged timeliness amounts to 6.298 hours at data-reception time. 

When using the NRT priority downlink functionality outlined in section 4.5.4.2.2 ensuring that 

specific zones are acquired with NRT-compatible latencies, the remaining global timeliness 

distribution may be altered significantly; Figure 4-7 shows that in the same 4 stations 

scenario, prioritizing Europe for NRT timeliness makes the geographical distribution of data 

age vary meaningfully with respect to the routine scenario. 









Figure 4-6 Average age of the sensor data (in hours) at the time of acquisition on-ground at a 

CGS network composed of Kiruna, Svalbard, Maslapomas, and Prince-Albert stations 

Figure 4-7 Summer distribution of the data-age at the time of acquisition on-ground with 

Europe promoted for availability with NRT-compatible timeliness 

The latency over Europe does not exceed 4 hours (the major part with an age inferior than 2 hours), but the 

longest latency appears in new zones like South of Africa and areas near Iran. In this scenario, the maximum 

data latency value has increased to 7.6878 hours instead of 6.3 hours obtained for the routine scenario. 









In summary, the global downlink capacity offered by a well distributed CGS network to 

recover the data on-ground is the major driver impacting Sentinel-2 data timeliness. 

As illustrated on Figure 4-8, it was simulated that, starting from the 4-stations CGS network 

baselined in [AD-03], the global data availability with NRT-compatible timeliness can be 

achieved by adding two complementary stations. 

Figure 4-8 Simulated global NRT-compatible data-age on-ground using a CGS network 

composed of Kiruna, Svalbard, Maslapomas, Prince-Albert, Matera and Gatineau stations 

4.3.10.2 Real-Time Data Timeliness 

Based on the mission requirements, the spacecraft design includes the capability to downlink 

the payload data in real-time as soon as it is acquired by the instrument. Although primarily 

aimed at serving regional data to ground-stations operated outside of the GSC framework, 

such capability could be used over a limited number of core stations to achieve data 

availability in real-time. 

Considering that the nominal data supply rate of the MSI (490Mbps) is comparable to the 

downlink rate (520Mbps), transmitting data in real-time would not represent a large overhead 

on the overall downlink budget if used seldomly. 

For instance, it could be considered that by operating one CGS located over Europe for 

acquiring Sentinel-2 direct downlinks during descending passes, real-time data timeliness 

could be achieved regionally over Europe. As another benefit, this would allow any LGS 

placed under the CGS mask to receive in parallel the Sentinel-2 direct downlinks performed 

over that station. Figure 4-9 depicts (in yellow) the complete coverage of all European 

countries achievable using one CGS. 









Figure 4-9 Real-Time Land Cover over Europe using one X-Band CGS 

4.3.10.3 Data Accessibility 

The mission requirements [AD-01] coupled with the GMES service requirements call for some 

data to be available from the PDGS right at the user bases in short time after sensing from 

the spacecrafts. 

As described in the previous paragraph, a first constraint to this is imposed by the CGS 

network driving the overall amount of data that will be recovered on-ground with “NRTcompatible” 

timeliness. Supposing the PDGS can elaborate higher-level products directly at 

ground-stations in no time, a second constraint inherent to the CGS network is driven by the 

potential of ground-stations to serve the generated data products downstream to the final 

user bases. 

Considering the physical locations of ground-stations, their potentially limited connectivity to 

user-bases via digital networks may become a non-negligible bottleneck in the overall path, in 

turn impacting on data accessibility of the large Sentinel-2 datasets from data consumers. 

This constraint may hence impose specific trade-offs on the overall operation scenario such 

that, based on the selected CGS network, the NRT data-path is globally optimised from 

sensing down to the user-base avoiding the connectivity bottlenecks at remote groundstations 

having reduced connectivity towards end-users. 





4.3.10.4 X-Band Downlink Conflicts between Sentinel Missions 





As it has been the case for the TMTC interface to the Sentinel spacecrafts in S-Band leading 

to the pre-defined allocation described in section 4.3.7.1, potential conflicts among Sentinels 

are also anticipated for the share of X-Band resources considering that: 

○ The GSC aims for maximised common and interoperable usage of ground-segment 

resources. This particularly applies to the Sentinels and to the common use of X-Band 

ground-stations; 

○ X-Band LEO-capable ground-stations are considered a scarce resource considering 

the overall number of EO missions in flight, the required locations of ground-stations 

and the investments they represent; 

○ The data-rates introduced by the Sentinel missions and the dual spacecraft approach 

for each mission require overall a very large number of X-Band station contacts to 

recover the data on-ground; 

○ The mitigation of the required X-Band downlink resources via the use of EDRS are at 

this stage only considered as a potential future evolution. 

In this respect, an on-going analysis is performed by ESA and concludes in a preliminary 

analysis report [RD-29], that manageable but non-negligible X-Band access conflicts are to 

be expected to support the increased volumes brought in by the Sentinels. 

The X-Band downlink conflicts across the Sentinels missions can be classified as follows: 

 

Signal interferences on ground when performing simultaneous X-Band downlinks: due 

to the X-Band shared frequencies and different orbit cycles of the Sentinels, 

simultaneous X-Band operations can produce seldom RF interferences; 

Ground-stations resource conflict: in which the spacecrafts visibility over a groundstation 

do not constrain simultaneous RF activities but the available allocated onground 

resources (i.e. antennas availability); 

The Sentinel-2 PDGS will hence account for these constraints when planning the mission 

data downlinks to CGS and LGS such that: 

Sentinel-2 X-Band transmission activities during specific periods can be precluded due 

to other Sentinels (Sentinel-1 and/or Sentinel-3) conflicting X-Band activities having 

priority during those periods; 

Among all X-Band downlink opportunities offered by the CGS network for Sentinel-2, 

some can be precluded or shortened by configuration due to prioritised access to the 

CGS available antennas by other Sentinels; 

It is assumed [Assumption-19] that based on the CGS and LGS networks, a conflict-free 

coordination among Sentinels will result in a predefined definition of the above constraints 

applicable to each Sentinel satellite in orbit. 









4.3.10.5 Contact Overlap Management Constraints 

Specific operation constraints of the CGS network may have to be considered for optimisation 

purposes related to the management of overlapping downlink opportunities within the 

network. Although mostly applying to the case of complementary polar X-Band CGSs more 

inclined to share a common coverage of the LEO orbit (e.g. Svalbard, Kiruna, Tromsoe, etc), 

optimisation may have to be generalised in particular for the relative apportioning of X-Band 

ground-station contacts with respect to time-overlapping data-relay contacts when EDRS 

capabilities will be included. 

4.3.11 CONSTRAINTS AND DEPENDENCIES DRIVEN BY THE EDRS 

EXPLOITATION SEGMENT 

Besides the constraints strictly linked to the use of the OCP (cf. section 4.3.8.6), the multimission 

intended usage of EDRS, in particular regarding its parallel usage by the Sentinel-1 

and Sentinel-2 missions imposes that access to the EDRS resource is apportioned between 

Sentinel-1 and Sentinel-2. For this purpose, the PDGS accounts for a specific interface to the 

EDRS exploitation segment (cf. section 4.2.1). 

As per the current assumptions described in sections 3.7.1, a constellation of a TBD number 

of EDRS relay spacecrafts is considered, each one characterised by a given position on the 

GEO orbit and with identical characteristics in terms of data-rate supported (520Mbps end-toend) 

and required reception hardware on-ground. 

It is further assumed that the apportioned availability of the EDRS constellation to Sentinel-2 

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. 

The above elements will drive the PDGS operations regarding the planned mission evolution 

specific to Sentinel-2 introduced previously in paragraph 3.7.2. 









4.4 Data Products 

This section provides a comprehensive view over the Sentinel-2 mission data-products that 

will be delivered by the PDGS. The baseline choice of Sentinel-2 data products and their 

characteristics presented here has been motivated mostly by an analysis of the GMES 

service requirements extrapolated from the DAP-R and from the Sentinel-2 MRD provided in 

Appendix-A. 

4.4.1 PRODUCT PORTFOLIO 

The detailed Sentinel-2 product list and characteristics are provided in the GSC Sentinel-2 

PDGS Products Definition Document [RD-07]. 

Table 4-2 outlines the Sentinel-2 product list and main characteristics of each product. A 

mapping to the “Optical Processing Level” labelling used in the DAP-R is provided for 

reference. 

Product- 

Type 

Identifier 

DAP Optical 

Processing 

Level 

Outline Description 

S2HKTM N/A Sentinel-2 spacecraft 

Housekeeping telemetry in TF 

format 

S2MSI0 0 MSI raw-image-data (compressed) 

in raw ISP format 

S2MSI1A L1A MSI uncompressed raw image data 

in sensor geometry with spectral 

bands coarsely co-registered and 

appended Ancillary data 

S2MSI1B L1B Radiometrically-corrected 

(calibrated) MSI image data in 

sensor geometry with spectral 

bands coarsely co-registered and 

refined geometric model appended 

but not applied 

S2MSI1C 

L1B 

orthorectified 

Ortho-rectified and UTM geo-coded 

Top-of-Atmosphere Reflectance 

with sub-pixel multi-spectral and 

multi-date registration 

Intended 

Users 

FOS 

MSI 

instrument 

experts 


internal users 

Expert users 

General 

users 

Acquisition Coverage 

(all systematic) 

Global at every orbit 

+ All land surfaces between 

56 South latitude and 84 

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 

through the HLOP. 

Cf. section 4.5.4.1.1 

Table 4-2 Sentinel-2 Product list and product main characteristics 

In addition, a prototype Level-2A product hereafter referred to as the S2MSI2Ap will provide 

Bottom-of-Atmosphere multi-spectral reflectance in the S2MSI1C geometry (orthorectified & 









UTM). The generation of this prototype product will be triggered interactively by the PDGS 

users based on S2MSI1C products. 

Product Granules or Tiles: 

All MSI products will aggregate one or several “granules” of fixed size. In this respect, the 

product granularity corresponds to the minimum indivisible partition of one Sentinel-2 product. 

The products are always split per orbit, i.e. granules corresponding to distinct orbits are never 

compiled within the same product. 

Table 4-3 summarises the product granularity associated to each type of product. 

Product-Type Identifier 

Granularity 

S2HKTM 

One entire downlink pass (downlink dependent) 

S2MSI0 

Per detector and on-board scene 

25km across-track x 23km along-track 

S2MSI1A 

Per detector and along-track on-board scene size 

S2MSI1B 

25km across-track x 23km along-track 

Along-track band co-registration is performed w.r.t. 

one reference band of the L0 scene 

S2MSI1C 

100km x 100km UTM tile 

Tiles are identified on a fixed world reference system 

based on UTM zones 

Table 4-3 Sentinel-2 Product Granularity 

Figure 4-10 illustrates this concept in the particular case of the Level-1C products where a 

granule corresponds to a portion of the global world surface in the UTM projection, called a 

tile. 

For such products, the product tiles will be preset and consistently identified on a fixed global 

world reference system based on UTM zones. This feature shall facilitate the data 

management for multi-temporal applications while fostering the multi-temporal registration 

requirements of the measurements at pixel level (cf. section 4.4.4.1 about the Level-1C 

Quality Baseline) 









Figure 4-10 MSI Product Granule Concept – Level-1C 

products aggregate one or several UTM tiles of 100km x 100km 

4.4.2 USER PRODUCT CONCEPT 

To optimally answer to Sentinel-2 user needs mostly targeting the regional or continental 

mapping of specific areas of interest, the PDGS will be optimised for the delivery of “User- 

Products” corresponding to: 

○ A user-defined geographical subset from their parent “Orbit-Product” compiling only 

the required granules covering the area along the orbit; 

○ A user-defined selection of the embedded product components (e.g. spectral bands, 

metadata, etc) and of the product packaging format from available options. 

Figure 4-11 illustrates this concept where the user-product aggregates entire granules 

corresponding to the user-defined selection criteria. 

The parent “Orbit-Product” being a particular case of a “User-Product” exhaustively 

embedding all granules of a given orbit and all product components, the simplified 

terminology “product” will commonly refer to a “User-Product” for Sentinel-2 MSI data. 

A Preview Image (PVI) file will optionally be packaged in each product based on the defined 

user-area. 









User-defined area 

User-Product 

Figure 4-11 User-Product Concept 

4.4.3 DATA-SET SUBSCRIPTION CONCEPT 

The PDGS will implement the concept of user-defined Data-Sets. Data-Sets will correspond 

to a set of products meeting specific user-defined criteria and for which the download is 

automated via user-defined subscriptions. 

Basic data-sets will accumulate products filtered according to any user-defined combination 

of criteria on metadata supported for user-queries such as the spacecraft unit, the producttype, 

the geographical-coverage (e.g. continental/local scale bounding box), the cloud-cover, 

sensing period, etc. 

In complement, the construction of more complex Data-Sets will be supported including: 

○ Seasonal datasets, implying a time-constraint on the sensing-time of the data falling 

within specific seasons; 

○ Optimised cloud-free datasets, ensuring a minimal coverage of the user-area within a 

given compound maximum cloud-cover computed over given periods (e.g. monthly, 

seasonally, etc). The later will be supported for S2MSI1C and allow discrimination of 

thin-cirrus from thick-cloud as cloud threshold. 

Table 4-4 summarises the dataset subscriptions supported per product-type 








page 100 of 350 

Product- 

Type 

Identifier 

Basic Product 

Subscriptions 

Seasonal Subscriptions 

S2MSI0 √ N/A 

Optimised Cloud-Free 

Subscriptions 

N/A 

S2MSI1A √ √ 

S2MSI1B √ √ 

S2MSI1C √ √ √ 

Table 4-4 Sentinel-2 Data-Set Subscriptions per product-type 

4.4.4 PRODUCT QUALITY 

User needs in terms of product quality derive from a set of requirements expressed in 

Sentinel-2 MRD [AD-01]. In order to meet these data quality standards and to ensure data 

integrity, the measurement system (including both space and ground sub-systems) shall be 

calibrated and the resulting products submitted to a Quality Control (QC). 

The following paragraphs present the main quality requirements applicable to the Level-1C 

(S2MSI1C) and prototype Level-2A (S2MSI2Ap) products. 

To meet the defined quality requirements, the Calibration and Validation (Cal/Val) plan 

defined in section 4.5.4.10 will systematically be applied. In complement, the operational 

monitoring of the resulting product-quality will be ensured through well-defined QC 

procedures. 

Products will be annotated with Quality Indicators (QI), which provide to the user the required 

information to assess the suitability of the data for a particular use/application. The Sentinel-2 

Product Definition Document [RD-07] details the QI concept and provides a complete list of 

the QIs provided with each product. 

4.4.4.1 Level-1C Quality Baseline 

Concerning the radiometry requirements, Table 3-2 shows the spectral bands characteristics 

and the required Signal-to-Noise Ratio (SNR) for the reference radiances (L ref ) defined for the 

mission. Other radiometric image quality requirements are presented in Table 4-5. 

Radiometric image quality requirement 

Performance 

Absolute calibration knowledge accuracy 

3 % (goal) , 5 % (threshold) 

Cross-band calibration knowledge accuracy 3 % 

Multi-temporal calibration knowledge accuracy 1 % 

Linearity knowledge accuracy 1 % 

Modulation Tranfer Function (MTF) 

10m bands: between 0.15 and 0.3 

20m and 60m bands: below 0.45 





Table 4-5 Radiometric image quality requirements. 




page 101 of 350 

Geometric image quality 

requirement 

Performance 

Ground processing 

hypothesis 

A priori accuracy of image location 2km max (3) No processing 

Accuracy of image location 

Accuracy of image location 

Multitemporal registration 

Multispectral registration for any 

couple of spectral bands 

20m (2) 

After image processing 

without control points 

12.5m (2) After image processing 

with control points 

3m (2) for 10m bands 






Table 4-6 Geometric image quality requirements. 

4.4.4.2 Prototype Level-2A Quality Baseline 





Prototype Level-2A products are those related to the correction of the atmospheric and 

topography influences in order to derive radiometric measurements at surface level. 

The target accuracy for the bottom-of-atmosphere (BOA) reflectance is 5% relative. For water 

vapour a relative accuracy of 10% is aimed for in the range between 0.1 and 4 g/cm 2 . The 

target aerosol optical depth (AOD) accuracy is 10% relative for the range between 0.05 and 

3. Being a prototype product, the above quality levels will be monitored and fine-tuned during 

the mission lifetime. 

4.4.5 PRODUCT TIMELINESS 

The product characteristics in terms of timeliness will be settled in the HLOP based on the 

choice of the CGS network and priority rules. As such, they will directly cascade from the 

high-level mission operation principles outlined in section 4.5.1.5 on this matter and further 

detailed in section 4.5.4.2. According to the above, product timeliness will be observed as 

falling into three classes with their association with GSCDA timeliness denominations defined 

in [AD-02]: 

○ Real-Time (RT), corresponding to the product on-line availability no later than 100 

minutes after data sensing. As all data will be processed “on-the-flow” from datareception 

it is anticipated that a large part of RT products will match the NRT1h 

timeliness denomination of the GSCDA; 








page 102 of 350 

○ Near-Real-Time (NRT), corresponding to the product on-line availability between 100 

minutes and 3 hours after data sensing. This matches the NRT3h timeliness 

denomination of the GSCDA; 

○ Nominal timeliness, for all other products and corresponding to the Fast24h 

denomination of the GSCDA with a guaranteed product on-line availability between 3 

and 24 hours after data sensing. 

4.4.6 PRODUCT RETRIEVAL LATENCY 

Depending on the age of the data and product type, different latencies to the actual delivery 

of the data will be observed, depending on user-needs while allowing for trade-off and 

optimised management of the product archives. 

Two classes of data access latency are defined: 

○ On-line latency: Products are archived in the medium-term archive and ready for online 

retrieval 

○ Off-line latency: Products are made available on-line from the long-term archive with 

latencies in the order of one day. Retention on-line following recovery from long-term 

storage will be in the order of several months. . 

Table 4-7 defines the retrieval latency baseline per type of product and product age. The 

retention qualifiers refer to the time after sensing. 

It shall be noted that this baseline directly impacts the initial sizing of the PDGS elements but 

can be fine-tuned and enhanced at will by increasing the sizing of the medium-term archive. 





Product- 

Type 

On-Line 

retention 

Off-line 

retention 

Data-storage strategy 




page 103 of 350 

S2HKTM 1 week Missionlifetime 

and 

Data is available on-line at the station for 1 week then 

circulated for long-term archival 

S2MSI0 3 months 

beyond 

Data is available on-line at the station for 1 week whilst 

circulated for 3 months medium-term archiving in parallel to 

long-term archiving. The 3-months on-line archive allows for 

swift reprocessing in particular during commissioning. 

S2MSI1A 1 month N/A Products are maintained on-line for 1 month. 

S2MSI1B 1 month Missionlifetime 

and 

beyond 

S2MSI1C 

1 month 

global 

1 year 

global 

cloud-free 

1 year over 

Europe 

Missionlifetime 

and 

beyond 

Products are maintained on-line for 1 month then 

accessible from the long-term storage. 

All products with a detected cloudiness below a given 

threshold (e.g. 80%) are maintained on-line for 1 year. 

Over Europe, all products are maintained regardless of 

cloud cover. All data is kept on-line for at least one month. 

When not on-line, all products can be retrieved off-line from 

the long-term archive. 

Table 4-7 Product retrieval baseline strategy per product-type 

This concept is illustrated on Figure 4-12. 

Figure 4-12 Data Access latency versus data retention in archives 








page 104 of 350 

4.5 Mission Operation Concepts 

This section aims at providing a comprehensive view over PDGS operations within the overall 

Sentinel-2 mission context. The high-level mission operation concepts are building upon the 

SOCD [AD-03] to meet the high-level mission requirements expressed in [AD-01]. The 

operation constraints outlined in the previous section will be referred to as relevant. 

The GSC Data-Access System operation scenarios defined in [AD-02] are also applicable. 

4.5.1 HIGH-LEVEL CONCEPTS 

4.5.1.1 Multi-Spacecraft Operations 

All mission operation concepts apply to the Sentinel-2 constellation as a whole which is 

assumed to include after the launch of Sentinel-2B two spacecrafts operating concurrently as 

defined in section 3.3 and to sustain this configuration in the long-term by the gradual 

inclusion of replacement units. 

As such, the operations specifically applicable to each unit in orbit will naturally cascade from 

the high-level scenarios global to the constellation, each one contributing to the global 

mission objectives. 

Nevertheless, the possibility to fine-tune the mission returns by load-balancing rules amongst 

the units is embedded in this principle and will be highlighted when relevant in the operation 

concept descriptions. 

4.5.1.2 Systematic and Data-Driven PDGS Operations 

Taking advantage of the global and systematic nature of the Sentinel-2 data-acquisition plan, 

the product elaboration processes implemented by the PDGS will be entirely mechanical and 

data-driven whereby the data processing down to the delivery to users will plainly cascade 

from the data reception at the CGS in a systematic manner. 

At the PDGS output gateways, data-access workflows will allow users to harvest the PDGS 

production either interactively or automatically extending the stream of data products down to 

the user-base following the subscription concept. 

4.5.1.3 PDGS Automation 

The PDGS operations will embed in all end-to-end processes a high degree of automation 

requiring only operator supervision wherever feasible throughout the chain starting at the 

mission-planning stage and ending at product delivery. 

Specific processes will however include break-points wherever human intervention is deemed 

necessary to bridge the workflow such as: 

o Generally the Cal/Val and product Quality Control activities requiring specific care and 

expertise; 









page 105 of 350 

o The seldom mission configuration change operations (e.g. new spacecraft or EDRS 

phase-in periods) requiring specific care and coordination; 

o The shipment and reception of data via media within PDGS centres as a trade-off 

solution whenever such operations cannot be automated via digital networks due to 

the excessive volumes to be transported; 

o The resolution of contingencies occurring in the automated processes. 

The above operations will nevertheless be designed so as to strictly bridge the computerised 

processes and embed procedural steps such that: 

o Cal/Val and product QC operations requiring expertise or decision making are 

triggered according to well-defined procedures clearly isolated within the automatic 

workflow; 

o Mission reference configuration is centrally performed allowing the dispatch of 

coordinated updates by computer means to the whole PDGS and external interfaces 

as needed; 

o Media loading, release and shipment procedures to circulate data between centres are 

mechanical and generally modelling an automated transportation network; 

o Operator alerts are centralised within an operational centre allowing for maximised 

efficiency. 

The system integration, verification and validation processes required by the corrective 

maintenance or system evolutions and which cannot generally be efficiently automated will be 

supported by wide-ranging tools covering the specific needs of this activity. 

4.5.1.4 Centre Operation Autonomy and Federative Data-Access Concept 

The PDGS operations, scattered in stations and centres, will be based on a federative model 

with a maximised independence at centre-level converging at PDGS-level into a unique entity 

as seen from the data-access viewpoint. This model is depicted on Figure 4-13. 

As applied to the Sentinel-2 mission, this model has the following advantages: 

o It is well adapted to the high data volumes generated by the Sentinel-2 mission as per 

the inherent issues related to data transportation. 

In this model, the data is transported from place to place within the PDGS centre 

network with the sole aim of bringing the Sentinel-2 data closer to the consumers or to 

provide for redundancy. Likewise, real-time data-access can be provided right at the 

station whilst it is circulated to other centres with relaxed timeliness constraints to 

improve accessibility and access performance in the longer term; 

o It matches adequately with the mostly regional and continental expected usage of the 

mission data. In this model, local access can be optimised by operating community 

centres (e.g. national) fed with regional data and mirroring it globally with maximised 

performance when accessed from within their geographical perimeter. 

o It well matches the required operability in a distributed setting whereby each 

operational centre has a maximised independence to ensure alone that it fulfils its 

dedicated role allocated within the global operation picture. 




o 




page 106 of 350 

It well matches the required operational redundancy between centres regarding dataaccess 

reliability whereby the data availability can be guaranteed no matter where the 

data effectively relies; 

o It is flexible and scalable vis-à-vis mission operation evolutions, in particular 

considering the phase-in of EDRS providing multi-cast capabilities that will allow any 

location in Europe to receive and process part of the data, contributing to the overall 

global dataset availability to users. 

o It is open to collaborative opportunities aimed at optimising global data-access 

performance whereby PDGS-compatible centres operated by third-party in full 

autonomy participate to the PDGS data-access network in exchange of a privileged 

access to the data at their premises for local usage. 

Long-Term 

NRT 

RT 

Figure 4-13 Federative PDGS Model 





4.5.1.5 Scalability and Flexibility regarding Data-Timeliness 




page 107 of 350 

As outlined in 3.5.4 and further described in [AD-03], the satellite design includes the 

functionality to manage the MSI data on-board such that data can be real-time downlinked or 

selectively prioritised for playback in NRT breaking the FIFO rule of the nominal playback 

process. 

In counterpart, the selected CGS network will impose a number of constraints and 

dependencies as described in sections 4.3.10.1 and 4.3.10.2. 

To provide for the required trade-offs in all cases, the PDGS will: 

○ Manage the data playback processes from the spacecrafts, including the RT and NRT 

priority downlink functionality such that critical zones to be monitored with RT or NRT 

timeliness can be optimised by the MMA via the HLOP. The commanding of RT directdownlinks 

regionally will require the operation of one or several specific CGS offering 

visibility over the areas to be monitored in RT; 

○ Implement optional load-balancing rules on the data-recovery scenario among the 

constellation satellites, such as to further enhance flexibility; 

○ Perform with appropriate sizing on-ground such as to keep up with the input flow in 

delivering the final products in a FIFO manner driven by the flow of spacecraft data 

received at each CGS. 

This approach will result in: 

○ Critical zones promoted for NRT-compatible timeliness through the HLOP being 

ensured to be covered with a guaranteed NRT timeliness at product-level, i.e. in less 

than 3 hours from sensing ; 

○ Some selected regional zones within the X-Band visibility mask of dedicated CGS to 

be covered with a guaranteed RT timeliness at product-level, i.e. in less than 100 

minutes from sensing; 

○ A fully flexible and scalable solution up to 100% of effective RT or NRT timeliness 

should the PDGS be equipped with the sufficient number of CGS (typically 6); 

○ Approximately 25% of the globally acquired data effectively available in NRT, should 

the PDGS typically include four CGSs as baselined in [AD-03]. 

Hence, it is assumed that this HLOP driven approach together with the choice of the CGS 

network will globally comply with the required product timeliness while provisioning for 

evolutions. In particular, it is assumed that to comply with Emergency Response Core Service 

(ERCS) and Security Pilot Service (SEC) requirements, a list of high-priority areas will be 

agreed with the Sentinel-2 MMA in a preventive way leading to: 

○ The coverage of high-priority areas being available with at least NRT timeliness up to 

about 25% of the globally acquired data; 

○ The coverage of other areas being available as early as possible in a FIFO manner 

and in any-case within one day from sensing. 








page 108 of 350 

4.5.1.6 Long-Term Data Preservation 

As a background task, the PDGS will ensure long-term data preservation of all Sentinel-2 

mission acquired data for at least 25 years after end-of-mission. 

By complying widely with the draft coordinated European guidelines [RD-18] put in place in 

the Long-Term Data Preservation (LTDP) area, this service aims at ensuring through a 

dedicated long-term archive (LTA) function: 

○ The reliable storage and inventory in two redundant European sites of all Sentinel-2 

raw-data (S2HKTM, S2MSI0), the main user-product at Level-1C (S2MSI1C) and all 

required auxiliary data (e.g. orbit and AOCS information, GPS data, instrument 

characterisation data, etc) for the Sentinel-2 missions lifetimes and for at least 25- 

years after the end of space-segment operations; 

○ The collocated reliable storage of all associated project documentation (e.g. 

algorithms, data formats, etc); 

○ The collocated mirror copy of the data-access index globally maintaining the access 

points of all storage granules held throughout the PDGS and its associated long-term 

operations; 

○ The collocated long-term operations of Data-Access elements to provision for the 

sustained retrieval of the data beyond end-of-life through several interfaces including 

the HMA (DAIL) to allow for data-access interoperability; 

○ The collocated long-term operations of an automated data-circulation element to 

provision for the bulk transportation of data, including via media, between LTAs or to 

other PDGS centres; 

○ A collocated long-term operated and maintained reprocessing function allowing for regeneration 

of all Sentinel-2 products from raw data. 

The Sentinel-2 PDGS long-term archive function is expected to be hosted in dedicated 

redundant centres possibly exploiting synergy with the long-term archiving already performed 

for other Earth-Observation missions. 

It is further expected that the collaborative opportunity provisioning for the Sentinel-2 

interoperable data mirroring through third-party operated centres (cf. sections 4.2.3 and 

4.10.2.1) will further contribute to the LTDP objective. 

In support to the long-term usability of MSI raw-data in particular for reprocessing, the PDGS 

will provision for the long-term maintenance (>40 years) of the MSI WICOM decompression 

software. 

4.5.1.7 Operational Redundancy and Contingency Handling Concepts 

As cascaded from the GSC operational context (cf. 4.3.1), the PDGS will provision for 

redundancy and for contingency operations focussing on guaranteeing the data availability to 

the end users in a timely and reliable manner. 

From the operational reliability globally inherited from automation embedded in most PDGS 

processes (cf. section 4.5.1.3), system redundancy and contingency operations will aim at 

further improving the quality of the PDGS services. 








page 109 of 350 

Although not generalised in all PDGS systems, hardware redundancy will be ensured on 

critical items such as the front-end processors (hot redundant) and will be embedded in the 

processing infrastructures through the management of a large number of compatible 

processing nodes. Archive redundancy will be ensured through a multi-site approach 

provisioning for at least dual redundancy on the overall mission archive. 

In complement, contingency operations will be provisioned for throughout the dataelaboration 

processes including data-reception, data processing and archive-to-archive 

circulation. 

4.5.2 DATA ACCESS CONCEPTS 

4.5.2.1 Product Data Handling and Data-Access Strategy 

Throughout the PDGS, the MSI product data will be managed as a set of physical product 

components hereafter referred to as Product Data Items (PDI). Referring to the Product 

Definition Document [RD-07], each PDI will be a set or excerpt of the following type of data: 

○ Image data 

○ Image metadata 

○ Image quality indicators 

○ Ancillary data (satellite orbit position, velocity, time, attitude) 

○ Orbit metadata 

○ Auxiliary data (GIPP, etc.) 

Each PDI will be self-standing as a physical item e.g. a GIPP file, the reflectance image of 

one band covering one tile, a quicklook image, the ancillary data covering a specific orbit, etc. 

On the other hand, all PDIs will be organised and referenced within a logical product 

hierarchy by implementing basic cross-PDI relationships. Examples of such embedded 

relationships are common in many EO products such as the auxiliary data used for 

processing, the mission orbit, geo-referencing information on an image subset (e.g. a tie-point 

grid), summary quality indicators on a set of along-track measurements, etc. 

Managing PDIs separately brings the immediate benefit of avoiding duplication of information 

(e.g. global ancillary data usage over an orbit, auxiliary data validity over long periods, etc) 

wile providing for flexibility in a distributed environment (the data composing one product may 

be scattered geographically in several remote archives). 

In the Sentinel-2 PDGS, this concept will be used substantially as an effective answer to the 

data-access challenge for the seamless provision of data products geographically scattered, 

with large volumes, and required by the users under stiff constraints for wide ranging 

applications of regional to continental scale. 

Based on the federation concept outlined in section 4.5.1.4, the PDIs generated and archived 

in each PDGS centre as well as circulated between centres will be globally federated allowing 

the overall PDI hierarchy to be maintained and redundancy to be managed consistently. In 

counterpart, data-circulation mechanisms between centres will be coordinated ensuring that 








page 110 of 350 

PDIs are redundantly available in several centres as required to ensure long-term availability 

or to tune access performance. 

Hence, whilst the PDGS will be geographically distributed and will implement its own 

mechanisms for managing the data internally, its underlying complexity will be hidden through 

a single virtual point of access. 

The scattering of the data imposes that the Sentinel-2 products are reconstructed from the 

various pieces before delivery. Similarly to any communication protocol, this process can be 

seamlessly embedded during the data transfer and will be performed on the consumer 

hardware as requiring negligible additional computing. This strategy will allow in addition 

optimising the supply performance by implementing load-balancing between the possibly 

redundant seeding sites, according to the network topology to the final consumers. 

Figure 4-14 illustrates this strategy schematising the flow of product components (PDIs) 

among PDGS centres and the product reconstruction process at the consumer base from the 

various distributed servers. 

Distributed PDGS 

PDIs 

Coordinated Data-Driven Circulation Network 

Federated DA Servers 

PDI 

(e.g. image tile X) 

PDI 

(e.g. geom-model 

metadata) 

Data-Access 

Network 

User 

Gateway 

PDI 

(e.g. image tile Y) 

PDI 

User-Product 

Figure 4-14 PDGS Product Data-Handling Strategy 

The global PDGS archive will be populated autonomously after every new data acquisition 

from the constellation is performed in the systematic PDGS data elaboration flow. This will 

result in on-line availability of the data for download strictly following the data-acquisition and 

processing strategy implemented by the PDGS through the HLOP (cf. 4.5.1.5). 








page 111 of 350 

On the other hand, the data-access mechanisms will be user-driven from the discovery of the 

data in the catalogues down to the download of the PDGS products to the user bases. 

4.5.2.2 Data-Access Interfaces 

ESA’s Multi Mission User Service (MMUS) environment, and in particular its Next Generation 

User Services for Earth Observation (ngEO) component, will act as front-end gateway to all 

Sentinel-2 User-Products and Data-Sets versus authorised users: 

○ Towards end-users, the MMUS will provide a web-portal supporting graphical query 

and navigation capabilities down to the triggering of the actual product downloads with 

automation capabilities. 

○ Towards CDS/DAIL, the MMUS will provide an HMA compliant interface to Sentinel-2 

data supporting catalogue and on-line data access, interoperable within the GSC 

framework. 

In complement, an independent component hereafter referred to as the On-Line Image 

Browser (OLIB), will provide anonymous internet on-line access to Sentinel-2 imagery. 

In support to all above methods, the actual data downloads from the distributed PDGS 

archives over the communication network will be carried out by a specific component, 

referred to as the Data-Access Gateway (DAG), and transparently triggered through the 

MMUS and OLIB interfaces. 

The following sections briefly describe the complementary roles and interface mechanisms of 

each component. 

4.5.2.2.1 ESA’s Multi-Mission User Services (MMUS) Portal 

Towards end-users, ESA’s Multi-Mission User Services (MMUS) environment will offer a webportal 

interface accessible from the public Internet with the global functionality of: 

○ Providing complete and comprehensive information about the GMES Sentinel-2 

mission and products (e.g. availability, formats, quality, etc.), the mechanism to 

access them, and the management of a Support-Desk; 

○ Providing self-registration capabilities and centralised management of user 

authentication and data-access authorisations based on user grants and privileges (cf. 

section 4.5.2.2.4); 

○ Providing graphical query and navigation capabilities on a consistent and consolidated 

catalogue of available products including the display of preview images similar to 

portal page mock-up depicted on Figure 4-15; 

○ Triggering the User-Product downloads according to user-defined options (e.g. 

spectral bands, metadata, spatial coverage, etc as outlined in section 4.4.2) and 

supporting download automation matching user-defined Data-Set subscriptions (cf. 

section 4.4.3); 

○ Providing enhanced data-access services whereby users can trigger their own 

processors previously integrated in the PDGS as part of the hosted-processing 

collaboration framework (cf. sections 4.8.1.2 and 4.10.2.2). 








page 112 of 350 

The above functionality will be implemented by the ngEO component of the MMUS 

complemented by other MMUS legacy systems such as the Single-Sign-On (SSO), the Multi- 

Mission Support-Desk., etc. [RD-44] provides an outline of the MMUS operation scenarios 

implemented through the ngEO component. 

Figure 4-15 Mock-up of the MMUS/ngEO Web-Portal Interface 

4.5.2.2.2 CDS/DAIL Interface 

Access to Sentinel-2 data will be harmonised within the GSC through the CDS/DAIL 

component. Interfaces to DAIL will be provided via the MMUS ngEO component (cf. [RD-44]) 

including the Catalogue service interface [RD-14]/[RD-15] and the On-Line Data-Access 

service interface [RD-16]. 

4.5.2.2.3 On-Line Public Access to Sentinel-2 True Colour Images 

Building on the Envisat/MERIS experience with the MERIS Image Rapid Visualisation service 

(MIRAVI, http://miravi.eo.esa.int) the Sentinel-2 PDGS will provide anonymous internet on- 








page 113 of 350 

line access to Sentinel-2 imagery as True Colour Images (TCI) via a separate On-Line Image 

Browser (OLIB) application. This service will foster the distribution of eye-catching digital 

images rather than scientific products with the objective of sharing Sentinel-2 imagery with 

the general public. 

Access to the images will be provided through a dedicated web-portal, offering enhanced 

navigation and image visualisation capabilities. Figure 4-16 shows a screenshot of the 

MIRAVI client as an example of imagery access provided directly via any Internet browser. 

Figure 4-16 Envisat/MIRAVI Client Screenshot 

Imagery will be visualised at the maximum instrument resolution down to about 10 meters 

ground-pixel size. MSI image acquisitions not relevant to the general public such as the ones 

acquired at night or over deep oceans for instrument calibration purposes will not be 

published through this interface. 

Visualisation capabilities will support selective image display according to the timestamp of 

the data and allow for time-based animations. Additional filters will be supported to enhance 

database searches based for instance on cloud cover, countries, cities, etc. 

4.5.2.2.4 DAG Interface 

The DAG component will be responsible for hiding the PDGS distributed nature and 

complexity behind a virtual simple access-point managing the actual data-access tasks on 

behalf of the front-end MMUS and OLIB applications. The DAG interface will support: 

○ The download of the product components from the PDGS archives and their assembly 

into consistent User-Products as triggered through the MMUS, based on the userselected 

catalogue items (e.g. granules) and download options (e.g. product 

components and packaging format); 








page 114 of 350 

○ The routing and tunnelling throughout the PDGS of the hosted-processing tasks 

triggered via the MMUS, based on the user-selected catalogue items (e.g. Level-1C 

tiles) and processing options; 

○ The download of the TCI images from the PDGS archives for visualisation and/or 

delivery at the user base according to the user-triggered OLIB interactions. 

As encapsulating the complete data-access process down to the user base, the DAG 

component will implement a client-server mechanism between the PDGS core infrastructure 

elements acting as servers and the user-base platforms acting as clients. The internal data 

exchange protocol between the PDGS servers and the clients will be transparent to the data 

consumers. As for any protocol (http,. ftp, bittorrent, etc), this approach will thus require 

minimal software to run on the client side which will be kept simple and portable for 

deployment at the user-base. 

4.5.2.3 Registration & Access Grants 

A registration process will associate specific grants to users or group of users. This process 

will be delegated to the Multi-Mission User Services (MMUS) (cf. [RD-44]). Grants will be 

configurable per type of product and/or datasets with possible restrictions such as: 

○ User registration capabilities including self-registration; 

○ User groups definition (e.g. anonymous users, registered users, etc); 

○ User priorities management for the data-access activities based on user groups and 

profiles (i.e. data-access requests will define a priority level based on the user profile); 

○ User authentication; 

○ Datasets definition (i.e. collections) by different criteria such as Sentinel-2 spacecraft 

unit, sensing-time, age of the data, etc; 

○ Submission of hosted-processing requests based on the user profiles (only specific 

users will be able to submit hosted-processing requests); 

○ User authorisation wrt product discovery and product download activities on the 

different datasets; 

○ Accessibility to reserved datasets containing products such as calibration products or 

products under investigation after quality-control assessment activities. Such products 

will be hidden to general users whilst accessible to Cal/Val and QC teams; 

○ Subscriptions management to the different available datasets for every individual user; 

○ Accessibility to specific versions of the available product collections discriminating 

amongst several revisions of the processing algorithms (e.g. to allow or prevent 

accessibility to new collections generated after reprocessing campaigns). 

It is expected that this level of granularity will provide, if and when required, the adequate 

leverages to well balance the data-access load among users while allowing for optimising the 

PDGS resources accordingly. 








page 115 of 350 

4.5.2.4 Support Desk 

ESA’s MMUS includes a first-line Support-Desk for all EO users in general. For Sentinel-2, 

this service will cover general support on registration issues, generic data access methods 

and interfaces, mission facts, etc. 

Then, a second-line Support-Desk will support the CDS and the MMUS on all specific matters 

requiring Sentinel-2 specific expertise, including: 

○ Expertise regarding any product on data quality, availability, timeliness, etc; 

○ Investigation of quality anomalies reported by the Users. 

The CDS also includes a support desk for GMES Service Projects (GSPs). The coordinated 

CDS Support Desk will interface with the PDGS first-line or second-line Support Desks for 

issues related to Sentinel-2 data and services. 

4.5.3 MISSION SUPPORT OPERATIONS 

4.5.3.1 Mission Planning and Scheduling 

The PDGS will be responsible for implementing the global mission plan cascading from the 

specific requirements of the HLOP in accordance with the operation scenarios described 

here. 

To this end, the PDGS will interface with the Sentinel-2 FOS in charge of scheduling the 

spacecrafts from the PDGS provided mission-planning inputs as introduced in section 4.2.4. 

In counterpart, the FOS will provide the PDGS will all required information under its 

responsibility to allow the successful downstream planning of the PDGS managed systems 

such as for enabling data-reception from the spacecrafts. 

The following paragraphs outline the operation principles applicable to the mission planning 

and scheduling operations, dividing the ones performed in coordination with the FOS from the 

ones strictly applicable to the PDGS downstream activities. 

4.5.3.1.1 Mission Planning & Scheduling Loop with the FOS 

Taking benefit of both the near-deterministic nature of the Sentinel-2 data-acquisition plan (cf. 

4.5.4) and the 15 days autonomy of spacecraft operations coupled with the use of the OPS 

mode (cf. 3.5.5), the Sentinel-2 mission planning and scheduling operations aims for a very 

systematic operation concept. 

To this aim, the PDGS and the FOS will jointly operate to plan and schedule the spacecraft 

operations for long periods of typically 15 days while allowing for short-term re-planning in 

case of need in particular during the commissioning phases. As such both PDGS and FOS 

work-flows must be coordinated. 

As regarding mission scheduling and uplink, the FOS has defined a specific operation 

concept (cf. section 4.3.7.1) which predefines daily opportunities for uplinking the operation 

schedule to the spacecraft together with constraints associated on the PDGS-driven missionplanning 

loop. 








page 116 of 350 

The PDGS mission planning operations will be hence be defined according to the above 

constraints and provision for: 

○ A nominal planning scenario, activated recurrently according to a pre-defined interval 

(every two weeks or more) during working days only, and feeding the FOS with 

mission-planning input covering the plan increment required for autonomous 

operations until the next PDGS plan interval with appropriate margin (i.e. 15 days or 

more according to the defined plan update interval); 

○ A re-planning scenario, activated seldomly and when strictly required (e.g. unplanned 

events, commissioning-phase requirements, etc). 

The nominal planning scenario will be phased with the agreed S-Band pre-allocated uplink 

scenario described above and account for at least 3 working-days margin as nominally 

required by the FOS. The re-planning scenario activation will be constrained with a nominal 3 

working-days margin that can be relaxed to one working-day in special situations. 

Each planning session, whether of the nominal planning or re-planning scenario will be 

performed in closed-loop with the FOS as follows: 

○ The PDGS will provide a conflict-free 2 planning file of the required coverage such as to 

systematically describe the operations up to the beginning of the next PDGS plan 

interval with appropriate margin. All operations will be tagged under the OPS scheme 

except for operations specifically requiring MTL programming. 

○ In response, the FOS will verify the PDGS generated plan against satellite safety 

constraints, detect any other potential conflict with other constraints (i.e. Flight 

Dynamics planned activities, Flight Control Team operations, etc.), and acknowledge 

the effective planning back to the PDGS, reporting failures on specific requests if any. 

Any rejected request will invalidate the entire planning session, and trigger contingency 

operations followed by a new planning loop. 

Contingencies on the planning-loop will be handled on a case-by-case basis as theoretically 

seldom and corresponding either to unforeseen events occurring at satellite or FOS levels or 

not well anticipated at PDGS level. According to the specific conflict reported by the FOS, and 

in the case an unforeseen spacecraft safety constraint was violated, the generation of new 

plan aiming at satisfying the constraint will be attempted. 

4.5.3.1.2 EDRS/OCP Scheduling 

Although not precisely known at this stage, downlink capabilities via the OCP are anticipated 

to support the potential mission enhancements via EDRS outlined in section 3.7. The 

constraints applicable to OCP operations (cf. 4.3.8.6), together with the effective downlink 

budget and effective data-relay opportunities that will be provided are currently TBD or TBC. 

In this respect, the PDGS operations concepts will provisionally include the commanding of 

data-downlinks via the OCP based on the following assumptions: 

2 The spacecraft operations constraints to be verified by the mission plan will be identified in a coordinated 

document called the Spacecraft Safety Constraints File (SSCF). This interface, maintained by the FOS 

throughout the mission lifetime under the form of a document, characterises the constraints and provides a 

relative apportioning of the ones to be verified at PDGS level, FOS level or both. The PDGS will explicitly refer to 

the applicable version of the SSCF used for the planning in every plan provided to the FOS. 









page 117 of 350 

○ OCP downlink commanding will be performed via the FOS similarly to X-Band 

downlinks; 

○ The FOS will require that the PDGS provides the location (or identification) of the 

EDRS spacecraft associated to a data-relay downlink to allow consistent commanding 

of OCP pointing activities towards the relay GEO transponder; 

○ The FOS will transparently take charge of commanding the OCP preparatory 

operations required for an effective downlink according to the PDGS provided 

downlink segments. 

As per the above assumptions, the commanding of OCP operations vis-à-vis the FOS will be 

managed by the PDGS similarly to the case of X-Band downlinks, with additional 

parameterisation of the downlink requests related to the identification of the EDRS GEO 

spacecraft required by the FOS to manage OCP pointing and activation activities. 

Regarding the PDGS interface to the EDRS exploitation segment, no recurrent and dynamic 

scheduling will apply. 

4.5.3.1.3 PDGS Downstream Planning and Scheduling Operations 

To a high-level, the PDGS operations will be entirely driven by the raw-data downlinked from 

the spacecrafts supported by complementary deterministic and predefined schedules of 

activities targeting mission performance overall assessment and control (cf. next paragraph). 

Hence, there will be very limited explicit planning of the PDGS operations beyond the 

scheduling of data-reception operations at the CGS network that will trigger most of all 

downstream operations in cascade and in a systematic manner. Those operations are 

outlined in section 4.5.6. 

In addition, data-reception at the LGS network will be scheduled as described in section 

4.5.4.3. 

4.5.3.2 Mission Performance Monitoring and Control Operations 

As a background task, the PDGS will perform routine monitoring of the mission performance 

and retrofit configuration changes as required to ensure the mission overall quality over time. 

The scope of this activity will comprehensively cover the performance monitoring of all 

mission elements including the spacecrafts and its payload, the FOS and the PDGS with 

particular focus on the availability, reliability and quality of the data delivered to end users 

according to HLOP mission quality targets. 

The monitoring of the product-quality and overall mission performance will be ensured 

through well-defined Quality-Control (QC) procedures. QC operations will be performed 

following a predefined and recurrent schedule such as e.g. daily, monthly or following the 10- 

days repeat cycle or in a data-driven manner on reception of specific data takes pre-planned 

for this purpose. They will cover: 

○ The systematic short to long-term assessment of the payload performance, the 

products quality and overall mission performance; 

○ The systematic retrofit on the system configurable items impacting on the mission 

performance based on the output of assessment activities. 







page 118 of 350 

This includes in particular the recurrent assessment of the image quality and triggering as 

needed of the required configuration changes on-board the MSI and/or on-ground in the dataprocessing 

chain to meet the baseline product quality requirements defined in section 4.4.4. 

To meet this objective, specific processes referred to as Cal/Val operations will be carried-out 

regularly. They are described as core mission operations in section 4.5.4.10 as involving 

coordinated on-board and on-ground operations. As resulting from Cal/Val activities, on-board 

configuration management of the MSI with coordinated configuration on-ground of the PDGS 

processing chains will be described in section 4.5.3.3.2 as requiring accurate configuration 

control and FOS commanding. 

4.5.3.3 Mission Configuration Control Operations 

4.5.3.3.1 General Principles 

The PDGS will perform systematic configuration control over all mission reference data 

applicable to the PDGS in every operation scenario. All critical configuration parameters, 

either derived from the HLOP or fined-tuned and retrofit after mission performance 

assessment operations, will be centrally managed in the PDGS over time. 

The management of mission configuration data strictly applicable to the FOS will however not 

be duplicated in the PDGS as already taken care of by the FOS. 

Hence, the scope of mission configuration control operations performed by PDGS will include 

the management of configurable items such as: 

○ The reference orbit of each spacecraft; 

○ Satellite operation constraints definition impacting the PDGS-generated planning 

○ The database of X-Band stations and their characterisation (for CGS and LGS); 

○ The sensor data-acquisition and downlink scenario definitions; 

○ On-ground configuration data (GIPP for Level-0/1 processing) 

○ Payload parameters (e.g. MSI NUC tables, thermal control tables, etc) 

○ PDGS data management rules (e.g. for data circulation, archiving, etc) 

Some of this critical configuration will be managed independently per spacecraft whilst other 

will have global relevance to the constellation and will be dealt with accordingly. 

Mission configuration control operations will include: 

○ Housekeeping operations and maintenance over time of all reference data in a central 

repository, associating applicable dates and operation scenario; 

○ The delivery of the applicable reference data to their intended functional targets in a 

coordinated and controlled way. This coordinated configuration functionality will be 

used in particular to support the changes of mission scenarios as required via HLOP 

upgrades (e.g. for the phase-in of EDRS and switch to the operation scenario with 

EDRS); 

○ On-demand reporting over the mission configuration over time. 








page 119 of 350 

4.5.3.3.2 Coordinated MSI Configuration Control 

As taking part to the overall operability of the instrument as well as driving its performance inflight, 

the configuration of some MSI parameter tables loaded on-board will be managed by 

the PDGS under strict configuration control. The MSI tables managed by the PDGS are: 

○ The Non Uniformity Coefficients (NUC) table 

○ The Front-End Electronics (FEE) table 

○ The set of seven Image Processing Parameter Sets (IPS) tables 

○ The Thermal Control Module (TCM) tables, TCM-SBY and TCM-NOM 

Other tables such as the WICOM microcode and the Global Parameter table will be managed 

directly by the FOS. 

The uplink and activation operations of these tables will be performed by the FOS (cf. section 

4.3.7.2) and will be coordinated via the Special Operation Request (SOR) interface of the 

FOS. This interface associates a desired activation time to the table data deposited 

separately on the FOS server. The FOS will reply to every SOR by an SOR acknowledge 

providing the planned activation time. 

The PDGS will feed every new parameter table to the FOS with sufficient time in advance 

allowing for uplink and on-board activation operations (e.g. following uplink, a new NUC table 

activation on-board will need preliminary transfer from the OBC to the MSI requiring about 15 

minutes to be executed in the eclipse phase of the instrument). In counterpart, It is assumed 

the acknowledged time will not exceed 24 hours after the desired timing expressed in the 

SOR. 

4.5.4 CORE MISSION OPERATIONS 

The core mission operation concepts are based to a large extent on the MRD [AD-01] and on 

the mission simulations reported in [RD-19], while justifying the needed extrapolations when 

relevant. 

4.5.4.1 On-Board Sensor Acquisition 

4.5.4.1.1 MSI Acquisition 

According to the MRD [AD-01], the Sentinel-2 mission nominal acquisition scenario is 

targeting the systematic and continuous acquisition with the MSI of all land surfaces between 

56 South latitude (Cape horn in South America) and 84 North latitude (up to northern 

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

small islands located at less than 20km from the coastline. In addition it is required to acquire 

the whole Mediterranean Sea, all inland water bodies and all closed seas. 








page 120 of 350 

Figure 4-17 Land Coverage by the MSI 

MSI data will be systematically acquired during daylight portions of the orbit where the target 

surface has a sun zenith angle below a certain threshold (currently being specified at 82 

degrees). Different illumination conditions will hence derive seasonal patterns as described in 

[RD-19] and lead to varying acquisition scenarios according to summer solstice, winter 

solstice and autumn/spring equinoxes. 

Based on two simultaneously operating spacecrafts and taking into account cloud-cover, this 

will result in a continuous coverage with high-revisit. Figure 4-18 shows the result of a 

simulation of the coverage revisit using two spacecrafts and with cloud cover under 15% over 

Europe and Africa during summer. 








page 121 of 350 

Figure 4-18 Coverage time over Europe and Africa in summer 

with 2 satellites (considering clouds) 

In complement, the acquisition plan will provision for additional observation campaigns to be 

defined according to the available data downlink capabilities and resources. Observation 

campaigns will consist in the periodical acquisition of specific areas within limited time periods 

(e.g. southern islands below 53 degrees south acquired once per month during their summer 

months). 

Amongst others, the following areas outside of the baseline mission requirements will be 

candidates for specific campaigns: 

 

 

 

 

Southern islands below 53 degrees south; 

Water imaging on coral reefs and algae bloom; 

Night imaging observations for fires or volcanoes activity monitoring; 

Antarctica coverage. 








page 122 of 350 

In practice, such acquisitions will be handled such as to avoid any impact on the overall 

baseline mission objectives (e.g. timeliness conflicts), possibly using the margin left within the 

available downlink budget. 

Nevertheless, the mission-planning capabilities will provision for the possibility of acquisition 

campaigns to take precedence over the nominal acquisition scenario if needed. 

To provide for additional trade-off, the MSI acquisition scenarios will take advantage of 

Sentinel-2 constellation capabilities and embed load balancing between the spacecraft 

acquisition plans (e.g. alternate acquisition campaigns on Sentinel-2A and Sentinel-2B 

spacecrafts). 

As detailed in section 4.5.4.10, additional and possibly interfering acquisitions will be 

performed recurrently for Cal/Val activities. Although generally taking precedence over the 

nominal plan, the impact of Cal/Val requirements on the mission plan will be very limited. 

To satisfy the MSI constraint described in section 4.3.8.3, the MSI acquisition plan will ensure 

that the instrument nominally enters standby mode when the spacecraft reaches eclipse after 

the descending measurement pass. At the end of the eclipse period, the MSI will be switched 

back into idle mode to reach thermal stability 300 seconds before the start of image 

acquisitions at the next pass. Exceptions to this rule will however be permitted to allow for 

seldom acquisitions to be performed during night time (e.g. for dark-signal acquisitions or 

specific acquisition campaigns). In this case and according to the planned night-time 

observations, the instrument commanding to standby (resp. from standby) will be delayed 

(resp. anticipated) to satisfy at best the constraint when better qualified. 

The detailed MSI acquisitions scenario implemented during phase-E2 will be implemented 

from HLOP input along the principles defined above. During Phase-E1 of any spacecraft, the 

PDGS Commissioning Plan (CP) will supersede the HLOP for the operations relevant to that 

spacecraft. 

4.5.4.1.2 Ancillary Data Acquisitions 

The processing of MSI data on-ground requires time-correlated satellite ancillary data. To this 

end, satellite ancillary data will be nominally acquired on-board without interruption and stored 

into the dedicated Ancillary-data memory store. This memory will be managed as a circular 

buffer such that newly acquired data systematically and autonomously replaces the oldest 

one within the total allocated buffer size. 

It is assumed this recording operation is not requiring any specific triggering at PDGS 

mission-planning [Assumption-16]. 

4.5.4.2 Core Mission Data-Recovery On-Ground 

The operation scenario for Sentinel-2 satellite downlinks aims for: 

○ The systematic recovery on-ground of all satellite generated data with an optimised 

apportioning of RT, NRT and nominal timeliness characteristics driven through the 

HLOP; 

○ A very systematic and steady process to the maximum feasible extent. 








page 123 of 350 

○ Making best possible usage of the overall downlink budget available through the CGS 

network in this respect. 

This section describes the approach followed referring when relevant to all operation 

constraints applicable to this process listed in section 4.3. 

4.5.4.2.1 Problem Logic 

This section summarises the overall logic applicable to the definition of the downlink scenario, 

starting from the characterisation of the CGS network and ending at the recurrent detailed 

downlink planning fulfilling all operation constraints applicable to the process. 

The PDGS mission-planning operations will follow the logic described here as four-steps 

approach: 

○ In a first step, the CGS resources globally selected to support the data reception from 

the GSC Sentinels will be characterised for use within the Sentinel-2 PDGS. This step 

will embed a first level of optimisation aimed at mapping at best the high-level scenario 

within the PDGS end-to-end operation objectives, constraints (cf. section 4.3.10.4) and 

target performance (e.g. timeliness); 

○ In a second step, the characterised downlink resources will be mapped to each 

Sentinel-2 spacecraft. This will include the necessary allocations dedicated to Sentinel- 

2 amongst the other Sentinels and a first-level of load-balancing optimisation among 

the Sentinel-2 spacecrafts resulting in a coarse downlink budget applicable to each 

spacecraft; 

○ In a third step, the detailed downlink scenario will be derived based on the actual MSI 

acquisition plan, the data-timeliness priorities set in the HLOP and will implement all 

operation constraints not taken into account in the previous steps. This step will finally 

trigger the mission planning loop with the FOS to carry out spacecraft scheduling; 

○ In a last step, the ground stations (CGS and LGS) will be scheduled for acquisition. 

The two first steps will be carried out at least once in an initial interactive configuration 

operation. They will be repeated as needed following HLOP high-level changes, evolutions in 

the CGS network resources or their relative apportionments to Sentinel-2, or to perform 

general load-balancing optimisations. 

In counterpart, the third step will be automated and embedded in the recurrent missionplanning 

activity performed in closed-loop with the FOS (cf. section 4.5.3.1.1). 

The last step will be triggered independently based on the detailed downlink plan settled at 

the term of step-three and according to the ground station scheduling constraints (typically 

daily). 

The following paragraphs detail this four-step logic. 

4.5.4.2.1.1 Characterisation of the CGS Resources 

This first configuration step aims at globally characterising the CGS resources and providing 

an apportionment of their usage in the overall distributed data-recovery scenario mapped to 

their physical capabilities (e.g. accessibility and sizing). 








page 124 of 350 

The CGS network will be composed X-Band LEO-tracking stations potentially complemented 

by Ka-Band GEO-pointing stations characterised by: 

○ For X-Band tracking stations, their location and derived visibility mask based on the 

Sentinel-2 orbit plane and altitude; In addition, to account for visibility overlaps 

between CGSs, a precedence order will be defined. 

○ For Ka-Band stations, the inherited visibility masks of each EDRS spacecraft with the 

Sentinel-2 orbit, their location being assumed inside of the multi-cast footprint of EDRS 

relay transponders; 

○ To provide for optimisation and map at best their intended usage in the overall mission 

scenario, the above resources will be further classified through specific configurable 

grants allowing or preventing reception of NRT or RT data partitions. 

These grants will be settled based on their complementarity in fulfilling the overall NRT 

and RT requirements of the HLOP outlined respectively in sections 4.3.10.1 and 

4.3.10.2. Their capabilities and constraints in terms of downstream accessibility 

outlined in 4.3.10.3 will globally apply to the trade-off rationale. 

In particular, the fulfilment of the acquisition requirements with RT timeliness (e.g. 

European land coverage), will naturally require that a corresponding CGS located onground 

over the RT selected areas (e.g. in a European site) and with efficient 

downstream connectivity is operated. 

4.5.4.2.1.2 Characterisation of the Coarse Downlink Budget 

This second configuration step aims at defining a static coarse downlink-budget available to 

each Sentinel-2 spacecraft along the repeat cycles. 

To provision for load-balancing optimisations between the Sentinel-2 units, the downlink - 

budget will be separately characterised for each Sentinel-2 satellite.. 

For each spacecraft, a database of downlink opportunities offered through the station network 

along the 10-days repeat cycle will be derived and annotated adequately to characterise the 

overall static budget available for data-recovery on-ground. This database will be 

characterised by: 

○ A list of potential X-Band contact segments along the satellite orbit; 

○ A list of potential OCP contact segments with each EDRS GEO relay transponder; 

○ NRT and RT reception grants applicable separately to every X-Band station acquisition 

or to OCP segments as a whole, as cascading from the CGS characterisation and 

provisioning for load-balancing optimisations. This will result into a pre-classification of 

the core downlink-budget where the segments specifically promoted to receive NRT, 

RT and nominal data are apportioned. 

○ Specific trade-off controls among the above opportunities implementing the timeoverlap 

constraints outlined in section 4.3.10.5 and resulting into the exclusive or the 

compound successive usage of the time-overlapping opportunities. 

○ Explicit segments where the OCP shall be artificially operated in parallel to nominal 

XBS opportunities for OCP commissioning purposes. 








page 125 of 350 

To account for potential conflicts with other Sentinel missions in utilising the X-Band and 

EDRS resources, the available downlink-budget will be further characterised by a database of 

constraints applicable separately to 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; 

○ A list of EDRS Availability Segments: a pre-defined pattern of time segments with an 

N-cycles repeatability during which EDRS spacecrafts are available to relay Sentinel-2 

data (cf. section 4.3.11). 

The above constraints will be defined outside of the strict scope of the Sentinel-2 PDGS. 

4.5.4.2.1.3 Detailed Downlink Planning 

This step will define the effective downlink scenario applicable to each satellite based on the 

associated MSI acquisition scenario and comprehensively ensuring that all operation 

constraints are fulfilled. It will be applied recurrently as required by the mission planning and 

scheduling loop with the FOS (cf. section 4.5.3.1.1). 

The dynamics of the downlink scenario will be constrained by: 

○ The static Coarse Downlink Budget as characterised in the previous step with all its 

embedded constraints defining ground station, OCP and XBS usability; 

○ The plans for station temporary unavailability provided by the ground station operators 

(e.g. during maintenance periods); 

○ The strict satellite operation constraints related to the use of the X-Band data 

transmission subsystem described in sections 4.3.8.4 and the ones related to the 

operations of the OCP as anticipated in section 4.3.8.6. 

In particular, the number of on-off transitions imposed on the XBS and OCP 

subsystems will be minimised on a repeat-cycle basis within the duty-cycle constraints 

of each subsystem imposed at orbit-level. This will impose when relevant the merging 

of non overlapping opportunities into one single transmission segment within the dutycycle 

constraints. In turn, it may further reduce from the coarse figure the downlink 

budget available at specific orbits whenever the duty-cycle does not allow full merging 

of the downlink opportunities. 

Additional TBC conflicts brought in by OCP operations with respect to MSI imaging (cf. 

section 4.3.8.6) or the satellite power budget, coupled with the required TBD transitory 

operations of the OCP itself, will further constrain the usage of EDRS/OCP contact 

opportunities. 

○ The effective zone coverage partitioning into NRT, RT and nominal data defined in the 

HLOP and intersecting the MSI acquisition scenario defined in section 4.5.4.1.1. 









page 126 of 350 

For this, the capabilities offered by the satellite design outlined in 3.5.4 and further 

detailed in [AD-03] and [RD-41] regarding NRT prioritisation or RT downlink will be 

used as described in section 4.5.4.2.2; . 

It is assumed for this final stage that the timeliness partitioning will be compatible with 

the respective capabilities and grants allocated accordingly at the previous 

configuration steps. 

○ A scene security constraint [TBC] to ensure that the last MSI scene downlinked is 

effectively entirely transmitted before LOS (~3.5 seconds TX duration per scene). 

○ The requirements provided through the HLOP for the parallel accommodation of LGS 

direct-downlinks introduced in section 4.2.7 according to the operation scenario 

detailed in 4.5.4.3. 

○ The accommodation of ancillary-data downlinks at the term of each downlink at every 

CGS or LGS as further explained separately in section 4.5.4.2.3. 

○ The accommodation of HKTM data downlinks at selected CGSs according to the 

operation scenario detailed separately in section 4.5.5. 

The mission plan elaborated by the PDGS will comprehensively optimise the detailed 

downlink scenario based on the above considerations. 

Considering the maximum size of the on-board MSI store of 2360 Gbits corresponding to 

about 5 times the storage requirement of an average orbit, this limit will not jeopardize the 

nominal scenario even considering acquisitions campaigns complementing the nominal 

acquisition plan (cf. 4.5.4.1.1). In case of a degraded contingency downlink scenario required 

to operate with less than 4 stations, the data acquisition plan will be reduced accordingly to fit 

within the 2360Gbits packet store autonomy. A safety check in this respect will be 

implemented to invalidate plans neglecting this constraint. 

4.5.4.2.1.4 CGS Scheduling 

As driven by the detailed mission plan settled with the FOS, the CGS schedule will be 

generated to trigger the on-ground data reception activities (cf. section 4.5.4.2.4). This 

scheduling will be performed periodically and will include: 

o A reception schedule to enable the satellite acquisition from the station antenna; 

o A front-end processing schedule to enable front-end processing activities. 

This decoupled scheduling between data reception and front-end processing activities will 

be used to selectively manage the acquisitions between overlapping ground station contacts 

Whilst the reception schedule will ensure satellite tracking from satellite entry into the station 

visibility mask, the front-end processing schedule will selectively map to the data playback 

activities assigned to the station in the downlink plan. 

4.5.4.2.2 MSI Packet-Store Management 

Following the logic described in the previous paragraph, the detailed downlink planning of 

MSI data will require the accurate management of the on-board MSI packet-store to gradually 

playback the data acquired and buffered on-board according to the timeliness requirements 

set for each image segment. 







page 127 of 350 

This section describes the baseline scenario for MSI Playback management using MMFU 

command sequences. 

4.5.4.2.2.1 MMFU Command Sequences 

The baseline management of the MSI packet store is described in the SOCD [AD-03]. It 

involves the commanding of the MMFU for MSI data recording and playback activities as 

summarised hereafter. 

For recording, two exclusive states will be used in rotation: 

○ Record-NRT to be used for the recording of all MSI acquisition segments prioritised for 

NRT playback; 

○ Record-Nominal to be used for the recording of all other MSI acquisition segments 

which are not planned for RT downlink to a core station and hence shall be buffered 

on-board; 

For playback, two distinct commands will be used to trigger the start of the downlink in two 

alternative modes. Both will be explicitly suspended at will by way of a common Playback- 

Stop command. 

○ Playback-Regular-With-Memory-Freed to be used to trigger the playback of the MSI 

packet store while sustaining the recording, and ensuring that the data which was 

recorded with the NRT option is downlinked before any other data. At playback stop 

playback stop, the data downlinked in this session will not be retained for further 

playbacks; 

○ Playback-RT-With-Memory-Freed to be used to trigger an MSI real-time downlink 

without recording the data in parallel; 

Based on the above, Figure 4-19 depicts a typical scenario including RT, NRT and nominal 

MSI acquisitions that will translate the HLOP definitions using the above MMFU recording and 

playback commands. 








page 128 of 350 

Orbit N-1 descending part 

Orbit N descending part 

Downlink Plan 

MSI packet store playback timeline 

CGS-A 

CGS-B 

Regular with- 

Memory-Freed 

Stop 

Regular with- 

Memory-Freed 

Stop 

MMFU commands 

MMFU playback 

command timeline 

RT- with- 

Memory-Freed 

Stop + 

Regular with- 

Memory-Freed 

Stop 

Regular with- 

Memory-Freed 

Stop 

Nominal 

NRT 

Nominal 

NRT 

Nominal 

MMFU record command timeline 

NRT 

Nominal 

HLOP-driven acquisition plan 

NRT NRT Nominal ocean 

NRT 

MSI imaging timeline 

RT 

MSI data recovered 

at core stations 

CGS-A 

CGS-B 

Figure 4-19: MMFU Baseline Commanding Scenario for MSI 

To avoid unnecessary NRT/Nominal transitions, the recording timeline will be optimised such 

that Nominal-NRT-Nominal transition patterns are removed whenever the inner NRT fragment 

is downlinked within the same playback segment as its adjacent Nominal observations (cf. 

case of the first NRT segment in Figure 4-19). 

4.5.4.2.2.2 MMFU Scene Overlap Management 

As introduced in section 4.3.8.2, the management of the MMFU memory will generate 

discontinuities in the timeline received at every CGS. To simplify the PDGS operations in 

handling those discontinuities in view of MSI data processing, the MMFU design is being 

adapted as described in [RD-41] to allow, via appropriate commanding, to artificially 

introduce three redundant MSI scenes covering every timeline discontinuity. 

This functionality will be used by the PDGS mission planning function as follows: 

○ The Scene Rewind flag will be activated at every interruption of Playback-Regular- 

With-Memory-Freed operations provided the MMFU memory is not emptied at the term 

of the playback (cf. case-A in the figure depicted below); 








page 129 of 350 

○ The Scene Duplication Flag will be activated at every recording NRT/Nominal 

transition provided the MSI is operating during that transition (cf. case-B in the figure 

depicted below); 

○ The Scene Duplication Flag will be activated in case of Playback-RT operations on the 

following cases (cf. case-C in the figure depicted below): 

‣ The Scene Duplication Flag will be activated at every Playback-RT-With- 

Memory-Freed transition provided the MSI is operating immediately before that 

time (i.e. at the entry point of the RT segment). 

‣ The Scene Duplication Flag will be activated at every interruption of Playback- 

RT-With-Memory-Freed operations provided the MSI is operating immediately 

after that time (i.e. at the exit point of the RT segment). 

Figure 4-20: MMFU Scenes Duplication Cases 

As justified in [RD-30], this strategy will result in sufficient MSI data received at every groundstation 

to cover the discontinuities between stations and ensure consistency of the global 

processing. It will also fulfil the MSI spatial registration constraint described in section 

4.3.9.2.3 requiring that the MSI downlink in every CGS does not create orphan MSI segments 

of less that 60km along-track. As a matter of fact, the appended three scenes will ensure that 

although one station may receive trunks of data of less than three scenes, another one will 

necessarily receive the same data in a larger set to cover the processing needs. 

4.5.4.2.2.3 Playback Management 

The accommodation of the Playback-Regular sequence within the station contact period will 

differ based on whether the MSI packet store can be emptied at the term of the contact or 

whether it must be explicitly suspended to let a subsequent playback operation recover the 

remains of the buffer. This implies that the evolution of the MMFU memory is modelled by the 

PDGS with sufficient accuracy as part of mission planning activities. 

Figure 4-21 depicts these two distinct approaches simulating identical initial conditions of the 

memory at the time of Acquisition-Of-Signal (AOS) with different lengths of the visibility 

segment available for playback. 








page 130 of 350 

(a) In case the visibility segment allows for a full playback, the start of the MSI playback 

sequence is delayed such as to minimise the downlink requirement for the next pass. 

No explicit playback-stop will be required but one can be set for safety shortly after 

LOS. 

(b) When the visibility segment is too short to accommodate the full playback, the 

playback sequence is started at AOS and explicitly suspended with a Playback-Stop 

command. 








page 131 of 350 

Figure 4-21: MSI Playback Commanding within Station contact time 

Although playback segments may be scheduled some time after the station AOS, the XBS 

commanding will on the contrary be activated starting shortly before AOS to offer the best 

possible conditions for satellite tracking initialisation. It is assumed [Assumption-17] that 









page 132 of 350 

whenever no data is fed by the MMFU, the satellite XBS will automatically transmit idle 

frames with an adequate noise pattern to make the modulated signal compatible with CCITT 

regulations. 

4.5.4.2.3 Ancillary-Data Packet-Store Management 

As introduced in section 4.3.8.5, the asynchronous handling of the Ancillary and MSI data on 

board, each one routed to different packet stores separately operated for downlink, imposes a 

specific scenario to ensure that the ancillary data coinciding in time with the MSI data 

downlinked at a specific CGS or LGS is appended to the downlink. 

The ancillary data acquired along one orbit can be downlinked in a very short time at any 

given station pass unlike the corresponding MSI data which will necessarily be scattered 

throughout several station passes. It is hence required that the ancillary packet store is 

managed as a time-rolling buffer systematically ensuring via its complete playback the 

coverage in time of the MSI data timeline received at every CGS or LGS. 

To this aim, and coupled with the ancillary data acquisition scenario described in section 

4.5.4.1.2, the ancillary-data circular buffer will be operated as follows for data recovery onground: 

○ It will be minimally sized such as to hold at any given time the data down to a couple of 

orbits in the past corresponding to the maximum uncertainty inherent to the MSI data 

downlink strategy; 

○ It will be managed as a time-rolling buffer (cf. 4.5.4.1.2) and downlinked entirely by 

playback to every CGS or LGS following the MSI downlink. This will ensure that the 

acquired ancillary-data covers entirely the MSI timeline recovered at the station. 

Playback commanding of the Ancillary memory will be driven by the PDGS through the 

mission-planning loop with the FOS. 

Adequate sizing of the packet store can be performed in-flight via a specific telecommand. 

The PDGS will manage this parameter as part of its mission planning activities such that it 

can be re-adapted at will following changes on the overall data downlink scenario. 

4.5.4.2.4 On-Ground Data Reception 

At every CGS, the PDGS will acquire the mission data downlinked from the spacecrafts as 

driven by the CGS schedules derived from the downlink plan (cf. section 4.5.4.2.1.4). 

According to the downlink agenda, the reception activities will be activated shortly before the 

planned AOS event and include the following real-time operations: 

o The antenna selected for acquisition will be moved to the AOS position and signal 

search will be activated enabling tracking on the RF carrier signal with the associated 

antenna movement until the planned LOS; 

o Bit synchronisation, locking on the Sentinel-2 signal and demodulation from AOS to 

LOS will be autonomously performed by the demodulation hardware. For Ka-Band 

acquisitions via EDRS, a dedicated EDRS compatible hardware will perform the 

demodulation; 

o Front-end processing activities will be performed in parallel according to the front-end 

processing schedule including frame synchronisation, decoding (descrambling and 







page 133 of 350 

Reed Solomon FEC), time annotation of telemetry data and real-time storage.. In 

parallel, the acquired raw data will be supplied in real-time to downstream PDGS 

functions for further elaboration. 

Demodulation and front-end processing will be performed in parallel onto two redundant 

equipments to provide for reliability. A single equipment will be configured for nominal 

autonomous downstream data-supply operations to the Level-0 processing chain. The 

second unit will be used on contingency (cf. section 4.5.4.3.2). 

4.5.4.3 Real-Time Data Downlinks to Local Stations 

As anticipated in section 4.2.7, the PDGS will accommodate LGS real-time downlinks in the 

mission plan. This operation will be based on a predefined network of LGS granted through 

HLOP for direct-downlink access. 

4.5.4.3.1 Planning Strategy 

At each mission-planning session (cf. 4.5.3.1.1) and after the preliminary downlink plan to the 

CGS network has been settled, additional opportunities for real-time transmission left in the 

X-Band downlink budget (cf. section 4.3.8.4) will be computed. An ancillary data playback will 

systematically be appended at the term of each RT opportunity as described in paragraph 

4.5.4.2.3 and further detailed in [AD-03]. The resulting plan will be merged in the nominal 

mission-plan fed to the FOS. 

As mentioned earlier, the prospects of a core mission data-recovery scenario to a CGS 

network including X-Band ground-stations appointed to receive RT data (e.g. over Europe) 

will enhance the possibility to serve a coinciding LGS network. In this case, the Ancillary 

packet store enabling MSI processing might require two successive downlinks: 

○ A first one at the term of the core RT downlink in such a way that it can be received by 

the coinciding LGS network; 

○ A second one placed immediately after a possibly trailing NRT/Nominal playback 

commanded following the RT segment to take benefit of the remains of the core station 

visibility. 

Figure 4-22 depicts an example of this scenario whereby a core RT downlink over a CGS 

located in Europe is received in parallel by two coinciding LGSs, LGS1 and LGS2. 

It successively features: 

○ One continuous RT segment covering the European zone acquired entirely in the CGS 

and in parts by LGS1 and LGS2; 

○ One Ancillary-Data playback at the term of the European coverage RT acquisition 

dedicated to enabling MSI data-processing in LGS stations; 

○ One playback segment of on-board recorded MSI data (NRT, Nominal or both) taking 

benefit of the remaining CGS visibility whilst RT is no more required; 

○ One trailing Ancillary-Data playback at the end of the CGS visibility to enable MSI 

data-processing at the CGS. 








page 134 of 350 

Core MSI RT Downlink 

Received at LGS1 

Received at LGS2 

Ancillary–Data 

Playbacks 

for LGS1/2 

for CGS 

MSI Record 

MSI Playback 

Figure 4-22: RT Downlink over one CGS and several coinciding LGSs 

To account for potential conflicts between several candidate LGS in using the remaining 

downlink budget, the planning strategy will apply a round-robin priority scheme to reach 

fairness of opportunities among LGSs. This scheme will in particular ensure that in the case 

of LGSs having overlapping station masks, the data gaps in the MSI data induced by the 

ancillary data trailing playback to another LGS is not systematically repeated. 

4.5.4.3.2 LGS Scheduling 

The LGS network will be periodically scheduled for acquisition similarly to the CGS network 

(cf. section 4.5.4.2.1.4). In this case, each LGS station schedule will be derived by 

intersecting the LGS station-mask with all RT downlink opportunities settled in the mission 

plan and including the ancillary data playback. 








page 135 of 350 

4.5.4.4 Level-0 Data Processing Operations 

Level-0 data processing operations will be performed in real-time during the data-reception 

operations described in section 4.5.4.2.4. They will consist in packaging the MSI and satellite 

ancillary raw-data supplied by the front-end CGS equipment, and in locally archiving it as 

Level-0 data files together with appropriate annotations and metadata to enable further 

processing. 

It is highlighted however that the advanced Level-0 consolidation processing (as defined 

later) will not be performed as part of this operation which is dedicated to safeguarding the 

data received in real-time from the spacecrafts preserving its integrity. Therefore, MSI & 

Satellite Ancillary telemetry advanced analysis and preliminary cloud mask generation will be 

performed as part of the Level-0 consolidation processing. 

Level-0 processing performed in real-time during data-reception includes: 

o MSI Tememetry Analysis (performed within the GPP by the Ana_TM-Image function 

from the Ana_TM IAS). This processing step organizes ISPs in granules and includes 

data analysis and errors detection. 

o Datation (performed within the GPP by the Datation function of the Datation & LR 

Extraction IAS). This processing step implements the datation method at granule level. 

o Low-Resolution Image Extraction (performed within the GPP by the LR_Extraction 

function of the Datation_&_LR_Extraction IAS).This processing step extracts the lowresolution 

images fro the preliminary quicklook generation from the ISPs. 

o Satellite Ancillary Telemetry Analysis (performed within the GPP by the Ana_TM- 

SAD function of the Ana_TM IAS). This processing step generates satellite ancillary 

data from bit values and checks it with respect to admissible ranges. 

Contingency operations of the critical Level-0 processing and archiving step will be accounted 

for by means of operational procedures triggered by appropriate alerts to the station operator. 

Two contingency recovery procedures will be supported: 

○ Short time recovery triggered by the operator before the next satellite pass. This firstlevel 

procedure aims at recovering from potential problems occurring either: 

o On the nominal front-end equipment, in this case the recovery procedure will 

trigger the redundant unit for data-supply to the Level-0 processors, 

o From problems occurring during Level-0 processing or at the real-time datasupply 

interface from the front-end equipment. 

Off-line during blind orbits by an appropriate operator-driven selection of the pass to be 

recovered from the front-end processor rolling buffer. This second-level procedure accounts 

for more generalised problems on the Level-0 processing chain or inadequacy of the firstlevel 

procedure in some specific case (e.g. late operator reaction). 

4.5.4.5 Level-0 Consolidation and Level-1 Data Processing Operations 

As introduced in sections 4.5.1.2 and 4.5.1.5, all data acquired by the MSI from the Sentinel-2 

constellation will be mechanically processed up to Level-1C, as cascading from datareception 

on-ground in a systematic manner. Level-1C processing comprehensively includes 








page 136 of 350 

radiometric and geometric corrections including ortho-rectification and spatial registration on a 

global reference system with sub-pixel accuracy to facilitate multi-temporal data exploitation. 

The MSI Level-1C product will provide Top-Of-Atmosphere (TOA) reflectance measurements 

with all metadata necessary to convert it in radiances. The Level-0 consolidation and Level-1 

data-processing steps are based on the GPP algorithms [RD-31]. 

Level-0 consolidation will append all necessary metadata for Level-0 data long-term archiving 

and upper level processing. 

Level-1 processing includes the three-step processing to generate Level-1A, Level-1B and 

Level-1C data starting from the consolidated Level-0 data. These three levels correspond 

respectively to the S2MSI1A, S2MSI1B and S2MSI1C data-products baselined in section 4.4. 

The accommodation of the processing workflow defined for the GPP into the distributed 

PDGS operational context has nevertheless required a careful analysis (cf. [RD-30]) of the 

specific constraints imposed by the Level-1 algorithm (cf. section 4.3.9) to provide 

systematically and globally the products with a guaranteed timeliness and quality. 

This section provides an outline of the operational Level-0 consolidation and Level-1 

processing approach adapted for the PDGS. After an outline description of the algorithm 

logic, the context of Level-1 processing in the distributed PDGS will be presented followed by 

the main adaptation made in accommodating the processing workflow defined for the GPP as 

justified by [RD-30]. 

4.5.4.5.1 Level-0 Consolidation and Level-1 Processing Logic 

The PDGS Level-0 consolidation and Level-1 processing breakdown is based on the 

Sentinel-2 GPP algorithm (cf. [RD-31]). The processing workflow from instrument raw data 

(Instrument Source Packets, ISPs) to Level-1C data is depicted on Figure 4-23. The 

processing sequence is decomposed in the following steps: 

Level-0 Consolidation Processing 

o Level-0 Viewing Model Initialisation (performed within the GPP by the Init_Loc_Inv 

IAS). This processing step computes the viewing model for the generation of the 

preliminary quicklook. 

o Preliminary Quick-Look Processing (performed within the GPP by the Init_Loc_Inv 

IAS). This includes the preliminary quick-look (PQL) resampling and the computation 

of ancillary data for consolidated Level-0 product. 

o Preliminary Cloud Mask Processing (performed within the GPP by the Cloud_Inv 

IAS). This processing step generates the cloud mask from the preliminary quicklook 

based on spectral criteria. 

o Preliminary Quick-Look Compression (performed within the GPP by the 

JP2KCompression IAS). Performs the compression of the preliminary quick-look. 

Level-1A Processing 

o Level-1 Viewing Model Initialisation (performed within the GPP by the Init_Loc_Prod 

IAS). This processing step computes the viewing model that will be used to initialize 

Level-1B processing. 









page 137 of 350 

o Decompression (performed within the GPP by the MRPBC function). This processing 

step performs the decompression of the ISPs inverting the on-board WICOM 

compression. 

o Level-1A Radiometric Processing (performed within the GPP by the first part of the 

Radio_S2 IAS). This step includes the SWIR pixels arrangement. 

o Level-1A Compression (performed within the GPP by the JP2KCompression IAS). 

This processing step compresses Level-1A imagery using JPEG2000 algorithm. 

Level-1B Processing 

o Level-1B Radiometric Processing (performed within the GPP by the second part of 

the Radio_S2 IAS). This includes dark signal correction, pixel response non-uniformity 

correction, crosstalk correction, defective pixels identification, high spatial resolution 

bands restoration (deconvolution and denoising) and the binning of the 60m spectral 

bands. 

o Common Geometry Grid Computation for Image-GRI Registration (performed 

within the GPP by the Geo_S2 IAS). This processing step defines the common 

monolithic geometry in which the GRI (Global Reference Images) and the reference 

band of the image to refine shall be resampled. 

o Respampling on Common Geometry Grid for Image-GRI Registration (performed 

within the GPP by the Geo_S2 IAS). This processing step performs the resampling on 

the common geometry grid for the registration between the GRI and the reference 

band. 

o Tie Points Collection for Image-GRI Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step includes the collection of the tie points from the 

two images for the registration between the GRI and the reference band. 

o Tie Points Filtering for Image-GRI Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step performs a filtering of the tie points over several 

areas (sub-scenes) and a given number of trusty tie points is required for each subscene. 

o Spatiotriangulation for Image-GRI Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step refines the viewing model using the initialized 

viewing model and the set of ground control points from previous steps. The output 

refined model ensures the registration between the GRI and the reference band. 

o Common Geometry Grid Computation for VNIR-SWIR Registration (performed 

within the GPP by the Geo_S2 IAS). This processing step defines the common 

geometry in which the registration will be performed. The VNIR-SWIR registration 

processing is optional and applicability will be decided at commissioning. 

o Respampling on Common Geometry Grid for VNIR-SWIR Registration (performed 

within the GPP by the Geo_S2 IAS). This processing step performs the resampling on 

the common geometry grid for the registration between VNIR and SWIR bands. The 

VNIR-SWIR registration processing is optional and applicability will be decided at 

commissioning. 

o Tie Points Collection for VNIR-SWIR Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step includes the collection of the tie points from the 







page 138 of 350 

two images for the refinement of the registration between VNIR and SWIR focal 

planes. The VNIR-SWIR registration is optional and applicability will be decided at 

commissioning. 

o Tie Points Filtering for VNIR-SWIR Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step performs a filtering of the tie points over several 

areas (sub-scenes) and a given number of trusty tie points are required for each subscene. 

The VNIR-SWIR registration processing is optional and applicability will be 

decided at commissioning. 

o Spatiotriangulation for VNIR-SWIR Registration (performed within the GPP by the 

Geo_S2 IAS). This processing step refines the viewing model using the initialized 

viewing model and the set of ground control points from previous steps. The output of 

this step is a refined viewing model ensuring the registration between VNIR and SWIR 

focal planes. The VNIR-SWIR registration processing is optional and applicability will 

be decided at commissioning. 

o Level-1B Compression (performed within the GPP by the JP2KCompression IAS). 

This processing step compresses Level-1B imagery using JPEG2000 algorithm. 

Level-1C Processing 

o Level-1C Tiles Association (performed within the GPP by the Tiling_S2 module of 

the Resample_S2 IAS). This module selects pre-defined tiles which intersect the 

image footprint. 

o Level-1C Resampling Grid Computation (performed within the GPP by Phases 1 to 

7 of the Resample_S2 IAS). This processing step calculates the resampling grids, 

linking the image in native geometry to the target geometry (ortho-image). 

o Resampling on Level-1C Geometry (performed within the GPP by Phase 8 of the 

Resample_S2 IAS). This processing step resamples each spectral band in the 

geometry of the ortho-image using the resampling grids and an interpolation filter. In 

addition, it calculates the TOA reflectances. 

o Masks Computation (performed within the GPP by the Mask_S2 IAS). This step 

generates the cloud and land/water masks at Level-1C geometry. 

o Level-1C Compression (performed within the GPP by the JP2KCompression IAS). 

This processing step compresses Level-1C imagery using JPEG2000 algorithm and a 

GML geographic imagery encoded header. Level-1C data is output at the term of this 

step. 








page 139 of 350 

Figure 4-23 Level-1 Processing Workflow (Doted boxes indicate optional processing steps). 








page 140 of 350 

4.5.4.5.2 Level-1 Processing Context and Datastrip Processing 

The terminology “Datastrip” refers to all MSI data acquired during a given orbit and received 

at a given CGS during a given satellite pass. In the PDGS distributed context, to ensure the 

timeliness requirements and as driven by the downlink scenario scattering MSI Datastrips 

amongst several ground-stations, the Level-1 processing will be carried out per Datastrip as 

opposed to being applied on the complete MSI orbit. 

Datastrips will stem from RT or NRT priority downlinks or from on-board playback 

interruptions explicitly commanded at LOS to let subsequent ones recover the remains of the 

on-board store. Considering the average imaging duration of 16 minutes per orbit relatively to 

the average downlink budget available at every ground-station pass (about 8 minutes), every 

MSI imaging orbit received on ground will hence produce at least two Datastrips, even without 

any RT or NRT commanding within the orbit. 

Figure 4-24 depicts this general case where the MSI orbit imaging pass is systematically 

fragmented after downlink into two sub-orbit Datastrips acquired at remote stations. 

Datastrip 1 dowlinked at 

station A 

Datastrip 2 dowlinked at 

station B 

Figure 4-24 Sub-Orbit Datastrips 

This happening creates a major constraint to the Level-1 processing as it imposes that the 

processing is performed on Datastrip portions of a non deterministic sub-orbit size. 

The MSI processing constraints described in sections 4.3.9.1, 4.3.9.2.2 and 4.3.9.2.3 require 

continuity of the input flow. Such continuity is ensured by the MMFU on-board memory 

management as described in 4.5.4.2.2.2 section. MSI scenes are duplicated on the MSI 

segments boundaries allocated in the memory to avoid sensing discontinuities on-ground 

produced by the on-board recording operations switch to different priorities (i.e. transitions 

amongst RT/NRT/nominal recording priorities) and the downlink operations as explained in 

3.5.4.3 section. 








page 141 of 350 

The update of the MSI Packet-Store Management strategy, which is presented in section 

4.5.4.2.2, ensures the required margins in the input data-flow to the level 1 processing (3 MSI 

scenes preceding each time-continuous segment) are embedded in the space-to-ground 

downlinks to produce a continuous level 1 timeline along all the Datastrips. 

Figure 4-25 MSI level 1 continuous processing timeline 

4.5.4.5.3 Level-1A and Level-1B Processing 

4.5.4.5.3.1 Ancillary-Data Handling 

As highlighted previously, the on-board recorded Ancillary-Data is required for MSI Level-1 

processing and is recovered by playback separately to the MSI data. Nevertheless, the 

downlink strategy defined in 4.5.4.2.3 will ensure that the Ancillary-Data coinciding in time 

with every MSI Datastrip will be available on-ground contemporaneously at the term of every 

downlink. 

Hence, whilst the Level-0 initial processing will be performed in real-time in parallel to datareception 

operations, Level-0 consolidation and Level-1 processing activities will be delayed 

as triggered after the recovery on-ground of the Ancillary-Data at the end of every satellite 

pass. 

Ancillary-Data will be ingested together with the MSI raw-data at the beginning of the Level-0 

consolidation processing sequence and used seamlessly through the algorithmic steps by 

time-correlation with the MSI data. 

4.5.4.5.3.2 Datation Refinement 

The datation refinement will not be nominally performed as justified in section 4.3.9.2.1. 

Nevertheless, to provision for a possible contingency on the on-board datation process, 

Level-1 processing will optionally support the generation and handling of a refined datation 

model. The generation of this ancillary data by the PDGS is currently not foreseen but will be 

accommodated if required as a change to solve this eventual contingency. 

In addition, datation accuracy will be monitored in the PDGS as part of nominal and recurrent 

quality control procedures (e.g. on a monthly basis). 








page 142 of 350 

4.5.4.5.3.3 Processing Margins 

Considering that Level-1 image processing can be performed independently per-detector, the 

required overall fore+aft margin amounts to twice the sum of the margins budgeted in 

sections 4.3.9.1 (2/3 rd of a scene) and 4.3.9.2.2 (10% of a scene), resulting in 2 scenes 

considering the granularity of the measurements. 

For spatial registration (cf. section 4.3.9.2.3) it is introduced a margin of three MSI scenes 

total overlap (fore+after margin overlap) at each discontinuity (cf. section 6.20.3Appendix-B - 

MSI Scenes Overlap Analysis). 

Hence, the compound processing will require a fore+aft margin of three MSI scenes to be 

ensured as described in section 4.5.4.2.2.2. 

4.5.4.5.3.4 Preliminary Quick-Look and Cloud Mask Processing 

Since all data will be elaborated up to Level-1C, the final preview image (PVI) will be 

computed over the Level-1C images. Nevertheless, a preliminary quick-look (PQL) 

processing will be performed and will be used to derive a preliminary cloud-mask mapped on 

the Level-1A and Level-1B geometry. 

This preliminary quick-look generation requires coarse band registration (with at least 150m 

accuracy) which is impaired by the Datastrip discontinuities (cf. previous paragraph). As such, 

it will be implemented as a Level-0 consolidation processing sequence, deferring the 

extraction steps specified for the GPP Level-0 inventory sequence. 

In complement, the derived cloud-mask will be used to extract a coarse cloud-cover metadata 

comprehensively summarising the cloudiness of each MSI scene and detector measurement. 

This metadata will be appended as ground-generated ancillary data and processed as an 

inventory item such that it can be used to selectively filter the data by simple threshold at 

Level-0, Level-1A and Level-1B processing levels and with a spatial granularity of 23km x 

25km. 

During commissioning phase, the preliminary quick-look will be provided optionally as a 

downloadable ground ancillary data of the Level-0/1A/1B products to provision for potential 

problems in the higher level processing steps preventing final quicklook generation. 

4.5.4.5.3.5 Spatial Registration 

As outlined in paragraph 4.3.9.2.3, the stringent requirements of multi-temporal registration 

lead to setup a specific processing to improve the location accuracy based on automatic 

ground control point (GCP) selection and a geometric viewing model refinement algorithm. To 

this end, a global reference image will be produced starting at commissioning phase of 

Sentinel-2A as described in section 4.5.4.10.3.1. Any Sentinel-2 image will then be 

geometrically refined thanks to automatic tie-point selections with respect to these reference 

images. 

Within the PDGS distributed context, the quality of this refinement will be ensured by means 

of: 








page 143 of 350 

○ A global refinement at Datastrip level as recommended in [RD-30] (cf. section 

4.3.9.2.3) to constrain the model with the maximum number of GCPs extracted over all 

images of the Datastrip. 

○ The usage of MMFU scene duplication capabilities (cf. 4.5.4.2.2.2), ensuring that: 

o no orphan segment of less than 60km along-track is left alone, hence 

complying with the algorithm constraint outlined in 4.3.9.2.3. 

o three MSI scenes systematically cover each datastrip discontinuity, 

guaranteeing continuity of the refinement at the boundaries (cf. 4.5.4.5.3.3). 

Figure 4-26 illustrates this process showing the small overlaps artificially introduced between 

Datastrips to ensure continuity. 

4.5.4.5.3.6 NUC Table Handling 

The periodic NUC table updates triggered by the Cal/Val processes (cf. section 4.5.4.10.2.2) 

will require that the GIPP corresponding to the NUC table loaded on board is unambiguously 

selected for the processing. This association will by dynamically performed based on the 

NUC table identifier stamped in every MSI raw-data scene. 

Reference image 

Datastrips 

geometrically 

refined 

Figure 4-26 Independent Geometric Refinement 








page 144 of 350 

4.5.4.5.4 Level-1C Processing 

4.5.4.5.4.1 Digital Elevation Model Handling 

Based on the constraints highlighted in section 4.3.9.2.5, two DEMs at different spatial 

resolutions will be used for the Level-1 processing: 

o A nominal DEM at a fine spatial resolution and according the DTED1 class (resolution 

of 90m) such as the ones highlighted as candidates in section 4.3.9.2.5; 

o A backup DEM at a coarser resolution for areas not covered by the finer-resolution 

DEM. 

The backup DEM, called GLOBE, was generated based on two sources: NOAA GLOBE DEM 

and GTOPO30 (result of eight sources of altimetric data delivered by USGS). This DEM 

defines altitude information with an average value for all the point on a global grid with a 

kilometric resolution. It is characterised by an absolute horizontal accuracy (90% Circular 

Error) of 60 meters and an absolute vertical accuracy (90% Linear Error) of 100 meters. 

The quality of the DEM GLOBE is not sufficient for reaching the required Level 1C products 

absolute geolocation accuracy baselined in 4.4.4.1. It will be used only as backup if no global 

DEM of DTED1 class is available globally. 

To provide for flexibility in adapting to any global DEM that could be made available, DEM 

input to the Level-1 processing will comply with the generic DTED format (DTED1 or DTED2). 

The selected DTED DEM (with the GLOBE DEM as backup) will be used uniformly 

throughout the PDGS as a configurable GIPP to ensure consistency of the global Level-1C 

dataset. 

To ensure traceability, the derived geolocation accuracy and source DEM usage will be 

systematically traced back in every product as QI metadata. 

4.5.4.5.4.2 Resampling 

The Level-1C processing algorithm includes an orthorectification step together with a 

resampling step mapping the images into a geocoded space to be usable by Sentinel-2 

product users. The resampling step imposes geometric transformation of the pixels from the 

source instrument frame to the geocoded space. For this transformation an appropriate filter 

will be chosen as recommended in [RD-30]. 

The Level-1C data will be directly mapped into an earth fixed projection, widely used, and 

adapted as much as possible to the downstream usage of Sentinel-2. The standard UTM 

projection space has been chosen as the best compromise in this respect while ensuring the 

continuity and harmonisation with other data of the Sentinel-2 group of missions such as 

SPOT and Landsat. The Level-1C data will be provided at 10/20/60 meters spatial resolution 

corresponding to Level-1B resolution. 

As justified in [RD-30], the resampling to UTM from the instrument vieweing geometry may 

have to be performed on supersampled versions of the Level-1B images. This technique can 

also be applied by downstream users when performing remapping to other projection spaces 

required for their applications. 








page 145 of 350 

4.5.4.5.4.3 Griding and Tiling 

The Level-1C data, systematically ortho-rectified, spatially registered and geocoded in UTM 

projected space will be divided in tiles steadily mapped into a fixed global reference system, 

embedding the Level-1C multi-temporal spatial registration features (cf. previous paragraph). 

A tile sizing of 100km x 100km was chosen as a good compromise adapted to data selection 

granularity and transport. The tiling concept is illustrated on Figure 4-27 showing the standard 

6º longitude x 8º latitude UTM zones divided into 100km x 100km tiles. 

one 100km x 100km tile 

Figure 4-27 Level-1C Tiling Concept in UTM 

The tiles will be generated during the resampling process on all intersections of the image 

footprint with the tiled reference system. This process is illustrated on Figure 4-28. Small 

overlaps across tiles will be generated at the boundaries of the UTM zones as naturally 

implied by the UTM projection space. 

The downstream product reconstruction mechanisms will allow the aggregation of several 

tiles of the same orbit into a single product as explained in section 4.4. 








page 146 of 350 

UTM Tile 

Tile overlaps 

across UTM zone 

boundaries 

MSI footprint 

4.5.4.5.4.4 Image Compression 

Figure 4-28 Tile Processing 

At the term of the processing, the Level-1C image data will be compressed via JPEG2000 to 

reduce the volumes to be transported. The standard JPEG2000 compression algorithm 

features: 

o Image compression capabilities with adequate control over the compressed image 

quality (in lossless mode or quality controlled mode) with possibility of internal tiling; 

o Compression / decompression times compatible with customer requirements, and 

long-term availability as standardised through ISO/IEC 15444-1:2004 

According to preliminary tests performed on a simulated Sentinel-2 dataset and reported in 

[RD-30], an average compression of the 12bpp image to a 5.2 bpp image can be obtained in 

lossless mode (corresponding to a compression ratio of about 2.3) 

Compression in lossy mode will still be acceptable from an image quality point of view by 

setting a compression-rate slightly superior to the 4 bpp data-rate used by the on-board 

WICOM, hence resulting into a equivalent compression-ratio slightly inferior than 3. 

The JPEG2000 compression rate will be configurable via a configuration parameter to be 

evaluated during the commissioning phase. For sizing purposes, a compression-rate of 

4.2bpp will be assumed (corresponding to a ratio of about 2.8 from the 12bpp radiometry 

coding). 

4.5.4.5.4.5 Preview and True-Colour Images Generation 

The Level-1C processing will include the systematic generation of reduced-resolution preview 

images (PVI) as well as full-resolution True-Colour Images (TCI), the latter being optionally 

activated: 








page 147 of 350 

○ PVI data will be inventoried and maintained over the mission and beyond. It will be 

used for data browsing purposes and will be optionally aggregated in the product 

structures available to users on product delivery. 

○ TCI data will be published independently through an on-line Public Access system (cf. 

section 4.5.2.2.3). 

4.5.4.6 Level-2 Data Processing Operations 

The Level-2 data-processing operations aim at the on-demand generation of the S2MSI2Ap 

prototype product introduced in section 4.4. It will be carried out by a user triggered 

atmospheric correction prototype processor integrated in the PDGS by means of the hosted 

processing service (cf. 4.8.1.2). 

The algorithm aims at performing enhanced cloud screening and atmospheric correction in 

order to derive Bottom-Of-Atmosphere (BOA) reflectances from the TOA reflectance data 

extracted at Level-1C. The Level-2A product definition baseline is detailed in [RD-32] and 

mirrored in the overall Sentinel-2 product model described in [RD-07]. 

Two options are currently being considered for implementing Level-2A processing: SMACbased 

[RD-34] and ATCOR-based [RD-35] approaches. They are briefly summarised 

hereafter: 

○ The SMAC-based approach is based on a semi-empirical approximation of an 

atmospheric radiative transfer code. The signal at the satellite is decomposed as the 

sum of a set of terms. This simplified model, that runs much faster than a full radiative 

transfer model, is used to invert the radiative transfer equation, and to calculate the 

surface reflectance from satellite measurements. Aerosol properties and water vapour 

content are derived from the image itself. Auxiliary data sets [RD-33] are used for 

ozone content as well as back-up climatological data for those cases in which 

atmospheric properties retrievals would fail. 

○ The ATCOR-based method performs atmospheric correction based on the 

MODTRAN-4 radiative transfer model. MODTRAN is run once to generate a large 

look-up table (LUT) accounting for a wide variety of atmospheric conditions, solar 

geometries and ground elevations. This LUT is used as simplified model (running 

faster than the full model) to invert the raditaive transfer equation, and to calculate 

bottom-of-atmosphere reflectance. All gaseous and aerosol properties of the 

atmosphere are either derived by the algorithm itself or fixed to an a priori value. 

Therefore, no auxiliary data is used by this approach. 

An on-going activity will result in a comparative assessment of the two alternatives which will 

then drive the final selection implemented for operational processing. 

The prototype Level-2A will be generated on-demand based on Level-1C tiles and the 

resulting BOA reflectance images will be mapped and tiled identically. 

4.5.4.7 On-Line Quality Control Operations 

A subset of the QC activities will be performed over all the systematic production before data 

products are made available to the users. This essential QC will be performed in the 








page 148 of 350 

production flow and include checks performed autonomously (operator unattended) on every 

PDGS generated production. 

Data-access towards general users will be granted based on those essential checks and QC 

traceability will be embedded in every product under the form of one or several “qualityreports” 

provided as QI metadata in the product structure. Examples of such QIs are provided 

in [RD-07]. 

Even if the systematic QC will be as automatic as possible, complementary visual inspection 

will be performed daily by the operator on the basis of the preview images to provide a 

second line interactive quality stamping authorising or preventing distribution beyond the day. 

In addition, this on-line QC process will be used to perform pre-processing steps in the overall 

QC chain which immediate results will be fed to the complementary off-line QC process (cf. 

section 4.5.3.2) running more complex QC algorithms over short to long-term mission 

periods. The long-term monitoring of the on-board image datation error budget (cf. 

4.5.4.5.3.2) is one example of this second-line quality monitoring process using on-line preprocessing 

to sample the timing information from the instrument raw-data. 

4.5.4.8 Reprocessing Operations 

The PDGS will provision for data reprocessing operations in response to two distinct 

requirements: 

○ Reprocessing campaigns, provisioning for the reprocessing of entire mission periods 

over the archived data after 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; 

○ Reprocessing as a recovery from contingencies after malfunctions of the real-time 

chain e.g. at a particular orbit; 

These two scenarios are separately described in the following paragraphs. 

4.5.4.8.1 Reprocessing Campaign Scenario 

Level-1 reprocessing campaigns will consist in regenerating the S2MSI1C dataset from 

S2MSI0. During Level-1 processing, the Level-1B data will also be regenerated and 

maintained in the archives according to the retention policies in place (nominally 1 month) 

before long-term archiving. 

Considering the high data volumes generated by the mission, bulk reprocessing campaigns 

will require large additional hardware resources. To this end, two alternative reprocessing 

strategies will be proposed according to the volume of data to be reprocessed, whilst possibly 

followed in parallel: 

○ Reprocessing of the data accumulated over typically 6 months on PDGS nominal 

resources provisioning for a minimum reprocessing capability scalable with hardware; 

○ Bulk reprocessing via a specific service procured on-demand at the long-term 

archives. Those upgrades will be budgeted separately on a case-by-case basis 

according to the need. 








page 149 of 350 

The PDGS initial sizing will embed minimum reprocessing capability operating at a production 

rate of typically 2 days per every full day of accumulated Level-0 data to be regenerated at 

Level-1C from a single spacecraft. This capability will presuppose that the data to be 

reprocessed is collocated to the reprocessing hardware which will be ensured separately as 

relevant via the standard PDGS internal data-circulation mechanisms. 

Data reprocessing capabilities will be commanded and performed automatically in orbit 

trunks. The sequence of orbits to be processed will be selected by the centre operator after 

which the reprocessing chain will operate automatically as for nominal processing on all 

selected orbits. The automatic scheduling will allow the natural orbit sequence to be reversed 

allowing for reprocessing most recent data in priority. 

During reprocessing, the new PDIs generated will be stored and circulated through the 

nominal path shared with the nominal processing. Unambiguous discrimination of the 

reprocessing flow from the nominal one will be ensured through the use of a specific identifier 

embedded in all PDIs and managed down the path in all downstream functions. 

4.5.4.8.2 Reprocessing after Nominal Processing Contingency 

To ensure the reliability of the nominal processing flow, reprocessing operations will be 

provisioned for in every PDGS centre (including CGS) with the capability to recover from 

contingencies of the Level-1 productions. The reprocessing capabilities will be sized to allow 

for the recovery of typically one day of nominal processing within about one week of 

sustained reprocessing. The commanding and execution of contingency reprocessing 

operations will be identical to the ones described in the previous paragraph. 

4.5.4.9 Data Archiving and Circulation Operations 

The data archiving and internal data circulation operations aim at comprehensively answering 

to the global accessibility to the Sentinel-2 datasets featuring: 

○ Global product accessibility at the user-bases with optimised access for regional to 

continental usage; 

○ The reliability of the products availability ensured by redundancy; 

○ The long-term availability of the products responding to the LTDP objectives outlined in 

section 4.5.1.6. 

To this end, the archiving strategy will map the characteristics defined for product accessibility 

baselined in section 4.4.6 under the timeliness constraints outlined in section 4.4.5. 

Archiving and data circulation are hence tightly coupled to this objective and will follow the 

product data handling coordinated strategy defined in section 4.5.2.1. 

The overall data-archiving and circulation operations within the PDGS will be coordinated 

towards the global data-access objective. Coupled with the archiving operations, the 

circulation processes will operate mechanically dictated by the data-circulation rules 

configured in each centre archive, cascading gradually the PDI data from the source to the 

destination in a totally data-driven manner. 









page 150 of 350 

Operator driven inter-archive circulation will be possible to recover from contingencies or to 

execute specific cross-archive circulation operations (e.g. as required for reprocessing 

activities). 

In complement, the above operations will provision for the operational data supply towards 

potential collaborative entities operating a PDGS compatible data-access mirror centre (cf. 

sections 4.2.6 and 4.8). 

4.5.4.9.1 Data Archiving Operations 

In the distributed PDGS context, data archiving will make use of two type of facilities: 

○ Medium-term archives, designed for high performance accessibility to the distributed 

dataset in short time after processing on-ground. These archives will be located either 

at the ground-stations or in dedicated centres to provide on-line accessibility over a 

mission time period covering typically one year of Sentinel-2 constellation data in a 

rolling buffer. 

○ Long-term archives, designed for long-term accessibility of the global dataset and 

reliability through full redundancy. 

The scattered medium-term archives will comprehensively provide: 

○ Access to RT, NRT and all daily nominally acquired and processed data-products at 

the ground-stations. Ground-station archives will be sized to hold about one month of 

recent data products from the constellation in a rolling buffer. 

○ Access to data-products aged by up to one year after satellite sensing. 

All systematic product collections (S2MSI0, S2MSI1A, S2MSI1B, S2MSI1C) will be 

retrievable from these archives with on-line access latencies as baselined in section 4.4.6. 

The long-term archives will comprehensively provide full redundant access to the global 

S2HKTM, S2MSI0, S2MSI1B and S2MSI1C datasets with off-line access latencies. The 

S2MSI1A collection will not be archived in the long-term. 

4.5.4.9.2 Data Circulation Operations 

PDGS data-circulation operations will be used to supply in a data-driven manner the mediumterm 

and long-term archives from the source archives distributed in the CGS network. The 

data-driven circulation rules will operate systematically on the PDIs and dictate their 

systematic routing across centres according to the following granularity attributes available at 

any product-level: 

○ Spacecraft unit; 

○ Product type; 

○ Timeliness (RT, NRT or else); 

○ Geo-location at product granule level; 

○ Cloud-cover at product granule level; 

○ Summary quality indicators set at product granule level or group of granules; 

○ Specific MSI acquisition mode flags used for Cal/Val activities (cf. 4.5.4.10.2); 








page 151 of 350 

Three types of physical data transportation means will be supported for internal datacirculation 

providing for trade-off: 

○ Ground network, considering that ground-lines supporting a throughput of up to about 

100Mbps will be available at reasonable operation costs in the 2013 timeframe. 

○ Satellite multicast via the EDRS data-repatriation transponders, considering the 

availability of the shared EDRS data-repatriation capability with 220Mbps throughput 

for a third of the total time (cf. [Assumption-13]); 

○ Media such as LTO tapes or USB devices (e.g. removable hard disks); 

Circulation via physical media is currently accounted for as a trade-off solution to 

ensure cost-effectiveness of the global circulation required as not requiring stringent 

timeliness whilst potentially providing for higher effective throughput at lower operation 

costs. To guarantee operational effectiveness of this process, media loading, release 

and labelling operations will be mechanical and the physical flow of media will be 

controlled modelling an automated transportation network. 

4.5.4.10 Cal/Val Operations 

Cal/Val corresponds to the process of updating and validating on-board and on-ground 

configuration parameters to ensure that the product data quality requirements are met. 

To meet the baseline product quality requirements later defined in section 4.4.4, a welldefined 

Calibration and Validation (Cal/Val) plan will be systematically applied. This section 

presents an outline of the Cal/Val plan that will be implemented during Phase E2 of each 

spacecraft. During Phase-E1, a dedicated Cal/Val plan will be specified as part of the 

Commissioning-Plan. 

The following paragraphs define each of the Cal/Val operations specific to Level-1 and Level- 

2 data. Level-1 Cal/Val operations are divided between Radiometry and Geometry 

operations. 

Each one is described with a short outline of the method and details whether it will be carried 

out automatically by PDGS computer systems, through an operational service offered by an 

expert Cal/Val team, or by a hybrid semi-automatic combination. 

4.5.4.10.1 MSI Decontamination 

The purpose of the decontamination operation is to get rid of the molecular contaminant on 

the MSI SWIR focal plane. The MSI decontamination operation consists in heating the SWIR 

focal plane from the nominal operating temperature (around 200 K) to the decontamination 

temperature (around 300 K). 

The typical expected duration of the decontamination operation is approximately 48 hours (cf. 

[RD-43]); the periodicity is once every six months. During the decontamination operation, the 

MSI nominal operations are interrupted. 

The programming of the MSI decontamination will be commanded by a Flight Control 

Procedure starting with the Instrument from STANDBY, CSM being commanded to open 

position and applying decontamination heater power for a time period as needed, typically 48 

hours (cf. [AD-03]). 







page 152 of 350 

Therefore the activation of the MSI decontamination will not be requested directly by the 

PDGS but the FOS (managed via a Flight Control Procedure). Such operation causes a 

disruption of the nominal MSI operations that will be handled as a specific MSI unavailability, 

accordingly planned by the FOS and notified to the PDGS to constrain the planning of the 

MSI observation/calibration activities. 

Nevertheless, the PDGS will monitor the performance of the SWIR detectors to identify the 

need of such decontamination operations, and when required, coordinate together with the 

FOS the best time for the activation (i.e. it involves a disruption of the nominal MSI operations 

of 2 days [TBC]). 

4.5.4.10.2 Level-1 Radiometry Cal/Val Operations 

Level-1 radiometric Cal/Val operations will require the use of the MSI in six different operation 

modes. Mode selection will be commanded when entering MSI image mode by activating of 

the appropriate IPS table (cf. 3.5.2.4 and [AD-03]) pre-loaded on board the MSI. 

Table 4-8 defines each mode, associated IPS settings and specific use for calibration. When 

entering the Absolute-Calibration mode, the CSM will be commanded in parallel and moved 

to its sun-diffuser position through an appropriate telecommand sequence. 

Data-driven calibration operations on-ground will be enabled through the use of a specific 

mode-identifier preset in the IPS table of each mode (the “SAD” parameter) which is traced 

back in the raw-data received on-ground and propagated to higher product levels. 

Other calibrations will make use of nominal mode acquisitions (e.g. desert sites, Greenland, 

etc) originating from the nominal data acquisition plan. 

Mode Specific IPS configuration Usage 

Nominal Nominal Calibration over specific targets either inside 

or outside of the background acquisition plan 

(e.g. Greenland, Dome-C) 

Dark-Signal 

Calibration 

Absolute 

Calibration 

Vicarious 

Calibration 

Raw 

Nominal with WICOM 

equalisation bypass 

Nominal with WICOM 

equalisation bypass 

Nominal (TBC) 

WICOM compression 

bypass and only 2 pairs of 

detectors selected (one pair 

on each MSI half-swath) 

Dark-signal calibration operations 

Acquisition of on-board sun-diffuser images for 

absolute calibration 

Vicarious calibration over specific targets 

Acquisitions with compression bypassed 

TDI Specific TDI settings Acquisitions with specific TDI settings 

Table 4-8 MSI Image Modes for Radiometric Calibration 

The following paragraphs outline the operations applicable to the radiometric Cal/Val. 








page 153 of 350 

4.5.4.10.2.1 Dark Signal Assessment 

The assessment of dark signal will be performed through acquisition of images over oceans 

during night time. This will allow determining the radiometric calibration parameters for 

removing the offset due to dark current. 

This operation will be automatic and data-driven based on the reception of the Dark-Signal 

Calibration data which will be commanded every 3 repeat cycles (30 days). 

Such acquisitions will be optimised such as to cover areas without lucent plankton (e.g. 

Pacific Ocean close to Chile) and to avoid full moon conditions. Based on the selected 

calibration sites, the repeat-cycle orbit will be selected such as to minimise the impact on the 

on-board memory evolution. 

Figure 4-29 shows the coverage extracted from [RD-19] of typical image acquisitions 

optimised for this purpose by simulation during summer and winter. 

The result of both seasonal simulations overlap substantially such that it will be possible to 

select a common site providing equal conditions for the continuity of this calibration process in 

the long-term. 








page 154 of 350 

(a) Summer Simulation 

(b) Winter Simulation 

Figure 4-29 Suitable calibration orbits for Dark-Signal Calibration in winter 

4.5.4.10.2.2 Detector Relative Sensitivities Determination 

Detector relative sensitivities will be determined through the use of: 








page 155 of 350 

○ On-board sun diffuser images acquired by the instrument to determine radiometric 

equalization parameters for inter-pixel calibration (on-board and on-ground). 

This operation will be data-driven on reception of Absolute Calibration data with CSM 

in sun-diffuser position that will be commanded every 3 repeat cycles (30 days). 

On-board equalization parameters (NUC table) with associated on-ground processing 

parameters (GIPP) will be derived and the NUC parameters will be checked against 

their current values automatically. In case of minor changes, the NUC will not be 

updated and the calibration will only be performed on the on-ground processors 

through the activation of a newly generated GIPP. Otherwise a coordinated update of 

the NUC (on-board) and the GIPP (on-ground) will be triggered after validation by an 

expert Cal/Val team. In this case, the Level-0/1A/1B and 1C of the calibration dataset 

will be provided to the expert Cal/Val team to perform the validation of the precomputed 

coefficients.. 

Calibration using the on-board sun-diffuser will be performed at specific orbits of the 

repeat cycle such that (1) the angle between the +x-axis of the MSI and the spacecraft- 

Sun direction is minimum and (2) the impact on the nominal acquisition plan, if any, is 

minimised while taking into account the required 10 minutes waiting-times with no 

possibility of nominal acquisition due to the MSI shutter movement. 

As per the simulations presented in [RD-19], those conditions can be optimised at one 

specific orbit distinct between summer and winter repeat-cycles. Sun-calibration 

operations will hence be pre-defined and commanded once every 3 repeat-cycles in a 

deterministic manner. 

○ Images acquired over ground uniform areas (e.g. Greenland, Dome-C). 

In principle this calibration operation will be triggered only during Phase-E1 for onboard 

diffuser validation, and on contingency during Phase E2. It will not be automated 

and be carried out when required by an expert Cal/Val team after appropriate 

commanding of specific image acquisitions in Nominal mode. 

4.5.4.10.2.3 Determination of Absolute Radiometric Calibration Parameters 

Absolute radiometric calibration parameters will be determined through the following 

operations: 

o Calibration using on-board sun diffuser images. 

This operation will be data-driven on reception of Absolute Calibration data that will be 

performed on a 30-days basis reusing the pre-defined planning outlined for the 

detector relative sensitivities determination (cf. previous section). 

Although generated automatically, updated calibration parameters will be validated and 

accepted by an expert Cal/Val team prior to triggering their feedback in the PDGS 

processing chains. 

o Vicarious calibration and validation based on image acquisitions over specific areas 

such as snow sites (e.g. Dome-C in Antarctica), instrumented Cal/Val sites from the 

CEOS network (e.g. La Crau), or desert sites for cross calibration with other sensors 

and monitoring of temporal stability. 








page 156 of 350 

Such calibration operations will be performed by an expert Cal/Val team 2 or 3 times 

per year with a processing of all data acquired over typically 1 month. 

For all vicarious calibration, image-acquisitions will be deterministic and pre-defined on 

a yearly basis. Figure 4-30 shows typical acquisitions over the Dome-C sites which can 

be commanded during austral summer over one 10-days repeat cycle. 

o Inter-band calibration through the processing of sun-glint measurements. During 

Phase E2, this will only be done to consolidate and monitor the calibration performed 

during Phase E1. This activity will be performed on a yearly basis by an expert Cal/Val 

team. 

o Refocusing of the instrument using mirror temperatures. During Phase E2, this 

calibration would only be performed in case of contingency and performed by an 

expert Cal/Val team. Given the criticality of the calibration, a robust approval procedure 

will be established including POM approval. 

o Crosstalk characterisation and correction. Sentinel-2 is designed in order not to require 

any crosstalk correction. In case one would be required, ground processing will 

account for it and the determination of the associated parameters will be performed by 

an expert Cal/Val team. 

Figure 4-30 Suitable calibration orbits over Dome-C within winter repeat-cycles 

4.5.4.10.3 Level-1 Geometry Cal/Val Operations 

During Phase-E2, geometric calibration will mainly consist on the update of the Global 

Reference Image (GRI) used by to meet multi-temporal registration requirements. Calibration 

will be complemented with a set of activities to be only triggered in case of contingency, and a 

validation plan to check that user requirements are being met. 








page 157 of 350 

4.5.4.10.3.1 Generation of the Global Reference Image 

A Global Reference Image will be generated to enable the extraction of Ground Control 

Points (GCP) used for the systematic refinement of the geometric model at the term of the 

Level-1B processing such as to meet multi-temporal registration requirements outlined in 

section 4.4.4.1. 

To this end, a global database of cloud-free mono-spectral Level-1B images (B4 band) 

corresponding to each orbit of the repeat cycle (143 orbits) will be generated as part of 

nominal operations starting at the commissioning phase of Sentinel-2A and fed to a specific 

calibration system. 

The global reference images will be gradually built through an appropriate selection of orbits 

followed by an accurate geometric refinement performed on the basis of spatio-triangulation 

using Sentinel-2 data and an auxiliary database of third-party images with geometric patterns 

and for which the geometry is mastered. 

This auxiliary database is currently TBD and is likely to compile geometrically calibrated 

images available from other missions such as SPOT. 

The Global Reference Image will be generated nominally once at the beginning of the 

Sentinel-2A mission and will be validated and accepted by a Cal/Val team. 

The Global Reference Image will be gradually fed-back into the PDGS processing chains as 

regular GIPP components. 

4.5.4.10.3.2 Contingency Calibrations 

Geometric Cal/Val of the system will be complemented through the following contingency 

operations: 

o Correction between reference frames (steered/camera). This calibration will be 

performed during Phase-E2 only in case of contingency by an expert Cal/Val team. 

o Correction between detectors reference frames. This calibration will be done only 

during Phase E1 and on contingency during Phase-E2 by an expert Cal/Val team. 

4.5.4.10.3.3 Validation 

Geometric performances validation will be performed on a yearly basis by an expert Cal/Val 

team, including: 

o Geolocation accuracy assessment using reference sites with geometric patterns and 

for which geometry is mastered. 

o Multi-temporal registration assessment using image correlation techniques. 

o Multi-spectral registration assessment using correlation between images of different 

bands. 

4.5.4.10.4 Level-2 Cal/Val Operations 

For Level-2 data, Cal/Val operations are divided between cloud-screening and atmospheric - 

correction components. 








page 158 of 350 

4.5.4.10.4.1 Cloud Screening 

For Cloud Screening, algorithms will be calibrated (i.e. threshold and parameters will be 

defined) based on an empirical approach using an imagery dataset composed by a calibration 

sub-set (for defining the algorithm parameters) and a validation sub-set (for algorithm and 

products validation purposes). 

Calibration and Validation will be performed based on the visual inspection of images and for 

a set of test sites based on ground observation of atmosphere status (eventually also 

supported by instrumental measurements of variables such as aerosol optical thickness). 

4.5.4.10.4.2 Atmospheric Correction 

For Atmospheric Correction, the calibration of the algorithms and the validation of the 

obtained products (bottom-of-atmosphere reflectance, aerosol optical thickness and water 

vapour content) will be performed using a set of test sites representative of main surfaceatmosphere 

types. 

For a quantitative validation, these sites will include the LANDNET sites which are a set of 

Land Equipped Sites (LES) endorsed by CEOS as standard reference sites for the calibration 

of space-based optical imaging sensors. In addition, ad-hoc validation campaigns will be 

organized involving airborne, balloon and ground measurements. 

4.5.5 X-BAND HKTM MISSION OPERATIONS 

As outlined in section 4.3.7.3, HKTM data is required by the FOS for spacecraft health 

monitoring with an update frequency of no less than once per orbit. 

To this end, the PDGS will perform the following operations: 

○ Through the mission-planning and scheduling loop (cf. 4.5.3.1.1), the MMFU HKTM 

data-store will be systematically commanded for playback at every spacecraft 

revolution coinciding with a downlink opportunity at a CGS, making sure that all HKTM 

data buffered on-board since the last playback operation is downlinked and then freed 

to start a new recording cycle. 

○ On reception and as part of its systematic data-driven operations outlined in paragraph 

4.5.6 the PDGS will package the data and forward it to the FOS no later than one hour 

following downlink; 

For sake of optimising this process, the PDGS generated mission-plan will concentrate as 

much as possible all HKTM downlinks to a limited number of CGSs, in particular to the ones 

pre-allocated for NRT processing at the station, such that HKTM delivery to the FOS is 

performed in a reliable and deterministic manner at every orbit. 

Although this is likely to result into a systematic scenario with one-orbit frequency and using 

polar stations, the final HKTM mission scenario will be settled once the operational CGS 

network has been selected. 








page 159 of 350 

4.5.6 PDGS END-TO-END OPERATIONS 

On a daily basis, the PDGS will schedule the CGS network for data-reception according to 

the mission plan preliminarily settled with the FOS (cf. 4.5.3.1). Then, as driven by the 

downlink plan (cf. 4.5.4.2), the PDGS will operate systematically via configurable rules 

commanding all elaboration steps cascading from data-reception, including: 

○ Antenna acquisition, signal demodulation, front-end processing, Level-0 processing 

and archiving (cf. sections 4.5.4.3.2 for MSI data and 4.5.5 for HKTM data); 

○ Systematic processing of all MSI acquired raw-data to higher levels (cf. sections 

4.5.4.3.2 and 4.5.4.6); 

○ Systematic essential quality-control over the MSI acquired and processed data (cf. 

section 4.5.4.7); 

○ Systematic inventory and archiving of all data with well-defined retention (cf. section 

4.5.4.9.1); 

○ Systematic and data-driven internal data circulation among the distributed stations and 

centres according to a coordinated and well-defined configuration (cf. section 

4.5.4.9.2) 

○ Systematic data distribution towards external interfaces (cf. sections 4.5.2 for MSI 

products and 4.5.5 for HKTM) 

This overall process will be carried out in a FIFO manner as driven by the downlink scenario 

defined in section 4.5.4.2. 

The generation of the Level-2A prototype product will be triggered interactively by authorised 

users via the hosted processing functionality (cf. 4.5.4.6). 

As driven either by the Cal/Val agenda or recurrently following a predefined agenda, the 

PDGS will perform the following operations in the background: 

○ Systematic Cal/Val activities (cf. section 4.5.4.10) with retrofit on the instrument and 

ground-processing chains configurations (cf. section 4.5.3.3); 

○ Systematic Quality Control over the globally processed data and on the overall mission 

performance (cf. section 4.5.3.2) in the short to longer term. 

Contingency operations will be triggered on malfunctions in the nominal data flow covering: 

○ Recovery of malfunctions in the Level-0 processing chain (cf. section 4.5.4.3.2), 

○ Recovery of higher-level productions (cf. section 4.5.4.8.2), 

○ Recovery of problems throughout the data archiving and circulation network (cf. 

section 4.5.4.9). 

Reprocessing operations will be performed as driven by the required evolutions of the 

Sentinel-2 Level-1 and Level-2 datasets in the long term (cf. section 4.5.4.8.1). 

All above operations are described in more details in Chapter-6 according to the functional 

breakdown provided in Chapter-5. 





4.6 System Maintenance and Evolution Concepts 




page 160 of 350 

The Sentinel-2 PDGS will assume a single overall configuration serving both Sentinel-2A and 

Sentinel-2B units. As such, the PDGS will be designed and qualified (since its first deployed 

configuration before Sentinel-2A launch) for operations in the dual spacecraft context, at least 

on a functional point of view. 

Nevertheless, the time separating the two launches together with the requirements on the 

PDGS to insure specific tasks during the commissioning-phase of the spacecrafts will impose 

that while the PDGS is fully operational for Sentinel-2A, it shall accommodate the gradual 

phase-in of the activities required to serve the second unit (e.g. PDGS sizing, non-regression 

testing, OSV, commissioning activities, etc). 

It is further anticipated that although the two units are theoretically identical [Assumption-01], 

slight changes might have to be accommodated before-hand on the PDGS to prepare for the 

assimilation of Sentinel-2B in addition to the hardware sizing increase required to cope with 

the dual data-flow. 

Hence, the PDGS operations concept shall include a specific operation scenario provisioning 

for the accommodation of additional constellation spacecrafts while in operations. 

As regarding the foreseen evolution of the Sentinel-2 mission with EDRS (cf. section 3.6) 

which will possibly happen subsequently to Sentinel-2A launch, similar provision shall be 

made in the PDGS operations concepts to allow for accommodating the new interfaces in 

operation. 

More generally, the PDGS shall account for the necessary evolutions of its system-level 

configuration throughout its lifetime in hardware and software as required by its operational 

maintenance activity. 

This section settles the operation baseline in this respect. Following introductory paragraphs, 

a common approach applicable to the PDGS operational transfer is specified. Then, 

specialised scenarios targeting the operational phase-in of new spacecraft units and EDRS 

are described. 

4.6.1 REFERENCE-PLATFORM 

The operational maintenance activity of a system with distributed complexity such as the 

PDGS will not efficiently be carried out directly on the target platform. As it will commonly be 

installed with a dedicated environment tailored for its operational scope (e.g. without space 

dedicated to IV&V activities and associated teams), and considering its geographical 

distribution in various sites, problem troubleshooting and resolution would be doubtlessly 

unproductive. 

Hence, for self-supporting its system maintenance and evolution activities, the PDGS will 

include a specific Reference-Platform (RP) function. The Reference-Platform will aim at 

simulating 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. There will be a unique 

Reference-Platform that will be equipped and manned specifically in order to: 

○ Support the IV&V Phases of the PDGS; 








page 161 of 350 

○ 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. 

As holding a true functional role including during the entire PDGS operational phase, the 

PDGS RP is intended as a specific functional item of the PDGS with a dedicated associated 

operations concept. 

4.6.2 SYSTEM STATES AND CONFIGURATIONS 

Throughout its lifetime, the PDGS will evolve between several configurations and states as 

required by its development and maintenance activities and by the gradual phase-in of the 

Sentinel-2 constellation spacecrafts it will serve. 

As regarding the successive phase-in of the Sentinel-2 units with their respective mission 

phases, and while it is assumed that a single and unique PDGS system will be shared to 

serve the constellation, a distinction has to be made between the PDGS instance and the 

specific state in which it is operating. 

The instance of the PDGS refers to its specific existence as an integrated system. As such, 

there will be a single physically deployed PDGS instance. In complement, a localised (in a 

single location) reference instance of the PDGS called the Reference-Platform (RP) will be 

used for testing, simulation and long-term maintenance purposes (cf. previous section). 

In counterpart, the state of the PDGS refers to its capability in serving a specific spacecraft 

mission. Hence, it is assumed that a single PDGS instance can operate in 2 distinct states 

simultaneously, one per Sentinel-2 unit. E.g. the PDGS may operate operationally for 

Sentinel-2A at the time Sentinel-2B is launched for which it operates in pre-operational state 

until the end of its commissioning phase. 

Finally the configuration of the PDGS applies to a particular PDGS instance and is configured 

to operate on one or both missions each one in their respective states. 

The following paragraphs describe those concepts in more details. 

4.6.2.1 System States 

As driven by the successive phases of the Sentinel-2A and Sentinel-2B missions described in 

section 1.3 leading to a fully operational system supporting the Sentinel-2 constellation, as 

well as beyond this point, the following states of the PDGS are identified: 

○ Development state: In this state, the PDGS is being built and pre-assembled as a 

system on the RP for testing purposes. It is assumed it embeds at this point some but 

not necessarily all of its intended functionality and as such may support only partial 

services limited to testing activities in a reduced configuration e.g. external interfaces 

compatibility testing, etc; 








page 162 of 350 

○ Reference-qualified state: In this state, the PDGS is built and qualified on the RP. Most 

of its external interfaces are simulated or at-least re-localised e.g. for the Sentinel-2A 

pre-launch period, the satellite data is simulated for testing purposes. Once referencequalified, 

the PDGS is considered ready for being physically deployed; 

○ Preliminary-state: In this state, the PDGS is being deployed and integrated in its 

operational physical layout i.e. the PDGS is assembled in possibly various distributed 

centres hosting the PDGS sub-systems and connected together in their intended 

operational form. It is manned so as to support IV&V activities. 

○ Qualified state: In this state, all PDGS intended functionality and services can be 

demonstrated however using simulated external interfaces. It is manned and operated 

so as to support OSV activities within the overall ground-segment. 

○ Validated state: In this state, the PDGS is validated vis-à-vis its external interfaces as 

much as they can be actual interfaces (e.g. the satellite data was simulated for testing 

purposes). The PDGS was qualified through the OSV activity as ready to support preoperations. 

It is manned for operational readiness and its configuration is frozen at 

ORR; 

○ Pre-Operational state: In this state assumed at satellite launch, the PDGS is manned 

as required by mission Phase-E1. Some interfaces, in particular the PDGS interfaces 

vis-à-vis the data exploitation entities (GSCDA, GSPs, etc) remain simulated for 

validation purposes, i.e. without involving the actual end-users; 

○ Operational state: In this state, the PDGS is qualified for nominal operations within the 

GSC. All services and interfaces are operated nominally according to operational 

procedures and manned accordingly. This state extends beyond spacecraft end-of-life 

to continue serving past accumulated data. 

4.6.2.2 System Configurations 

The PDGS will assume several configurations along time. The configuration of the PDGS 

includes the hardware and software (e.g. software version of the functional sub-systems 

installed), system configuration elements (e.g. configuration files) as well as infrastructure 

sub-systems such as network links. 

Two specific configurations of the PDGS will co-exist: 

○ The Deployed-configuration, corresponding to the actual configuration of the PDGS in 

its deployed physical layout; 

○ The Reference-configuration, aiming at reproducing as precisely as possible the 

behaviour of the Deployed-configuration on the RP instance system for system 

corrective maintenance purposes; 

In addition, one or several Development-configuration may be maintained temporarily as 

being “working” or “beta” version of the PDGS and candidate for being finalised or qualified. 

Finally, several Deprecated-configurations will be maintained for historical reference, as 

corresponding to previously Deployed or Reference configurations that have then been 

superseded by new ones. 





4.6.3 OPERATIONAL TRANSFER BASELINE APPROACH 




page 163 of 350 

As introduced earlier, the PDGS Reference-Platform will be a key functional element of the 

PDGS enabling the swift transitions of PDGS configurations in operations. 

Following PDGS maintenance or evolution activities at system or sub-system level, a 

common baseline approach will apply to the operational transfer of all new PDGS system 

configurations as follows: 

1. The upgraded (or new) sub-system(s) are assembled on the RP environment and 

tested at sub-system level as relevant depending on the maintenance or evolution 

performed; 

2. On success, system-level IV&V tests are performed on the RP pre-configured as a 

system-level representation of the target PDGS environment surrounding the subsystem(s) 

e.g. the RP would be configured as a ground-station to validate a new 

version of the front-end-processor interface; 

3. On success, the upgraded (or new) reference-qualified sub-system(s) are deployed on 

the true PDGS (after scheduling minimum downtimes as necessary, ideally none) with 

their upgraded (or new) operation instructions as appropriate, so creating a new 

preliminary-configuration baseline. 

4. The preliminary configuration behaviour is monitored in operations. If critical problems 

occur after upgrade, the previous operational-configuration baseline is swiftly 

redeployed, the problems are investigated on the RP through more thorough tests 

aiming at reproducing the operational behaviour, and maintenance actions are 

triggered accordingly. 

5. On success, the newly deployed preliminary-configuration becomes the operational 

baseline deprecating the current one, and associating the new reference-qualified 

configuration as mirror on the RP. 

4.6.4 SENTINEL UNITS PHASE-IN APPROACH 

Building upon the general principles settled in the previous paragraphs, Table 4-9 below 

outlines the scenario applicable to the phase-in of the spacecraft units in the PDGS operation 

life-cycle. 








page 164 of 350 

Activity or 

Milestone 


development 

Reference 

Configuration 

Deployed 

Configuration 

State S2A State S2B State S2A State S2B 

Remarks 

Development N/A PDGS is integrated on RP 

PDGS is deployed and 

PDGS IV&V 

Preliminary 

verified in its definite physical 

layout 

PDGS is pre-qualified for 

PDGS QR 

operating on the constellation 

Qualified 

Sentinel-2 Ground-Segment is 

OSV 

integrated and validated for 

pre-operations 

GS-AR validated Qualified OSV excludes SVTs for S2B 

ORR 

S2A launch 

S2A Phase-E1 

S2A IOCR & 

PDGS AR 

Delta-S2B IV&V 

dry-runs 

completed 

S2B HW 

deployment & 

delta-S2B IV&V 

Delta-S2B PDGS- 

QR 

Delta-S2B OSV 

Delta-S2B GS-AR 

Delta-S2B ORR 

S2B launch 

S2B Phase-E1 

S2B IOCR 

reference-qualified 

S2B specific deltadevelopment 

referencequalified 

development 

reference-qualified 

preoperational 

N/A 

Ground-segment configuration 

is frozen until S2A launch. 

From now on, PDGS state for 

S2B is assumed by not 

formally qualified. 

S2A commissioning is 

performed while PDGS is 

validated for full operation 

Mission enters Phase-E2 with 

S2A 

Specific S2B updates are 

integrated on RP. RP still 

maintains reference-qualified 

configuration deployed in 

operations 

S2B updates are referencequalified 

on RP 

operational preliminary 

PDGS hardware is upgraded 

to support S2B while PDGS is 

in full operations for S2A 

PDGS is qualified for 

Qualified 

operating on the constellation 

OSV non-regression and S2B 

specific SVTs are performed 

Sentinel-2 ground-segment is 

validated 

validated for pre-operations 

ground-segment configuration 

preoperational 

is frozen until S2B launch 

S2B commissioning is 

performed 

Sentinel-2 Mission enters full 

Operational 

routine phase 

Table 4-9 Sentinel-2 Spacecraft Units Phase-In Scenario within the PDGS 

It shows in particular: 

○ A RP configuration accurately following the deployed PDGS configuration 

systematically reference-qualified for the constellation; 

○ A pre-launch version of the PDGS already (pre-)qualified for the constellation following 

initial PDGS IV&V activities; 








page 165 of 350 

○ A PDGS deployed configuration with a hybrid state starting at the time the PDGS 

infrastructure is upgraded from a single mission sizing to its final sizing required to 

support the constellation. From this event onwards, the PDGS assumes nominal 

operations for Sentinel-2A while tests are carried out in parallel to prepare for 

readiness of Sentinel-2B operational phase-in; 

○ A PDGS configuration reaching the validation state for the Sentinel-2A/B constellation 

only after the completion of OSVs applicable to Sentinel-2B; 

○ A PDGS configuration with full functionality vis-à-vis the GSC for the Sentinel-2A/B 

constellation after successful Sentinel-2B commissioning. 

The hybrid-state PDGS configuration immediately following its full-size reconfiguration to 

support Sentinel-2B preparatory activities will be the critical step of this scenario. It will 

impose: 

○ A careful configuration of all Data-Access elements of the PDGS so that user access is 

not spoilt by the testing activity performed on the Sentinel-2B specific dataflow. 

○ A careful configuration of the PDGS mission-planning elements, in particular vis-à-vis 

the FOS, so that the mission planning function continues operating nominally for 

Sentinel-2A independently from Sentinel-2B test planning; 

○ A thorough pre-configuration and validation on the RP of new infrastructure elements 

shared between Sentinel-2A and Sentinel-2B before deployment in operations; 

○ Specific functional, interface and reliability requirements at system and sub-system 

level as appropriate to ensure conflict-free Sentinel-2A and Sentinel-2B mission 

dataflows within the PDGS; 

○ Well-defined operational procedures dedicated to this phase-in scenario, validated and 

rehearsed initially as part of the pre-Sentinel-2A launch PDGS IV&V activity. 

4.6.5 EDRS PHASE-IN 

The launch of the EDRS piggyback payload is currently planned in the 2013 timeframe, 

hence in the same timeframe as the Sentinel-2A launch and start of operations. At this stage, 

it is however not foreseen to commission Sentinel-2A together with EDRS within the short 

time allocated for commissioning. Hence, unless EDRS is launched and commissioned wellbefore 

Sentinel-2, the approach described here foresees as general case an EDRS 

operational phase-in while Sentinel-2A is already in operations. 

The phase-in of EDRS imposes at term a drastic change to the mission operation scenario 

due to the reshaping of the CGS network required from the strict X-Band scenario. It is hence 

expected that a commissioning period of Sentinel-2 with EDRS will be required in parallel to 

the Sentinel-2A operational service before this change is effectively carried out. 

This paragraph describes the resulting two-step phase-in approach. 

4.6.5.1 Commissioning of EDRS Capabilities with Sentinel-2 

As described in 3.7.2, the Sentinel-2 PDGS foresees the use of EDRS capabilities at three 

levels, being the data-relay, data repatriation and data-dissemination. As the latter is 








page 166 of 350 

considered an enhancement to the PDGS data dissemination capabilities, it can be 

commissioned separately without any impact on on-going operations. The data-relay and 

repatriation links will however require dedicated validation before operational transfer. 

As the reshaping of the PDGS to support the EDRS scenario will require specific investments 

for the deployment of new facilities or the upgrade of existing ones, it is assumed that EDRS 

capabilities will be preliminarily validated as part of EDRS commissioning activities without 

requiring such investment as pre-requisite. It is hence expected that for all three services, the 

EDRS program will put in place a validation framework. The PDGS RP and specific front-end 

processing hardware will however be used in complement to this framework to support 

Sentinel-2 specific validation activities. 

The overall approach will thus result in a two-phase validation: 

○ At first, the EDRS service will commissioned making use of the EDRS validation 

framework and the RP; 

○ Once pre-qualified on this framework, the required PDGS deployment activities will 

follow and a second validation activity will be performed. The validation of this last 

step will trigger the operation transfer activities described in 4.6.5.2. 

As part of its nominal operations, the reference platform will pre-qualify all specific hardware 

required to support the EDRS scenario before deployment to the PDGS centres. 

The following paragraphs describe this approach as applied to the three distinct EDRS 

services. Although described separately they will be carried out in parallel. 

4.6.5.1.1 Data-Relay Link 

The EDRS data-relay capability can be commissioned with Sentinel-2 at the same time and 

without any impact on operations. This will be achieved via the parallel downlink of the 

mission data routed through the XBS and OCP at selected orbits. 

In a preliminary step, to be carried out during the commissioning phase of the EDRS 

piggyback payload, the data-relay link with Sentinel-2 will be validated using the EDRS 

provided validation framework. For this, a PDGS provided front-end reception equipment will 

be installed in this framework and used to validate the data-reception compatibility. In turn the 

received data will be shipped to the reference platform and tested for compatibility against the 

Level-0 and higher level processors. 

In a second validation step, to be carried out at one PDGS ground facility intended to 

ultimately receive EDRS relayed data, the ground-reception compatibility will be 

commissioned and further processing will be carried out, possibly delayed after the 

operational processing (e.g. during idle periods) if this ground-facility happens to be reusing 

an X-Band facility. 

4.6.5.1.2 Data-Repatriation Link 

It is assumed the EDRS data-repatriation link will be commissioned in a preliminary step on 

the EDRS validation framework without any involvement of the Sentinel-2 PDGS. 

Following the PDGS required hardware deployments, such as the transmission and multicast 

reception equipment, the data-repatriation capabilities will be validated in parallel to nominal 









page 167 of 350 

operations by means of data-product circulation operations from the transmit stations to the 

receiving ones. It is assumed this can be carried out directly using the front-end datacirculation 

capabilities of the operational PDGS with an appropriate configuration to avoid any 

impact on nominal data-circulation operations by other means. 

4.6.5.1.3 Data-Dissemination Link 

The validation of the Data-dissemination service for Sentinel-2 will be carried out similarly to 

the data-repatriation case. Following the PDGS required hardware deployments, such as the 

transmission equipment to the dissemination transponder for data-broadcasting, the datadissemination 

capabilities will be validated in parallel to nominal operations by means of databroadcast 

operations from the transmit stations to one or several test receiving stations. It is 

assumed this can be carried out directly using the capabilities of the operational PDGS with 

an appropriate configuration to avoid any impact on nominal operations. 

4.6.5.2 Operational Transfer 

Once commissioned through the activities described above, the PDGS will be already 

deployed and sized to support the change of mission scenario. This presupposes that all the 

necessary additional hardware was pre-qualified on the RP before deployment. 

Depending on the requirements of this scenario, the operation transfer activity will be either 

gradually phased with separate phase-in activities of the data-relay and data-repatriation 

services or performed all at once. The data-dissemination service can be phased-in totally 

independently to the other ones. 

Regarding the required PDGS software upgrades, the baseline operational transfer approach 

described in section 4.6.3 will globally apply, involving preliminary reference-qualification on 

the RP before operational transfer as part of normal work. 

Finally the operational switch to the new mission scenario will be performed by applying the 

nominal mission configuration control procedures defined for the PDGS and outlined in 

section 4.5.3.3, ensuring the accurate coordination of the PDGS configuration and the 

mission-planning configuration applicable to the new operation scenario. 

4.7 Network and Security Concepts 

4.7.1 SECURITY 

The Sentinel-2 PDGS handles, processes, stores and exchanges information of sensitive 

nature, including: 

○ information related to Sentinel-2 users and organisation (with profile and authentication 

details) 

○ information regarding specific requests from the GMES Security Core Service that 

might be subject to restriction (e.g. users identity) 

The Sentinel 2 Security Concept is currently based on: 

○ policies and regulations that are part to the internal ESA/EO security frameworks, 




○ Sentinel 2 data policy 




page 168 of 350 

○ EU directives on privacy (Regulation EC No 45/2001) and EU Directive on data 

retention [COM(2005)_438 final)] 

○ Common best practice standards and guidelines such as ISO 27001 and CiS 

benchmarks 3 . 

In addition, Sentinel-2 products shall be protected by the Terms & Conditions signed with the 

end users during registration. 

According to this, the security needs (in terms of confidentiality, integrity and availability) for 

each information category will be identified and proper access control means and access 

rights will be implemented in order to preserve these needs. 

In particular end users authentication and authorization functions to request and access to the 

Sentinel-2 products will be delegated to the CDS for GSPs and to the MMUS for other Users 

(see sections 4.10.1.1, 4.10.1.2). 

No need for a formal security classification, as defined in the EU Council regulations 

(2001/264/EC), the EU commission decision (2001/844/EC,) and the ESA Security 

regulations, has been defined up to now, and no such requirements have been expressed up 

to now by the EU Commission (TBC). 

No need for clearance has been identified up to now, either. 

4.7.2 NETWORK INFRASTRUCTURE 

The PDGS network infrastructure will provide connectivity services to the Sentinel-2 PDGS 

centres and users and will support the following communications: 

○ Payload Data Ground Segment network connectivity; 

○ Electronic circulation of satellite data, mainly from the satellite acquisition stations to 

the specialized processing and archiving centres; 

○ Transfer of planning and M&C data between the PDGS centres; 

○ Electronic circulation of auxiliary data, mainly from the external providers to the 

centres; 

○ Data exchanges with the FOS; 

○ User access to the products catalogues for consulting and ordering; 

○ Sentinel-2 data dissemination to scientific and commercial users; 

○ Operators access to PDGS systems for operation and maintenance; 

○ Data communications internal to the different centres and facilities; 

The PDGS network will offer functions and services inspired from ESA’s principles and 

requirements described in [RD-20], [RD-21], and [RD-22]. 

3 CiS: Centre for Internet Security, www.cisecurity.com 








page 169 of 350 

The infrastructure aims for maximised scalability, flexibility and capacity to be upgraded and 

modelled to: 

○ Meet and adapt to the evolving data circulation and dissemination requirements of the 

PDGS; 

○ Satisfy the timeliness constraints of the NRT services; 

○ Serve all the intended Sentinel-2 users according to the Mission requirements 

specifications. 

The network infrastructure will additionally provide a set of auxiliary Information and 

Communication Technology (ICT) network services aimed to ensure the necessary 

connectivity and security services, such as Email, NTP, Proxy and DNS services. 

4.8 Collaborative PDGS Concepts 

As introduced in section 4.3.2.4, the Sentinel-2 core PDGS will offer specific collaboration 

opportunities aiming, in a harmonised approach, at enhancing the capabilities and scope of 

the global GSC through third-party contributions, i.e. beyond the sole scope of the core GSC. 

This section describes the two baseline practical collaborative services identified for the 

Sentinel-2 PDGS in responding to this global objective. 

Whilst the opportunity to feed Sentinel-2 data to nationally or privately managed Local Ground 

Stations exists and can be considered as a collaborative opening, it falls beyond the strict 

scope of the Sentinel-2 PDGS apart from the operations of an LGS commanding interface to 

enable the data reception activity directly from the Sentinel-2 spacecrafts. 

In counterpart, the Sentinel-2 PDGS will formalise the GSC collaborative concept through the 

offering of additional opportunities in two main collaboration areas: 

○ Enhancement of Sentinel-2 data-access performance, data availability and reliability: 

This opportunity involves separate collaborative centres operated outside of the GSC 

framework but fed with Sentinel-2 data products though the core PDGS whilst hosting 

PDGS software enabling local mirroring and distribution of the data; 

○ Support to the development of new GSC products and their transfer to operation for 

operational sustainability: 

This opportunity involves separate collaborative entities, possibly scientific institutes or 

the GMES service providers themselves, which collaborate by hosting their privately 

developed data-processing software in the PDGS core (or collaborative) centres 

enabling the sustained generation of additional products. It is motivated to a large 

extent by the recent experience gained at ESA in this domain (cf. section 4.3.5.4). 

The following sections describe the above opportunities. 

Access and management of those two opportunities will be formalised as actual PDGS 

services as described in section 4.10.2 and covered further down as detailed operation 

concepts enabling the collaborations. 








page 170 of 350 

4.8.1.1 Collaborative Data-Access Mirroring Centres 

This opportunity aims at contributing to enhancing the global Sentinel-2 data-access 

availability, reliability and performance by locally mirroring the data from third-party operated 

premises in counterpart of a privileged access to Sentinel-2 data products. 

This collaborative opportunity is motivated by the demonstrated successes of digital media 

sharing opportunities offered throughout the internet, further complemented by the trends 

advertised by internet carriers in optimising the effective bandwidth by replication and 

localisation of the data close to its consumers. 

From the PDGS system point of view, collaborative data-mirroring centres will be seen as an 

extension of the PDGS operationally supplied with Sentinel-2 products and contributing to the 

harmonised on-line publishing of the data they hold locally by implementing the PDGS dataaccess 

protocols. 

From the collaborative centre point of view, the core PDGS will act as primary data supplier 

granting privileged access to large quantities of Sentinel-2 data products reusing the PDGS 

standard cross-archives data-circulation mechanisms (cf. section 4.5.4.9). In addition, the 

core PDGS will provide operational data-management software to be hosted and operated 

locally for receiving, housekeeping and relaying the data internally to legacy systems as well 

as externally to GSC users. 

A dedicated PDGS service will be defined and operated to enable this type of collaboration 

(cf. section 4.10.2.1). 

4.8.1.2 Hosted Processing Collaboration Opportunity 

The Sentinel-2 PDGS will provide a dedicated service to data users enabling their data 

processors to be hosted and run in the PDGS processing environment. This collaborative 

opportunity fosters the development of additional products to complement the base product 

list provided through the core PDGS services. It is motivated to a large extent by the recent 

experience at ESA in this domain (cf. section 4.3.5.4) and as such aims for a significant reuse 

of the established concepts applicable to the G-POD CAT-1 opportunity (cf. [RD-36] and [RD- 

37]). 

The goal of this service is to foster the use of Sentinel-2 data and the development of new 

derived operational products by enabling the remote access and processing of PDGS core 

products according to user-provided algorithm implementations. 

This service ultimately aims at enhancing the PDGS offerings vis-à-vis the GSPs indirectly or 

directly: 

○ Indirectly through collaborations with scientific research partners whereby new and 

complementary Sentinel-2 value-added products (e.g. Level-2) can be test-bedded, 

validated on large datasets, and finally swiftly transferred to sustainable operations for 

global usage. 

This collaborative approach avoiding bulk product transportation commonly required 

for algorithm development aims at solving data-access bottlenecks while making new 

processors ready for swift operational deployment when required; 








page 171 of 350 

○ Directly through collaborations with the GSP entities themselves whereby their 

proprietary value-added processors can be hosted in the PDGS and remotely operated 

either on-demand or systematically on the incoming Sentinel-2 data-flow. 

Since it is expected that most information products likely to be developed by GSPs 

from Sentinel-2 data will be substantially reduced in size compared to the base 

products (e.g. land classification maps, flood extents, etc), this approach will contribute 

to solving data-access issues (and associated large-bandwidth network demands) by 

transporting the user processors close to the data source instead of the opposite. 

The hosted-processing collaboration opportunity will include options targeting specific usage 

and mode of operation: 

○ A first option to provide on-demand triggering capability of the user-provided 

processors on the available data. Triggering will be managed and performed by the 

users themselves after an initial step required for processor integration in the PDGS. 

○ A second option targeting the automated triggering of the user-processors on the 

incoming data flow for the autonomous generation of value-added products. The valueadded 

products will be generated automatically on the available input flow and put at 

disposal for download. 

In both scenarios, the generated products may benefit each peer collaborative entity alone, or 

a wider community as agreed in the collaborations. 

The first on-demand processing option is targeting either: 

○ The development of value-added applications requiring interactivity or applicable only 

under certain circumstances (e.g. a crisis event), whilst needing large volumes of data 

in input summarised by processing into a lightweight comprehensive product. 

○ The interactive test-bedding and validation of new algorithms as a preliminary step 

towards a potential sustained processing under the second scenario. 

The second automated production scenario is enabling the generation of bulk datasets with 

the objective of either: 

○ Avoiding massive data distribution to the users by performing production on their 

behalf provided the valued-added products have a substantially reduced volume 

compared to the one of the source data (e.g. data mining, land classification, etc); 

○ Offering research partners with the possibility to mature and validate new processing 

algorithms by applying them on large datasets possibly spanning several years and 

corresponding to various measurement conditions; 

○ Gradually enhancing the portfolio of GSC available datasets with new and mature 

value-added products under a collaborative IPR scheme. 

The service model enabling the collaborations will follow a shared workflow with a welldefined 

role-split between the PDGS operators and the collaborative partners inherited from 

the one in-place for G-POD CAT-1 opportunity implementations as recalled on Figure 4-31. 








page 172 of 350 

Figure 4-31 Schematic of the EO G-POD CAT-1 Collaborative Workflow 

A dedicated PDGS service will be defined and operated to enable this type of collaboration 

(cf. section 4.10.2.2). 








page 173 of 350 

4.9 PDGS Operation Layouts 

This section describes potential configurations of the distributed PDGS to support end-to-end 

operations. The initial layout that will be put in place for the launch of Sentinel-2A will be 

settled at a later stage, building upon the layout principles presented hereafter. 

All operational configurations are made of an assembly of core PDGS operational entities 

including: 

Core Ground Stations (CGSs) with X-Band LEO tracking and/or EDRS Ka-Band GEO 

pointing capabilities responsible for acquiring the data from the Sentinel-2 satellites, 

feeding the PDGS processing chains collocated at the station and distributing the data 

on-line. 

In principle, all data processing operations cascading from every acquisition will be 

performed directly at the ground stations ensuring on-line data product distribution 

directly from the station archives shortly after acquisition. Flexibility of the PDGS 

distributed design will however allow for data acquisitions to be performed at remote X- 

Band ground stations responsible for generating the Level-0 data and relaying it to 

processing/archiving centres centralised in Europe; 

Processing/Archiving Centres (PACs) in charge of either or a combination of the 

following operations: 

o Processing and distributing the data acquired at and relayed from remote 

ground stations; 

o Archiving the mission products in the mid term (typically one year) with on-line 

distribution capabilities; 

o Data reprocessing operations of contained scope; 

o Hosted processing operations in support to third-party collaborations; 

o Long-term archiving and preservation of all mission products with full 

redundancy and off-line distribution capabilities. In addition, those centres will 

take charge of bulk reprocessing operations over the global dataset. 

An entity in charge of all QC, Cal/Val, and POD operations, interfacing the expert 

Cal/Val team (possibly collocated) as required. It will also be in charge of the validation 

of the instrument processors on behalf of the Reference Platform operators. 

An entity in charge of PDGS system-level coordination, configuration and general 

control of the mission embedding all interfaces with the FOS. 

A Reference Platform in charge of PDGS system maintenance, evolutions and transfer 

to operation (cf. 4.6.1). 

With the exception of the X-Band ground stations which will be bound to specific geographical 

locations, other entities (such as EDRS Ka-Band stations or processing/archiving entities) 

may be collocated or distributed around Europe. As far as data archiving and distribution is 

concerned, the advantages of a scattered physical layout with several distributed archives will 

be considered. In particular, the full mission archive redundancy will be achieved by means of 

a minimum of two geographically distributed entities. 








page 174 of 350 

Beyond the scope of the core PDGS, other third-party entities will potentially add-up to the 

PDGS extended layout, namely: 

Local Ground Stations entitled to receive Sentinel-2 data in real-time via X-Band (or 

Ka-Band when relayed from EDRS); 

Collaborative data-access mirroring centres (cf. 4.8.1.1) acting as core PDGS archives 

locally mirroring the PDGS data from their premises. 

The following paragraphs provide an insight over specialised core PDGS configurations 

starting from an X-Band station based layout to configurations with EDRS in operations. 

4.9.1 BASELINE OPERATION LAYOUT 

The PDGS baseline operation layout is based on a CGS network of at least four X-Band 

stations. 

It assumes that at least two CGSs are situated in polar areas hence allowing receiving at 

least half of the mission data. The other half will be received by complementary X-Band 

stations located at lower latitude ranges. It further accounts for one CGS with limited 

connectivity resources to the mainstream European communication network, hence 

potentially creating a bottleneck for data access. 

All CGSs but one will be entitled to receive NRT data. A CGS centred over Europe will bring 

the additional benefit of bringing a RT access capability over most European land areas (cf. 

section 4.3.10.2) as well as contemporaneous direct-downlink capabilities over European 

LGSs (cf. section 4.5.4.3). 

To optimally respond to the data-access requirements, two additional and complementary 

PACs will be operated in Europe to mirror the data received from the CGS network and 

optimise data-access performance: 

○ One will be dedicated to: 

o Processing the data repatriated from the remaining CGS up to Level-1C; 

o Mirroring the archive of all cloud-free data processed at Level-1C (S2MSI1C) for 

the last 12 months after sensing; 

o Providing reprocessing capabilities from an on-line Level-0 archive of 3 months. 

○ A second one will be dedicated to providing medium term storage of the S2MS1C 

coverage of Europe for one year. 

Each PAC will additionally hold a collocated LTA service providing LTDP services in full 

redundancy over the mission lifetime. 

The three main CGSs and the two PACs will all participate to the federated data-access 

network. 

This PDGS operation layout is depicted below: 








page 175 of 350 

S2A/B 

X-Band 

X-Band 

LGS 


X-Band 

CGS 


X-Band 

CGS 

X-Band 

LGS 


X-Band 

CGS 

Short-Term 

Circulation 

Data 

Circulation 


Data-Access 

Network 


X-Band 

CGS 


PAC 


PAC 

Figure 4-32 Baseline Mission Operation Layout 

4.9.2 ENHANCED OPERATION LAYOUT WITH EDRS 

This ambitious mission operation configuration will take benefit of all EDRS service 

components (Data-Relay, Data-Repatriation and Data-Dissemination services) with 

associated capacities allocated for Sentinel-2 as described in section 3.7.2. 

It will be based on the assumption of a CGS network composed of: 








page 176 of 350 

○ Polar X-Band stations (typically one or two) able as a whole to receive the data from 

Sentinel-2 spacecrafts once per orbit. They will additionally be equipped to retransmit 

the data in near-real-time through EDRS 220Mbps data-repatriation transponders; 

○ A network of a TBD number of Ka/Ku-Band stations spread throughout Europe in the 

EDRS reception footprints of both the data-relay and the data-repatriation 

transponders. Those stations will be able to receive the complementary Sentinel-2 

downlinks via the OCP and EDRS as well as the data repatriated by multicast in Ku- 

Band from polar stations. 

Taking benefit from the compound usage described above, the repatriation capability will be 

used to multicast in near-real-time the raw-data acquired at polar-stations throughout Europe 

which will amount to half of the overall mission data. Coupled with the data-relay downlinks 

securing the other half in multicast directly from the spacecrafts, this operation configuration 

will lead to a fully flexible ground network bringing the huge Sentinel-2 data volumes nearly 

anywhere in Europe for local processing and distribution close to the users. 

The repatriated data volume from polar-stations, amounting in average to 8 minutes of 

payload data from each spacecraft, can be multicast within about 18 minutes on the EDRS 

220Mbps bandwidth repatriation path. Considering two Sentinel-2 units in orbit, usage of the 

link will be limited to 36 minutes in average per every 100 minutes which is about a third of 

the assumed time-shared capacity allocated to Sentinel-2. 

This scenario is hence deemed achievable while providing NRT access to the global Sentinel- 

2 data anywhere in Europe, provided the repatriation path is available to the Sentinel-2 

mission at the right time. Beyond the noteworthy benefits that such scenario would bring in 

terms of flexibility, reliability and performance, it would also considerably reduce the needs for 

operating high-bandwidth point-to-point ground-lines to move the large volumes of Sentinel-2 

data throughout Europe. 

The global multicast data will be filtered in input to each centre (e.g. divided by geographical 

regions) while providing for the necessary redundancy between centres to ensure global 

reliability. Each centre will autonomously bring the raw data to higher-levels by local 

processing and distribute it into a federated data-access network. 

End-users will mostly rely on the ground network infrastructure, possibly enhanced to their 

needs, to access the data from the local centres via the federated network. In complement, 

the 

data-broadcast capability will be used to reach locations that are poorly served otherwise. 

This operation configuration is depicted below: 








page 177 of 350 

S2A/B 

LCT 

Data-Relay 

Transponder 

X-Band 

Data-Repatriation 

Transponder 

EDRS 

Ka-Band 

relay 

multicast 


X-Band 

CGS 


X-Band 

CGS 

Ku-Band 

repatriation 

multicast 

X-Band 

LGS 

EDRS 

LGS 

EDRS 

LGS 

X-Band 

LGS 


EDRS CGS 


EDRS CGS 


Data-Access 

Network 

Long-Term 

Circulation 


EDRS CGS 


EDRS CGS 

EDRS 

LGS 

EDRS Dissemination 

Transponder 

Dissemination 

broadcast 


PAC 


PAC 

Figure 4-33 Enhanced PDGS Operation Layout with EDRS 





4.9.3 ALTERNATIVE OPERATION LAYOUTS WITH EDRS 




page 178 of 350 

Additional possible mission operation configurations are outlined here should EDRS not 

provide high-bandwidth repatriation services or should they not be finally sized sufficiently to 

support the baseline requirements. 

Figure 4-34 Alternative PDGS Operation Layout with EDRS 








page 179 of 350 

It is inheriting the principles of the EDRS enhanced layout while using ground-networks (or 

media shipment as trade-off) to repatriate the data acquired at polar stations to a mediumterm 

centre. According to the actual X-Band CGS set-up, RT and NRT acquisitions will be 

routed in priority via the OCP to EDRS enabled CGSs to take benefit of the wide multicast 

coverage provided through EDRS. This will ensure that the two EDRS Ka-Band stations can 

share the RT and NRT processing or provide for redundancy by simple configuration. 

4.10 PDGS Services Portfolio 

The portfolio of PDGS services aims at stating all high-level services the Sentinel-2 PDGS 

system will offer vis-à-vis its external interfaces during operations starting at Phase-E1, using 

the PDGS system capabilities defined in [RD-01]. 

The service requirements cascade from the PDGS specific function within the overall 

Sentinel-2 system and, to a higher level, within the GSC to be guaranteed starting at Phase- 

E1 and sustained in the long term throughout Phase-E2. 

This chapter describes all services offered by the PDGS highlighting for each one, the scope 

and characteristics, the invocation mechanism and the relevant PDGS interface applicable to 

it.. 

4.10.1 SERVICES TO PDGS STAKEHOLDERS 

This section describes all PDGS services dedicated to supplying Sentinel-2 data to the 

identified data consumers, namely: 

○ End-users, including GSPs, for the supply of Sentinel-2 data products through the 

MMUS; 

○ GSPs for the supply of Sentinel-2 products via the CDS through the CDS/DAIL I/F; 

○ Local Ground Stations through the LGS commanding interface enabling the native 

Sentinel-2 X-Band space-to-ground real-time data reception to any authorized LGS; 

○ The FOS for the supply of HKTM data received at the PDGS; 

○ The general public for the on-line publishing of Sentinel-2 true-colour images. 

4.10.1.1 Sentinel-2 User Services 

As introduced in section 4.5.2.2.1, the Sentinel-2 PDGS will offer a homogenous data access 

to supply Sentinel-2 generated products to all authorised users via ESA’s MMUS. 

Besides product access provided through a multi-mission interface, this service embeds all 

necessary user-support functions such as the publishing of relevant documentation and the 

management of a Support-Desk. 

4.10.1.1.1 Service Users 

Service users are all registered end-users entitled to access Sentinel-2 products via the 

MMUS interface. 








page 180 of 350 

Service access will also be granted to specific user-groups responsible for CAL/VAL or 

product quality-control activities. In particular, the CNES will belong to this category during 

phase-E1 of the spacecrafts. 

4.10.1.1.2 Service Characteristics 

The MMUS Data-Access service includes three components for product discovery, supply, 

and subscribed automated download. 

This service will interface the authorised users via the MMUS web-portal allowing to: 

○ Browse and query the Sentinel-2 catalogue of available products; 

○ Retrieve the Sentinel-2 products available for download; 

○ Automate the downloads based on user-defined subscriptions.; 

○ Get on-request support via a Support-Desk. 

4.10.1.1.2.1 MSI Product Discovery and Data-Set Definition 

The MMUS Data-Access service will allow discovery of MSI data products available for 

download and meeting specific criteria. 

In complement to sensing-time based criteria, the discovery criteria will support filtering based 

on the spacecraft unit, the product-type, the geographical-coverage (e.g. continental/local 

scale bounding box), the cloud-cover, and any other criteria on metadata supported for user 

queries. 

Access to products within the product list will be driven by user-access rights. In particular: 

○ QIs defined for each product-type will allow filtering out degraded quality products visà-vis 

general users whilst making them available to expert users for investigation; 

○ Sentinel-2B products will be hidden by configuration to general users during the 

commissioning phase of Sentinel-2B while the Sentinel-2A collections are nominally 

serviced. 

○ More generally, access grants will be managed independently per spacecraft and 

product-type and include additional filtering granularity as defined in section 4.10.3.1 

Data Access Control Service. 

The table below summarises per product-type the minimum set of criteria supported. 





Product- 

Type 

Identifier 

S2MSI0 

S2MSI1A 

S2MSI1B 

Geographical 

coverage 

Granule intersection 

with user-area 

S2MSI1C Granule (Tile) 

intersection with userarea 

Cloud-cover 

Rough cloud-cover 

threshold (%) at granule 

level or cumulated over the 

user-area per orbit 

Could-cover threshold (%) 

at granule (tile) level or 

cumulated over the userarea 

per orbit 

Cloud-cover criteria 

discriminating thin-cirrus 

from thick-cloud cover 




page 181 of 350 

Additional criteria 

Spacecraft unit, QIs, acquisition 

station, etc 

Spacecraft unit, QIs , other TBD 

metadata 

Spacecraft unit, QIs , other TBD 

metadata 

Table 4-10 Sentinel-2 user-defined criteria for product selection 

4.10.1.1.2.2 MSI Product Supply 

The MMUS Data-Access service will supply MSI products (in the form of User-Products as 

defined in section 4.4.2) that will be assembled on-the-fly at download time according to userdefined 

parameters. 

Reusing the query capabilities defined in the previous paragraph, the supplied products will 

be constructed following product-templates defining the user-preferences in terms of product 

contents and format from available options. 

The product-template will allow further customisation of the product components to include 

into the final products. The selection of product components across product levels will also be 

possible such that lower-level product components can be integrated into the upper-level 

product structure when required. User-preferences will additionally drive the product 

packaging format such as SAFE or DIMAP. 

By default, the sole granules selected through the reduction filter will be compiled in the 

product. Alternatively, a specific user-option will enforce that, provided at least one product 

granule meets the criteria, the reconstructed product is either of: the full orbit stripline, the full 

MSI swath, or the full MSI swath intersecting the user-area. 

4.10.1.1.2.3 Download Automation and User-Defined Data-Set Subscriptions 

As introduced in section 4.4.3, the Data-Access service will provide functionality to automate 

the retrieval of the MMUS defined Data-Sets at the user site based on the User-Product 

construction mechanisms. Practically, Data-Set subscriptions will correspond to the 

autonomous streamed download of User-Products following user-preferences as outlined in 

the previous sections as soon as new products meeting the reduction criteria are made 

available in the PDGS. 








page 182 of 350 

4.10.1.1.2.4 Support-Desk 

As described in section 4.5.2.4 a first line Support-Desk will respond to general userenquiries. 

A second-line Support Desk, triggered through the first-line Support Desk, will 

provide expertise support. 

4.10.1.1.3 Service Dependencies and Constraints 

The MMUS Service access will require preliminary user registration vis-à-vis the POM, cf. 

section 4.10.3.1 for the applicable registration service. 

The timeliness, supply latency and quality of the MSI products accessible through this service 

directly cascades from the high-level baseline outlined in section 4.4. 

4.10.1.1.4 Triggering Mechanism and Interface 

The service is triggered by the end-users through the MMUS client for the product discovery 

and product download meanwhile the “download manager” triggers the automatic product 

download based on subscriptions (cf. [RD-44]). 

The support Desk will be provided through an operator interface (telephone and email). 

4.10.1.2 Interface Service to CDS/DAIL 

The Sentinel-2 PDGS will offer a dedicated electronic interface service towards the CDS/DAIL 

for discovery and download of Sentinel-2 products. This service aims at responding precisely 

to the SCE-01 applicable GSCDA scenario defined in [AD-02] whereby the Sentinel-2 

datasets identified in the GSC DAP are made available for download to authorized users 

directly through an external interface of the PDGS. 

This interface service aims at implementing the Catalogue service interface [RD-14]/[RD-15] 

and the On-Line Access service interface [RD-16] of CDS/DAIL as required by the 

GSCDA/CDS [RD-02]. 

This service is implemented by through ESA’s MMUS complemented by the Sentinel-2 

specific DAG interface for the effective product downloads. 


The service user is the GSCDA/CDS and more particularly its DAIL component. The final 

users of the Data Access service through the CDS/DAIL are the GSP entities registered 

through the GSCDA. 


The CDS/DAIL Interface service will answer autonomously to DAIL requests by translating 

the Catalogue (resp. On-Line Access) requests into equivalent Sentinel-2 catalogue query 

(resp. product download) requests. 








page 183 of 350 


As cascading from MMUS generic services, the DAIL interface service inherits the 

dependencies and constraints defined in section 4.10.1.1.3. 


The service will be triggered via the ngEO MMUS component and comply with the applicable 

DAIL interfaces, namely the HMA Catalogue service interface [RD-14]/[RD-15] and the HMA 

On-Line Access service interface [RD-16]. 

4.10.1.3 Coverage Interface Service to CDS/SCI 

The Sentinel-2 PDGS will autonomously publish the coverage of all acquired images to the 

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

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


The service user is the GSCDA/CDS and more particularly its SCI component. 


This service will autonomously and systematically push all Sentinel-2 acquired image 

coverage metadata to the applicable SCI interface according to [RD-13]. 


The timeliness of the coverage reports published through this service directly cascades from 

the availability of Level-1C data from the PDGS processing chains, itself driven by the highlevel 

mission operation concepts stated in the HLOP. 


Service operation will be autonomous. Sentinel-2 coverage reports will be systematically 

placed on the SCI interface according to [RD-13]. 

4.10.1.4 Performance Reporting Service to CDS/CQC 

The Sentinel-2 PDGS will autonomously publish CDS Service Performance Reports (CDS- 

SPR) to the GSCDA/CDS on the Sentinel-2 generated production and the quality of service 

provided to the GSPs. 

The Service Performance Reports will include: 

 

 

Product quality reports of all acquired/generated images to the CDS/CQC necessary to 

support the correct data exploitation by the GSPs; 

Mission performance reports to determine the quality of service provided to the GSPs; 








page 184 of 350 

Up to date references to the Sentinel-2 MSI performance and characteristics definition 

and the products specification; 


The service user is the GSCDA/CDS and more particularly its CQC component. 


This service will autonomously and systematically push all the CDS-SPRs to the CQC 

interface according to [RD-38]. 


No specific dependency or constraint is identified. 


Service operation will be autonomous. CDS-SPRs will be systematically generated according 

to CDS/CQC interface defined in [RD-38]. 

4.10.1.5 Sentinel-2 X-Band Real Time Data Access Service 

As introduced in section 4.2.7, this service aims at enabling the data reception at Local 

Ground Stations (LGS) of X-Band data downlinked in real-time from the Sentinel-2 

spacecrafts. 


Service users are national or foreign X-Band ground-station operators having agreed 

Sentinel-2 real-time access with the MMA. 


The service enables Sentinel-2 X-Band data reception at LGS through the automated supply 

at the stations defined interfaces of planning information relevant to the real-time acquisition 

opportunities. Planning information will be provided separately to each authorised LGS 

provided its configured station mask intersects with the real-time opportunity. 

Reception Planning information will typically contain accurate orbit data of the spacecrafts 

together with begin and end times of the planned downlinks of each of the data partitions 

(MSI and Ancillary data). It will be provided at the station interfaces shortly before acquisition 

(typically 12 hours). 

As a preliminary step to this service, the PDGS will maintain and make available to each LGS 

the decompression software required for processing the Sentinel-2 raw-data with associated 

user documentation. 








page 185 of 350 


As pre-requisite, the LGS Service user shall be registered vis-à-vis the MMA as an LGS for 

Sentinel-2. All authorized LGS will be reported in the HLOP with their configuration and 

agreed service parameters. 


The service operation will be autonomous and will systematically deliver LGS data reception 

plans at a well-defined and documented interface dedicated to each authorised LGS. 

4.10.1.6 Sentinel-2 True Colour Images On-Line Publishing Service 

As introduced in section 4.5.2.2.3, this service provides public anonymous access to the 

collection of Sentinel-2 TCIs through a dedicated web-portal. 


Service users will be general public individuals sitting in Europe or elsewhere with 

connectivity to the internet. 


Service characteristics will be as outlined in section 4.5.2.2.3. 


The timeliness of new imagery updates accessible through this service directly cascades from 

the high-level mission data recovery strategy on ground as settled in the HLOP (cf. 4.5.1.5). 


The image publishing service will be operated by the end-users through a web-portal 

remotely accessing the imagery publishing servers according to user actions. 

4.10.1.7 Housekeeping Data Distribution Service to FOS 

This service is dedicated to the Sentinel-2 FOS for the timely supply of Sentinel-2 

housekeeping data products (S2HKTM) immediately after data reception from the 

spacecrafts. 


The Sentinel-2 FOS is the only identified user of this service. 


This service is entirely autonomous and will result from the X-Band HKTM operation scenario 

described in section 4.5.5. Once per orbit and immediately following data reception at the 








page 186 of 350 

CGS from Sentinel-2A or Sentinel-2B, one S2HKTM product containing the spacecraft HKTM 

data acquired on board since the last downlink will be systematically generated at the CGS 

and published on the FOS interface server. 

New data will be available on the FOS server within one-hour after acquisition. 


No dependencies or constraints are identified. 


Service operation will be autonomous. The generated S2HKTM products will be 

systematically placed on the FOS interface server according to a well-defined ICD. 

4.10.2 SENTINEL-2 COLLABORATIVE PDGS SERVICES 

As introduced in sections 4.2.6 and 4.8, the Sentinel-2 PDGS will offer specific collaboration 

opportunities aiming, in a harmonised approach, at enhancing the capabilities and scope of 

the global GSC through third-party contributions, i.e. beyond the sole scope of the core GSC. 

This section describes the two baseline practical collaborative services identified for the 

Sentinel-2 PDGS in responding to this global objective. 

4.10.2.1 Collaborative Data Mirroring Centre Integration Service 

This service aims at supporting the deployment of collaborative centres which, in counterpart 

of a privileged access to Sentinel-2 data products, contribute to enhancing the global 

Sentinel-2 data-access availability, reliability and performance by locally mirroring the data 

from their premises. The following paragraphs describe the specific PDGS service enabling 

this collaboration. 


Service potential users range from scientific institutions to industrial bodies including GSPs. 

Access to this service will cascade from collaboration agreements preliminarily set-up with the 

POM. 


The service vis-à-vis the peer collaborative entities is characterised by the combination of: 

○ Technical support activities regarding the setting up and operations of a PDGS 

compatible mirror centre; 

○ Operational data supply activities. 

Technical support activities include: 

○ The provision and maintenance of PDGS standard data-management software to be 

installed and operated at the mirror centre for data-reception, housekeeping and 

internal/external distribution of products; 









page 187 of 350 

○ The provision and maintenance of documented guidelines covering centre installation 

and configuration (hardware and software installation/configuration manuals, software 

user manuals) 

○ The provision and maintenance of relevant operational procedures covering the centre 

operations vis-à-vis the PDGS provided software systems; 

○ Support to the centre set-up under the form of a help-desk activated during the initial 

phase of the collaboration. 

On completion of the centre set-up, the core PDGS will start supplying data operationally 

according to the terms of the collaboration agreement. Data supply will be performed either 

electronically or via media reusing the mechanisms developed for the core PDGS internal 

data-circulation. 


Eligibility to the service will be managed by the POM through the detailed definition of 

collaboration agreements applicable to this type of collaboration. 


The service will be globally managed through a dedicated Collaboration support PDGS 

function. Please refer to section 5.2.4.6 for an outline description of this function. 

Data-supply activities will be performed through a generic PDGS data-circulation function. 

Please refer to section 5.2.3.8 for an outline description of this function. 

4.10.2.2 Hosted Processing Service 

Based on to the concepts defined previously in section 4.8.1.2, the Sentinel-2 PDGS will 

provide a collaborative opportunity to data users enabling their data processors to be hosted 

and run in the PDGS processing environment. The following paragraphs describe the specific 

PDGS service enabling this collaboration 


This service targets the scientific research community or the GSP themselves. Access to this 

service will be managed through the POM via a well-defined collaboration agreement. 


The hosted-processing collaboration opportunity includes options targeting specific usage 

and mode of operation: 

○ A first option providing on-demand triggering capability of the user-provided processors 

on the available data by the users themselves; 

○ A second option targeting the automated triggering of the user-processors on the 

incoming data flow for the autonomous generation of value-added products. The valueadded 

products will be generated automatically on the available input flow and put at 

disposal for download. 







page 188 of 350 

Largely based on the G-POD CAT-1 experience heritage summarised in sections 4.3.5.4 and 

4.8.1.2, the following paragraphs describe the characteristics of the service in a stepwise 

approach as applicable to the service implementation of each option: 

○ The characteristics of the initial processor integration service, as a prerequisite for 

enabling the required hosted processing for both hosted-processing models; 

○ The characteristics of the on-demand processing scenario option, either to be 

sustained as final operation scenario or carried-out as a preliminary step towards the 

sustained processing scenario; 

○ The characteristics of the systematic hosted-processing scenario 

4.10.2.2.2.1 Processor Integration 

This service offering corresponds to the initial step of the collaboration enabling the third-party 

provided processor to be remotely operated within the PDGS environment. 

It provisions for: 

○ The publishing and maintenance of documented integration guidelines (similar to [RD- 

37]) with relevant technical documentation such as a well-defined Interface Control 

Document between the user-processor and the PDGS host environment; 

○ The provision of a remotely accessible test-bedding environment for user processors 

coupled with test-data for compatibility testing and integration preparatory activities; 

○ The effective integration and deployment of the user-processor into the PDGS 

environment according to the agreed processing model (on-demand, systematic). This 

includes the development of a user interface to be configured on the MMUS/ngEO web 

portal; 

○ Support to the definition and integration of user-processors under the form of a helpdesk 

activated throughout this phase of the collaboration; 

4.10.2.2.2.2 On-Demand Hosted-Processing Scenario 

Following processor integration activities, this operation scenario will be activated according 

to the agreed on-demand hosted-processing option or as a preliminary step to the systematic 

processing option. 

The user-provided processor will be available for remote-triggering on-demand from the userbase. 

For this, a user-interface to the processing will be provided allowing the authorised user 

to: 

○ Define the processing jobs input parameters such as input data products and 

processing parameters; 

○ Trigger the job processing and monitor its execution; 

○ Retrieve the generated output and execution log files; 

○ Define batch execution rules triggering the automated generation of products. 








page 189 of 350 

The ability to trigger the hosted-processors is dedicated and private to each collaborative 

peer. Optionally, the collaborative peer may extend the accessibility to its processor and grant 

access to other parties by configuration. 

4.10.2.2.2.3 Systematic Hosted-Processing Scenario 

Following successful validation activities performed under the on-demand processing 

scenario, this operation scenario may be agreed optionally. In this mode, the user-processor 

will be triggered automatically within the PDGS processing chain, generating the value-added 

products according to a well-defined configuration, and making them available for discovery 

and download through the Data-Access Service. 

This presupposes that: 

○ The hosted processor can be triggered autonomously through the definition of 

systematic processing rules and default processing parameters; 

○ The generated products can be inventoried and archived in the PDGS as any other 

core product. This constraint will impose the value-added products to comply with a 

well-defined standard model for product handling in the PDGS inherited from the core 

product model defined in [RD-07]. 

The on-line retention of the so generated value-added products will be configurable and 

typically span between a few weeks to several months. 

Whilst access to the value-added products will be dedicated and private to each collaborative 

peer, it may be extended to other parties by configuration. 

Service evolutions: 

A last level of collaboration is provisioned for to enable the sustained generation and 

publishing within the PDGS of third-party product collections as other GSC Sentinel-2 

products through the Data-Access service. 

Eligibility to this enhanced level of collaboration and associated management will be dealt 

with on a case-by-case basis by the POM. 

This enhanced collaboration presupposes that: 

○ The value-added dataset is complementary to existing ones, valuable for wide 

publishing via the GSC and was as such promoted for inclusion in the DAP. This 

imposes in particular that adequate licensing of the value-added products exists and 

comply fully to the Sentinel-2 data-policy in place; 

○ The value-added products generated are adequately and publicly documented in 

semantics and format for publishing to third-parties and have been pre-validated 

according to an agreed qualification criteria; 

○ The hosted processor is considered mature and operational and can operate 

autonomously in the PDGS with little required supervision overhead; 

○ Assurance is provided that the hosted-processor software and associated 

documentation will be maintained in the long-term by the peer collaboration entity; 








page 190 of 350 


Service dependencies are described here such as eligibility constraints and the management 

of Intellectual Property Rights (IPR) inherent to the collaborations. 

4.10.2.2.3.1 Eligibility 

Eligibility to the service will be managed by the POM through the detailed definition of 

collaboration agreements applicable to this type of collaboration. 

The following general constraints will drive eligibility to the hosted-processing service: 

○ The Sentinel-2 product set available as basis for higher-level processing through the 

hosted-processing service includes solely the S2MSI1C product-type; 

○ Additional auxiliary data required by the hosted-processor will have to be agreed upon 

as part of the collaboration set-up and be at minimum supported by an operational 

third-party electronic data provision service; 

○ The product classes supported as candidate value-added products to be generated 

through the hosted-processing service are Sentinel-2 only Level-2 and Level-3 classes 

of products. Level-3 products include mono-mission or multi-mission compound 

products aggregating the data of a single or several Sentinel-2 spacecrafts; 

○ The user-processors will have to be pre-existing, tested and portable to the supported 

PDGS computing platforms; 

○ For eligibility to the systematic hosted-processing service, the value-added product 

model will have to comply with a well-defined model inherited from the core product 

model defined in [RD-07] allowing a swift integration via the generic product handling 

mechanisms implemented by the PDGS. 

4.10.2.2.3.2 Intellectual Property Rights Management and Licensing 

The Intellectual Property Rights (IPR) over software and algorithms held by the collaboration 

peer entity will not be altered in any way by the collaborative opportunity. 

As far as the use of third-party software and algorithms is concerned, the peer entity will be 

fully responsible for requesting the necessary authorizations and/or licenses when 

appropriate. 

To sustain the operations of the systematic hosted-processing service as described under 

service evolutions, the peer collaboration entity will have to grant to the POM an adequate 

usage license allowing for a long-term exploitation of the hosted-processor within the PDGS. 

The licensing of the resulting collaborative products will in principle be managed by the 

collaborative entity and will be documented in the collaboration agreements. 


For the preliminary processor integration step, the service will be managed through a 

dedicated Collaboration support PDGS function. Please refer to section 5.2.4.6 for an outline 

description of this function. 








page 191 of 350 

Access to the subsequent service operation steps for the triggering of hosted-processors and 

access to the resulting products will be managed via the MMUS/ngEO enhanced data-access 

interface (cf. [RD-44]). 

4.10.3 SENTINEL-2 MISSION SUPPORT SERVICES 

Sentinel-2 Mission Support Services regroup all PDGS services vis-à-vis the POM in 

supporting the achievement of the PDGS requirements starting at Phase-E1 of the Sentinel- 

2A spacecraft. 

The PDGS services described in the following paragraphs aim at supporting the POM 

towards this global objective. 

4.10.3.1 Data Access Control Service 

This service will allow the POM to define, control and monitor all accesses to Sentinel-2 

products. This includes: 

○ The configuration of data-access profiles as defined in section 4.5.2.2.4; 

○ The registration of users and association to the data-access profiles to group of users; 

○ The statistical monitoring of all user data accesses including catalogue search 

requests, and product requested for download performed through the data supply 

services defined in section 4.10.1.1 and 4.10.1.2. Typical access statistics will be 

generated on a monthly basis per data type and will provide comprehensive statistics 

qualified by user base origin, sentinel-2 spacecraft, geographical zone (e.g. 

continents), data-age, retrieval latency, etc as appropriate and providing compound 

figures on the volumes downloaded.; 

○ The statistical monitoring of the True-Colour image publishing service exploitation. 

4.10.3.2 Mission Control Service 

This service aims at driving the main PDGS operations cascading from the HLOP. The HLOP 

will be superseded by the commissioning-plan during Phase-E1 of each spacecraft unit for all 

operations linked to that spacecraft. 

To this end, the Mission Control Service will cascade down all HLOP-driven requirements 

applicable to the PDGS, configure and operate the PDGS accordingly and provide feedback 

measures on its performance as well as global measures on the overall mission performance. 

Three complementary background services components are identified in supporting this goal: 

The Mission Configuration and Planning component effectively managing the HLOP 

implementation by deploying a coordinated mission configuration baseline throughout 

the space and ground segment systems including the PDGS, the FOS via the PDGS 

and the spacecrafts via the PDGS and the FOS; 

The PDGS HW/SW Maintenance and Configuration Control effectively managing the 

PDGS system configuration baseline at hardware and software level with its 

maintenance and evolutions along time; 









page 192 of 350 

The Mission Performance Assessment component providing in return the associated 

feedback measures on the PDGS and overall mission performance. 

The coupling of those three components aims at closing the mission control loop by providing 

feedback assessment of the impacts of configuration changes carried out following HLOP 

changes, or as required by lower-level operation plans (e.g. calibration updates, instrument 

processor updates, system maintenance activities, system upgrades, etc). 

The following paragraphs detail each of the above-mentioned components. 

4.10.3.2.1 Mission Configuration and Planning 

The operational mission configuration baseline will cascade in the large part from the HLOP 

complemented by lower-level operation plans in line with the HLOP and driving the internal 

functioning of the PDGS. 

Vis-à-vis the POM, the Mission Configuration and Planning service component will perform: 

○ The cascading of the HLOP into lower-level operation plans down to a well-defined 

operational mission configuration baseline applicable to the PDGS operations; 

○ The management of HLOP changes (e.g. change of acquisition scenario) leading to 

mission configuration baseline changes and their coordinated activation; 

○ The management of mission configuration baseline changes driven internally as 

required by the mission performance assessment activities or system evolutions; 

○ Based on the defined mission operation baseline, the recurrent coordinated planning of 

the mission operations under PDGS responsibility including the planning of the 

satellites observations and downlinks with corresponding PDGS ground-station 

reception activities. 

○ The collection and maintenance of all operations reports generated by the PDGS subsystems 

providing systematic traceability to the relevant mission configuration 

baselines they apply to; 

4.10.3.2.2 PDGS HW/SW Maintenance & Configuration Control 

The PDGS system hardware and software configuration will evolve in time as required by the 

system maintenance activity or as triggered by system evolutions. 

Vis-à-vis the POM, the PDGS Maintenance & Configuration Control service component will 

perform: 

○ 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 providing 

traceability to the system 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; 







page 193 of 350 

○ Systematic reporting to the POM upon the validation activities performed before 

operational transfer; 

○ On-request reporting to the POM upon the PDGS system configuration baseline 

evolutions over time, covering hardware items, software items and their configuration. 

4.10.3.2.3 Mission Performance Assessment 

This service component will provide the POM with comprehensive measures along time on 

the PDGS performance and globally on the mission performance, covering: 

○ The quality of the products delivered, the performance of the processing algorithms, 

and long-term trends in the product quality; 

○ The quality along time of the MSI and other critical on-board subsystems such as the 

GPS and AOCS systems; 

○ The overall end-to-end PDGS performance vis-à-vis its stakeholders and globally the 

mission performance with respect to the HLOP. 

4.10.3.2.4 Collaborative PDGS Management Support Service 

This service will allow the POM to trigger and monitor the activities related to the 

Collaborative PDGS based on the setting-up of the relevant collaboration agreements. 

Once authorised, the collaborative service operation will proceed directly vis-à-vis the 

collaboration peer as defined in section 4.10.2 Sentinel-2 Collaborative PDGS Services 

according to the type of collaboration and the agreed terms of the collaboration. 

Throughout the collaboration phases, dedicated reporting will be made as required to the 

POM on the status of the collaboration and main outcome (e.g. maturity of new products, 

data-distribution statistics from collaborative data-access mirroring centres, etc) with respect 

to the agreed terms of the collaboration. 

A dedicated Collaboration support PDGS function will carry out those tasks. (cf. 5.2.4.6). 

4.10.3.3 Data Factory Operations Service 

This service manages the recurrent operations of the PDGS at CGSs and PACs from data 

reception from the satellites down to the production of all its output products and operation 

reports according to the PDGS configuration. 

As driven by the downlink plan applicable to each CGS and the operational configuration 

settled via the Mission Control Service (cf. 4.10.3.2), the PDGS will operate systematically all 

elaboration steps cascading from data-reception, including: 

○ Antenna acquisition, signal demodulation, front-end processing, Level-0 processing 

and archiving according to the downlink plan; 

○ Systematic processing of all MSI acquired raw-data to higher levels according to the 

configured processing parameters; 

○ Systematic essential quality-control over the MSI acquired and processed data 

according to the configuration; 








page 194 of 350 

○ Systematic inventory and archiving of all data with the configured retention; 

○ Systematic and data-driven internal data circulation among the distributed CGSs and 

PACs according to the configuration; 

○ Systematic generation of operation reports at all elaboration steps for performance 

monitoring and assessment; 

○ Systematic distribution of the output data and reports towards external interfaces or 

local publishing through the data-access network. 

The generation of the Level-2A prototype product will be performed as triggered interactively 

by authorised users via the hosted processing functionality. 

Contingency operations will be triggered on malfunctions in the nominal data flow covering: 

○ Recovery of malfunctions in the Level-0 processing chain; 

○ Recovery of higher-level productions; 

○ Recovery of problems throughout the data archiving and circulation network. 

All malfunctions will be centrally reported to the Reference Platform for investigation. 

4.10.3.4 Long-Term Data Preservation Service 

This background service aims at globally responding to the long-term accessibility of Sentinel- 

2 data. It features in particular the parallel operation of redundant long-term archive centres 

via well-defined service level agreements ensuring the LTDP objectives described in section 

4.5.1.6. Bulk reprocessing operations will be performed as driven by the required evolutions 

of the Sentinel-2 Level-1 and Level-2 datasets in the long term. 





5 PDGS DESIGN 




page 195 of 350 

This chapter defines the internal design of the PDGS in answering to the operation baseline 

described in the previous chapter. It consists in a breakdown description of the system into 

building-block components with reduced perimeter which consistently extend as a whole to 

the PDGS system perimeter through inter-component interactions. 

After an outline description of the overall design logic, this chapter details the design of the 

PDGS from the functional and physical viewpoints. 

A last section describes the operation layout of the PDGS in each of its different operational 

configurations as corresponding to the three mission operation scenarios preliminarily 

introduced in section 4.9 - PDGS Operation Layouts. 

5.1 Overall Design Logic 

The system breakdown will be described at two levels: 

○ At functional level (cf. section 5.2), providing a logical split of the required PDGS 

functionality into functional blocks, each one regrouping a consistent set of low-level 

functions and operating interfaces with other functions. 

The breakdown components will be referred to as “Functions” related via “Functional 

Interfaces”; 

○ At physical level (cf. section 5.3), providing an actual split of the defined functionality 

into generic centres geographically distributed, each one having a well-defined 

operational role characterised by the logical grouping of the previously defined 

functional blocks (i.e. Functions), and interacting one with another via physical 

interfaces within the overall layout. 

The breakdown components will be referred to as “Centres” related via physical 

interfaces, exposing some of them externally to the PDGS and corresponding to the 

external interfaces defined in section 4.2.2. 

The comprehensive design will derive from this logical-to-physical aggregation of primary 

Functions into physical Centres, mapping the leading and complementary role of each centre 

by a simple collocation of primary Functions. The PDGS operation layout will be described 

(cf. section 5.4) according to the baseline operation scenario defined in section 4.9. 

The PDGS high-level design does not intend to provide an engineered decomposition of the 

PDGS into physical components beyond distributed Centres. Some Functions in parts or as a 

whole will aim at a near direct translation into hardware and software systems (reused or 

explicitly developed or both). Others will either refer to: 

○ a functional service that will not lead to any explicit development and that is intended to 

be procured through the direct reuse of services that can answer to the demand with 

little required customisation; 

○ a specific functionality that cannot be provided through automated and computer 

means as requiring specific interactivity and expertise; 








page 196 of 350 

○ a system-level functionality expected to be translated into an automated behaviour of 

the PDGS through actual systems but which is intentionally left at system-level to 

maximise the opportunity of fulfilling it by reusing aggregate or customisable existing 

solutions; 

5.2 Functional Model 

This section describes the decomposition of the PDGS overall functionality into 

complementary high-level primary Functions. 

5.2.1 DESIGN LOGIC 

Based on the overall design rationale presented in the previous paragraph, the functional 

decomposition aims at defining a logical split of the PDGS overall required functionality into 

primary Functions which can optimally be distributed across centres to globally implement the 

operation baseline of the PDGS. As such, the functional breakdown comprehensively aims at: 

○ Providing a first-level layout of primary Functions each one solving part of the problem 

in coordination with others in a logical way; 

○ Providing a clear basis for the definition of operation concepts at Function-level that 

logically aggregate at system-level in responding to the PDGS baseline services; 

○ Isolating Functions in view of optimising the logical-to-physical mapping into macrofunctional 

roles for the definition of PDGS Centres; 

○ Isolating Functions according to typical existing market solutions that can be reused in 

parts or entirely from previous PDGS developments, while concentrating the 

specificities of the Sentinel-2 PDGS into other dedicated Functions; 

○ Providing a clear view over the envisaged enhancements compared to previous 

developments, to meet the particular challenges of the Sentinel-2 mission; 

○ Ensuring the functional blocks can be clearly associated to their key design-drivers in 

view of their implementation; 

○ Embedding the required flexibility and scalability in the design in view of the distributed 

but yet unknown physical layout of the PDGS; 

Following a first section defining the breakdown, each identified function is then separately 

detailed with its specific objective, design-drivers and logical interfaces to the other functional 

blocks. The design rationale pertinent to each function group or function is described recalling 

the source operation constraints and drivers of section 4.3. Specific relevance to the PDGS 

operation baseline definitions outlined in chapter 4 is also pointed out. 

5.2.2 FUNCTIONAL BREAKDOWN 

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

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








page 197 of 350 

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. 

The following paragraphs follow this first level decomposition and provide the second and 

final breakdown into the PDGS Functions. 

5.2.2.1 Data Management Functions 

5.2.2.1.1 Core Objective 

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. 

5.2.2.1.2 Design Drivers 

The main drivers shared by all data-management functions are mostly driven by the Data- 

Access services characteristics complemented by the baseline requirements on the data 

products as defined in section 4.3. Associated drivers are highlighted such as: 

○ The reliability of service for the systematic and timely availability of products on-line at 

the user interfaces according to the baseline plan including NRT and daily timeliness at 

the latest; 

○ The uniform, well-defined and controlled quality of all products delivered; 

○ The capability for discovery of products according to user-defined criteria including 

time geographical coverage and cloud-cover; 

○ User-oriented supply mechanisms allowing the products to be delivered according to 

the strict user-needs in terms of format and contents; 

○ The high expected demand for Sentinel-2 high-resolution optical products considering 

the open data-policy; 

○ The long-term outlook of the PDGS services for data-supply of daily refreshed data 

during the 7 to 12 years of each spacecraft lifetime and to be extended for 25 years 

beyond. 

On a functional design point of view, the following drivers and constraints are highlighted: 

○ The gradual phase-in of spacecrafts in the constellation during operations imposes that 

the data-management functions are designed with multi-spacecraft embedded features 

since the beginning allowing to clearly discriminate each spacecraft dataflow on a 

logical point of view; 









page 198 of 350 

○ As inherited from lessons learnt and taking advantage of the systematic nature of the 

Sentinel-2 data-acquisition plan, all data-management functions aim at a data-driven 

mode of operation whereby the data processing down to the delivery for user access is 

performed as triggered by the data reception at the CGS in a systematic manner. 

User-accesses are also aimed for a data-driven approach as required by the 

subscription concept to supply user-products and specific Data-Set compilations 

directly at the user-base. 

○ A specific constraint to the data-driven approach is introduced by the specificities of 

the MSI instrument which packages the data measurements with spectral-bands 

delocalised on earth (cf. Sections 4.3.8.2 and 4.3.8.1). A provisional scenario to solve 

this constraint at space-segment level through an accurate commanding of the MMSU 

playback operations. Nevertheless, the current baseline scenario for MSI downlinks 

described in section 4.5.4.2.1.3 currently imposes to circulate raw-data segments 

between stations on-ground in a reliable way and within the day to ensure the quality 

and timeliness of all the production. 

○ The very large dataflow generated by a single Sentinel-2 spacecraft and doubled 18 

months after imposes: 

o To limit the internal data circulation on-ground while bringing the data “close” to 

the users on a network accessibility point of view as directly as possible; 

o Parallel processing capabilities to cope with the dataflow in real-time; 

o Openness to current and new technologies and their trends in areas such as 

high-performance computing, digital media storage and delivery over the 

internet prone to substantially helping with the required gain in performance; 

o Trade-off solutions for data-access including capabilities for data-product 

reduction to the strict user needs and the provision for a user-hosted postprocessing 

capability whereby the users can further reduce the data to their 

precise downstream usage; 

o Trade-off solutions for data storage coping with timeliness and data-access 

required performance on one hand and with the required reliable data 

accessibility in the long-term on the other; 

o Trade-off cost-effective solutions for the systematic and reliable data 

transportation on-ground for optimising user-accessibility and long-term data 

availability considering wide ranging data circulation supports such as groundnetworks, 

data broadcast (e.g. EDRS) and media; 

o Highly-scalable solutions on all above items to cope with the planned doubling 

of the dataflow and the possible exponential evolution of the user-demand for 

Sentinel-2 products; 

○ Long-term operational sustainability of the PDGS coupled with the large data volumes 

to be managed imposes a high-level of automation throughout to the datamanagement 

functions with stiff robustness, limiting operator interventions to the strict 

necessary; 

○ A highly flexible, modular and scalable solution with respect to mission operation 

evolutions considering an evolving PDGS layout imposing variable characteristics (e.g. 







page 199 of 350 

CGS network and accessibility via networks, ground network bandwidth, major user 

sites, etc); 

○ Additional design-flexibility to adapt to the EDRS phase-in for its optimal usage; 

○ An open design provisioning for the accommodation of the GSC third-party 

collaboration opportunities defined in section 4.2.3 to provide for long-term scalability 

in both data-access performance and range of products supplied; 

○ A very high degree of automation requiring only operator supervision throughout the 

data-elaboration chain from the antenna to the user bases. 

In addition, the design rationale and derived functional breakdown shall account for the 

potential for pre-existing solutions responding in the large part to the demand, hence 

optimising the downstream competitive procurement processes and the reuse of well-proven 

and reliable solutions. 

5.2.2.1.3 Breakdown 

The data-management functional breakdown is described here following the data elaboration 

logic from Sentinel-2 data acquisition at the ground-stations to data delivery the final users. 

The functional breakdown is depicted on Figure 5-1 and features: 

○ 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 hosted-processing 

collaborations (Cf. sections 4.2.3 and 4.10.2.2). 

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. 

○ 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 PDGS data-products. 

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

collaboration service defined in section 4.10.2.2 will be integrated as independent IDP 

functions. The prototype Level-2A processor will be hosted in the PDGS via this 

method. 








page 200 of 350 

Figure 5-1: PDGS Data-Management 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; 









page 201 of 350 

○ 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 long-term 

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 collocated with Sentinel-2 PDGS specific functions for data-circulation and dataaccess. 

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

distributed PDGS archives and more generally centralising all file-based 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 (cf. section 4.4.4); 

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

likely to be required to perform the PDGS processing activities (e.g. IERS UT1-UTC 

correlation data). This function is aims at being mapped directly to the external datasources 

identified in [RD-09]. 

○ 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; 

○ A group of Front-End Services responsible for answering to the several end-user 

access service interfaces: 

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

supporting catalogue queries and subsequent triggering of product downloads 

based on the DAG function. It provides the user interface for product data-access 

(cf. section 4.10.1.1) and the CDS/DAIL interface service (cf. section 4.10.1.2); 

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

(TCI) publishing service towards the general public. It provides the user interface 

to the general public for access to the global Sentinel-2 imagery (cf. section 

4.10.1.6). 







page 202 of 350 

5.2.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 main drivers shared by system-control functions are mostly driven by the Mission- 

Support services characteristics including the baseline requirements for system evolutions 

defined in section 4.6 and extensions through third-party collaborations as described in 

4.10.2. Associated drivers are highlighted such as: 

○ The reliability of service for the accurate management of the overall system 

configuration according to the HLOP and its derived plans and throughout mission 

phase changes; 

○ The operational reliability, availability, maintainability of all PDGS services versus their 

stakeholders such as the FOS and downstream data consumers, including during 

specific phase-in activities of new spacecraft units or EDRS. 

○ The well-controlled performance of the PDGS, the FOS and the space-segment vis-àvis 

the availability, timeliness and quality of all products delivered and of the mission as 

a whole; 

○ The operational assessment and monitoring of the PDGS sub-systems functioning and 

performance in operations following well-defined procedures for anomaly 

management, preventive maintenance and corrective maintenance; 

○ The long-term outlook of the PDGS services within the GSC in terms of flexibility and 

evolution capability it will be required to cover; 

○ The long-term sustainability of PDGS operations. 

On a functional design point of view, the following drivers and constraints are highlighted: 

○ To support the POM in its responsibilities (cf. section 4.2.1) the PDGS design shall 

feature a well-defined mission-control-loop directly responding to the services 

described in section 4.10.3 in providing the appropriate leverages on the main PDGS 

configurable elements systematically complemented by feedback visibility and 

measures on the associated performance. 

○ Taking advantage of the systematic and near-deterministic nature of the Sentinel-2 

data-acquisition plan, the mission planning and mission performance assessment and 

control activities aims for a near-autonomous and automated behaviour to the 

maximum feasible extent; 

○ The required long-term operational sustainability of the PDGS operations imposes a 

high-level of maturity to all system-management activities following well-defined 

procedures supported by widely used system management tools embedding 

computer-based automation when relevant; 








page 203 of 350 

○ The Sentinel-2 spacecrafts and in particular the MSI instrument featuring leading-edge 

technology coupled with the stiff requirements imposed on the accuracy of the final 

products impose that a certain number of critical tasks are assumed interactively by 

experts teams rather than fully automated in particular in the MSI performance and 

product quality control areas; 

○ The gradual phase-in of spacecrafts in the constellation as well as EDRS during 

operations imposes strict configuration control mechanisms for the accurate 

management of the software, hardware and of the overall PDGS configuration 

especially during the transitory phases separating operational scenarios. 

It also imposes that the PDGS functions are designed with multi-spacecraft embedded 

features since the beginning allowing to clearly discriminating the PDGS configuration 

applicable to each spacecraft on a logical point of view; 

○ Lessons learnt coupled with the long-term outlook of the Sentinel-2 mission imposes 

that the planning capabilities be flexible and include room for evolutions with respect to 

the strict baseline defined at present; 

○ The non a-priori knowledge of the EDRS OCP exploitation methods and constraints at 

the time of design imposes additional flexibility in the mission planning element to allow 

for a swift and optimal assimilation of EDRS capabilities when they will be better 

defined and/or measured; 

○ The cross dependencies between the LGS downlink opportunities and the nominal 

data recovery plan to the CGS network impose that the mission planning capabilities 

allow for optimising the direct-downlink opportunities to LGS throughout the mission 

plan within the constraints settled for the nominal mission; 

○ The fostering and effective implementation of collaborative PDGS opportunities will 

impose that specific technical support is provided towards the peer entities with 

mission management feedback to guarantee the appropriate definitions and successes 

of the collaborations. 


Derived from the above considerations, the functional breakdown regarding system-control 

functions is depicted on Figure 5-2. 








page 204 of 350 

Figure 5-2: 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 the performance assessment activities of each baseline; 

○ 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. It also aims at assessing the effective end-user data usage as 

measured on the data-access element. 

As such, the MPA function is intended as scattered and embedded across all 

functional domains, in particular in every step of the data elaboration down to the final 

products themselves, for gathering the data required for the quality assessment 

activities. It complementarily includes a central console compiling the high-level 

performance and quality figures required for decision making. 








page 205 of 350 

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

○ A Reference Platform (RP) function previously introduced in section 4.6 and globally in 

charge of system-level configuration control, system validation and transfer to 

operation activities as required for maintenance and evolutions throughout the PDGS 

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 expressed in sections 4.10.2.1 and 4.10.2.2, and liaising 

with the mission management for the definition of the collaborations and associated progress 

reporting during implementation as defined in section 4.10.3.2.4. 

5.2.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 function group is hence supporting all other functions requiring physical data exchanges 

across PDGS centres or towards external interfaces. 


The main drivers shared by Communication Functions are mostly driven by the high volumes 

of data to be transported within and beyond the PDGS premises. Associated drivers are 

highlighted such as: 

○ A high communication throughput down the data elaboration chain for the timely 

distribution of heavyweight products as close as possible to the user sites; 

○ The guaranteed security of all internal digital data communications between 

geographically distributed PDGS centres preventing unauthorised access or usage of 

the communication means by entities beyond the extended scope of the PDGS, i.e. not 

excluding potential collaborative entities; 

○ The guaranteed security of all digital data communications versus the FOS preventing 

unauthorised access or usage of the communication means beyond the sole PDGS- 

FOS transactions; 

○ The reliability of the communications in preserving the integrity of the data transported; 








page 206 of 350 

○ The overall quality and reliability of service related to access availability and 

guaranteed communication throughput when required; 

○ The flexibility in terms of range of solutions offered for trade-off between transport 

capacity, throughput, quality of service and operation cost. 

○ The use of modern, high capacity network technologies (e.g. MPLS, 10G Ethernet) 

and standard TCP/IP protocol suite. 


Derived from the above considerations, the functional breakdown regarding data 

communications is depicted on Figure 5-3. 

It features: 

Figure 5-3: PDGS Data Communication Functions 

○ 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 datarepatriation 

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 









page 207 of 350 

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; 

○ A Voice Communication Network (VCN) Function, possibly reusing public telephone or 

Voice-Over-IP (VOIP) services to enable human communications between PDGS 

internal or external interfaces. 

5.2.3 DATA MANAGEMENT FUNCTIONS 

5.2.3.1 Data Reception (DRX) Function 

5.2.3.1.1 Function Objectives and High-Level Description 

The DRX function is responsible for data acquisition from the spacecrafts and front-end datahandling 

activities. 

As such, it is in charge of: 

○ Data acquisition from the X-Band downlink interface of the Sentinel-2 spacecrafts 

through a LEO tracking antenna, or in Ka-Band on a still antenna pointing to EDRS 

spacecrafts relaying the Sentinel-2 data transmitted through the OCP; 

○ Real-time demodulation of the acquired signal and front-end processing of the CCSDS 

formatted bit-stream down to VCDU or ISP extraction; 

○ Real-time local storage of the acquired data; 

○ Real-time supply of the acquired ISPs or VCDUs to the DPC function as required for 

the nominal Level-0 product generation; 

○ On-request replay from local storage of the supply activities to the DPC function on 

contingency or for simulation purposes; 

○ Data housekeeping activities on the local-storage such as the autonomous cleaning of 

old acquisition buffers after a configurable retention period (typically after 3 days); 

○ Offering standard FTP/SFTP access on the local-storage for remote deposit or 

download of pass data; 

○ Systematic post-acquisition reporting on the data-reception quality to the MCC via the 

DC according to the monitoring requirements of the MPA; 

5.2.3.1.2 Design Drivers and Constraints 

The following drivers and constraints are identified: 








page 208 of 350 

○ The DRX function aims for a maximum reuse of existing ground-infrastructure X-Band 

tracking antennas or EDRS compatible Ka-Band still antennas; 

○ Demodulation and front-end processing activities are aimed for reuse of a sentinelgeneric 

DFEP equipment; 

○ DFEP activities are aimed for systematic operation with hot-redundant capability on 

separate hardware; 

○ The CGS operations aim for sharing the DFEP capabilities between several GMES 

Sentinel missions though a single equipment if their respective acquisition plans allow 

for it. 

○ Sentinel-2 data downlink characteristics feature a high data-throughput of twice 

280Mbps parallel real-time data-rate requiring equal or higher throughput capability on 

the DRX equipment at least from data acquisition to local DFEP storage; 

○ The DCP function shall not be constrained to process the DRX input stream at 

560Mbps data-rate; 

○ A Sentinel-2 data-reception pass may include the independent streamed downlinks of 

MSI data, spacecraft HKTM data and Ancillary data; 

○ DRX operations aim at 99% reliability in average from antenna acquisition down to 

nominal or contingency data supply to the DPC function, even if the DFEP equipment 

is shared synchronously among GMES Sentinel missions; 

○ Potential antenna operation conflicts between Sentinel spacecrafts may impose 

switching between a nominal and a backup antenna; 

5.2.3.1.3 Function Interfaces 

The following function interfaces are identified for the DRX: 

○ The external X-Band or Ka-Band RF signal interface from Sentrinel-2 or EDRS 

spacecrafts; 

○ The data-supply interface vis-à-vis the DPC function (e.g. via network); 

○ An FTP/SFTP server interface for remote access to the local-store; 

○ A data-reception commanding and configuration interface from the MPL function via 

the MCC and DC functions; 

○ A reporting interface to the MCC function via the DC function; 

○ An M&C interface for status monitoring. 

5.2.3.2 Data Processing Control (DPC) Function 


The DPC function is responsible for coordination & orchestration of data processing and 

archiving activities according to defined processing rules. As such the DPC function manages 

and fragments inputs data (i.e. MSI input data for higher level product generation) and then 

coordinates required processing activities to be performed according to mission timeliness. In 








page 209 of 350 

addition DPC coordinates archive activities of generated outputs to chain new processing 

activities according to the configuration processing rules. 


○ Supporting the generation of Sentinel-2 products including post-processing QC 

algorithms within applicable timeliness constraints; 

○ Level-0 products generation through a specific interface with DRX function to process 

received ISP data; 

○ Supporting “on-the-flow” processing as input data become available managing 

required processing activities; 

○ Fragmenting input data flow in processing data-trunks (e.g. L0 data fragmentation per 

detector and on-board scene) according to the processing parallelisation strategy to 

support simultaneous processing activities; 

○ Managing simultaneous processing activities of MSI data fragments for product 

generation activities; 

○ Managing simultaneous QC post-processing activities on generated data fragments; 

○ Interfacing with archive for required inputs retrieval (MSI data fragments and related 

ancillary & auxiliary data) and new generated MSI data fragments storage; 

○ Integrating user-provided hosted-processors (e.g. L2 or L3 processors) following a 

TBD ICD; 

○ Supporting user requests for hosted-processing activities triggered by the DAG 

function; 

○ Supporting operator-driven bulk-data re-processing activities (i.e. to perform reprocessing 

campaigns); 

○ Supporting configurable processing and quality-control activities chaining with adaptive 

priorities management (e.g. NRT, nominal, re-processing, etc.); 



○ Strong input data flow fragmentation in data-trunks (i.e. processing units) needed for 

the parallelization strategy; 

○ Near-linear processing scalability achieved via input-data fragmentation & 

management of simultaneous processing activities; 

○ Processing resources scalability (i.e. possibility to enhance processing capabilities by 

swift new HW addition); 

○ High performance interface between DPC function managed processing nodes and 

archive & inventory function for required I/O storage and retrieval; 

○ High performance interface with DRX function for level-0 processing activities; 

○ Well-defined processing interface supporting swift third-party processor integration 

(QC, TCI, coverage-report, user-processors); 







page 210 of 350 


The following function interfaces are identified for the DPC function: 

○ The data-gathering interface vis-à-vis the DRX function (e.g. via dedicated network 

interface) for the level-0 processing activities; 

○ The query interface vis-à-vis the AI function (e.g. via network) for required data-trunks 

discovery; 

○ The data exchange interface (data-trunks storage & retrieval) vis-à-vis the AI function 

(e.g. via dedicated network); 

○ The commanding & control interface vis-à-vis the IDP & OLQC functions (i.e. to 

manage desired processing and quality control activities execution); 

○ The commanding & control interface vis-à-vis the hosted user processors deployed in 

the PDGS; 

○ The interface with the DAG function for the hosted-processing requests reception and 

management; 

○ The provided HMI towards the operator in support of bulk-data re-processing 

campaigns, failed processing recovery activities, on-demand processing requests, etc; 

○ A reporting interface on performed processing & QC activities to the MCC function via 

the DC function (to be later used by MPA function); 

○ The M&C interface for status monitoring; 

○ The MPA function for the reception of QC and TCI processors; 

5.2.3.3 Instrument Data Processing (IDP) Function 


The IDP function is responsible for processing the instrument and satellite telemetry to 

generate PDIs that will compose Level-0 consolidated, Level-1A, Level-1B and Level-1C 

products. The processing is performed according to the algorithm and processing steps 

described in section 4.5.4.5. 

The IDP functionality is triggered and globally managed through the DPC function for data 

input/output, commanding and control. 

As such, the IDP function is specifically in charge of: 

○ Generation of PDIs according to the DPC processing directives; 

○ Reporting on the performed processing activities to the DPC reporting interface; 



○ High reliability of performed processing activities; 

○ High performance of performed processing activities (i.e. required processing time); 





○ Effective processing resources usage (i.e. CPU and memory usage); 




page 211 of 350 

○ Allow simultaneous instances execution to achieve processing parallelization; 

○ Compatibility with the DPC interfaces for commanding & control and data input/output. 


The following function interfaces are identified for the IDP function: 

○ The DPC function commanding & control interface for the IDP execution management; 

○ The DPC function data input and output interfaces for processing job input and output 

data flows; 

○ M&C interface for status monitoring; 

5.2.3.4 MSI Decompression Software (MDS) Function 


The MDS function is responsible for providing to the IDP function, and more generally to any 

third-party entity such as the LGSs, with the capability to handle and decompress Sentinel-2 

MSI on-board compressed raw-data. In addition to the capability of fully decompressing the 

image, the decompression software shall be able to extract the low-frequency image content 

in order to quickly generate an under-sampled image. 


The following drivers and constraints are identified for this function: 

○ Maximum reuse of an existing software components developed for Pleiades and 

Astroterra missions (known as MRCPBG); 

○ Long-term maintainability and portability (>40 years) is required to meet Sentinel-2 

LTDP objectives defined in section 4.3.5.2. 


The MDS function will be interfaced directly at software level through a well-defined API 

provided in compiled form. 

Software distribution will be ensured through a dedicated internet interface (e.g. a web-site). 

5.2.3.5 On-Line Quality Control (OLQC) Function 


The OLQC function is responsible to perform the systematic and real-time essential data 

analysis and anomaly detection over all Sentinel-2 PDGS elaborated PDIs. As part of the 

Sentinel-2 PDGS products generation activities, the OLQC function will generate Quality 

Indicators (QI) as required to: 








page 212 of 350 

○ Summarise the PDI overall essential quality under the form of “quality reports” that will 

be included in the product metadata; 

○ Authorize or block the PDI for distribution to general users through the flagging of 

specific metadata that will be managed by the DAG function; 

○ Feed quality information to subsequent short to long term quality assessment activities 

performed by the MPA function. 

Identically to the IDP function, OLQC functionality is triggered and globally managed through 

the DPC function for data input/output, commanding and control. 

The OLQC function performs the quality checks defined in the Product Definition Document 

[RD-07]. 



○ High reliability of performed QC activities; 

○ Minimize timeliness penalties of performed QC checks; 

○ Flexibility and adaptability to cope with different QC checks configurations; 


The following function interfaces are identified for the OLQC: 

○ DPC function commanding & control interface for the OLQC execution management; 

○ Input interface for required data-supply for quality control activities vis-à-vis the DPC 

function; 

○ Output interface for generated quality information supply vis-à-vis the DPC function 

(e.g. quality reports); 

○ The M&C interface for status monitoring; 

5.2.3.6 Archive & Inventory (AI) Function 


The PDGS AI function is responsible for archiving the Sentinel-2 mission products (science 

and HTKM products) and the associated auxiliary data in an effective manner. Accordingly 

the MSI science products components are structured and archived as Product Data Items 

(PDI) with the related satellite ancillary and auxiliary data required for their processing. 


○ Autonomously archiving and inventorying the PDGS generated production and related 

ancillary and auxiliary data; 

○ Maintaining a consistent record of all the locally stored product units with their 

associated metadata; 








page 213 of 350 

○ Providing data discovery and retrieval capabilities on the locally archived data 

elements through the inventory queries based on complex metadata criteria (to the 

DPC and DAG functions); 

○ Provide a high performance data exchange interface towards the Data Processing 

Control function in support of the production generation activities (i.e. products archive 

& retrieval operations); 

○ Provide a high performance data distribution interface towards the DAG function (i.e. in 

response of user requested products); 

○ Coupling with the LTA service function for long term data storage and retrieval; 

○ Mirroring systematically the LTDP archived items to the LTA service function; 

○ Maintaining a consistent record of the LTA service function archived content by 

inventorying its stored product units with their associated metadata and flag them as 

“off-line”; 

○ Mirroring systematically all the inventoried items to the PDGS data index (DAX 

function); 

○ Providing data discovery and retrieval capabilities on the LTA service archived data 

elements through the inventory queries based on complex metadata criteria (to the 

DPC and DAG functions); 

○ Implementing configurable retention policies for the stored elements supporting 

complex criteria; 

○ Implementing data-driven archive-to-archive circulation policies supporting complex 

criteria (i.e. based on geolocation coverage, cloud cover indicators, additional 

metadata, etc.) making use of DC function; 

○ Supporting autonomous and manual data extraction activities from the archived items 

according to configurable data extraction rules; 



○ High scalability to support configurations from lightweight (~50TB) to massive storage 

capabilities (~1PB); 

○ Distributed deployment in support of the PDGS federated concept; 

○ Long-term data storage reliability with minimum down-times; 

○ Archive & retrieval performances according to the high load of data and products 

layout; 

○ Adaptability towards third-party LTA solutions; 


The following function interfaces are identified for the AI function: 








page 214 of 350 

○ Input interface to the AI function for the file based configuration (e.g. data retention 

policies, data circulation rules, etc.) provided by the MCC function (e.g. distributed 

archived with different data retention policies); 

○ Input and output data circulation performed through the DC function; 

○ Input and output interface for the PDIs gathering and supply (archival and retrieval) 

with the DPC function in support of the PDGS processing activities; 

○ Output interface for the “archive reports” supply via the DC function to the DAX and the 

MPA functions that summarizes archive / removal / update activities of every 

distributed archive; 

○ Query interface on the archive content for data discovery purposes (e.g. network 

interface); 

○ Output interface for archived PDIs supply towards the DAG function in support of the 

PDGS data-access activities; 

○ Archived data and metadata configurable import/export interfaces; 

○ Input and Output Interfaces to the LTA service function (i.e. systematic circulation to 

the LTA service function and on-request data retrieval from the LTA service function); 

○ M&C interface for status monitoring; 

5.2.3.7 Long-Term Archive (LTA) Service Function 


The PDGS LTA service is responsible for ensuring long-term data preservation of Sentinel-2 

data, including product and auxiliary data. 


○ Archiving the MSI Product Data Items and auxiliary data provided by the AI function 

for LTA management; 

○ Restoring the MSI Product Data Items and auxiliary data on request to the AI function; 

○ Providing bulk data re-processing capabilities on the locally archived dataset. 



○ Maximum reuse of European existing infrastructures; 

○ Service provider reliability; 


The following interfaces are identified for the LTA service: 

○ Input interface to receive PDI and auxiliary data from the AI function from remote 

centres; 









page 215 of 350 

○ Output interface to provide archived PDI and auxiliary data on request to the AI 

function; 

5.2.3.8 Data Circulation (DC) Function 


The PDGS DC function is responsible for performing file exchange operations between subsystem 

interfaces within and external to a PDGS centre. File exchange circulation can be 

performed between electronic and media interfaces. 


○ Autonomously retrieve required files from configured source interfaces, perform file 

transformation operations (e.g. format conversion, compression, file renaming, etc.) 

when required and deliver them to configured target interfaces; 

○ Perform above described data circulation operations between electronic interfaces 

and/or media interfaces when required; 



○ Circulation operations reliability. DC function shall ensure that no file is lost during the 

data circulation operations due to network failures, media errors, etc.; 

○ Flexibility in handling interfaces of very different nature such as electronic via ground 

link, via EDRS broadcast and via media. Therefore this capability will require versatility 

in adapting to such variety of interfaces and state-of-the-art media technologies; 

○ Capacity to manage electronic interfaces with different connectivity requirements (e.g. 

secure/non secure connections, file naming conventions, different clean-up policies, 

etc.). Connectivity capacities will rely on standard protocols make use of standard 

protocols to perform data circulation operations (i.e. SFTP, FTP, SMTP, HTTP, etc); 

○ Adaptability to support circulation operations from different PDGS functions and 

capacity to integrate in a seamless manner with them; 

○ DC function circulation services towards the others PDGS functions aim at 99,9% 

reliability in average; 

○ Full automation of all circulation capabilities versus electronic interfaces; 

○ Maximised automation of circulation mechanisms via physical media aiming at a 

mechanical process driven by simple operational procedures modelling an automated 

transportation network; 


The following function interfaces are identified for the DC function: 

○ PDGS functions requiring file-exchange capabilities; 

○ A reporting interface to the MCC function via the own DC function; 







page 216 of 350 

○ Files circulation towards EDRS ground link gateway; 

○ Relevant M&C information; 

5.2.3.9 Precise Orbit Determination (POD) Function 


The POD function is responsible to generate predicted/restituted orbit products to support 

MSI science data processing activities in case the Navigation Solution (PVT) presents a 

degraded error-budget. 


○ Providing Sentinel-2 predicted POD products every orbit for each spacecraft (S2A and 

S2B) for science data processing in 3h-NRT; 

○ Providing Sentinel-2 restituted POD products for each provided L0 satellite ancillary 

product (for both S2A and S2B spacecrafts) for nominal 24h science data processing; 

○ Analysing the on-board navigation solution accuracy and associated reporting activities 

(delegated to the Off-line POD service interfaced by the MPA function as an Expert 

Team; cf. section 6.16.3.6); 

○ Analysing the own generated POD products accuracy with respect to their related 

timeliness and accuracy thresholds (delegated to the Off-line POD service interfaced 

by the MPA function as an Expert Team; cf. section 6.16.3.6); 

Predicted POD product will be generated by the POD function using as input the GNSS L0 

products (obtained from satellite ancillary packet store), auxiliary files from external data 

providers (GPS clocks & orbits ephemeris, environmental data, etc) and information on the 

Sentinel-2 spacecraft (manoeuvres, attitude, etc.). The accuracy ensured for POD predicted 

products is 10m on the 2D position. 

Restituted POD product will be generated by the POD function using as input the GNSS L0 

products, auxiliary files from external data providers (GPS clocks & orbits ephemeris, 

environmental data, etc) and information on the Sentinel-2 spacecraft (manoeuvres, attitude, 

etc.). The accuracy ensured for POD restituted products is 3m (TBC). 



○ Reuse of common multi-sentinels equipment. POD function is designed to offer POD 

products to different sentinels missions; 

○ POD products generation timeliness according to coverage and accuracy needs for 

science processing. 3h-NRT and 24h nominal processing timeliness for MSI science 

data imposes timeliness constraints on the POD products generation. 


The following function interfaces are identified for the POD function: 








page 217 of 350 

○ Input satellite L0 ancillary data provided by DPC function through DC function; 

○ Input auxiliary data autonomously gathered by POD function from external auxiliary 

providers (e.g. GPS orbits & clocks data from IGS) making use of DC function; 

○ Input FOS orbit files (i.e. predicted & restituted orbit files) provided through the MCC 

and DC functions 

○ FOS manoeuvre and resulting satellite mass property files provided through the MCC 

and DC functions; 

○ Output POD predicted and restituted products autonomously delivered to all centres 

with MSI data processing capabilities; 

○ M&C interface; 

5.2.3.10 Auxiliary Data Supply (ADS) function 


The ADS function is in charge of the generation and supply of all the PDGS required auxiliary 

data from external sources (cf. [RD-06]). 


The ADS function aims for a direct mapping to the external data-sources identified in [RD-06]. 

Accordingly it will fully mimic the applicable interface mechanisms for every external data 

source; in such manner ensuring the complete operability of the PDGS without any interaction 

with the real external data sources. 


A unique interface to the DC function is identified, either centralised at PDGS level or 

distributed in every processing centre. 

5.2.3.11 Data-Access Index (DAX) Function 


Because of the distributed PDGS context, Product Data Items (PDIs) may be scattered and 

possibly mirrored in several PDGS centres. The DAX function aims at providing a single 

centralised point for maintaining data location indexes of all product data amongst PDGS 

federated archive centres. Their physical location and relevant metadata is indexed to support 

their discovery for download as part of the User-Product generation process. In addition, it is 

in charge of consolidating the global PDGS data catalogue and mirroring it to downstream 

functions and to external interfaces to allow for catalogue browsing by the users. 


○ Creating and maintaining indexes of all PDGS archived Product Data Items; 








page 218 of 350 

○ Maintaining consistent references to the multiple archive/inventory sources and the 

corresponding data-access sinks (data-access gateway servers); 

○ Managing data duplications in different archive/inventory instances; 

○ Consolidation of the PDGS archived metadata and browse images as part of the 

indexing activities to identify duplications across the federated archives; 

○ Providing a query interface to support remote requests on the physical location 

(archive centres and associated data-access gateway servers) of the archived product 

data items according to different criteria; 

○ Feeding the Front-End Services (i.e. the MMUS and OLIB functions) with consolidated 

(no duplications) browse images and metadata associated to the new or modified 

archived production; 



○ High availability. DAX function nominal activities (products availability and location 

query activities and support for product assembly) are aimed for systematic operation 

with hot-redundant capability on separate hardware; 

○ Support to the mission LTDP service granting data access operations accordingly; 

○ High reliability and scalable performance; 

○ Minimize operator-driven maintenance activities; 


The following function interfaces are identified for the DAX function: 

○ The PDGS/AI function archive reports to follow-up the PDGS archives content 

including the metadata required to be indexed; 

○ The remote query interface vis-à-vis the DAG client (e.g. query requests to the data 

indexes through HTTP); 

○ The Front-End Services (i.e. the MMUS and OLIB functions) for the supply of 

representative browse images and associated metadata of the PDGS available 

production; 

○ The CDS/SCI for the systematic provision of the coverage reports of the Sentinel-2 

generated production by the PDGS (delivered through the MCC function as proxy); 

○ A file report regularly on the data indexing activities performed for the performance 

assessment of the PDGS activities (delivered through the MCC function as proxy); 

○ Relevant M&C information; 








page 219 of 350 

5.2.3.12 Data Access Gateway (DAG) Function 


The DAG function is in charge of providing a single point of access for the download of the 

PDGS imagery which is naturally scattered amongst the distributed archives. 

To this end, the DAG function follows a client/server paradigm in which the server side 

interacts with the relevant PDGS functions (e.g. the PDGS DAX, AI and DPC functions) and 

the client side to processes the requests to the imagery by accessing the appropriate servers. 

As such, the server side is deployed in each centre hosting an archive following the federated 

concept together with complementary functions relevant to the data retrieval activities. 

The DAG function is in charge of: 

○ Encapsulating the PDGS distributed nature through a single access point for data 

discovery and retrieval; 

○ Requesting the required PDIs in support of the User-Products assembly and supply; 

○ Prioritising the simultaneous data-access activities according to the request priority 

level as supplied by the MMUS function and the available network resources; 

○ Triggering the user-defined processors as requested by the MMUS function to support 

the hosted-processing activities implemented through the collaboration agreements; 

○ Providing a low level interface (command-line program, API, etc) to the data-access 

services it supports (data download and processor triggering mechanisms) towards the 

Front-End Services (i.e. the MMUS & OLIB functions) and potential legacy systems 

hosted at the GSPs; 



○ High availability and reliability. The DAG function nominal activities (PDI search 

location, PDI transport, and product assembly) are aimed for intensive operations; 

○ High performance and tight coupling with the underlying digital network for the 

provision of the product data items (i.e. download of PDIs). Flexibility in integrating 

various network transportation topologies and technologies is identified as a additional 

key driver; 

○ Clear client/server responsibilities separation and well defined protocol for the PDIs 

search location, retrieval and User-Product reconstruction activities following the 

defined product model (cf. [RD-07]); 

○ Client side software interoperability by third-party elements in support of the different 

Front-End Services (i.e. the MMUS and OLIB functions); 

○ Client side software portability to different platforms (HW+OS); 


The following function interfaces are identified for the DAG function: 









page 220 of 350 

○ The remote query interface offered by the DAX function on the PDIs location through 

the federated archives and associated data-sinks (i.e. query requests to the dataaccess 

indexes through HTTP for the appropriate DAG server); 

○ The interface vis-à-vis the AI function for the required PDIs requests and retrieval; 

○ The interface vis-à-vis the DPC function for the triggering of the hosted-processors; 

○ The interface vis-à-vis the different Front-End Services (e.g. the MMUS and OLIB 

functions) in order to support: 

‣ Data location and data retrieval requests submitted by the Front-End Services; 

‣ Final products assembly and supply (by the DAG client) to the Front-End 

Services; 

‣ Hosted-Processing requests from the Front-End Services (i.e. the MMUS 

function); 

○ The interface vis-à-vis the MMUS function for the supply of statistics and reports on the 

supplied PDIs, time to serve a product data item, volumes of data downloaded, etc; 

○ Relevant M&C information on the server side. 

5.2.3.13 Multi-Mission User Services (MMUS) Function 


The MMUS function is responsible for answering to the end-user access service interfaces 

defined in sections 4.10.1.1 and 4.10.1.2. As such, it will be in charge of the following tasks: 

○ Customer care & management providing on-line user registration and “my account” online 

handling capabilities; 

○ User groups management according to different levels of data-access (e.g. Cal/Val, 

unrestricted, etc); 

○ Help-Desk service by management of user inquiries (i.e. web based ticketing tool); 

○ Periodical provision of quality updated information on the available Sentinel-2 datasets, 

product quality, instrument unavailabilities, etc; 

○ Advertising of available mission, instruments and products documentation, including 

generic mission description; 

○ Centralised user authentication and authorisation (catalogue search, products browse, 

product download); 

○ Products collection management through the definition of datasets; 

○ Specialised datasets definition (logical datasets) based on the products cloud-cover 

percentage; 

○ Product catalogue including metadata and browse images supporting ingestion and 

query capabilities; 

○ Graphical products discovery and preview capabilities based on browse products and 

associated metadata; 







page 221 of 350 

○ Automation on the products download activities according to the users subscribed 

datasets; 

○ Graphical interface for user-triggered hosted-processing requests and management; 

○ Data-access (download) management based on previous data discovery/generation 

activities; 

○ Datasets/hosted-processing subscriptions management (i.e. creation, edition, deletion, 

etc) and download automation; 

○ CDS/DAIL catalogue and on-line access interface services implementing the 

CDS/DAIL ICDs; 

○ Generating statistics and reports on the catalogue search requests, products 

requested for download, etc. 



○ High availability and reliability. The MMUS function nominal activities are aimed for 

operations towards end-users; 

○ Support to the mission LTDP service granting data access operations accordingly; 

○ Clear and user-friendly HMI operations; 

○ Compliance with the applicable ICDs for the CDS/DAIL front-end; 


The Sentinel-2 users as interactively interacting with the MMUS through the web-client or the 

MMUS download manager. 

The following functional interfaces are identified via the MMUS: 

○ User interactive/automatic transactions (login, browsing of Sentinel-2 products, hosted 

processing triggering, product download, etc); 

○ Product discovery and on-line data access via CDS/DAIL i.e. through HMA service 

interfaces; 

○ The metadata ingestion interface from the DAX function (systematic reception and 

ingestion of browse products and associated metadata); 

○ The product data items location requests interface to the DAX function for the 

corresponding data-sinks location (DAG server) of the archived product data items; 

○ The data-access requests interface to the DAG function (client side) to perform the 

actual product data items download and final product reconstruction; 

○ The hosted processing transaction interface to the DAG function (triggering & 

monitoring of hosted-processing jobs); 

○ The statistics and reports on the data-access activities performed from the user side 

(i.e. catalogue searches, products downloaded, etc). 








page 222 of 350 

5.2.3.14 On-Line Image Browser (OLIB) Function 


The OLIB function is responsible for the Sentinel-2 true-colour images (TCIs) public 

publishing service towards the users. As such, the OLIB function will provide the following 

capabilities: 

○ Sentinel-2 True Colour Images streaming to the user (e.g. via JPIP); 

○ World navigation and visualisation of the Sentinel-2 TCIs; 

○ Time-machine view of TCIs for a given time period and geographical coverage; 

○ Image preview capabilities based on browse images; 

○ Download of the selected full resolution TCI; 


The following drivers are identified: 

○ High performance and tight coupling with the underlying digital network for the 

streaming and download of the TCI images. Accordingly flexibility in integrating various 

network transportation topologies and technologies; 

○ Service scalability on the number of simultaneous users supported without 

performance degradation; 

○ Cache mechanisms on the server side on the most demanded images; 

○ Buffering mechanisms on the client side to ensure a smooth images navigation; 

○ Sentinel TCI browser (client side) shall be implemented on a standard web client (i.e. 

plus additional plug-ins if required); 

○ Usage of W3C standards and open-source technologies; 


Sentinel(s) Image Browser for the on-line display and navigation through Sentinel-2 TCI 

images 

The following function interfaces are identified for the OLIB function: 

○ General-public users as interactively interacting with the Sentinel-2 TCI browser for the 

on-line display and navigation through TCI images; 

○ The metadata ingestion interface from the DAX function (systematic reception and 

ingestion of browse products and TCI associated metadata); 

○ The data-access requests interface to the DAG function (to perform the TCI product 

data items location and download activities); 

○ The statistics and reports on the TCI streamed and downloaded data triggered by the 

user. 








page 223 of 350 

5.2.4 SYSTEM CONTROL FUNCTIONS 

5.2.4.1 Mission Configuration Control (MCC) Function 


The MCC function is responsible for keeping under controlled environment all relevant 

mission reference files. MCC function controls critical configuration and essential operations 

information to allow a configuration control on critical parameters and resulting operations. 


○ Keep under a controlled environment all critical configuration parameters and essential 

operation reports into a central repository. Comprehensive management of all 

essential configuration and operations data over time; 

○ Manage the release of mission reference files updates, providing the functionality to 

activate (release) a specific system configuration throughout the distributed PDGS 

from a single point. The release and activation implies information delivery to 

applicable interfaces in a coordinated manner; 

○ File edition capabilities to generate required configuration parameters files (i.e. MCC 

function generates some configuration parameters files and others are gathered from 

applicable interfaces); 

○ Collection of all operation reports derived from configuration gathered from applicable 

interfaces. In addition delivery of such operations reports to applicable interfaces in a 

coordinated manner (i.e. acknowledged and triggered by the operator) or 

autonomously according to configuration (making use of the DC function); 

○ Providing query capabilities to the operator on the relevant aspects of the mission 

reference files management (e.g. ingestion time, release time, applicability time, etc.); 



○ Single point for the PDGS relevant parameters configuration management and 

release; 

○ Usage of the DC function for required data circulation activities; 


The following function interfaces are identified for the MCC function: 

○ MSI on-ground and on-board configuration gathered from the applicable interfaces 

(e.g. NUC tables and GIPP provided by the CNES/CST during the phase-E1 and the 

PDGS/MPA function during the phase-E2); 

○ Operation information and reports gathered from applicable interfaces (e.g. AI function 

archive reports); 









page 224 of 350 

○ The applicable interfaces for the release of the configuration parameters updates (e.g. 

NUC table delivery to the FOS and GIPP delivery to the PDGS DPC & IDP functions); 

○ The applicable interfaces for gathering and subsequent release of the mission 

operations reports and information delivery (e.g. AI function archive reports delivery to 

MPA function); 

○ The own function HMI supporting the operator on the configuration rules edition, 

coordinated release activities, historical queries, etc; 

○ The generated reports towards the POM on the mission reference files updates 

according to HLOP; 

○ The M&C interface; 

5.2.4.2 Mission Planning (MPL) Function 


The MPL function is responsible for Sentinel-2 mission plan generation for imagery 

acquisition and related data downlink activities to ground-stations and / or EDRS. 


o Generating the Sentinel-2 (S2A and S2B spacecrafts) Reference Orbit File; 

o Commanding MSI observation sensing activities; 

o Commanding MSI calibration sensing activities; 

o Commanding satellite on-board MMFU to record acquired imagery according to 

priorities (nominal/NRT data recording management); 

o Commanding satellite on-board MMFU to playback MSI data (according to priorities), 

satellite ancillary data and HKTM; 

o Characterising the Sentinel-2 assigned time segments for EDRS operations to produce 

the S-2 static EDRS Booked-Segments; 

o Commanding data transmission systems X-band transmitter XBS to downlink to 

ground stations and / or OCP for data delivery via EDRS; 

o Optimizing satellites resources usage (MSI acquisitions, memory load, downlink 

capabilities, etc.) according to constellation capabilities; 

o Verifying safety constraints from the SSCF applicable to the PDGS (e.g. MSI duty 

cycle, PDHT duty cycle, OCP duty cycle, etc.); 

o Editing the SSCF values for operations that applicable to the PDGS in order to assess 

their impact on the generation of the Mission-Plan; 

o Processing FOS response to the planned commanding activities to identify potential 

activities rejection; 

o Generating the Coarse Downlink Budget derived from the configuration characterised 

by the CGS/LGS network Characterisation and constrained by the X-Band RF conflict 

segments and the ground station resources conflicts; 







page 225 of 350 

o Automatically notification on the required downlink passes (pass-list) according to the 

generated Mission-Plan, for their booking at the ground stations (CGS/LGS); 

o Generating automatically the CGS/LGS X-Band & Ka-Band Acquisition-Schedule-Plan 

according to scheduled activities; 

o Generating automatically the EDRS-Booking-Plan according to scheduled activities 

and static EDRS Availability Segments assigned to Sentinel-2; 

o Automating explained above planning generation activities to avoid operator 

intervention when possible; 

o Supporting the PDGS-FOS mission planning loop. Accordingly verifying the complete 

scheduling by the FOS of the Mission-Plan activities; 

o Providing planning analysis & assessment capabilities (statistics generation on 

generated planning such as highest, average, lowest data latency figures, total sensing 

time, etc.); 



○ 

Flexibility to adapt to different acquisition & downlink scenarios (e.g. different ground 

stations assignation along mission life, ground stations roles, etc.). 

○ Multi-spacecraft management capabilities (i.e. load balancing strategies between S2A 

and S2B spacecrafts for acquisitions, downlinks, etc.). 

○ Automation capabilities for the planning generation activities; 

○ Usage of “Sentinels” Mission CFI generated by ESTEC (envisaged customisation of 

the Earth Explorer CFI); 

○ Operational interface for inputs/outputs through the MCC function acting as proxy; 

○ Usage of the DC function for required data circulation activities; 


The following function interfaces are identified for the MPL function: 

○ The POM for the definition of the mission acquisition and downlink scenario cascading 

from the HLOP; 

○ The MPA function operators for specific calibration requests; 

○ Input interface for relevant mission reference configuration (e.g. ground stations 

database, SSCF, etc.) provided by MCC function via DC function; 

○ Input interface for the FOS planning response (i.e. Plan Increment File) provided 

through the MCC and DC functions; 

○ Input interface for mission reference operations information (e.g. FOS PIF, predicted 

orbit file, etc.) provided by the MCC function; 

○ Output interface for mission reference files delivery (e.g. reference orbit file); 









page 226 of 350 

○ Output interface for Mission-Plan file(s) delivery to the FOS (MSI Image-Acquisition- 

Plan, Downlink-Plan) through to the MCC function; 

○ Output interface to the ground-stations for delivery of the pass-list for the booking of 

the required downlink passes and the provision of the Acquisition-Schedule-Plan to 

specify the required data-reception and front-end processing activities; done through 

the MCC function via the DC function; 

5.2.4.3 Mission Performance Assessment (MPA) Function 

5.2.4.3.1 Function Objectives 

As introduced in Section 4.5.3.2, the MPA function objective is to monitor if mission 

requirements are being fulfilled by the PDGS and to trigger corrective actions in case of 

anomaly. MPA covers the following four sub-functions: 

o Off-line Quality Control 

o Calibration and Validation 

o Instrument Data and Quality Control Processors Verification 

o End-to-end System Performance Monitoring 

The objective of the Off-line Quality Control is to monitor if the payload and specific on-board 

systems (e.g. on-board navigation solution) related products meet the quality requirements 

along mission life-time. 

The objective of the Calibration and Validation (Cal/Val) is to update on-board and on-ground 

configuration data in order to meet product quality requirements. 

The objective of the Instrument Data and Quality Control Processors Verification is to verify 

the quality of the image processing and quality control processors. 

The objective of the End-to-end System Performance Assessment is to detect anomalies at 

system-level and provide high-level performance figures on the overall mission performance. 


Due to the operational character of the Sentinel-2 PDGS, MPA function shall maximize the 

automation of recurrent tasks. For not-automatic tasks clear interfaces with human operators 

shall be defined. 

The MPA Off-line Quality Control shall provide a comprehensible reporting of its findings in 

order to minimize anomaly recovery periods. 

MPA shall be able to manage a multi-satellite configuration (2A/2B/…). 


MPA function has the following interfaces with other PDGS functions and external entities: 

o The MPA provides to the POM (via DC function) the Off-line Quality Control reports 

(daily and N-day cyclic) (including payload and platform status reports), on-demand 








page 227 of 350 

quality control reports for the Support Desk, Cal/Val reports (including requests for 

critical calibration parameters update), Processors Upgrade Requests (including 

verification results), processor upgrades requests and End-to-End System 

Performance reports. MPA gets from the POM (via DC function) mission requirements 

updates and on-demand quality control checks coming from the Support Desk; 

o The MPA feeds the CDS with quality control reports according to [AD-02] via the DC 

function; 

o The MPA gets products via the DAG function for performing Off-line Quality Control 

and Cal/Val tasks; 

o The MPA has access to a collocated DPC function embedding IDP and OLQC 

functions to perform processors validation activities; 

o The MPA has access to all POD data via the MCC and DC functions for performing 

Off-line Quality Control activities; 

o The MPA provides on-board and on-ground configuration data (OBCD and OGCD) 

and Cal/Val ad-hoc data acquisitions requests to the MCC function. MPA gets from 

MCC a reporting of the requests status; 

o The MPA has an operational interface with the RP function for the validation of the 

instrument data processing and on-line quality control processors before deployment 

of a new version; 

o The MPA function supports interactive access and batch requests to the FOS EDDS 

for the retrieval of decoded HKTM data (packets or parameters in engineering values) 

needed for the investigation of anomalies and / or auxiliary data processing activities; 

5.2.4.4 Monitoring & Control (M&C) Function 


The Monitoring & Control function is responsible at PDGS centre level for ensuring that all 

available resources (i.e. hardware, software and local network) required for the PDGS 

nominal operations are available, ready and running under expected conditions. M&C 

function allows detecting anomalies that a priori may involve working problems in the 

functional chain or help finding the cause of any malfunction of any PDGS function. 


○ Monitor physical resources (i.e. HW, network links, etc.) correct behaviour according to 

expected threshold ranges (e.g. free disk space thresholds); 

○ Monitor other PDGS functions key running processes to assess in real time their 

working status; 

○ Raising alarms to operators when monitored items are not under expected conditions. 

Alarms notification mechanisms to operators are configured according to error severity; 

○ Provide a single and harmonized logs view point for all PDGS functions. M&C function 

undertakes others PDGS functions logs messages and visualises them according to 

different configuration criteria; 







page 228 of 350 



○ Adaptability to support different PDGS functions execution environments and capacity 

to integrate in a seamless manner with them; 

○ Use of standard protocols for M&C function different data exchange needs (e.g. 

SNMP, SMTP, SSH, HTTP, SMS, etc.); 

○ Reuse of well proven off-the-shelf M&C existing solutions; 

○ Reuse of well proven off-the-shelf existing logs management solutions; 

○ M&C function services towards the others PDGS functions aim at 99% reliability in 

average to allow a clear understanding in real-time of their status; 


The following function interfaces are identified for the M&C function: 

○ M&C information gathered from other PDGS functions execution environment (i.e. 

SNMP information supplied to the M&C function console); 

○ Logs messages provided by other PDGS functions according to M&C logs 

management supported mechanisms (i.e. logs messages delivery via TCP sockets by 

other PDGS functions); 

○ M&C function generated and published reports (e.g. reports published on-line making 

use of HTTP); 

○ Alarms raised to the M&C operators (e.g. mails delivered via SMTP, messages to 

cellular phones via SMS, etc.); 

5.2.4.5 Reference Platform (RP) Function 


The RP function is globally in charge of hardware and software configuration control, system 

anomaly management, system validation and transfer to operation activities as required for 

maintenance and evolutions of the PDGS throughout its lifetime. 

As introduced in section 4.6, the RP function primarily aims at simulating 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. In addition, the RP function will include specific 

functionality tailored to its system-maintenance scope such as a software configuration and 

control environment, a hardware inventory database, a system anomaly management tool, 

test tools, interface simulators, reference test data sets, etc. Finally, the RP function will 

provide operator training functionality taking advantage of its simulation and operational 

rehearsal capabilities. 

To meet its primary objectives, the RP function will integrate all PDGS sub-systems (but 

excluding the specific non replicable ones such as antennas) and will be capable of swift 

configuration into their actual physical implementation in centre layouts, simulating all 








page 229 of 350 

operational interfaces between centres and external interfaces, such as the FOS, the CDS, 

LGS, etc. 

As such, the successful implementation of the PDGS will be demonstrated through the usage 

of the RP function, which will provide the necessary environment to ensure: 

○ The verification of every data flow of the deployed PDGS; 

○ The verification of PDGS requirements; 

○ The validation of all future PDGS operational mission scenarios; 

○ Support to the PDGS end-to-end tests and to OSV activities; 

○ Support to the Phase-E1 of the spacecrafts as required by the fast-reacting correctivemaintenance 

activity; 

○ Support to the qualification phase of all PDGS system upgrades before deployment 

such as the ones required for the gradual phase-in of spacecraft units or EDRS; 

○ Support the PDGS deployment phases of the initial and upgraded versions in 

configuring and assembling the preliminary-configuration elements to be deployed; 

○ Dedicated long-term support to the maintenance activities of the PDGS in operations; 

○ Ad-hoc training and rehearsal activities for PDGS operators; 

○ Recurrent reporting to the POM providing the required visibility on the PDGS system 

present and historical configurations at hardware and software levels, on-going 

maintenance actions and overall anomaly management activity. 

For all above activities, the RP function will make use of appropriate system management 

tools including: 

○ 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; 

○ 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 global system anomaly management tool for registering all problem occurrences, 

managing their accurate propagation to sub-system maintenance actions and ensuring 

backtracking capabilities down to system requirements. 

In complement, the RP function will rely on the MCC function from the maintenance and adhoc 

supply of the mission reference configuration to configure the platform and run the tests. 


The following drivers and constraints are identified for the RP function: 

○ It aims for a local and “fit for purpose” configuration in optimising the required hardware 

and infrastructure needs while allowing by extrapolation the assessment of deployed 








page 230 of 350 

PDGS performances. Nevertheless, it shall be sized sufficiently to allow for real-case 

representative load tests on the PDGS integrated systems; 

○ It aims for maximised flexibility targeting swift reconfiguration capabilities, mapping a 

given physical layout from available generic workstations to match the system test 

necessity, and supporting interactive handling of the platform itself as relevant for 

investigation purposes such as for the implementation of workaround solutions, the 

installation of operating system patches, etc. 

○ It aims for deployment in an adapted environment guaranteeing sufficient space for all 

the staff working in the IV&V and maintenance processes, and housekeeping all 

reference documentation with appropriate human browsing mechanisms (in paper form 

or otherwise); 

○ It shall be composed by hardware identical or compatible to a large extent with the one 

of the deployed PDGS including middleware configurations; 

○ It shall be assumed network connectivity to the PDGS deployed sites will be 

ascertained supporting secure remote access for software deployments and 

troubleshooting on the operational sub-systems. 

○ As a standalone PDGS, it aims for transportability in any European location clearly 

qualifying and quantifying associated site installation requirements (e.g. required 

power resources, cooling, workplace, connectivity requirements, etc). 

○ It aims for maximum reuse of widely used market solutions for all system management 

support functions dedicated to system inventory, revision control system (e.g. GIT, 

SVN, CVS, etc), documentation management (e.g. InfoTrove, KnowledgeTree, etc) 

and system anomaly management (e.g. Jira, Mantis, Bugzilla, etc). 


The following interfaces are identified: 

○ Secure network access interfaces to the PDGS centres (e.g. ssh, sftp) for 

troubleshooting and software deployment activities; 

○ An interface to the operational MCC function via a local DC function for the provision of 

the mission configuration required as reference for testing and validation activities. 

5.2.4.6 Collaboration Support Service (CSS) Function 


The CSS function is primarily aimed at providing technical support vis-à-vis the collaborative 

PDGS peers according to the needs of each type of collaboration expressed in sections 

4.10.2.1 and 4.10.2.2, based on collaboration agreement between the peer entities and the 

POM. 

In addition, it is responsible for liaising with the POM for the definition of the collaborations 

and to provide associated progress reports during implementation as defined in section 

4.10.3.2.4. 








page 231 of 350 

For hosted-processing collaborations, the CSS will be responsible for carrying out the 

Processor Integration Service activities defined in section 4.10.2.2.2.1 in coordination with the 

peer-entity. As such it will take charge of: 

○ Defining and maintaining a set of documented integration guidelines with relevant 

technical documentation (such as a well-defined Interface Control Document between 

the user-processor and the PDGS host environment). 

This documentation set is aimed for use by the collaboration peers in providing all 

information required to enable the hosting of their processor as a regular IDP function 

and in clarifying the tools and procedure applicable throughout the collaboration. 

○ Providing support to the peer entities for the definition, integration and running of their 

processors under the form of a help-desk activated throughout the collaboration; 

○ Performing the actual integration of the user-provided IDP processing functions within 

the DPC environment, including the coordinated configuration of other relevant 

elements such as the DAG elements. 

Regarding data-access mirroring centre collaborations, the CSS function will take charge of: 

○ Performing technical-support activities towards the collaboration peers as described in 

section 4.10.2.1.2 such as the provision and maintenance of software with associated 

documentation and the operations of a support help-desk; 

○ The configuration of the core PDGS for the operational data-supply of data-products to 

the peer mirror centres including the set-up of dedicated network links if applicable. 

Regarding support to POM, the CSS function will provide dedicated reporting on the status of 

the collaboration and main outcome with respect to the agreed terms of the collaboration. 

For hosted-processing collaborations, reporting will cover in particular: 

○ The overall collaboration status; 

○ The maturity of the new products generated and their validation status (e.g. through 

scientific publications); 

○ The evolution potential of the collaboration that could motivate valued-added 

promotion and sustained generation within the PDGS. 

For data-access mirroring centre collaborations, reporting will summarise the volume supplied 

and associated data-distribution statistics. 


As corresponding to an operational service, no specific design driver is highlighted for the 

CSS function beyond the compliance with its associated interfaces. 


The following functional interfaces are identified: 

○ The RP function for the testing of the user processors prior to deployment and the 

associated configuration required to support operational integration. 








page 232 of 350 

○ The POM operation interface for triggering the engineering phases of new 

collaboration, the fine-tuning of existing one and regular reporting on all collaboration 

activities. 

5.2.5 DATA COMMUNICATION FUNCTIONS 

5.2.5.1 Local Area Network (LAN) Function 


The LAN function is responsible for providing all ICT communication means necessary to 

connect all systems together (e.g. servers, operator consoles) residing within the same 

centre. 


The supporting LAN shall: 

○ Be scalable; 

○ Support the requested communications performance, 

○ Provide the necessary availability figure to achieve the overall expected value 

○ Guarantee the security of all internal digital data, communications, and systems by: 

o preventing unauthorised access or usage, 

o preserving integrity of exchanged and stored data, 

o preserving systems and service availability 

○ 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) 

○ Support the standard TCP/IP protocol suite 

○ Rely on commercial-of-the-shelf devices (COTS) compliant with the above standards. 

All systems to be connected to the LAN shall be equipped with the proper network interfaces 

(IEEE 802.3-2008). 



○ TCP/IP interfaces towards all supported systems at each centre; 

○ TCP/IP interfaces towards the DCN and/or DDN (interconnection gateway) at each 

centre; 

○ M&C interfaces; 








page 233 of 350 

5.2.5.2 Digital Circulation Network (DCN) Function 


The DCN function is responsible for all digital data communications between PDGS centres 

and may extend to support communications towards collaborative entities if required. This 

function will extend 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. It aims at being used to support in particular: 

○ The PDGS internal product data transportation required between centres; 

○ The electronic circulation of configuration and operation data between centres; 

○ The internal communication required by general ICT service (Email, remote login, etc) 


The DCN is built over a Wide Area Network (WAN) provided by an external Service Provider 

or by ESA (e.g. ODAD-NS), to be complemented by the 220Mbps EDRS data-repatriation 

broadcast link capabilities to support sustained product data circulation in multicast from 

CGSs to medium-term centres (cf. section 4.9.2). 

The following drivers are highlighted: 

○ Scalability (it shall accommodate at least a TBD % of traffic growth); 

○ The ability to reach all involved sites in a cost-effective manner, following a full-meshed 

or a partially meshed topology ; 

○ Communication performance supporting some or all of the required product data 

communications according to the System technical budget [RD-05]; 

○ The capacity to provide the necessary availability and reliability figures to measure the 

overall expected quality of service; 

○ A guaranteed security on all circulated digital data, communications, and systems by: 




○ Compliance with the standard TCP/IP protocol suite. 

○ The usage of new high capacity network technologies such as Multi Protocol Label 

Switching (MPLS); 

○ The ability to support Quality of Service techniques for differentiating and prioritizing 

high-priority traffic. 

○ The ability to integrate EDRS high-speed multicast capabilities when available. 











page 234 of 350 

○ TCP/IP interfaces towards the LAN and/or DDN (interconnection gateway) in all 

connected centres; 

○ High-capacity TCP/IP interfaces between centres circulating high volumes of product 

data within the PDGS; 

○ EDRS data repatriation TX and RX interfaces; 

○ M&C interfaces. 

5.2.5.3 Media Circulation Network (MCN) Function 


The MCN function is responsible for data communications performed via physical media (e.g. 

LTO, USB HDD, etc.) between PDGS centres, and expandable to support communications 

from the core PDGS to collaborative entities if required. This function embeds the physical 

media transportation between remote sites, e.g. using post mail services. It also includes the 

procurement of media required for data circulation and their recycling across centres. 


The following drivers are identified: 

○ Reliability, timeliness and cost-effectiveness of the shipment service; 

○ Full reuse of existing public or private off-the-shelf services; 

○ Automation of the media procurement processes and recycling between centres. 


In the PDGS operation context, the MCN function interfaces directly with the DC function 

responsible for creating the media for shipment or loading it on reception from other centres. 

5.2.5.4 FOS Communication Network (FCN) Function 


The FCN function is responsible for all digital communications between the PDGS and the 

Sentinel-2 FOS located at ESA/ESOC in Darmstadt (Germany). 


The FCN is built over a WAN or possibly reusing the ESA infrastructure network. The 

following drivers are highlighted: 

○ The ability to reach the FOS from selected PDGS centres requiring FOS connectivity 

(a single one is identified); 

○ A guaranteed security on all communications: 







○ Compliance with the standard TCP/IP protocol suite; 




page 235 of 350 


overall expected quality of service. 



○ TCP/IP interfaces towards the LAN and/or DDN (interconnection gateway) at selected 

PDGS centres; 

○ Network interface to the FOS operational network at ESOC; 


5.2.5.5 Data Dissemination Network (DDN) Function 


The Data Dissemination Network (DDN) Function is responsible for all communications 

towards 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. 

The main objective is to deliver the requested data to the end-user according to the relevant 

data category timeliness constraint in the most effective manner. 


The DDN is built over a Wide Area Network (WAN) provided by an external Service Provider 

or by ESA (e.g. ODAD-NS) to be complemented by the EDRS 110Mbps data-dissemination 

broadcast link capability towards end-users (cf. section 4.9.3). 

The following drivers are highlighted: 

○ Ability to reach intended users in a cost-effective manner; 

○ Sizing for the requested communications performance according to the System 

technical budget and products timeliness constraints (cf. section 4.4.5) up to the enduser 

premises for privileged users; 

○ Scalability (it shall accommodate at least a TBD % of traffic growth); 

○ The ability to reach all involved sites in a cost-effective manner, following a full-meshed 

or a partially meshed topology ; 


overall expected quality of service; 

○ A guaranteed security on all circulated digital data, communications, and systems by: 








page 236 of 350 




○ Compliance with the standard TCP/IP protocol suite; 

○ The usage of new high capacity network technologies such as MPLS and CDNs. 

○ The potential usage of new highly scalable media delivery content technologies (CDN). 

○ The ability to support Quality of Service techniques for differentiating and prioritizing 

high-priority traffic. 

○ The ability to integrate EDRS high-speed multicast capabilities when available. 



○ TCP/IP interfaces with all centres in charge of delivering products to the end users (in 

particular where the following functions are deployed: Archive and Inventory (AI), 

Data-Access Gateway (DAG), the Front-End Services towards the end-users such as 

the Multi-Mission User Services (MMUS) and the On-Line Images Browser (OLIB)); 

○ Possible dedicated TCP/IP interfaces with collaborative entities or GSPs; 

○ TCP/IP interfaces towards the LAN and/or DCN (interconnection gateway) at each 

involved centre; 

○ EDRS data dissemination TX and RX interfaces; 


5.2.5.6 Voice Communication Network (VCN) Function 


The Voice Communication Network (VCN) Function is in charge of supporting human 

communications between PDGS internal or external interfaces, possibly reusing public 

telephone or Voice-Over-IP (VOIP) services. 


The VCN function is aimed for cost-effectiveness and total reuse of existing public or private 

infrastructure. 


The VCN function is human operated. 








page 237 of 350 

5.3 Physical Model 

This section describes the decomposition of the PDGS decomposition into generic operation 

Centres. In turn, the so defined generic centres will be duplicated at will to build the actual 

operation layouts defined further down in section 5.4 

5.3.1 DESIGN LOGIC 

The PDGS will be geographically distributed in centres interconnected via communication 

means. Building on the concepts defined in section 4.5.1.4, each centre will be assigned a 

dedicated role defining its own responsibility perimeter within the overall PDGS operations. 

The PDGS operations will then result from the coordinated operations of the various centres 

enabled via the parallel operations of a shared communication infrastructure. 

The centre roles will be defined by aggregating one or several primary Functions defined in 

the functional layout (cf. section 5.2). Some generic functions will be operated in every centre 

as globally supporting the centre operations. Others will be combined such as to specialise 

the different centre roles. 

As primarily focussed on data-access performance and flexibility, the federative model 

introduced in section 4.5.1.4 and cascaded down in the functional design makes the primary 

basis for the definition of the physical layout. Several drivers are highlighted as particularly 

relevant in this respect; 

○ The data-access performance and scalability considering the high volumes to be 

managed and an exponential growth of the user demands as justified in section 

4.3.5.3; 

○ The guaranteed availability of the data in the long-term provisioning for redundancy of 

the data itself as well as the associated data-access services; 

○ The distinct levels of timeliness to be guaranteed at the data-access interfaces 

considering ground station downstream connectivity and communication performance 

between remote acquisition, processing and archiving centres; 

○ The enabling of evolutions via collaborative opportunities focussing on enhancing the 

data-access performance. 

In addition, the programmatic constraints impose an overall flexible, scalable and 

transportable solution in view of accommodating the initial PDGS set-up whilst provisioning 

for mission evolutions by further reshaping the PDGS layout. 

5.3.2 CENTRE DESIGN 

This section details the design of each type of centre. Each design is depicted in a dedicated 

schema using the following conventions: 

○ Centre interfaces are represented by yellow squares; 

○ External interfaces are represented with a blue background; 

○ PDGS internal interfaces or centres are represented with a green background; 








page 238 of 350 

○ Dataflows at the interface are represented with arrows in the direction of the dataflow; 

○ The functions aggregated in each centre are represented in circles with a grey 

background; 

○ A grey vignette on top of each centre external dataflow refers to the network function in 

charge of implementing the dataflow defined in section 5.2.5. The vignettes labelled 

with “WAN” refer to a communication via third-party networks interconnecting to the 

PDGS Network. 

5.3.2.1 Core Ground Stations (CGS) 

Two distinct Core Ground Station configurations are identified, a basic configuration and a full 

configuration. 

The basic CGS configuration maps the CGS to a strict data-reception role, ensuring the dataacquisition 

from the Sentinel-2 spacecrafts (via X-Band or via EDRS data-relay in Ka-Band) 

and safeguarding and relaying of the Level-0 data as received from the antenna. 

This CGS minimum configuration is depicted on Figure 5-4 within the “Basic configuration” 

outline. 


Figure 5-4 CGS Configurations 







page 239 of 350 

It features a data reception chain (DRX), and a minimum processing chain (DPC, OLQC and 

AI) comprehensively generating the Level-0 data, performing systematic quality control 

checks and storing the data in a rolling archive. The generated PDIs (Level-0 data and OLQC 

QIs) are systematically circulated downstream (DC) for higher level processing in other 

centres. 

From this basic configuration, the full CGS is provided with processing capabilities to 

generate higher-level products and data-access capabilities to publish its production via to the 

Data-Access network as depicted on Figure 5-4. 

It features a data-reception chain (DRX), and a fully configured processing chain (DPC, IDP, 

OLQC and AI) comprehensively generating the Level-0 data and all product higher-levels in a 

systematic manner. Systematic quality control checks are performed and the generated data 

is stored in the station rolling archive. The generated PDIs (Level-0, IDP, and OLQC) are 

circulated (DC) following the configured circulation rules (e.g. to long-term archives). The 

station participated to the federated data-access network by publishing a data-access 

gateway server (DAG) to all its production. 

5.3.2.2 Processing/Archiving Centres (PAC) 

The PAC is a generic data-centre providing processing and/or data-access capabilities. It is 

used to support medium term archiving and publishing with either or all of the following 

additional roles: 

○ Medium term Data processing and reprocessing. In particular, the nominal data 

processing from the Level-0 supply of a basic CGS would be supported by a PAC; 

○ LTDP role, including long-term archiving and bulk data reprocessing. 

○ Backup maintenance of the overall data access index of all PDGS distributed archives. 

It features all functions related to archive data management and publishing (AI, DAG and 

DC). According to its additional role, it optionally features: 

○ A fully configured processing chain (DPC, IDP, and OLQC); 

○ The interfaces to a collocated LTA service function; 

○ A DAX function in backup of the primary one operated in the PDMC (cf. 5.3.2.4) 

This PAC configuration is depicted on Figure 5-5, showing optional components in light 

square boxes. 








page 240 of 350 

PDMC 

DCN 

CGS 

PAC 

DCN 

MCN 

IDP 

Configuration data 

PDIs 

PAC (Processing / 

Archiving Centre) 

Processing Option LTA Option DAX Mirror Option 

PDMC 

DCN 

On-Line 

Quality 

Control 

OLQC 

Data 

Processing 

Control 

DPC 

Long-Term 

Archiving 

Service 

LTA 

Data- 

Access 

Index 

(backup) 

DAX 

DAX 

server I/F 

(backup) 

Data 

Access 

Gateway 

DAG 

Archive & 

Inventory 

AI 

Data 

Circulation 

DC 

M&C 

DAG server 

PDIs 

& all other data 

Users 

CNES/CST 

DDN 

CDAM 

DCN 

MCN 

WAN 

MPAC 

DCN 

MPAC, PAC, 

PDMC 

Figure 5-5 Processing/Archiving Centre (PAC) 

5.3.2.3 Mission Performance Assessment Centre (MPAC) 

The MPAC is responsible for performing all nominal mission performance assessment 

activities. It is supported by specific Expert Teams (for Cal/Val, specific quality control 

activities, etc.) as required. The MPAC configuration is depicted on Figure 5-6. 

The MPAC centralises the management of all specific mission performance expertise for the 

PDGS. In particular, all interface exchanges with CNES/CST during commissioning and with 

the expert teams (e.g. post launch office, MSI industry, MSI experts, off-line POD service, etc) 

during the entire operational phase are centrally managed at the MPAC. 

The MPAC includes a reduced version of the nominal processing chain to allow for IPF 

validation testing. It is systematically supplied by the PDMC with the required operation 

information (part of the mission reference files) for the monitoring and performance 

assessment activities. It is also supplied with PDIs data circulated from CGSs and PACs 

according to the configured internal circulation required by MPA nominal activities. 

Alternatively it can access any data published throughout the PDGS via a standard dataaccess 

gateway but does publish its own archive versus the data-access network. The 2 nd 

line Support-Desk is operated in the MPAC. 








page 241 of 350 

In addition, it hosts the POD function for the generation of the Precise Orbit Determination 

products and interfaces with the Off-line POD service (as a specific Expert Team) for the 

retrieval of reporting information on the accuracy of the Sentinel-2 on-board navigation 

solution and the POD products. 

Due to the nature of the activities performed in the MPAC (Cal/Val, quality control, 

performance assessment, etc.), it is likely that specific on-board parameters hosted only in 

the HKTM data could be needed to perform specific investigations. To this end, the MPAC 

relies on the FOS – EDDS service for the retrieval of the required decoded HKTM parameters 

as explained in the MICD (cf. [RD-06]) and following the mechanisms described in [RD-42]. 

Access to all the PDGS production is performed via the MMUS (client) and DAG functions. 

Finally, the MPAC hosts the 2 nd line Support-Desk interface accessible from the MMUS and 

CDS 1 st line Support-Desks, as well as priviledged interfaces such as the POM, CNES/CST 

and Expert Cal/Val Teams. 

PDMC 

DCN 

CGS 

PAC 

PDMC 

DCN 

CDAM 

WAN 

Expert Cal/Val Teams 

WAN 

CNES/CST 

FOS 

DCN 

GIPP, MSI tables PDIs CGS 

Off-line POD reports 

MCN PAC 

GIPP, MSI tables 

DCN 

FCN 

MRF/Operation Reports 

EDDS HKTM extracts 

PDMC 

MMUS transactions 

DAG transactions 

PDIs 

Archive & 

Inventory 

AI 

MPA Centre 

(MPAC) 

Multi-Mission 

User Services 

(web-client & 

download mngr) 

MMUS 

Data 

Access 

Gateway 

DAG 

IDP 

Data 

Processing 

Control 

DPC 

OLQC 

On-Line 

Quality 

Control 

Data 

Circulation 

DC 

POD 

Precise 

Orbit 

Determinati 

on 

M&C 

MPA 

EDDS HKTM web client 

2 nd line Support-Desk 

MPA reports 

OBCD/OGCD 

POD products 

FOS 

FCN 

CNES/CST 

DCN VCN 

POM 

CDS 

Expert Cal/Val 

Teams 

PDMC 

DCN VCN 

PDMC 

DCN 

Expert Cal/Val Teams 

CNES/CST WAN 

Figure 5-6 Mission Performance Assessment Centre Configuration (MPAC) 








page 242 of 350 

5.3.2.4 Payload Data Management Centre (PDMC) 

The PDMC centre coordinates all PDGS operations. It is responsible for: 

○ Mission planning activities with the FOS and scheduling of all CGSs and LGSs to 

enable satellite acquisitions (MPL). It centralises all interfaces to the Sentinel-2 FOS. 

○ The coordinated configuration of all PDGS stations and centres (MCC) in coordination 

with the POM; 

○ The federation of all remote PDGS inventories (DAX) and supply of coverage updates 

to the CDS; 

○ The management of collaborative opportunities implementations and coordination with 

PDGS centres and the POM; 

○ The management of all maintenance actions at system level (RP); 

○ Hosting the PDGS Front-End Services for data-access towards the users. 

o The operations of the Multi-mission User Services (MMUS) for Sentinel-2; 

o The cataloguing and ordering operations towards the CDS/DAIL interface 

through the MMUS function; 

○ The operations of the Multi-mission User Services (MMUS) for Sentinel-2; 

The PDMC configuration is depicted on Figure 5-7. 

Figure 5-7 Payload Data Management Centre configuration (PDMC) 








page 243 of 350 

5.3.2.5 Auxiliary Centres 

Auxiliary centre(s) are mentioned here for consistency as within the perimeter of the PDGS 

operations whilst not formally part of the Sentinel-2 ground-segment infrastructure. PDGS 

auxiliary centres are: 

○ Auxiliary Data Providers (ADP): (e.g. ECMWF, IERS, etc.) they are responsible for the 

operational supply of auxiliary data required by the PDGS for the data-processing 

activities. As such, the ADP(s) operate the ADS function on behalf of the PDGS. The 

auxiliary data generated by the ADP(s) will be fed throughout the PDGS via the PDMC. 

For a list of the PDGS Auxiliary Data Providers refer to [RD-06] – PDGS [MICD]. 

○ The MSI Decompression Software Provider (MDP): directly mapped to a TBD 

European software supplier, the MDP is responsible for supplying, publishing and 

maintaining in the long-term the MSI decompression software required to process MSI 

raw-data received by the Sentinel-2 satellites. As such, the MDP operates the MDS 

Function on behalf of the PDGS. The MDP will supply the software to the PDMC and 

LGSs. 

The auxiliary centres assumed configuration vis-à-vis the PDGS are depicted on Figure 5-8. 

Figure 5-8 PDGS Auxiliary Centres (ADP and MDP) 








page 244 of 350 

5.3.3 COLLABORATIVE/USER SITES LAYOUTS 

5.3.3.1 Collaborative Data-Access Mirror (CDAM) 

CDAM sites may be deployed following the collaborative opportunity defined in section 

4.8.1.1 for mirroring the data supplied by other centres within the data-access network. Its 

configuration is identical to a basic PAC as depicted on Figure 5-9. 

Figure 5-9 Collaborative Data-Access Mirror Configuration (CDAM) 

5.3.3.2 User Sites Layouts for Data Access 

The physical configuration applicable at the user premises for data access is depicted on 

Figure 5-10 as corresponding to the different data access methods dedicated to each user 

category: 

○ The GMES Service Projects and Sentinel-2 registered users will invoke the Sentinel-2 

data access services through the MMUS function either interactively using the webclient 

or automatically via the download manager. 

○ The general public will use the dedicated image browsing client to access to the 

Sentinel-2 TCI data. 








page 245 of 350 

Figure 5-10 User Sites Layouts 

5.4 Baseline Operation Layout 

The baseline operation layout applies to the X-Band mission scenario described in section 

4.9.1. Its physical layout features: 

○ Three CGS (CGS-1, CGS-2 and CGS-3) with a full configuration for data reception 

and processing; 

○ One CGS (CGS-4) with a basic configuration and relaying level-0 received data to the 

PAC-1; 

○ Two PACs (PAC-1 and PAC-2), each one holding a collocated LTA service function 

ensuring long-term data preservation in full redundancy of all Level-0, Level-1B and 

Level-1C data. In addition the two PACs are configured differently as regarding their 

mid-term role: 

o PAC-1 includes a processing chain configuration to process all CGS-4 

circulated acquisitions and perform medium-term reprocessing operations on a 

3 months level-0 archive. It is additionally sized for on-line publishing of one 

year of cloud-free level-1C data collected from all stations. 

o PAC-2 is sized for on-line publishing of one year of European coverage data 

supplied regularly by CGS-1/2/3 and by the PAC-1 for CGS-4 data; 

○ One PDMC to perform the PDGS global operations (e.g. configuration & control, 

mission planning, data-access coordination, etc.); 

○ One MPAC to perform Quality-Control and Cal/Val operations in coordination with the 

PDMC; 

The system level-configuration is provided on Table 5-1 detailing the circulation, processing 

and archiving configurations. 








page 246 of 350 

Centre 

reception 

from: 

Data-Circulation 

transmission to: 

Nominal 

Processing 

On-Line 

Archive 

Off-Line 

(LTA) 

Data- 

Access 

(Server) 

CGS-1 

CGS-2 

CGS-3 

Satellite 

PAC-1 

(Level-0/1C) 

PAC-2 

(Level-0/1B) 

CGS-4 Satellite PAC-1 (Level- 

0) 

PAC-1 

PAC-2 

MPAC 

PDMC 

CGS-4 

(Level-0) 

CGS-1/2/3 

(Level-0/1C) 

PAC-2 

(Level-1B) 

CGS-1/2/3 

(Level-0/1B) 

PAC-1 

(Level-1C) 

CGS/PACs 

(Cal/Val 

Level- 

0/1A/1B/1C) 

Metadata 

only 

PAC-2 

(Level-1C, 

CGS-4 Level- 

1B) 

PAC-1 

(CGS-1/2/3 

Level-1B) 

N/A 

Level- 

0/1A/1B/1C 

Level- 

0/1A/1B 

for 1 month 

Level-1C for 

1 month 

Level-0 Level-0 for 1 

month 

Level-1A/1B/1C 

+Reprocessing 

+Hosted 

Processing 

None 

Level-1A/1B/1C 

limited for 

purpose 

CGS-4 

Level-1A/1B 

for 1 month 

Level-1C for 

1 month 

Cloud free 

global Level- 

1C for 1 year 

Level-0 for 3 

months 

Europe 

Level-1C for 

1 year 

Level- 

0/1A/1B/1C 

limited for 

purpose 

N/A 

N/A 

Level- 

0/1B/1C for 

12 years 

Level- 

0/1B/1C for 

12 years 

N/A 

N/A None N/A N 

Table 5-1 Baseline Operation Layout Configuration 

Y 

N 

Y 

Y 

N 





6 DETAILED OPERATIONS CONCEPTS 




page 247 of 350 

This chapter provides an outline of the operations concepts translated at the level of every 

macro Function of the PDGS according to the design breakdown defined in Chapter-5. 

For each Function, the operation constraints and scenarios are summarised highlighting 

across-function interactions. 

6.1 Data Reception (DRX) Operations 

6.1.1 OPERATION CONSTRAINTS 

The following operation constraints are identified for the DRX function: 

○ The anticipated multi-Sentinels X-band data reception conflicts (cf. 4.3.10.4). 

○ Sentinel-2 spacecraft constellation concurrent operations. 

6.1.1.1 Multi-Sentinels X-band Data Reception Conflicts 

The DRX front-end processing sub-function will be designed and procured as multi-sentinel 

equipment that will be deployed in different data reception centres. Such centres can be 

shared with other sentinels missions and therefore data reception activities performed by 

other sentinels missions will constrain operations for the Sentinel-2 mission. 

6.1.1.2 Sentinel-2 S/C Constellation Concurrent Operations 

The DRX function will be designed to cope with the S2A and S2B units concurrent operations. 

The DRX function will be able to manage concurrent operations typically the data reception 

from the S2A spacecraft data and the S2B data supply operations (from a previous pass) or 

vice-versa and concurrent data supply operations of both S2A and S2B (previous pass data). 

Concurrent S2A and S2B data acquisition activities over the same centre are not allowed. 

Simultaneous data acquisition of the S2A and S2B satellites is not possible ensured by the 

180 degrees orbit shift foreseen between the two spacecrafts. 

The simultaneous operations for the both spacecrafts imply the independence per spacecraft 

on the data supply interface towards the data consumers (e.g. level-0 processing activities 

performed by the DPC function). This is to ensure that data supply activities performed for 

one spacecraft do not affect the data acquisition and pre-processing activities performed for 

the other one and vice-versa. In addition, it also implies that data supply activities of one 

spacecraft do not affect the same data supply activities of the other. Accordingly some 

separation at hardware level of specific subsystems responsible for data distribution activities 

will be required (e.g. interface servers, network interfaces, etc.). 








page 248 of 350 

6.1.2 OPERATION SCENARIOS 

6.1.2.1 Data Reception Configuration 

This scenario accounts for the operator-driven configuration of the DRX function in a CGS 

according to the Sentinel-2 specific needs. 

The following steps are identified for this operation scenario: 

1) The configuration of the physical locations in geodetic position and altitude of all X- 

Band LEO tracking antennas or Ka-Band GEO pointing antennas enabled for receiving 

the Sentinel-2 satellites; 

2) The ground station and antennas masks configuration is provided to the MCC function. 

Such configuration will be later on used by the MPL function for the mission planning 

activities (cf. section 6.15); 

3) The configuration of the RF signal acquisition, including the downlink frequencies and 

signal levels according to the Sentinel-2 spacecrafts, possibly differently per Sentinel-2 

spacecraft; 

4) The configuration of the front-end data-handling operations (e.g. the virtual channels 

identification); 

5) Data archiving configuration including: 

o The mapping of VCIDs into the archive files (all packets from the same virtual 

channel grouped in a single ordered stream as per data transmission 

constraint). The map is done according to the Sentinel-2 VCID map per 

spacecraft 

o Maximum dimension of the archive folder per pass (containing all archived 

files). An adequate maximum dimensioning will be needed to preserve the 

retrieval performances 

o The data retention time in the archive 

6) Data distribution configuration, including: 

o The front-end processing unit selected for nominal real-time data-supply among 

the two hot redundant items; 

o The network distribution rules to data consumers for data supply. This will be 

configured under the form of a routing table associating sink network addresses 

to the source data discriminating S/C-ID, VCID, and APID identifiers e.g. 

{netaddr X; enabled; S2A; VC 4; AP-x}. 

7) Monitoring and Control reporting configuration, including: 

o The list of parameters to be inserted in the reports (e.g. Mission, frames 

ingested, RS corrected frames, RS un-correctable frames, carrier input level, 

etc.). According to a well-defined ICD, Data reception reports will be customised 

for usage by the MPA function for assessment of the data reception 

performance 





o Report generation frequency and coverage 





page 249 of 350 

This operation scenario is used for the configuration of the DRX function when deployed in a 

Sentinel-2 assigned data reception centre. Firstly the configuration will cover the Sentinel-2A 

spacecraft and then complemented when additional spacecrafts are added to the mission. 

6.1.2.2 Load of the Acquisition Schedule 

This scenario accounts for the autonomous loading of Sentinel-2 acquisition schedule 

according to the DRX configuration. The acquisition schedule comprises the data reception 

and front-end processing activities. 


1) The DRX function autonomously gathers the new acquisition schedule (containing the 

spacecraft TLEs, the AOS & LOS events, and the front-end processing events) as 

provided by the MPL function; 

2) The DRX function autonomously loads the acquisition schedule to enable the data 

reception and front-end processing activities. Accordingly the acquisition and front-end 

agendas are updated ready to be activated shortly preceding the planned AOS. The 

antenna that will support the reception is pre-selected for each planned reception; 

3) The DRX function alerts in case of conflict with a previous planning (e.g. operations 

conflict with another mission). 

The acquisition schedule is generated by the MPL function as part of the mission plan 

generation activities. The MPL function supplies it to all the involved ground-stations. In a 

second step, the acquisition schedule is updated by the MPL function and supplied to the 

ground stations according to the availability of more accurate orbit ephemeris. 

6.1.2.3 Current Pass Data-Reception and Real-Time ISP Supply 

This scenario accounts for the autonomous data acquisition, front-end processing and realtime 

data supply. The DRX function acquires and decodes the mission data (science, 

ancillary & X-Band HKTM) downlinked from the satellites during a given pass, process it and 

distribute it in real-time towards the data consumers (i.e. the DPC function). The Instrument 

Source Packets supply towards the data consumers is started in real-time as soon as there is 

new data of the current pass available (i.e. not waiting until the pass has been completed but 

on-the-flow). 

This scenario also accounts for the local archiving of the acquired data and processed data at 

VCDU level discriminated by the VCID (science nominal, NRT and RT; ancillary and HKTM 

data respectively) according to the archiving strategy defined in the DRX function 

configuration scenario. 


1) According to the acquisition schedule (cf. 6.1.2.2), the data reception activities are 

activated shortly before the planned AOS event. The antenna selected for acquisition 

is moved to the AOS position using the applicable TLE and signal search is activated 

enabling tracking on the RF carrier signal with the associated antenna movement until 

the planned LOS; 







page 250 of 350 

2) Bit synchronisation and locking on IF carrier signal after AOS and until LOS is 

autonomously performed by the demodulation hardware; 

3) Front-end activities are triggered either autonomously based on the received signal or 

according to a specific commanding as specified by the acquisition schedule. The 

archive folder is created for the pass; 

4) Front-end processing activities are performed autonomously including data acquisition, 

demodulation, frame synchronisation, decoding (descrambling and Reed Solomon 

FEC), telemetry data time annotation and reconstruction of the acquired ISPs as per 

configuration; 

5) Decoded and annotated data is archived in real-time according to the DRX 

configuration; 

6) In parallel, the DRX function autonomously initiates the data-driven supply of AISPs to 

the DPC function as per configuration until LOS. Real-time distribution is performed in 

parallel for all configured output interfaces. In case the connections required for data 

distribution cannot be initiated or if they are closed by the remote end, the operator is 

alerted but no retry is autonomously attempted; 

7) At the planned LOS event, the acquisition activities are stopped leaving the output 

interfaces complete the AISP distribution operations until end-of-file, then releasing the 

network connections automatically. 

This operation scenario is used nominally for the real-time data reception and data supply to 

the DPC function when performing the Level-0 data processing simultaneously to the data 

reception. 

This scenario does not constrain the on-demand data supply activates as defined in the next 

scenario; both can be performed in parallel. 

Although triggered by the DRX function, the effective data-supply rate is systematically 

managed by the data consumers (i.e. the DPC function) through standard flow-control 

mechanisms. 

6.1.2.4 On Demand ISP Supply 

This scenario accounts for the operator-driven data supply operations as requested by the 

data-consumers possibly using one of the hot redundant front-end equipments. 


1) Through an appropriate HMI, the operator selects a pass folder previously acquired 

and maintained in the rolling archive and activates the operation; 

2) According to the operator-defined configuration, the DRX function autonomously 

initiates the supply of the ISPs from the archived pass data until reach the end-of file. 

The data supply operations are performed in parallel for all the activated output 

interfaces. No automatic retry is attempted in case the connections required for data 

distribution cannot be initiated or if they are closed by the remote end. 

The following use cases of this operation scenario are identified: 








page 251 of 350 

o On contingency cases of the data-supply operations following nominal real-time data 

reception, the operator triggers manually the data-supply operation to trigger the Level- 

0 processing activities performed by the DPC function. 

o For testing purposes, the operator simulates the raw data supply downstream activities 

following a satellite pass acquisition. 

6.1.2.5 Simulated Scheduled ISP Supply 

This scenario accounts for the operator-driven ISP supply simulations. In support of the 

system testing activities, this scenario is used for the activation of the data supply activities 

vis-à-vis the DPC function simulating one pass data acquisition from the Sentinel-2 

constellation. 

It requires that a number of simulated (or previously acquired) satellite pass folders are preloaded 

on the front-end equipment such that the data-supply activities can be activated by 

automation according to a well-defined agenda. 


1) Through an appropriate HMI, the operator defines the simulation agenda though a preselection 

and time scheduling of stored pass folders. The operator can reload 

previously defined agendas, modify and/or save new ones for future usage; 

2) The operator activates the simulation agenda, scheduling the data-supply interface 

mechanisms described in the previous scenarios on each stored pass folder following 

the agenda configuration. 

6.1.2.6 Archive Interface Operations 

This scenario provisions for upload/download file transfer and general housekeeping 

operations on the DRX function local archive to upload, download and remove the pass 

folders remotely using FTP or SFTP protocols. It is operated interactively from any FTP/SFTP 

HMI run from the station operator console or remotely from the RP function using the basic 

common mechanisms offered through the FTP/SFTP client programs. 

6.1.2.7 Reporting on the Operations 

This scenario accounts for the autonomous reporting on the performed operations according 

to the configuration. As such, the DRX function generates autonomously a report for every 

downlink pass that summarises the main performed activities on data reception and front-end 

processing activities. 

The DRX reports are autonomously supplied to the MPA function (via the MCC function) for 

the assessment on the data-link status, front-end reconstruction, errors occurred, data 

reconstruction activities, etc. 





6.2 Data Processing Control (DPC) Operations 

6.2.1 PRINCIPLES 

6.2.1.1 Processing On-The-Flow Concept 




page 252 of 350 

Due to the mission huge data rate, involved volumes of data and the processing timeliness 

constraints, the PDGS will need to parallelise the processing activities. 

The DPC function will systematically trigger the appropriate processing activities based on the 

new data availability. According to the PDGS parallelisation strategy and configuration of the 

DPC function divides the input product data items (PDIs) into processing units (a set of PDIs), 

and then orchestrates the subsequent simultaneous processing activities. 

The DPC functions responsibilities in support of the PDGS processing on-the-flow concept 

are: 

Support of a data granules cutting strategy according to the Sentinel-2 products 

breakdown (cf. [RD-07]) and the processing requirements (i.e. specified in the 

DPMs); 

 

Manage simultaneous processing executions with different sets of data granules. 

Figure 6-1 Parallelisation in the Processing “on-the-flow” Concept 


The following operation constraints are identified for the DPC: 

○ The timeliness requirements applying to the global production impose an orchestration 

of the processing and quality control activities performed by the IDP and OLQC 

functions in parallel and in a well-defined order. The decomposition of the overall 

Datastrip processing in a set of processing units will be the key driver for reaching the 

required level of parallelisation and complete the overall processing within the tight 

timing constraints; 








page 253 of 350 

○ The timeliness requirements also possibly impose the relative prioritisation of the 

processing jobs to ensure the different PDGS processing priorities as RT, NRT and 

reprocessing products imposing the access to a larger pool of processing resources 

than the ones required for the “nominal” processing; 

○ The DPC will be operable via HMI from an operator to carry out rehearsals, processing 

error recovery (i.e. trigger again a given processing), reprocessing activities, etc; 

○ The DPC will cope with the hosted-processing requests submitted by the PDGS frontend 

services; 

○ The DPC will be operable independently following several possibly conflicting 

triggering mechanisms (data-driven, operator-driven, support of hosted-processing 

requests). This constrains the DPC operations by an appropriate assignment and 

relative apportioning of the various processing resources available to each source 

trigger is well statically balanced or performed dynamically following the demand; 

○ Finally, the high volumes to be processed impose a constraint on the I/O performance, 

in particular versus the collocated AI function such that I/O does not become a 

bottleneck in the overall performance budget. 


6.2.3.1 Data Processing Control Configuration 

This scenario stands for the operator-driven configuration activities of the processing activities 

prior to its activation and normal operations. This scenario also accounts for the operatordriven 

definition and configuration of the DPC and the IDP (cf. section 6.3) functions. 

The DPC function is supported by the RP function in the process of the definition of the 

configuration according to the available processing resources, the expected processing load, 

timeliness definitions, etc by the usage of the mission configuration validation capabilities (cf. 

section 6.18.3.4) to test and rehearsal the processing activities devoted to the fine tuning 


Amongst others, the DPC and IDP functions configuration includes: 

○ Processing rules definition; 

○ Data fragmentation rules; 

○ Parallelisation rules; 

○ Processing resources definition. 

The use case of this scenario is the generation of the PDGS processing configuration (i.e. 

DPC/IDP functions). Such configuration is modelled to take into account the different data 

product load assigned to the different processing centres and can be managed by the MCC 

function (cf. section 6.14 - Mission Configuration Control (MCC) Operations) as Mission 

Reference Files for their release across the federated centres. 








page 254 of 350 

6.2.3.2 Current Downlink-Pass Level-0 Generation 

This scenario stands for the autonomous and data-driven and on-the-flow L0 products 

generation activities correspondent to the current downlink pass. The DPC function interfaces 

with the DRX function as the supplier of the current downlink pass ISPs raw data (cf. section 

6.1.2.3 - Current Pass Data-Reception and Real-Time ISP Supply). Subsequently to the L0 

product data items generation, the DPC function invokes the AI function for the archiving. 

This processing is performed on-the-flow by way of well defined processing units of fixed 

sizes for the MSI. 

This processing is performed in a data driven mode as triggered by the DRX function on 

reception of data from the satellites. 

The uses cases of this scenario are nominal L0 processing activities such as: 

○ S2HKTM generation; 

○ L0 satellite ancillary data generation; 

○ L0 MSI data generation. 

6.2.3.3 Previous Downlink-Pass Level-0 Generation 

This scenario stands for the operator-driven L0 products generation of a previous downlinkpass 

in response to potential contingencies. The DPC function will interface with the DRX 

function and accordingly make use of the supported mechanisms for the previous-pass data 

forwarding (cf. section 6.1.2.4). 

This scenario only differs from the previous one in the operator-driven activation. Once the 

operator has triggered the raw data ISPs forwarding from the DRX function to the DPC 

function, the latter performs the level-0 processing activities according to the configuration as 

explained previously. 

The uses cases of this scenario are the L0 reprocessing activities for contingency such as: 

○ S2HKTM generation; 

○ L0 satellite ancillary data generation; 

○ L0 MSI data generation. 

6.2.3.4 Data-Driven Processing Orchestration 

This scenario corresponds to the autonomous orchestration, commanding and control of the 

different processing activities according to the new input data availability. 

The DPC function on a data-driven manner, starting from the new L0 data trunks availability 

orchestrates the generation activities of the MSI higher level products data. As such, the DPC 

function interfaces with the IDP & OLQC functions, which are in charge of the MSI L1A, L1B, 

L1C, True Colour Image product data generation and associated QC activities respectively. 

The DPC function according to the configuration chains the different processing activities 

allowing the execution of multiple and simultaneous activities. 

The use cases of this processing scenario are orchestration of the following activities: 





○ MSI L1A, L1B, L1C and TCI product data generation activities; 

○ Quality control activities on the generated production; 





page 255 of 350 

○ Hosted-processing data generation activities according to the defined data-driven 


6.2.3.5 Operator-Driven Processing Orchestration 

This scenario accounts for the operator-driven autonomous orchestration, commanding and 

control of the different processing activities according to the processing request of a specific 

orbit(s). 

There are different use cases envisaged for this operation scenario such as: 

○ New processors verification and validation (e.g. in the MPA centre); 

○ Recovery from a failed data-processing; 

○ The reprocessing of all the product-data acquired/generated during the commissioning 

phase. The operator defines the commissioning phase set of orbits and the DPC 

function queues and orchestrates the appropriated processing jobs. 

6.2.3.6 Hosted-Processing Requests Processing Orchestration 

This scenario corresponds to the user-requests-driven orchestration, commanding and 

control of the hosted-processors. 

The DPC function will offer an interface towards the DAG function for the submission of the 

hosted-processing user requests and the subsequent processing management activities. 

The use case of this scenario is the hosted-processing activities as requested by the users 

through the MMUS function and routed by the DAG function to the local DPC function. 

6.3 Instrument Data Processing (IDP) Operations 


The PDGS/IDP function is a collection of processing modules in charge of processing the 

instrument and satellite telemetry to generate the product data items (PDIs) that will compose 

Level-0 consolidated, Level-1A, Level-1B, Level-1C and True Colour Images products. Each 

IDP function processing module can read input data from files and output its results to (newly 

generated) files. The IDP function processing elements can be chained so that the output of 

one task can be input to other tasks in the calling sequence. 

The IDP function main processing steps are summarized in Figure 4-23. It is highlighted that 

the last step from Level-1C to Level-2A will be carried out through an independent IDP 

function triggered interactively via the PDGS hosted processing functionality. 

Due to the huge volume of data to generate the MSI data production, the processing activities 

performed by the IDP function are envisaged to be on the flow, thus the IDP function will 

process MSI data linearly and systematically as available. 








page 256 of 350 

Thus the buffer of unprocessed data product is foreseen to be always under a predefined 

threshold in order to meet the timeliness requirement and to assure the completeness of the 

process. 

The IDP operations are systematically triggered through the DPC function supervision in 

charge of the overall handling of the input data-flow to the IDP instances and the generated 

outputs gathering. As such, IDP operation concepts are systematically managed through the 

DPC. 


The following operation constraints are identified for the IDP function: 

‣ Commanding & Control by the DPC function: the IDP function execution is managed 

through the DPC function interface and will comply with its interface requirements; 

‣ As hosted on the DPC environment, it will have a tight coupling and inherit constraints 

linked to the processing environment (I/O, hardware platform, etc); 

‣ Support to processing parallelisation: the IDP functional tasks must be decomposed 

into concrete processing steps maximising the opportunities for parallelisation and 

optimisation of the available HW resources (i.e. memory, CPUs, I/O). Accordingly the 

DPC function will be able to orchestrate simultaneously several IDP tasks (of different 

or same type) according to the inputs, configuration and available resources. 


6.3.3.1 Instrument Data Processing Configuration 

This scenario stands for the operator-driven configuration activities of the processing activities 

prior to its activation and normal operations. This scenario also accounts for the operatordriven 

definition and configuration of the DPC and the IDP (cf. section 6.3) functions and can 

be assumed to be performed jointly with the one defined in section 6.2.3.1 - Data Processing 

Control Configuration. 

Accordingly to the DPC function operation scenario, the operator is supported by the RP 

function in the process of the definition of the IDP configuration to test and rehearsal the 

processing activities devoted to the fine tuning configuration (cf. section 6.18.3.4 - Mission 

Configuration Validation). 

The use case of this scenario is the generation of the PDGS processing configuration (i.e. 

DPC/IDP functions). Such configuration is modelled to take into account the different data 

product load assigned to the different processing centres and can be managed by the MCC 

function (cf. section 6.14 - Mission Configuration Control (MCC) Operations) as Mission 

Reference Files for their release across the federated centres. 

6.3.3.2 IDP Data Processing 

This scenario accounts for the autonomous data processing activities performed by the IDP 

function according to the processing directives provided by the DPC function. 







page 257 of 350 

The PDGS/IDP function execution is managed by the PDGS/DPC function (cf. section 6.2), 

performing the commanding & control of the processing activities (i.e. triggering the function 

execution, trap its result, inputs/outputs management, etc). Accordingly, the IDP function 

once triggered by the DPC function performs autonomously the required processing activities 

according to the supplied processing directives without any operator intervention. 


1) The IDP function is invoked by the DPC function and provides the processing activities 

directive (i.e. a job-order file); 

2) The IDP function autonomously processes the provided processing directive to identify 

the requested processing activity, inputs location, desired outputs, etc; 

3) The IDP function autonomously processes (parsing, verification, loading into memory, 

etc) the input data (e.g. MSI data, auxiliary data, ancillary data, configuration); 

4) The IDP function autonomously invokes required processing modules with the 

gathered and decoded input data to generate the requested PDIs according to 

received processing directive; 

5) The IDP function deposits the generated PDIs to the DPC function interface according 

to the provided processing directive; 

6) The IDP function can autonomously generate a processing report which summarizes 

the performed processing activities; 

7) The IDP function exists notifying to the DPC function with a summary the result of the 

processing activities performed (i.e. success, failure, partially completed, etc.). 

All the IDP function data processing activities are performed autonomously without any 

operator intervention. In case of a contingency (e.g. failure process), the operator will be able 

to interactively submit on request the same processing directive and trigger the IDP function 

processing through the DPC function (cf. section 6.2). 

The use cases of this scenario are the different processing activities performed in the PDGS. 

The MSI L1A, L1B, L1C PDIs generation. The DPC function provides required L0 data 

granules and chain the upper levels processing activities by commanding the IDP 

function. 

True colour images generation. The DPC function based on the MSI generated data 

manages the true colour image processor generation. 

 

Collaborative hosted processors are considered part of the IDP function perimeter and 

managed as such. In particular, the MSI L2A prototype processor will be acting as a 

separate IDP function triggered interactively through the hosted-processing service 

interface. 





6.4 On-line Quality Control (OLQC) Operations 


6.4.1.1 Systematic Quality Control Concept 





page 258 of 350 

Systematic quality control consists in performing essential quality checks on all MSI data 

generated by the PDGS in an entirely autonomous manner (operator unattended). The 

checks include basic consistency verification of the format and value ranges, and more 

complex and specific control algorithms over the quality indicators associated to the 

radiometry and geometry properties of the images (e.g. histograms statistics, GCP residuals, 

etc). 

The result of the systematic quality-control activity is the annotation of Quality Indicators (QI) 

that will be embedded in the product metadata for: 

○ Monitoring and investigation purposes; 

○ Overall traceability under the form of one or several “quality-reports” linked to the 

product. 

In addition specific expert QIs will be computed for short to long term monitoring purposes 

through the PDGS/MPA complementary function. 

6.4.1.2 Quality Indicators (QI) Generation & Usage 

Depending on the product level, several on-line quality indicators have been identified. 

Examples of envisaged on-line quality check are described in [RD-07]. 

Most of them can directly be derived from the product quality indicators generated by the 

PDGS/IDP function during the products processing; others are derived by the OLQC function 

through simple operations on the product. 

Every QI generated by the OLQC function will be appended to the relevant data products. 

Most QIs will be used for off-line (i.e. not real time) monitoring activities (by the Off-line 

Quality Control sub-function of the MPA) in order to control products performance and 

accuracy trends, as well as to extrapolate instrument performances. 

6.4.1.3 Quality Indicators (QI) Scope 

The OLQC function quality checks are autonomously applied on the MSI product data and 

metadata according to the logic breakdown as defined in the Sentinel-2 Product Definition 

Document (cf. [RD-07]) and the physical layout modelled for the archiving purposes (i.e. the 

product data items – PDIs). 

Accordingly the OLQC operations are performed at different levels according to the 

production breakdown: 

PDI-level: this is the general case of processing the product data and metadata in 

order to retrieve and verify the quality information detected/contained at single PDI 







page 259 of 350 

level. This means that every PDI will be processed separately and the respective QI 

will be associated to it; 

Group of PDIs: some QI checks need more than one PDI (e.g. the set of image 

granules/tiles within a datastrip) and for this reason OLQC operations are envisaged to 

be applied to a group of PDIs. Furthermore, according to the Sentinel-2 Product 

Definition Document, if some granule/tile level QIs are common or shareable with 

others (i.e. at datastrip or orbit level) they will be stored as a single and common QI 

associated to the appropriate set of PDIs. 


The OLQC function shall be fully automatic. Overall, it shall run within very limited time and 

resources such as not to take more than 1% of the overall DPC processing budget. 


6.4.3.1 Definition & Configuration of the Quality Control Checks 

This scenario accounts for the operator-driven definition and configuration of the OLQC 

function by the specification of the quality controls to be performed to the PDGS generated 

production. The OLQC function can be supported by the DPC function with respect to the 

commanding and control of the test and rehearsal quality control activities devoted to the fine 

tuning configuration. 


1) The MPAC expert team defines the applicable quality control thresholds to be 

performed on the PDGS production (checks on the quality indicators); 

2) Accordingly the MPAC expert team supplies the OLQC configuration to the MCC 

function for distribution across the PDGS processing centres; 

3) The processing-centre operator undertakes the OLQC configuration and activates it. 

The use case of this operation scenario is the definition of the quality control checks that the 

OLQC function will apply. Such definition is done in the PDGS MPAC and then distributed to 

all the PDGS centres with data processing capabilities (e.g. the CGSs, PACs). 

6.4.3.2 Systematic Quality Control Checks 

This scenario accounts for the OLQC function autonomous quality control activities 

systematically performed on generated MSI products. The OLQC function will autonomously 

perform the QI computation for being appended as auxiliary data/metadata and the 

verification of the configured thresholds specified in the previous operation scenario. 


1) The OLQC function is invoked by the DPC function for quality control activities on the 

new production just generated by IDP function; 








page 260 of 350 

2) The OLQC function according to its configuration and provided product-type to be 

checked, verifies autonomously whether product relevant parameter-values and 

metadata are within threshold ranges; 

3) New generated Quality Indicators are autonomously stored as QI PDIs that might be 

included as product metadata according to configuration; 

4) The OLQC function autonomously generates a quality report on the verified products 

that summarises performed activities such as the quality checks, appended QI 

metadata, etc. 

6.5 Data Circulation (DC) Operations 


6.5.1.1 Data Circulation Concepts 

The PDGS DC function is responsible for performing file exchange operations between subsystem 

interfaces within and external to a PDGS centre. 

The DC function will support interface electronic and media data circulation according to the 

PDGS needs. PDGS DC function supports different “media” as any physical storage device 

pluggable to a computer (e.g. external USB HDDs, LTO equipment, etc). In addition it will be 

able to interface with the on-ground EDRS equipment for data multicasting. 

Data circulation operations performed either via electronic means or physical media will be 

identified and managed according to their nature. Electronic data circulation interfaces will be 

characterized by means of typical connectivity parameters such as hostname, protocol used, 

username, etc, while physical media interfaces will be identified from the physical media 

hardware devices to be circulated. 

The DC function allows defining data circulation rules for different type of files to be 

performed between two interfaces (source and target interface). It systematically performs 

data circulation required operations based on the new data available and the configured data 

circulation rules in a systematic manner and data-driven manner. 

Circulation activities are systematic and will limit operator intervention to the sole 

management of media volumes when required (e.g. load new media for data input, unload 

when complete, change media when full, etc). The DC activities will be triggered either: 

○ Automatically on availability of new files at an electronic input interface; 

○ Manually by the operator on reception of new media (e.g. by post mail) 

6.5.1.2 Horizontal Support to other PDGS functions 

The DC function supports all other PDGS functions when require circulating files (file retrieval 

and delivery operations) to and from other function interfaces internal or external hosted in 

other centres. 








page 261 of 350 


The following operation constraints are identified: 

○ Data circulation involving media will rely on mail courier services and therefore will not 

be used for critical timeliness data exchange operations; 

○ Data circulation operations via media will be automated to the maximum feasible 

extent, limiting operator intervention to the sole loading/unloading and labelling of tape 

media. 


6.5.3.1 Data Circulation Configuration 

The scenario accounts for the operator-driven configuration of the different instances of the 

Data-Circulation function. 

The DC function supports other PDGS functions allocated in the different PDGS federative 

centres and therefore may require a complete view for every single data circulation 

configuration according to the PDGS overall system. Therefore, in case the DC configuration 

requires coherency amongst the different PDGS centres, the configuration definition will be 

coordinated by the MCC function and as such, modelled as Mission Reference Files (cf. 

section 6.14). 

The operator will configure the DC according to the different ICDs for external interfaces data 

circulation and according data-flow needs for internal ones. 


1) Define and configure the different interfaces (media and electronic ones) according to 

applicable ICDs; 

2) Define the data circulation rules accordingly, associating the previously defined source 

and target interfaces (media or electronic), and identification of the type of data to be 

circulated; 

3) Depending on the scope of the DC configuration (i.e. PDGS global), the DC function 

configuration will be managed as Mission Reference Files by the MCC function (cf. 

sections 6.14.3.2 and 6.14.3.3). 

Some use cases are presented according to this operation scenario: 

PDGS deployment in a new centre - DC function will be configured accordingly 

(interfaces configuration + circulation rules definition); 

Implementation of an ICD change - DC function will be re-configured to adapt to new 

interface definition baseline; 

New product-type available - DC function will configure a new circulation rule for such 

new product. 








page 262 of 350 

6.5.3.2 Electronic Data Circulation 

This scenario describes the autonomous data circulation operations performed electronically 

(i.e. network connectivity not involving media usage). The electronic data circulation 

operations are performed systematically and automatically. They are triggered by a polling 

frequency on the source interface and performed autonomously without any operator 

intervention. 


1) The DC function retrieves autonomously from the configured source interface new files 

according to the data circulation rules. If required (data circulation post-retrieval file 

transformations configuration), file conversions are applied to the new files; 

2) The DC function delivers autonomously retrieved files to the configured target interface 

according to the data circulation rules. All completed data circulation operations will be 

reported (a data circulation report will be generated for the PDGS/MPA function). 


S2HKTM product data circulation from the PDMC to the FOS; 

Sentinel-2 products supply for ground link EDRS data circulation. The DC function will 

provide to the EDRS ground link gateway products to be circulated making use of 

EDRS capabilities; 

Between centres data circulation such as the mission reference files circulated from 

the applicable interfaces to the Payload Data Management Centre; 

Internal data circulation such as the mission reference files circulation in the PDMC 

from the MCC function to the RP function. 

6.5.3.3 Data Circulation via Media 

This scenario describes data circulation operations performed using different media devices 

(e.g. LTO, USB HDD, etc.). It will require operator intervention only for the media volumes 

management (i.e. media volumes preparation). Nevertheless, the data circulation operations 

are performed systematically. They are triggered by new data available in the source 

interface and performed autonomously without any operator intervention except for media 

volumes handling when required (i.e. media volume full replacement when writing, media 

volume already processed replacement when reading). The data circulation involving media 

requires presence of the DC function on both sides of the interface. 


1) The operator prepares the interface media volumes (for writing) in the originator DC 

function; 

2) New files are autonomously gathered from the source interfaces according to the 

configured data circulation rules. If required (data circulation post-retrieval file 

transformations configuration), file conversions are applied to the applicable files; 








page 263 of 350 

3) The files are autonomously copied into the media volumes. The operator is alerted for 

media volume replacement when current one is filled-up and a new empty one is 

required; 

4) The media volumes are sent to the destination data circulation function by mail courier; 

5) Operator connects / inserts received media volumes that activate the circulation 

actions. Then files are retrieved from media volumes; 

6) The retrieved files are placed in target interface exchange in-trays according to the 

configured data circulation rules. 

Some use cases are presented according to this operation scenario when no data availability 

timeliness constraints are declared: 

○ CGS light configuration with poor data repatriation capabilities may rely on the media 

circulation for the level-0 data supply to the PACs; 

○ Archive-to-Archive data circulation via media to fill-up a collaborative centre. 

6.6 Auxiliary Data Supply (ADS) Operations 


The ADS function responsibility is to provision the required auxiliary data to the PDGS for the 

products generation activities. 


As having a dependency on the different processing activities performed at the PDGS. 

Accordingly it inherits the applicable global production timeliness constraints with respect to 

every processing activity performed and shall therefore autonomously operate in advance. 


6.6.3.1 Auxiliary Data Supply 

This is the only single operation scenario of the ADS function. It accounts for the ADS 

function autonomous generation and supply of the PDGS required auxiliary data from 

external data-sources (e.g. meteorological data for atmospheric correction activities). ADS 

function autonomous generates required auxiliary data and together with the DC function 

autonomously makes it available to the applicable PDGS functions and centres via the MCC 

function (managed as Mission Reference Files). 

The use case of this operation scenario is the generation and supply of the auxiliary data 

available from external sources such as: 

○ IERS UT1-UTC time correlation data required for the L1 processing activities; 

○ ECMWF meteo data to be embedded in the Level-1 products; 









page 264 of 350 

○ GPS clocks and orbits needed by the POD function (e.g. could be supplied by the 

IGS); 

6.7 Precise Orbit Determination (POD) Operations 


The Sentinel-2 satellite spacecrafts will be equipped on-board with a GNSS receiver for 

position determination activities. Measurement Data from GNSS receiver, as well as the 

navigation solution computed on-board (PVT) will be made available as part of the satellite 

ancillary data on the TM packets from GPS-Receiver. Satellite ancillary data will be likely 

down-linked without on-board memory deletion to ensure coverage of the MSI down-linked 

data on the same pass. Such satellite ancillary data downlink strategy involves overlaps on 

the data retrieved at different passes. 

Once received at the ground stations, the GNSS data, as well as the navigation solution TM 

source packets (PVT) are extracted and processed to satellite ancillary data level 0 

product(s). 

The orbital information available in the navigation solution source packets (PVT) present an 

accuracy good enough for being used in the nominal operations for the generation of 

Sentinel-2 MSI science products. Nevertheless for contingency in case in case problems with 

navigation data arises (e.g. noisy data), a backup solution is foreseen with the Precise Orbit 

Determination function. 

The POD products will be generated on ground by the POD function and such are intended to 

be used as backup solution in case the Navigation Solution (PVT) presents a degraded errorbudget. 

The POD function is decomposed into the NRT-POD and Off-Line POD service that share out 

the different responsibilities. 

6.7.1.1 NRT-POD 

The NRT-POD is in charge of the Predicted POD products generation in support of the MSI 

processing activities with NRT timeliness in case of degraded accuracy of the on-board 

navigation solution. 

As such, the NRT-POD autonomously supplies to the DPC & IDP functions the Predicted 

POD products that can be potentially used for the MSI processing activities. 

6.7.1.2 Off-Line POD Service 

The Off-Line POD service is in charge of the Restituted POD products for better accuracy 

potentially used for re-processing activities. In addition the Off-Line POD service performs 

monitoring and assessment of the accuracy of the satellite on-board navigation solution and 

the POD products. 

The Off-Line POD service is integrated in the PDGS as an expert-team interfacing with the 

MPA function responsible of the monitoring of the satellite AOCS behaviour / accuracy and 








page 265 of 350 

the on-ground POD products generated (i.e. Predicted and Restituted POD products), which 

are relevant to the MSI processing activities according to the mission requirements in terms of 

geometric accuracy. 



○ POD function operations rely on adequate GNSS measurements and cannot be 

intended to generate orbit products in case of unavailability of the on-board GNSS 

receiver. 

○ POD activities result from an estimation process of an adequate GNSS measurements 

datasets that determine the position and the velocity of the Sentinel-2 satellite centre of 

mass. Depending on the parameterization needed for the required accuracy of the 

orbit determination, potential data gaps in the GNSS data may degrade the 

performance (typically when duration achieves a quarter of an orbit). Therefore 

significant GNSS data gaps due will result in the generation of degraded POD products 

or not generation at all depending on the gaps length. 


6.7.3.1 POD Configuration 

This scenario accounts for the operator-driven configuration of the Precise Orbit 

Determination function. The POD configuration includes amongst others required input files 

definition, auxiliary data provider interfaces definition, processing rules definition, etc. 

The following configuration steps can be performed in support of the other operation 

scenarios: 

1) Define and configure the different interfaces for inputs management (e.g. definition of 

the interfaces for the GPS clocks & orbits data gathering); 

2) Define the POD products generation rules by configuration of used input file-types, 

generation method (scheduled / data-driven), GNSS data gaps management, etc; 

3) Configure the analysis and reporting of the 

The use case of this operation scenario is the configuration of the different tasks performed 

by the POD function such as: 

Auxiliary inputs management. This is the definition of the interfaces plus applicable 

products gathered. 

Sentinel-2 predicted POD product generation configuration performed by definition of 

the triggering mode (scheduled or data-driven), inputs type, coverage, timeliness, etc. 

Sentinel-2 restituted POD product generation configuration performed by definition of 

the triggering mode (scheduled or data-driven), inputs type, coverage, timeliness, etc. 

Configuration of the on-board navigation and POD products reports by definition of the 

generation frequency, definition of the contents, delivery method, etc. 







page 266 of 350 

6.7.3.2 Input Data Gathering 

This scenario accounts for the autonomous gathering of the required input data for the POD 

products generation activities according to the POD configuration described in the previous 

scenario. 

The single step identified in this operation scenario is the POD function autonomous input 

data gathering, which is triggered in a scheduled driven manner (i.e. with a configured 

frequency) for polling of new inputs and subsequent retrieval. Such inputs are later on used 

during POD product generation activities. 

6.7.3.3 Sentinel-2 Restituted POD Product Supply 

This scenario accounts for the autonomous generation of the restituted POD products 

according to the POD function configuration. Restituted POD products generation is datadriven 

managed triggered by the received level-0 ancillary data products (i.e. on-board 

navigation solution). The POD function will regularly perform the computation of the restituted 

orbit solution in time for being used as auxiliary data for science data processing activities. 


1) The POD function autonomously gathers satellite level-0 ancillary data according to 

the POD configuration (see previous operation scenario); 

2) The POD function in data-driven basis (i.e. based on new L0 ancillary products 

gathered) triggers the restituted POD product generation; 

3) The POD function generates autonomously a restituted orbit product. Based on the 

configuration rules, the POD will autonomously select and make use of required input 

files; 

4) The generated POD file is autonomously made available to the PDGS and accordingly 

archived by the AI function. 

The use case of the presented operation scenario is the generation of MSI science products 

within the 24 hours timeliness constraint in case of contingency with the on-board navigation 

solution by usage of the restituted POD products supplied by the Off-Line POD Service 30 

minutes after. 








page 267 of 350 

6.7.3.4 Sentinel-2 Predicted POD Product Supply 

This scenario accounts for the autonomous generation of the predicted POD products 

according to the POD function configuration. The predicted POD products generation is 

schedule-driven for a generation at every orbit. 


1) The POD function in a schedule driven basis (i.e. every orbit) generates autonomously 

a predicted orbit product covering the next orbit plus [TBD] orbits according to the 

accuracy needs; 

2) Based on the configuration rules, the POD will autonomously select and make use of 

required L0 ancillary products and related input files; 

3) The generated POD file is autonomously delivered to the AI function for later use by 

the IDP function. 

The use case of the presented operation scenario is the generation of MSI science products 

within the 3 hours timeliness constraint in case of contingency with the on-board navigation 

solution by usage of the predicted POD products. 

6.7.3.5 Monitoring of the On-Board Navigation Accuracy 

This scenario accounts for the both autonomous and operator-driven activities performed for 

the monitoring of the satellite on-board navigation solution accuracy. The expert-team will 

perform different monitoring activities including the assessment of the POD products. 


1) Expert-team triggered activities for the assessment of the on-board navigation 

accuracy; 

2) Autonomous checks on the Satellite ancillary data (e.g. monitoring for potential gaps); 

3) Autonomous checks on the POD products (predicted and restituted products); 

4) Autonomous and on-demand reports generation containing the analysis results; 

5) Autonomous reports supply to the MPA function for later delivery to the POM. 

This scenario will allow assessing the on-board navigation solution accuracy with respect to 

the needs on-ground for the MSI processing activities. In addition, the POD products 

adequateness is assessed. 








page 268 of 350 

6.8 Archive & Inventory (AI) Operations 


6.8.1.1 PDGS Archive Concept 

The Sentinel-2 PDGS will archive all the MSI data during the mission operations phases (E1 

and E2 phases) plus 25 years after EOM. The PDGS will cope with different archive needs on 

data access timeliness, size storage needs, data availability, consumers requiring such data 

(end users, other PDGS elements, etc.). Accordingly, the PDGS archive concept is 

implemented through PDGS AI function and the LTA service function. 

More concretely the AI function will interface with the LTA service for data supply and retrieval 

of the long-term archived data. Thus the AI function will encapsulate the LTA service function 

to the other PDGS functions by direct interface. 

6.8.1.2 PDGS Archive Federated & Collaborative Concept 

6.8.1.2.1 Core PDGS Archive 

The Sentinel-2 PDGS Products Data Access and Long Term Data Preservation (LTDP) 

services will be ensured by the PDGS archive deployed in the different core centres. The 

PDGS archives will be deployed into the different centres following the PDGS federative 

concept whereby all individual archives contribute to the global PDGS archive. 

6.8.1.2.2 Collaborative Centre Archive 

In addition to the PDGS archive deployed into the different core centres, the collaborative 

centres will be able to mirror the archived data totally or partially. Such collaborative centres 

will enhance the global PDGS capabilities for data preservation (data mirrored in different 

centres) and data access (data available closer to the users based on regional use). 

Collaborative centres will be able to make use of media data circulation capabilities (import 

different media like tapes, external USB HDDs, etc) to ingest the data circulated from the core 

archives as a trade-off complement to digital network based circulation. 

6.8.1.3 Archived Elements 

The AI function will support the archive of data of different nature; this is the MSI data, 

satellite ancillary data, orbit data, auxiliary data for the MSI processing, HKTM, etc. Therefore 

the AI function will manage such different data in a homogeneous manner coping with every 

one specific characteristic. For instance, the MSI data will be archived on meaningful pieces, 

supporting effective retrieval and subsequent data processing strategies during their 

generation (e.g. parallelisation), used to compose the mission final products. The AI function 

minimum archive unit is defined as one or more product data items (PDIs) plus its associated 

metadata. 








page 269 of 350 


The AI function will be distributed amongst different PDGS centres supporting the data 

generation and products dissemination activities. The related archive configuration activities 

such as data retention rules on every centre will require synchronisation and coordination 

amongst the federated centres where deployed and therefore managed from the Payload 

Data Management Centre (PDMC). The PDGS/MCC function (cf. section 6.14) copes with the 

following aspects of the Archive distributed nature: 

Coupling between the AI function and the DPC function to support effective data 

processing strategies; 

 

 

 

Independence of each centre; 

Distributed responsibility; 

Central function of the Data Management Processes; 


6.8.3.1 Archive & Inventory Configuration 

This scenario accounts for the operator-driven configuration of the Archive & Inventory 

function. 

The AI function configuration is managed by the PDGS/MCC function (see Mission 

Configuration Control Operations section). As the AI function is deployed in several centres, 

the data retention policies may not be the same for all of them (e.g. core and collaborative 

centres may differ on the managed products, archive retention timeliness, etc.). Accordingly 

the MCC function releases the official archive configuration for every centre hosting the AI 

function. 

The POM will provide the full data retention picture for the overall PDGS then decomposed 

into individual data retention rules for every archive centre. The AI function archive rules 

configuration for each centre includes among others the following items: 

Archived mission, ancillary, auxiliary, HKTM, products type; 

Metadata inventoried for each archived product type; 

Retention rules based on products ageing or / and metadata parameters like 

geographic parameters; 

Clean-up rules such as deletion or circulation to long term archive service based on 

rules as for retention; 

Circulation rules based on metadata (e.g. geo-location coverage, cloud cover 

percentage, etc.). 


1) The MCC function produces a new AI function configuration; 

2) The AI function configuration is circulated to the archive centres; 








page 270 of 350 

3) The operator sets up the AI function according to the configuration received. 


A new collaborative archive centre with is incorporated to the PDGS federation. Thus 

the data retention policy map for that centre and others is updated according to the 

overall PDGS objectives; 

A change on the data retention policies decided by the POM (e.g. The POM may 

decide to increase data retention time of transient stored products, for instance the 

level 1a products or on the contrary limit it according to defined mission objectives. 

6.8.3.2 Data Archive & Inventory 

This scenario accounts for the autonomous data archiving activities performed by the AI 

function according to configuration. The AI function works in a data-driven manner fed by 

different PDGS functions; for instance the DPC and DC functions feed the archive with new 

data resulting of the processing and data circulation activities respectively. The AI function 

performs all the archiving and inventory activities automatically unattended based on new 

inputs. 

Theses are the main operations performed during the archival of new data: 

1) The AI function autonomously detects the new data to be archived in the in-tray(s); 

2) The AI function autonomously archives and inventories the new data according to the 

configured archive rules; 

3) The relevant metadata of new archived data is extracted and inventoried accordingly. 

The archive and inventory operations integrity must be ensured preventing for any data 

loss due to errors, missing disk space, etc; 

4) The AI function autonomously notifies and updates the PDGS/DAX function with the 

configured metadata of the new archived data; 

5) The AI function autonomously reports on the performed operations (archival, removal, 

extraction, inventory, etc) to the PDGS/MPA function (through the MCC function). 


New MSI production (e.g. level-0 production) generated by the DPC function is 

archived; 

Received X-Band HKTM data is archived (i.e. S2HKTM products); 

Auxiliary products (e.g. POD products) received via DC function are archived for later 

usage; 

6.8.3.3 Discovery of Archived Data 

This scenario accounts for the AI function autonomous archived data discovery capabilities 

offered to other PDGS functions (i.e. DPC and DAG functions) to provide a view on the 

archived PDIs. The data discovery operations are performed locally to the AI function 

inventory according to the defined query interface. 








page 271 of 350 

This scenario is always initiated by the other PDGS functions when searching for archived 

product data items based on some inventoried data (e.g. data-type, time segments, etc). The 

query interface relies on the inventory metadata associated to every product data item 

archived. Accordingly the AI function supports queries based on the inventoried metadata. 


1) A PDGS function generates a query and passes it to the AI function; 

2) The AI function processes the query request, thus it checks syntax & semantics with 

respect to the defined interface. Once the request has been validated, the AI function 

based on the metadata inventoried, looks for the matching PDIs; 

3) The AI function generates the query result (i.e. the list of product data items matching 

the request) and provide it to the originator request according to defined query 

interface. 


The DPC function queries on the required PDIs for a given processing job. By the 

query result, the DPC function knows whether the required data for such processing 

job is available; 

The DAG function queries to the AI inventory for some product data items availability 

according to the user requests. 

6.8.3.4 Archived Data Retrieval 

This scenario accounts for the autonomous data retrieval activities as requested by other 

PDGS functions. 


1) The DPC function requests for required input data for a given processing job according 

to the data retrieval interface; 

2) The AI function processes the retrieval request, validates by checking syntax & 

semantics; 

3) The AI function leaves the PDIs on the defined out-tray. 

The main use cases are presented according to this operation scenario: 

The DPC function relies on the AI function for the management and high performance 

data retrieval operations needed for the subsequent processing activities. In this 

scenario, due to the required archival/retrieval operations performance, the DPC and 

the AI function interact locally through a specific dedicated interface; 

The DAG function requests for the archived product data items needed to build a userproduct. 

The DAG function can interact remotely with the AI function due to lower data 

retrieval timeliness constraints with respect to the processing activities. 








page 272 of 350 

6.8.3.5 Archived Data Retention & Clean-up 

This scenario accounts for the autonomous archived data retention and clean-up operations. 

The AI function according to the defined archive rules configuration, autonomously performs 

the required clean-up operations, data circulation operations (e.g. data circulation to other 

centres), etc. 

The data retention policy is part of the archive rules configuration. Accordingly it is possible to 

define the archive time period (i.e. according to data ageing) for each data-type managed. 


1) The AI function verifies autonomously for new applicable archive data retention / cleanup 

rules; 

2) The AI function triggers the matching rules. The clean-up activities remove the 

appropriate PDIs and all or part of the associated metadata. 

One use case of this operation scenario is the L1A product data items archive during a limited 

time period (e.g. archive such products for two weeks for expert evaluation). 

6.8.3.6 Data-Driven Archive-to-Archive Data Circulation 

This scenario accounts for the autonomous archive-to-archive data circulation operations. 

The AI function autonomously makes available to the PDGS/DC function the new archived 

data required for data circulation operations according to the configuration. 

Finally it is the DC function that performs in last instance the delivery of the data to the 

configured interfaces. 


L0 production generated and archived in a given ground-station can be circulated to 

another processing centre to continue with the level 1 processing activities; 

The archived MSI production in a centre with the LTDP role will be systematically 

circulated to the PDGS long term archive service. 

6.8.3.7 On-Demand Archive-to-Archive Data Circulation 

This scenario describes the operator-driven archive-to-archive data circulation activities 

performed punctually according to different motivations (e.g. specific data mirroring into other 

archives, a bulk of data circulation to support specific calibration campaigns, etc). 

The AI function will offer to the operator an HMI for the selection of the archived data for the 

circulation activities. As explained in the previous scenario, the AI function relies on the 

PDGS/DC function to perform the data circulation operations (i.e. electronic or media data 

circulation). 


1) The operator selects via the AI function HMI the archived product data items to be 

retrieved; 








page 273 of 350 

2) The AI function retrieves the selected product data items and places them in the datacirculation 

out-tray; 

3) The DC function autonomously circulates the data to the interfaces. 

6.8.3.8 Bulk Archived-Data / Inventoried-Metadata Export 

This scenario accounts for the operator-driven selected archived data or/and inventoried 

metadata export. Accordingly the operator based on the AI function HMI defines the selection 

of the data / metadata to be exported (typically can be a defined time-window, product-type, 

etc.) and triggers the action. 

The main use cases envisaged for this operation scenario are: 

Bulk metadata export of one archive centre to feed the DAX function in case of 

contingency; 

 

Bulk archived data export to be ingested into a different AI function instance; 

6.8.3.9 Maintenance 

This scenario accounts for some operator-driven and other autonomous maintenance and 

special operations activities to ensure the correct behaviour of the function and ensure the 

required performances (for archival, retrieval, query, etc). 

The following actions can be performed as part of this operations scenario: 

Data relocation operations. When some storage HW needs replacement (e.g. due to a 

disk failure), the operator triggers for the data relocation activities to the new HW; 

Storage capacity enhancements. The operator adds and configures new HW elements 

to improve AI function storage capabilities; 

 

Inventory metadata index recreation. Performed autonomously to improve the AI 

function query and retrieval performances through metadata query parameters; 

Data backup activities. Backup activities include capabilities to dump/export relevant 

data to other functions (i.e. PDGS/DAX function that mirrors the AI inventory content); 

 

Data restore activities on contingency or on mirror archive centres; 

6.9 Data-Access Index (DAX) Operations 


6.9.1.1 Centralised Data Index 

In opposition to the PDGS archives that can be deployed in several centres, the Data-Access 

Index function (DAX) is a centralised function and concentrates the reference to all the 

products availability thorough the different archives instances. Therefore the index acts as 








page 274 of 350 

single access point to all the PDGS archived content keeping the necessary references to the 

archive sources. 

6.9.1.2 Data Index Composition 

The DAX function will host all the required information needed to support the data-location 

requests and assemble the Sentinel-2 products. Such information is the hereafter called “data 

indexes” and it is generated from the distributed archives inventoried metadata. 

The data indexes encapsulate the PDGS federated nature and manage the potential 

redundancy of the archived data available in different archives: 

The DAX function consolidates the metadata, identifying potential redundancies (same 

product data available on different archive centres), and normalizes it as part of the 

data indexes generation activities; 

The DAX function keeps trace to all the sources (i.e. the different archives) available to 

support the data retrieval operation of every component of the product data. 

The data indexes will make use of different product components metadata and will typically 

include: 

Product-type 

Sensing-time coverage 

Archive sources (data-sinks location) 

The supported data discovery requests based on the data indexes can be classified in: 

Data availability request. A view on the available data according to the request criteria 

is provided hiding data redundancies if any; 

Data location request. References to the data physical location within the archives are 

provided to support data retrieval activities. 

Therefore the data indexes will replicate as required the metadata inventoried in the 

distributed archives to support queries on the location of the product components archived on 

the different centres. 


The following operation constraints have been identified: 

The DAX function will be able to operate in hot-redundancy between remote centres 

(with a DAX function backup instance); 

As a federation function, the DAX function will systematically interface to newly 

deployed archives centres and in consequence assume additional indexing load; 

The DAX function will be able to support a growing number of simultaneous request in 

result of a potential increase of data-access requests; 

The DAX function will be centrally deployed in a PDGS single access point that will be 

mirrored for redundancy. 








page 275 of 350 


6.9.3.1 Data Indexes Configuration 

This scenario stands for the operator-driven required configuration activities prior to the 

function nominal operations. As such, the function configuration items, likely archive sources, 

metadata extraction/processing parameters, etc are defined and configured providing in 

addition a view of the whole PDGS archive map, with all the archive centres and the 

associated data-sinks. 

Additional configuration activities are covered within this scenario as for instance, the 

reception and activation of required auxiliary files (i.e. orbit ephemeris) for the data indexes 

generation. 

6.9.3.2 Population of the Data Indexes 

This scenario accounts for the autonomous data indexing activities according to the new 

archived product components (archived Product Data Items - PDIs -). 

The DAX function manages (i.e. as such it creates, refreshes, consolidates, sorts) the data 

indexes on all the PDGS archived data. 


1) On every new PDI archived (or removed), the AI function extracts the relevant 

metadata and generates an “archive report”; 

2) The archive reports are made available to the DAX function by the MCC function; 

3) The DAX processes the archive reports and the associated metadata. The data 

indexes are updated accordingly verifying potential duplications of the same product 

component; 

4) Storage of the browse images of the associated metadata as supplied by the AI 

function. 

All the archive updates are processed in order to maintain an up-to-date index of all the 

available production. The data indexing activities cover as well the data archived by the LTA 

service function. 

6.9.3.3 Consolidation of the Data Indexes 

This scenario accounts for the autonomous consolidation activities of the content of the data 

indexes. 

The DAX function consolidates the data-indexes by identification of the potential duplications, 

rationalise the storage of the metadata and browse images. As part of this operation scenario, 

the DAX function notifies to the PDGS front-end services the new available data. 










page 276 of 350 

1) On schedule basis (e.g. every 15 minutes), the DAX function consolidates the indexes 

by sorting on sensing-time, identification of duplications, relocation of the older data, 

etc; 

2) The DAX function detects the new indexed product components (not previously 

archived in any other centre) and extracts the relevant metadata and the associated 

browse image; 

3) The DAX function notifies to the PDGS Front-End Services (i.e. the MMUS and OLIB 

functions) the availability of the new product components. 

Some relevant use cases are presented according to this operation scenario: 

The DAX function feeds the MMUS function with the metadata and browse images of 

the new product components available. The MMUS function catalogues the Sentinel-2 

production in support of the product discovery activities performed by the user; 

The DAX function feeds the OLIB function with the TCI metadata and associated 

browse images. 

6.9.3.4 Coverage Reports Supply to the CDS/SCI 

This operation scenario stands for the autonomous generation of the coverage reports 

according to the CDS/SCI ICD [RD-11]. 

This scenario can be seen as a specialisation of the previous one in which, the DAX function 

autonomously notifies to the CDS/SCI the new product components available at the PDGS 

data-sinks. The DAX function supplies the information and generates a unique timeline that is 

formatted according to the SCI coverage report ICD to notify on the new production available. 

6.9.3.5 Product Data Location Requests 

This scenario accounts for the autonomous management and response to product data 

location requests based on the PDGS data indexes. This scenario is always initiated by other 

PDGS functions when searching for the location of the PDGS archived data according to 

some criteria. 

The DAX function returns the physical location of the product data present in the different 

archives in support of the data-access activities (as requested by the DAG function). 

The DAG function, when used by the Front-End Services (i.e. the MMUS and OLIB functions) 

for the data-access activities, will request to the DAX function the location of the desired 

product data items. The MMUS and OLIB functions catalogue the Sentinel-2 production but 

rely on the DAG function for the product location requests to the DAX and subsequent dataaccess 

activities. 

6.9.3.6 Bulk Metadata Harvesting and Indexes Re-Generation 

This scenario accounts for the operator-driven metadata harvesting from the archive centres. 

The operator collects manually the archive contents metadata (i.e. via network or specific 

media delivery) from the AI function and manually triggers the ingestion and processing into 

the DAX function. 







page 277 of 350 

As such, the DAX function processes the metadata and re-generates / updates the data 

indexes accordingly (as explained in population scenario). 

The main use case for this scenario is in case of contingency to re-populate and / or regenerate 

the data indexes. 

6.9.3.7 Maintenance 

This scenario accounts for the required maintenance activities in support of the function 

nominal operations. This is a mixed automatic and operator-driven scenario to ensure the 

correct performances when supporting the data-location requests. 

The PDGS/DAX function manages important volumes of data as part of its nominal 

operations (metadata ingestion, indexing, querying, etc). Therefore the required function 

capacities enhancement (mainly on data storage and query access timeliness) along the 

mission life-time is considered. 

The following activities have been identified for maintenance: 

 

 

 

 

 

Data relocation operations (e.g. due to a disk failure) 

Storage enhancements to cope with increasing data along mission life 

Data indexes sorting and recreation 

Data backup activities 

Data restore activities 

6.10 Data-Access Gateway (DAG) Operations 


6.10.1.1 Single Data-Access Point towards the Users 

The Data-Access Gateway (DAG) function is in charge of providing a single data-access point 

towards the PDGS distributed data-sinks. As such, the DAG function, supported by the DAX 

function, encapsulates the distributed archiving topology towards the Front-End Services 

such as the MMUS and the OLIB functions acting as central hubs for user data-access 

activities. 

Accordingly, the DAG function performs the download of the product-components spread 

through the archive centres and the subsequent user-product reconstruction at the user base. 

6.10.1.2 Client/Server Approach 

In order to achieve the single data-access point towards the users, it is envisaged a 

client/server approach with the following responsibility assignation: 

‣ DAG function server side, coupled with the PDGS data-sinks; 








page 278 of 350 

‣ DAG function client side, supporting the product-component download activities and 

user product reconstruction. 

The DAG function server side is strongly coupled to the PDGS data management functions 

(i.e. the AI and DPC functions) and as such it performs the following activities: 

 

Retrieve the required product data from the different archives 

Trigger the user requested hosted-processing activities 

Transmit the retrieved/processed data to the client side 

The DAG function client side is focused on the final user activities to get the desired Sentinel- 

2 image products, as such as the following activities are encompassed within the client: 

Connectivity towards the different centres 

Hosted-processing user requests management 

User-Products retrieval by product components download and subsequent build-up 

6.10.1.3 Interfaces to the Front-End Services 

To a high level, the users will perform the following operations as part of the data-access 

activities: 

‣ Product discovery operations based on the catalogued product data; 

‣ Subsequently products download operations. 

The Front-End Services are responsible of the catalogue of the Sentinel-2 product data, being 

the MMUS function the one that catalogues all the Sentinel production (cf. section 6.11) and 

the OLIB function (cf. section 6.12) the function that catalogues the Sentinel-2 True Colour 

Images. The product catalogue activities will support the Users product discovery requests 

including the product pre-visualisation, filter on the metadata, etc. 

After selecting the product(s) (through the MMUS or OLIB functions) interested in, The user 

will nominally request for the subsequent product download at the user base. The product 

download capabilities are responsibility of the DAG function as explained in the previous 

sections encapsulating to the user the PDGS distributed nature. 

Accordingly the DAG client side will interface with the MMUS and OLIB function to receive the 

user requests for product download based on the previous data discovery activities performed 

by the user. Therefore the DAG client side will implement the download request interface as 

defined mainly by the MMUS function. 


The DAG function operations must cope with a currently unknown and potentially evolving 

number of users of the Sentinel-2 production. As such, the function design and architecture 

must be able to efficiently use the network resources available and scale according to the 

new data communication capabilities. 








page 279 of 350 

Being one function that is directly attached to the user (through its client-side), the offered 

performances (relying on the network capabilities) and overall the function robustness and 

reliability must be optimal for the support of the Sentinel-2 downstream services. 


6.10.3.1 Product Download 

This scenario describes how the User-Products are requested and downloaded through the 

DAG function. 


1) The Users according to previously performed product discovery activities through the 

MMUS function (cf. section 6.11.3.5), identifies the product(s) interested in (i.e. spatial 

coverage, temporal coverage, spectral bands, metadata, product-type, desired format, 

etc); 

2) The MMUS function (cf. section 6.11.3.6) conforms the product request and supplies it 

to the DAG function (client side); 

3) The DAG function parses the request and invokes the DAX function to locate the 

required product items according to the user-defined download options (e.g. selection 

of spectral bands, metadata elements, etc); 

4) Based on the location of each item, the DAG function (client side) requests the items 

to each distributed server; 

5) The DAG function (server side) authorises the download via the MMUS function, then 

retrieves the required PDIs from the different archives and makes them available for 

download; 

6) The DAG function (client side) performs the correspondent PDI download activities; 

7) The DAG function (client side) builds up the user-product as requested performing 

additional product transformation activities (e.g. product consolidation, assembly and 

packaging) on the downloaded items as relevant based on the defined download 

options. 

6.10.3.2 User Hosted-Processors Commanding 

This scenario stands for the commanding of the hosted-processing activities as triggered by 

the user via the MMUS function. 

The DAG function interacts on one side with the MMUS function and routes the requests to 

the PDGS/DPC function which executes the processing (cf. section 6.2.3.6). 


1) The Users according to offered mechanisms by the MMUS function (cf. section 

6.11.3.8), supplies the hosted-processing processing parameters to the DAG function 

(e.g. input data, processing parameters, etc); 








page 280 of 350 

2) The DAG function parses the request and selects the processing centre by making 

use of the DAX function to optimise the hosted-processing activities based on the 

physical location of the items to process; 

3) The DAG function triggers hosted-processing activities by making use of the DPC 

function interface(s); 

4) During the processing, the DAG function tunnels the monitoring and control flow 

between the MMUS client and the DPC server(s); 

5) At the term of the processing, the DAG function collects the hosted-processing output 

products and makes them available for download; 

6) The MMUS function is invoked to trigger the effective download of the products. 

6.11 Multi-Mission User Services (MMUS) Operations 


6.11.1.1 Client/Server Approach 

The MMUS function follows a client/server approach as described in [RD-44]. The MMUS 

function client side is in charge of handling the user interactions meanwhile the server side 

implements the logic function behind the scenes. 

The MMUS function client-side, as explained in the following sections, supported by other 

PDGS functions, represents the PDGS front-end towards the users. As described in [RD-44], 

the MMUS function, the MMUS function client-side is separated into: 

‣ Web Browser Client: supporting the product discovery request by the user and 

subsequent product download; 

‣ Download Manager: supporting the automation of the products download and hostedprocessing 

requests. 

The MMUS function server side, interfaces with other PDGS functions for the autonomous 

reception of the relevant information to conform the Sentinel-2 product catalogue. As 

described in [RD-44], the MMUS function server side is separated into several components 

here highlighted the ones with direct interaction with the other PDGS functions: 

‣ ngEO-Feed: for the autonomous collection of the Sentinel-2 catalogue data (products 

metadata and associated browse images); 

‣ ngEO-Catalogue: to catalogue the Sentinel-2 production based on the supplied 

metadata; 

‣ ngEO-Browse Images Archive: to archive the Sentinel-2 browse images of the 

available production; 

‣ Gateway towards the SSO infrastructure for the users authorisation and 

authentication; 









page 281 of 350 

‣ Gateway towards the CDS/DAIL in support of the HMA cataloguing and ordering 

service. 

6.11.1.2 Role Split with the DAG Function 

The MMUS function catalogues the Sentinel-2 production in order to support the product 

queries performed by the users and subsequently offer an on-line download interface. 

As explained in section 6.10.1.3, the MMUS function will make use of the DAG function to 

perform the actual downloads. 


The MMUS function, although it has a multi-mission nature, it must cope with some mission 

specific design drivers in order to be able to perform the related product presentation and 

subsequent management of the product download activities. More concretely, the MMUS 

function will manage the Sentinel-2 product breakdown strategy (i.e. product decomposition 

into granules and tiles, cf. [RD-07]) as part of the catalogue activities and subsequent product 

discovery and download activities triggered by the user. 


6.11.3.1 Sentinel-2 Users Management 

This operation scenario stands for the operator-driven (administrator level) management of 

the Sentinel-2 users including definition of profiles, users pre-registration activities, accessleverage 

definition, etc. 

Accordingly the MMUS function operation will administrate the access to the users, and their 

related authentication and authorisation activities. 

6.11.3.2 Sentinel-2 Datasets Management 

This operation scenario stands for the operator-driven (administrator level) management of 

the Sentinel-2 production datasets (i.e. product collections) offered to the users. As part of 

this scenario, it is comprised the definition, publishing, update and removal of the different 

Sentinel-2 datasets. 

This scenario includes the appropriate definition of the access leverage to such datasets 

according to the different user profiles. 

The MMUS function operator will define the Sentinel-2 datasets and the access leverage 

according to the HLOP covering typically: 

‣ Datasets definition based on time-window and geographic coverage; 

‣ Datasets definition based on the cloud-cover percentage; 

‣ Datasets definition based on the product-type; 

‣ Datasets envisaged for the expert and cal/val users. 







page 282 of 350 

6.11.3.3 Users Self-Registration, Account Activation, Login and Preferences 

This operation scenario stands for the user-driven activities that are prerequisite to the data 

discovery and product downloads including the following ones: 

‣ User self-registration: based on the MMUS configuration with respect to the different 

profiles and user management configuration; 

‣ Account activation: in case of previously created predefined user accounts (as shown 

in previous scenario), the user activates it according to the offered authentication 

mechanisms; 

‣ User login: as the first step previous to the product discovery and download activities; 

‣ User preferences management: according to the profile grants, the user manages 

different preferences; 

‣ User subscription to the desired and authorised datasets (i.e. shopcart management). 

The user, by making use of the MMUS client-side (i.e. web browser), triggers the previously 

described activities. 

6.11.3.4 Catalogue of Sentinel-2 Product-Data 

This operation scenario stands for the autonomous catalogue of the Sentinel-2 Product Data. 

The MMUS function processes the archive centres updates in order to catalogue the new 

production available, and as such, supporting the subsequent product discovery activities. 


1) The MMUS function ingests the new Sentinel-2 archived production metadata and 

browse images (by the ngEO-Feed component) as provided by the DAX function; 

2) The new metadata is consolidated with the already metadata catalogued; 

3) The new browse images are archived; 

4) The catalogue content is consolidated; 

5) The contents of the Sentinel-2 datasets (product collections) are updated according to 

the new catalogued metadata. 

This scenario is a pre-requisite to the product discovery and downloads activities triggered by 

the user. The MMUS function consolidates the metadata information used to populate the 

catalogue and as such, it encapsulates the Sentinel-2 product physical breakdown details 

(granules and tiles) and the product components distributed location on the different archive 

centres, offering to the different users homogeneous Sentinel-2 “end products”. 

6.11.3.5 Product Discovery 

This operation scenario stands for the user-driven activities for the Sentinel-2 products 

discovery. The user, through the MMUS function client-side (i.e. web browser), looks for the 

authorised available Sentinel-2 production. Accordingly, the MMUS function offers amongst 

others the following product discovery capabilities: 








page 283 of 350 

‣ Navigation through the authorised datasets; 

‣ Search of products according to the user-driven filtering requests; 

‣ Specific Sentinel-2 filtering capabilities based on the products cloud-coverage; 

‣ Product pre-visualisation capabilities based on the archived browse images; 

‣ Geo-reference of the browse image and display through Web Map Servers; 

‣ Visual inspection of the associated product metadata; 

‣ Product selection and ordering based on the previous product discovery activities. 

This operation scenario allows the user to discover the available production according to the 

authorised access leverage. Subsequently, the user will be able to request the desired 

production for download at the user-base. 

6.11.3.6 Product Download 

This operation scenario stands for the user-driven activities for product download at the userbase. 

Once the user has identified the desired production (cf. previous scenario), it requests it 

for product download. 

The MMUS function relies on the DAG function for the product-component (granules/tiles) 

download activities from the archive centres and subsequent end-product reconstruction 

activities (cf. section 6.10.3.1). 


1) The user via MMUS client-side (i.e. web browser) request for download the desired 

production as identified by the product discovery activities; 

2) The MMUS function verifies the user access-leverage and authorises the request; 

3) The MMUS function conforms a request according to the defined interface and passes 

it to the DAG function client side (i.e. a plug-in to the web browser) that performs the 

products components download; 

4) The DAG function client side, once all the product components have been 

downloaded at the user base, reconstructs the user-product as requested. 

In this manner, the (registered) users can download the authorised Sentinel-2 products. 

6.11.3.7 Subscriptions for Automatic Product Download 

This operation scenario stands for the automatic product download at the user-base. By 

usage of the MMUS function (ngEO Download Manager), the user is able to automatically 

receive the desired Sentinel-2 products. 


1) The user subscribes to the desired and authorised datasets (i.e. shopcart 

management); 








page 284 of 350 

2) According to the new production available for a given dataset, the MMUS function 

generates the product requests downloads; 

3) The MMUS function supplies the product requests to the download manager; 

4) The download manager autonomously performs the product download and user 

product reconstruction as described in the previous scenario (using the DAG function 

client). 

Through the MMUS function download manager, the users are able to automate the Sentinel- 

2 product download activities. For instance, the GMES Service Projects could subscribe to 

specific datasets as defined by HLOP, and automatically retrieve the required Sentinel-2 

products. 

6.11.3.8 Hosted-Processing Management 

This scenario stands for the user-driven requests for hosted-processing activities. The MMUS 

function offer to the user an appropriate interface to request specific production supplied ondemand 

by the PDGS hosted-processors and retrieve the resulting products. 

The latency for the hosted-processors output retrieval is not immediate and such outputs 

could be available after sometime (hours/days). Therefore, the MMUS function routes the 

hosted-processing requests through its download manager for the monitoring of the submitted 

hosted-processing requests. 


1) The user requests for a specific processing (hosted-processor) request according to 

the MMUS function offered interface; 

2) The MMUS function conforms a hosted-processing request according to the defined 

interface and passes it to the user client side – the MMUS download manager -, that 

relies on the DAG client side (as a plug-in to the download manager) for the 

submission of the hosted-processing request to the DPC function; 

3) The download manager, via the DAG client, monitors the hosted-processing request 

and when the outcome is available, it downloads it at the user-base. 

The generation of the prototype Level-2A products can be triggered via the MMUS function 

hosted-processing interface. 

6.11.3.9 First-Line Support-Desk 

This scenario stands for the first-line Support-desk offered via ESA’s MMUS towards 

Sentinel-2 users requiring support on generic or Sentinel-2 specific matters. The incoming 

support requests, to be managed via a ticketing database system, can be classified as either: 

○ Generic support regarding the Sentinel-2 mission, its services and products (e.g. 

quality, availability, timeliness, etc), access methods and interfaces, etc; 

○ Expert Support for investigation of anomalies. 

On any request submitted by the users, the request will be registered, characterised and 

classified as per the above. In case of generic support resuests, ESA’s MMUS Support-Desk 









page 285 of 350 

operator will directly process the request. In case of Expert support requests, the First-Line 

operator will route the request to the Second-Line Support-Desk operated by the MPA 

function (see section 6.16.3.4 - Second-Line Support-Desk ) and collect the investigation 

conclusions provided in return. 

Every support request processing ends with the recording of the concluding response into the 

ticketing database and the triggering of a response notification to the request originator. 

6.11.3.10 Product Discovery and Download Statistics 

This scenario stands for the generation of statistics and reports on the product discovery and 

downloads activities performed by the user. The MMUS function (using the datawarehouse 

component) will be able to generate and store statistics that summarise the most demanded 

product discovery and product download activities requested by the users. 

This scenario allows the POM to have a comprehensive view on the most demanded product 

data, the most successful product collections, the amount of data supplied, etc. In this 

manner, the POM could define into the HLOP different product collections (i.e. datasets) 

according to the usage statistics. 

6.11.3.11 CDS/DAIL Cataloguing Service 

This operation scenario implements the HMA catalogue service offered towards the 

CDS/DAIL according to the applicable ICD [RD-13]. 

6.11.3.12 CDS/DAIL On-Line Data-Access Service 

This operation scenario implements the HMA ordering service offered towards the CDS/DAIL 

according to the applicable ICD [RD-14] for on-line data-access. 

6.12 Multi-Mission User Services (OLIB) Operations 


As part of the Sentinel-2 data-access services (cf. section 4.5.2.2.3), the PDGS will provide 

anonymous internet on-line access to Sentinel-2 imagery as True Colour Images (TCI). This 

service is focussing on the distribution of elaborated digital images rather than scientific 

products with the objective of sharing Sentinel-2 imagery with the general public. 

Access to the images will be provided through a client application (web browser with 

additional plug-ins) offering the image navigation and visualisation capabilities. 


As the main objective of the OLIB function is to promote and foster the usage of the Sentinel- 

2 imagery, the main operational constraint identified is the own function availability towards 

the users and good performances at the user-base when navigating through the available 

true-colour images. 







page 286 of 350 


6.12.3.1 True Colour Images Database Build-Up/Update 

This operation scenario stands for the autonomous creation and update of the Sentinel-2 true 

colour images database to be published towards the users. 

The OLIB function creates a catalogue based on the available true colour images production. 

This catalogue encapsulates the Sentinel-2 products components breakdown (i.e. the TCI 

product data items) and their archive location in the PDGS. 


1) The OLIB function autonomously gathers and processes the new available metadata 

and browse images supplied by the PDGS/DAX function; 

2) The new metadata is consolidated and according to the TCI database scope, the 

relevant TCI product data items are downloaded by use of the PDGS/DAG function 

(client side); 

3) The OLIB function consolidates the downloaded TCI product data items and updates 

caches areas for streaming and download. 

This scenario aims for grouping all the OLIB function server side activities in preparation of 

the images publishing towards the users. 

6.12.3.2 True Colour Images Streaming 

This operation scenario stands for user navigation activities on the published Sentinel-2 True 

Colour Images (TCIs). Triggered by the user interactions (i.e. navigation on a map) on the 

TCI Browser (i.e. OLIB client side), the OLIB function streams the required TCIs. 


1) The TCI Browser connects to the OLIB function server side for presentation of 

available imagery to the user; 

2) The TCI Browser can optionally support the images presentation based on the local 

cached images from previous connected sessions; 

3) The user through the TCI Browser navigates and visualises the desired map areas. 

Accordingly, the OLIB function server side streams the required imagery (e.g. via 

JPIP) to the TCI Browser; 

4) The TCI Browser caches the received imagery to minimize the imagery requests to 

the server side and optionally support “off-line” navigation activities. 

6.12.3.3 True Colour Images Download 

This operation scenario stands for the Sentinel-2 True Colour Images (TCIs) download by the 

user. Derived from the previous operation scenario, the user may request to download the full 

resolution TCIs (e.g. via a HMI interaction such as a polygon definition) that have been 

previously streamed and currently showed in the TCI Browser. 








page 287 of 350 

The TCI Browser identifies the required product-data items according to the OLIB function 

catalogue information and then relies on the DAG function (client-side) for the subsequent 

product data items download activities. 

6.13 Long-Term Archive (LTA) Operations 


The LTA service function is responsible of the long-term data preservation service 

implementation ensuring all mission data is safely stored at least 25 years after end-ofmission. 


The LTA service function operations will be performed through different distributed centres. 

Such operations involve a high data load plus a long time duration operations. 

Perform reliable archive and inventory in at least two redundant European sites for 

Sentinel-2 mission lifetime during at least 25 years after the end of space-segment 

operations; 

Make use of cost-effective storage solutions. To cope with the Sentinel-2 very high 

volume of data in an effective manner, LTA service function will make use of on-line, 

near-line and off-line storage mechanisms according to different products retrieval 

latency based on their ageing. 


6.13.3.1 Data Archive & Inventory 

This scenario accounts for the autonomous data archiving and inventory performed by the 

LTA service function. 


1) The LTA service function is fed by the AI function and work in a data-driven manner; 

2) The LTA service function archives the received product components and inventories 

them accordingly; 

3) On the other side, the AI function inventories as well all the data archived by its 

associated LTA service function. 

On the PACs (Processing & Archive Centres) with the long-term data preservation role 

assigned, the AI function instance locally deployed has associated a Long Term Archive 

service function to accomplish such role. Accordingly, the AI function autonomous supplies to 

its associated LTA service function, the data (products, auxiliary data, etc.) flagged for longterm 

preservation including all the data relevant to reproduce any MSI processing in the 

future. 








page 288 of 350 

6.13.3.2 Archived Data Retrieval 

This scenario accounts for the archived data retrieval from the LTA service function according 

to the offered interface. 


1) The AI function requests the retrieval of some archived data by the LTA service 

function; 

2) The LTA service function retrieves the requested data and supplies it to the AI function 

according to the settled interface. 

On the PACs (Processing & Archive Centres) with the long-term data preservation role 

assigned, the AI function instance locally deployed requests for (old) data archived in the 

associated LTA service function according to its needs (e.g. for data-access). The AI function 

archives the data supplied by the LTA service function (the retrieved data is now available online 

through the AI function). 

6.13.3.3 Bulk Data Re-processing 

This scenario accounts for the operator-driven MSI bulk data re-processing according to the 

HLOP (e.g. one year data-reprocessing with the most recent version of the IPF). 

1) The operator defines data-reprocessing campaign parameters (i.e. affected MSI data 

inputs time coverage, desired products type, execution priorities, etc.); 

2) The operator triggers the data-reprocessing campaign execution according to 

configuration definition; 

3) The LTA service function autonomously performs required processing actions 

according to the definition of the data re-processing campaign. 

This operation scenario will be used for the bulk data-reprocessing campaigns (i.e. one year 

of production data or more) triggered by the availability of a new IPF version and / or a new 

set of on-ground parameters effectively characterised and adjusted. 

6.14 Mission Configuration Control (MCC) Operations 


6.14.1.1 Mission Configuration Control Concepts 

The PDGS MCC function is responsible for keeping under a controlled environment all the 

mission reference files. 

The MCC function will control critical configuration and essential operations information with a 

multiple objective: 

Keep under a controlled environment all critical configuration parameters and essential 

operation reports into a central repository. This objective aims at a centralised and 








page 289 of 350 

comprehensive management of all essential configuration and operations data over 

time; 

Provide the functionality to activate a specific system configuration throughout the 

distributed PDGS from a single point, and to collect all derived operation reports. This 

objective aims at an accurate management of the PDGS configuration covering their 

preparation, activation and monitoring; 

Provide query capabilities to the operator for the full understanding on the active 

mission reference files at any moment along the mission life-time. 

6.14.1.2 Function Managed Data 

The MCC function will manage all the critical configuration and essential data that have an 

impact on the operations and performance as mission reference files. 

All the configuration parameters with an impact on the PDGS performance will be globally 

managed under POM supervision. One example of critical mission reference files is the MSI 

on-board configuration generated by the PDGS Mission Performance Assessment (MPA) 

function and used on-board to control the imagery acquisition. Such on-board configuration 

may change and evolve in time under the requests and approval of the POM. 

Essential mission reference information reporting upon mission performance measures and 

indicators will be as well managed and mainly used for overall mission performance 

assessment (used by the PDGS Mission Performance Assessment function). For instance 

ground stations acquisition, data circulation, data archive reports, mission plans, FOS 

schedule plans, etc will be managed as part of the mission reference files as providing 

indicators on the PDGS and overall system performance. 

The MCC function will manage mission reference files that are either common to both S2A 

and S2B spacecrafts or specific to a specific unit (e.g. orbital changes scenario will be 

addressed for each spacecraft while ground station characterisation is applicable to the 

mission). 

6.14.1.2.1 Configuration Files 

The MCC function regroups all the PDGS critical configuration files having a direct impact on 

the PDGS functioning and performance. Some of this critical configuration will be managed 

independently per spacecraft whilst other will have global relevance. Some of these files will 

be generated either internally by the MCC function or gathered from other functional systems. 

As Mission Reference Files, these files will be kept under controlled configuration and will be 

when required released to their intended functional targets in controlled way. 

Typical examples of configuration reference files are enumerated hereafter: 

Reference orbit (S2A, S2B) 

Ground stations database 

Ground stations characterisation 

Downlink scenario definition (S2A, S2B) 

Spacecraft Safety Constraints File (S2A, S2B) 

Downlink Constraints (X-Band Banned Segments, Station Banned Segments) 








page 290 of 350 

 

 

 

 

 

 

EDRS Availability Segments 

On-ground data processing parameters (e.g. GIPP) 

On-board payload parameters (e.g. MSI NUC tables for S2A and S2B) 

On-board platform parameters (e.g. thermal tables for S2A and S2B) [TBC] 

PDGS circulation rules 

PDGS archive rules 

6.14.1.2.2 Operation Files 

The MCC function regroups all essential measurements and operation reports as part of the 

mission reference files. Operation files are centrally collected for configuration management 

purposes and released for assessment (i.e. delivered to MPA for performance assessment 

activities). Managed operation files will either relate to spacecraft-specific data (e.g. station 

acquisition report) or globally to the constellation. Typical examples include: 

The Payload plan 

The FOS Scheduled plan 

The ground stations Acquisition-Schedule-Plan 

The EDRS Booking-Plan 

Unavailability reports 

Stations acquisition reports 

PDGS processing reports 

PDGS archiving reports 

PDGS circulation reports 

6.14.1.3 Mission Reference Files Management 

6.14.1.3.1 Applicability Time 

The PDGS/MCC function will provide for the managed configuration the final applicability time 

resulting of its coordination role. Applicability time is the period (applicability start time & stop 

time tags) when a given component version should be officially used by the target systems. 

Although the MCC function managed files that are gathered from other interfaces can already 

provide an estimated applicability time, it will be MCC in last instance the one defining 

components versions official activation time when released. 

On the other side, the managed mission reference files with operations information do already 

provide final applicability time (provided by the originator function) and they are usually 

related to their operations or reporting time period every component refers to. In this case the 

MCC is not required to change the applicability time. 

6.14.1.3.2 Release Concept 

The MCC function as for a proxy in the PDGS for what mission reference files release 

concerns. The release of a reference file is intended for its delivery to the applicable 

interfaces with a reference time (activation-time) for its usage. 

As explained in the previous section, the MCC function in some cases will define the files 

applicability time and therefore their activation time (i.e. the applicability start time). Generally 








page 291 of 350 

the MCC is likely to define this activation-time in coordination with other reference files and / 

or coordination with other interfaces for the applicability and usage time definition are 

required. 

In other cases, it is the source generation of the mission reference file the one in charge of 

defining this applicability for its official release although the MCC function will be able to 

override it if required. 

Driven by the required mission reference files management, the MCC function will provide 

releases: 

 

 

Mission Reference – Coordinated release (MR-C): the MCC function, when triggered 

by the operator, will release the selected set of mission reference files. Accordingly it is 

the operator who decides when to perform such release driven by the activation-time 

of the released files (e.g. PDGS circulation & archive rules); 

Mission Reference – Uncoordinated release (MR-U): according to configuration, the 

MCC function will automatically release the mission reference files that do not require 

update on the activation time already defined by the source (e.g. FOS PIF). 

6.14.1.3.3 Support to FOS Special Operation Request 

The MCC function handles the payload on-board configuration updates (as part of the 

mission reference files) that are released to the FOS for the uplink and activation on-board. 

The managed payload configuration updates (cf. section 4.5.3.3.2) are supplied by the MPA 

function, generated as part of the performed Cal/Val activities, but released by the MCC 

according to the FOS required interface. 

Every single on-board configuration update is composed by the applicable payload table in 

the agreed format -SPF or OBSM- (cf. section 6.16.4.3) accompanied with a Special 

Operation Request (SOR) form (cf. section 4.5.3.3.2) submitted to the FOS. This mechanism 

is applicable to the update of the payload on-board configuration handled under both, MR-C 

and MR-U release mechanisms. 

In addition, the MCC function processes the SOR form response provided by the FOS to 

acknowledge the scheduled uplink time or the update rejection. 


The MCC function will be centrally operated from the Payload Management Coordination 

Centre. As such, MCC operations will have to: 

Cope with the asynchronous generation of the different mission reference files fetched 

from throughout the PDGS and other ground-segment interfaces (e.g. FOS) and 

automatically register the data in a common repository; 

Support operator-driven mechanisms for the coordinated release (MR-C) of critical 

data; 

Support autonomous asynchronous file delivery mechanisms for the uncoordinated 

releases (MR-U) (e.g. most of operations files). 








page 292 of 350 

To support the effective file collection and release mechanisms, file transfers to and from the 

MCC function interfaces will be managed via a collocated Data-Circulation function. As such, 

effective data-circulation is considered out of the strict scope of the MCC function operation. 


6.14.3.1 Definition of the MRF Configuration Rules 

This scenario accounts for the operator-driven definition of the Mission Reference Files 

Configuration Control rules. This scenario includes the various configuration-control rules 

applicable to each kind of mission reference file (i.e. identified by the file-type), associating for 

each one typically: 

 

The assigned release mechanism MR-C or MR-U; 

Data circulation configuration (retrieval and delivery operations and associated I/F 

definitions); 

The operator will define and maintain along time the data management possibly adding new 

components, modifying them or removing deprecated ones as relevant. 

Some use cases are presented here according to this operation scenario: 

Initialisation of the function configuration. Preliminary rules will be defined and tested 

until OSV; 

Preparation for second spacecraft S2B operations. Additional rules for spacecraft 

specific configuration will be added neither affecting nor conflicting current operational 

S2A ones; 

Change the data-management rule for a given file-type (e.g. once mission planning 

has been well validated and used it may be released automatically under MR-U, 

previously configured under MR-C for the operator supervision). 

6.14.3.2 Registration of new Mission Reference Files 

This scenario accounts for the new mission reference files registration by the MCC function. It 

includes the mission reference files gathering from the other PDGS functions and the 

operator-driven generation of own MCC responsibility mission reference files. 


1) The MCC function gathers autonomously all the Mission Reference Files generated by 

other PDGS functions; 

2) The MCC function supports via an adequate HMI the operator on the generation of the 

Mission Reference Files under its responsibility; 

3) The MCC function autonomously or triggered by the operator performs the validation 

(i.e. syntax, semantics, specific verification on mission rules, etc); 

4) The MCC function keeps under configuration and control the new Mission Reference 

Files. 









page 293 of 350 

The MSI on-board and on-ground configuration generated during the phase E-2 will be 

supplied by the PDGS/MPA function; 

PDGS operations reports such as the ground stations acquisition reports will be 

gathered and stored for later supply to the MPA function; 

 

The operator via the MCC HMI will generate the PDGS data-circulation / archive rules. 

6.14.3.3 Coordinated Release 

The scenario stands for the operator-driven release of a selected set of Mission Reference 

Files. The release of such files should be done before their activation time (i.e. before they 

become applicable). In some cases, the operator will explicitly define such activation time, or 

leave original activation time stamped on the file as defined by the source generator. 

Prior to the mission reference files release, the POM is made aware of the mission reference 

changes and their expected impact and is sought for approval. 


1) The POM can be reported on the mission reference files updated (e.g. affected files, 

specially the ones related to the mission configuration). The MMA approves such new 

configuration changes; 

2) The Operator validates the selected files to be released (e.g. file validation, parameters 

cross checks among different files, specific rules according to the file nature); 

3) The MCC function generates a check-list to specify the mission reference files to be 

released defining their activation time; 

4) After successful coherency checks and the check-list generation, the selected mission 

reference files are released and delivered (i.e. components are delivered according to 

the data circulation rules). 


New NUC table (generated by the MPA function) is released to the FOS. It is supplied 

in OBSM and a SOR form request is submitted to the FOS. The SOR form response is 

autonomously processed by the MCC function and in case of update rejection, the 

operator alerted; 

New reference orbit scenario is delivered to the FOS and the PDGS relevant functions; 

The MCC function will ensure both the on-ground and on-board applicability time 

coherency when required (e.g. on-ground GIPP updates and the on-board 

configuration update). 

6.14.3.4 Uncoordinated Release 

The scenario stands for the autonomous uncoordinated release of the configured mission 

reference files as they are gathered, ingested and classified by the MCC (cf. Registration of 

new Mission Reference Files). 






1) Refer to the Mission Reference Files registration section; 




page 294 of 350 

2) After the configured mission reference files gathering and ingestion activities, the 

configured files to be delivered as MR-U are autonomously circulated to the applicable 

interfaces. 

Some relevant use cases, more concretely for the mission operations data, are presented 

according to this operation scenario: 

The different PDGS functions activity reports are autonomously circulated to the 

PDGS/MPA function for monitoring and assessment activities; 

The mission plan, once based on already well proven configuration is gathered from 

MPL function and autonomously circulated to FOS; 

Ground stations acquisition reports are gathered and autonomously delivered to the 

PDGS/MPA function. 

6.14.3.5 Configuration Reporting & Query Capabilities 

The scenario is activated on-request by the operator for reporting on the managed mission 

reference files changes. In addition, the MCC will be able to provide traceability between 

mission reference files flagged as configuration and the ones flagged as operations. This 

scenario is based on the interactive visualisation and reporting capabilities of the MCC. 

The following use cases are identified following this operation scenario: 

The MCC operator presents a report with including the description mission reference 

files (flagged as configuration) updated to the POM for assessment and approval 

before release; 

In response to a POM request, the MCC function supplies the appropriate reporting 

information about a specific mission reference configuration parameter, its current 

value and its evolution along mission lifetime. The operator will display or generate a 

report with the requested information; 

On anomalies management, the MCC operator will present a report with the irregular 

mission reference file and the configuration that was applicable during its generation; 

The MCC operator queries the function on the applicable set of mission reference files 

for a given time-period. 








page 295 of 350 

6.15 Mission Planning (MPL) Operations 


6.15.1.1 Global Mission & Systematic Planning 

The Sentinel-2 mission aims for the global and sustained monitoring of land and coastal 

areas (cf. section 3.1). According to the mission objectives, continuous acquisitions over well 

defined and predictable areas of interests are performed. 

The Sentinel-2 near-polar sun-synchronous orbit characteristics with a 10 days repeat cycle 

(cf. section 3.4) ensures a high revisit time with same illumination conditions over the mission 

area of interest which will be doubled with a second spacecraft unit (cf. section 3.3). 

The Sentinel-2 MSI payload provides a large spatial coverage on every acquisition (i.e. single 

wide swath coverage 290 km) with a single observation mode to be scheduled on the mission 

area of interest at every opportunity (cf. section 3.1). 

As such, Sentinel-2 requested sensing will be highly predictable with little changes as derived 

from special acquisition campaigns, special calibrations, etc (cf. section 4.5.4.1.1). 

6.15.1.2 PDGS Planning Scope 

In this section it is explained the perimeter of the PDGS planning. The PDGS provides the 

mission plan to the FOS for its scheduling and uplink to the satellite (cf. 4.5.3.1.1). 

The PDGS planning perimeter will include the scheduling of ground stations reception 

activities derived from the mission plan (cf. 4.5.3.1.3). 

The PDGS generates the mission plan and commands the required satellite elements 

including: 

o Generation and maintenance of the mission reference orbit file 

o Management and use of the Spacecraft Safety Constraints File for operations 

o Generation of the Coarse Downlink Budget 

‣ Characterisation of the CGS and LGS network resources 

‣ Management of the Multi-Sentinels restriction for X-Band operations 

‣ Management of the EDRS Availability Segments assigned for the Sentinel-2 

Mission 

‣ Ground stations and EDRS GEO contact time generation 

‣ Contact times restriction and optional manual update 

o Generation of the Image-Acquisition-Plan 

‣ MSI commanding for imagery acquisition 

‣ Memory recording of MSI acquired data synchronised with MSI acquisition 

activities 





o Generation of the Downlink-Plan associated to the Image-Acquisition-Plan 

‣ Memory playback of MSI data 

‣ Memory playback of satellite ancillary data 

‣ Memory playback of satellite HKTM data 

‣ X-band downlink synchronised wrt. playback activities 

‣ OCP downlink synchronised wrt. playback activities 




page 296 of 350 

o Notify in advance to every ground station the list of required downlink passes 

according to the Mission-Plan 

o Generation of the ground stations Acquisition-Schedule-Plan 

o Generation of the EDRS Booking-Plan 

All planning activities will be referenced in OPS mode. Very specific activities might make use 

of the MTL scheduling mechanism. 

6.15.1.3 Multi-spacecraft Management 

Load balancing between the constellation spacecrafts will be implemented at mission 

planning level. This will be performed at various levels: 

○ In the MSI Image-Acquisition-Plan such that the relative planning of the two satellites 

can slightly diverge to accommodate special acquisitions; 

○ Downlink-Plan generation according to different ground resources assigned (i.e. 

possibility to downlink the data to different ground-stations); 

○ In the mission data recovery plan such that different zone coverage priorities impacting 

timeliness can be managed independently. 

6.15.1.4 SPF-PIF Protocol 

The PDGS together with the FOS will implement the mission planning loop (cf. section 

4.3.7.1). 

The exchange of planning information between PDGS and FOS will follow the SPF-PIF 

protocol. 

The Skeleton Plan File (SPF) is generated by the PDGS and delivered to the FOS. The SPF 

mainly contains requests to schedule an instrument task or command sequences according 

to the mission database. Sentinel-2 mission supports MTL and OPS requests. 

In response to the PDGS provided SPF, the FOS generates the Plan Increment File (PIF) 

when checking and verifying PDGS requests suitability. 


The following operation constraints have been identified: 








page 297 of 350 

Staff involved in the mission-planning activities on both FOS and PDGS sides are 

available during nominal working hours only (operations performed on weekly days); 

S/band opportunities assigned to Sentinel-2 mission for the mission uplink plan (cf. 

4.3.7.1); 

X-Band ground stations scheduling duty cycle for the downlink-passes booking beforehand 

according to the planned activities; 

 

Additional operation constraints derived from the EDRS exploitation. 


6.15.3.1 Planning Configuration 

This scenario accounts for the operator-driven MPL function configuration covering all 

preparatory activities prior to the mission plan generation. The following activities are 

considered part of the configuration scope: 

Ingestion and handling of the applicable Mission Reference Files released by the MCC 

function (i.e. mainly the FOS files required for planning acknowledge and ground 

station scheduling activities); 

 

Planning templates rules generation and their activation to span the Image-Acquisition- 

Plan; 

Characterisation of the Downlink capabilities assigned to the Sentinel-2 (Coarse 

Downlink Budget); 

Management of the FOS released Spacecraft Safety Constraints File with impact on 

the PDGS mission planning activities; 

Internal configuration parameters such as planning mode (automatic or manual, 

generation frequency, default plan coverage, etc.); 

The PDGS/MPL function configuration comprises activities that are performed automatically 

and others attached to operator handling. 

The operator defines and introduces the mission planning configuration parameters for the 

latter mission planning generation activities. See below a proposed example of some 

parameters that can be defined and used to characterise the CGS/LGS usage by the two 

spacecrafts units. 






S2A 

Precedence RT NRT Nominal HKTM 

CGS-A 1 yes yes yes yes 

CGS-B 2 no no yes yes 

CGS-C 3 no no no no 

CGS-D 4 no no yes no 

LGS-X 5 yes no no no 

LGS-Y 6 yes no no no 

S2B 

Precedence RT NRT Nominal HKTM 

CGS-A 1 no no yes yes 

CGS-B 2 yes yes yes yes 

CGS-C 3 yes yes yes no 

CGS-D 4 no no no no 

LGS-X 5 yes no no no 

LGS-Y 6 yes no no no 

Figure A-1 CGS/LGS Usage Characterisation parameters 




page 298 of 350 

The PDGS/MPL function required input files management, which includes file gathering and 

ingestion activities is performed automatically. 

The operator defines and activates the planning rules (i.e. observation templates rules, 

calibration templates rules, etc.). Supported by the MPL function file edition capabilities and 

according to the HLOP, the operator defines the planning rules (e.g. area of interest, 

NRT/nominal flag, priority, etc) that will drive the mission plan outcome. 

6.15.3.2 Manual Mission Plan Generation 

This scenario accounts for the operator-driven mission planning generation using the MPL 

function. According to the PDGS/MPL function configuration the operator will perform the 

mission plan generation. 


1) The operator ensures that the required mission reference files and planning 

configuration rules are up to date; 

2) The current applicable mission configuration is activated by default. Nevertheless, the 

operator is offered the possibility to alter input files versions to be specifically used in 

the manual plan generation session. Accordingly the MPL function offers to the 

operator input file versions that are coherent with the current planning window 

generation; 

3) The operator activates desired planning rules by the selection of the correspondent 

observation and calibration rules templates; 

4) The MPL function generates the SPF mission plan file (including the MSI Image- 

Acquisition-Plan and the associated Downlink-Plan) for a user-defined mission period 

according to the SSCF and compatible with the FOS operation constraints defined in 

4.3.7.1. 

Some use cases of this operation scenario are: 







page 299 of 350 

Test new planning configuration not previously used for the mission plan generation. 

During the commissioning phase, it is likely to increase MSI load progressively by 

addition of new observation and calibration rules or by the modification (relaxing) of 

some constraints modelled in the SSCF; 

Re-planning generation. In case it is needed to re-plan due new specific calibration 

operations to be added, change of downlink priorities, etc; 

New manual planning generation after “failed” automatic planning (mission plan 

rejected by the FOS). 

6.15.3.3 Automatic Mission Plan Generation 

According to the PDGS/MPL function configuration, the mission plan will be generated 

automatically on a predefined schedule basis. This scenario accounts for the automatic 

mission planning generation according to the operational duty cycle established with the FOS. 


1) The MPL function autonomously triggers the mission plan generation according to 

schedule configuration (i.e. typically every 2 weeks); 

2) The MPL function autonomously takes current applicable inputs (e.g. observation plan, 

calibration plan template, SSCF, etc.); 

3) The MPL function autonomously identifies the next planning period (i.e. planning start 

and stop, typically 15 days) according to configuration and the previous planned 

period; 

4) The MPL function generates the mission plan autonomously according to the SSCF 

and compatible with the FOS operation constraints defined in section 4.3.7.1; 

5) The MPL function autonomously optionally notifies to the ground-stations based on a 

configurable time the downlink passes required in advance (i.e. pass-list) to support 

the generated Mission-Plan; 

6) In case any error happened during the planning generation, the operator is alerted 

(e.g. via SMS or email). If planning is successful the operator is reported accordingly 

(e.g. report delivery via email). 

This scenario can be used once the configuration planning has been consolidated and 

already proven in real operations. 

6.15.3.4 Planning Loop Closure 

This operation scenario is part of the nominal working-flow with the FOS as part of the 

mission planning activities. Every time a new mission plan is generated and delivered to the 

FOS, the latter performs the satellite safety checks and generates a PIF in response to such 

mission plan. The PDGS/MPL verifies that all planned activities have been scheduled by the 

FOS. 

This operation scenario hence accounts for the automatic planning loop closure although it 

may be as well triggered manually by the operator. 









page 300 of 350 

1) Activated by the reception of a new FOS PIF, the MPL function looks for the 

associated mission plan; 

2) Alternatively to the previous step, the operator selects for the desired Plan Increment 

File to be verified in case of manual configuration; 

3) The MPL function autonomously (or triggered by the operator) according to the 

configuration correlates the FOS planning response with the mission plan and verifies 

that all the planned activities have been scheduled; 

4) In case any mission plan request is not scheduled by the FOS, the PDGS/MPL 

function will alert the operator (e.g. via an e-mail, sms, etc) who will attempt replanning 

activities. 

This operation scenario is used as part of the planning activities performed during the mission 

and it may be activated manually or automatically by the availability of a new FOS Plan 

Increment File. 

6.15.3.5 Automatic Ground Stations Scheduling 

This scenario stands for the automatic generation of the ground stations scheduling according 

to the mission planned downlinks vis-à-vis CGS and LGS. All the planned downlinks will 

result from preliminary planning activities with the FOS and will be acknowledged in the PIF. 

This operation scenario will include the following steps: 

1) Based on a predefined schedule for each ground station (i.e. daily, weekly, etc), the 

MPL function autonomously triggers the generation of the Acquisition-Schedule-Plan 

with respect to the planned downlink events of every configured ground-station; 

2) The MPL function autonomously identifies the applicable last orbit information (i.e. 

FOS predicted orbit file and TLE); 

3) The MPL function autonomously generates for each configured ground station (CGS or 

LGS) its scheduling plan containing the events information such as AOS, LOS, satellite 

TLE events, etc according to the defined interface; 

4) In principle the generated Acquisition-Schedule-Plan for every ground-station is 

autonomously delivered to the MCC function for their official release (cf. section 

6.14.3.4). 

Analogously, the MPL function will autonomously generate the EDRS Booking-Plan based on 

the OCP scheduled activities by the FOS as defined in the Plan Increment File. The 

generation of the Booking-Plan will be automatic and compatible with the EDRS capabilities 

assigned to the Sentinel-2 Mission defined by the EDRS Availability Segments. 

6.15.3.6 Planning Statistics Visualisation 

This scenario accounts for the operator-driven planning statistics generation and visualisation 

activities. The MPL function generates several statistics parameters on generated mission 

plan to assess usage of the satellite & the ground resources. 








page 301 of 350 

This operation scenario allows the understanding of the system capabilities usage and allows 

evaluation for potential mission scenario evolutions. As such, resources like the MSI usage 

(i.e. sensing times segments length), on-board memory usage, downlink times, on board data 

latency, etc. are evaluated and relevant statistics are generated. 

In this manner, the generation of the mission plan according to different rules can be 

assessed to see potential bottlenecks, improvements, and in general, aiding the operator and 

in last instance the POM on a better mission planning definition. 

6.16 Mission Performance Assessment (MPA) Operations 


6.16.1.1 MPA Decomposition 

The PDGS Mission Performance Assessment (MPA) function is responsible to verify that the 

mission requirements are being met. Accordingly, the MPA function will cope with various and 

different aspects of the mission operations: 

‣ Off-line quality control of the MSI production; 

‣ Definition of the MSI on-board configuration and calibration; 

‣ Definition of the processing and quality control configuration parameters; 

‣ End-to-end system performance monitoring. 

Such activities may require different work-flows definition and involve different teams, 

therefore the MPA function operations scenarios presented in this section are grouped 

according to this decomposition. 

6.16.1.2 Off-line Quality Control 

The Off-line Quality Control (OFQC) is responsible of identifying if the mission data quality 

requirements are being met on the generated production along mission life-time and to 

monitor the quality indicators trends evolution in time. 

The OFQC includes the monitoring of instrument response and the generated product data 

quality at regular intervals to guarantee the timely identification of any instrument or product 

quality anomaly. 

As a result of the quality control activities performed during the production generation, the 

products are annotated with Quality Indicators (QI), which provide the information to assess 

the suitability of the data for a particular use/application. Therefore the Off-line Quality Control 

(OFQC) complements and synthesises the On-line Quality Control (OLQC) function results 

(cf. section 6.4). 

The Off-line Quality Control is conceived to detect anomalies that cannot be detected by the 

On-line Quality Control function due to the need of an overall view on the generated 

production instead of a product-per-product level. 









page 302 of 350 

According to this overall view on the production quality trends and associated instrument level 

performance, the Off-line Quality Control (OFQC) scope is: 

o To identify any potential anomaly arising from the MSI instrument down to the 

processing chain and which may require corrective actions as soon as possible after 

data acquisition; 

o To perform a short-term and long-term mission performance monitoring including the 

verification of the consistency between expected mission products, generated mission 

products and auxiliary information usage; 

o To perform long-term instrument performance monitoring including the monitoring over 

the long-term of key instrument performance parameters annotated on or derived from 

the mission data product; 

o To perform long-term product quality monitoring, which includes the monitoring of the 

product quality key parameters annotated on or derived from the mission data 

products; 

o To perform automatic checks on the auxiliary data format compliance (e.g. DEM, GRI, 

etc) prior to the official release and usage. 

The OFQC role is to detect any anomalies according to the presented scope and report them 

accordingly. The potential mitigations and solutions of the raised anomalies fall out of the 

scope of the OFQC but on other elements of the MPA function as explained in the next 

sections. 

6.16.1.3 Calibration and Validation 

The Cal/Val corresponds to the process of updating and validating on-board and on-ground 

processing configuration data (respectively OBCD and OGCD) to ensure meeting product 

data quality requirements (cf. section 2.4 for detailed of the Cal/Val terminology according to 

CEOS definitions). The Cal/Val operations for Sentinel-2 are described in section 4.5.4.10. 

The MPA function as result of the performed Cal/Val activities will generate updates on the 

MSI on-board configuration data (OBCD) to tweak and tune its performance. Accordingly it 

will be responsible of the updates of the following MSI tables: 

‣ IPS (7 tables, one per each MSI imaging mode) 

‣ TCM-NOM 

‣ TCM-SBY 

‣ Front-End Electronics 

‣ NUC 

Analogous to the update of the on-board configuration, the MPA function as result of the 

Cal/Val activities will generate updates on the on-ground processing configuration (OGCD) 

which for Level-0/1 processing are the GIPP) to tweak and tune its performance. 

The update of the OBCD and OGCD is usually done in parallel as the update of one on-board 

configuration may have impact on the manner the processing is performed on ground. The 

MPA function generates both updates although it is the MCC function (cf. section 6.14) that 

ensures the coordinated activation of the on-board and on-ground configuration. 







page 303 of 350 

6.16.1.4 Instrument Data and Quality Control Processors Verification 

The scope of this MPA role is to verify the instrument data and quality control processors 

modelled in the PDGS as the IDP and OLQC functions with respect to their respective 

technical specifications covering functional, quality and processing performance aspects. 

The implementation of the instrument data and on-line quality control processors is done 

through the encapsulation of the algorithmic and computational part within the so-called 

Instrument Processing Facility (IPF). 

The IPF evolution is an evolving cycle as depicted in Figure 6-2 which covers the “Routine 

Monitoring and Quality Control” sector of the cycle. The other activities are considered 

outside of the PDGS system. 

IPF Perform. 

Assessment 

Algorithm Inputs 

IPF: Instrument Processing Facility 

Algorithm 

Review 

IPF Anomaly 

Investigation 

IPF Implem. 

Verification 

Scientific 

Routine 

Community 

monitoring 

and QC 

Expert 

Support 

Laboratories 

Algorithm 

Specifications 

Prototype 

Implementation 

IPF 

Implementation 

IPF Baseline 

Delivery 

IPF Baseline 

Verification 

Figure 6-2 IPF Evolution Cycle. 

The presented activities complement the new IPF versions validation performed on the PDGS 

Reference Platform (RP) function (cf. section 6.18) as such it includes its fine-tuning 

configuration for the operations. 

Accordingly the MPA function will make use of a collocated processing infrastructure (i.e. the 

DPC, IDP and OLQC functions deployed in the MPAC, cf. section 5.3.2.3) to verify that the 

new IPF version releases (including new configuration) are suitable for the operations 

according to the new version scope before proceeding with the release and deployment 

activities. 

The verification activities are performed according to the ECSS-E-ST-40C standard. Firstly by 

revision of the associated validation information outcome from the testing campaigns 

performed at the Reference Platform. 

The MPA function will assess the implementation quality / performance figures of the IPFs as 

a recurrent background activity or in response to specific anomalies detected by the qualitycontrol 

and the system monitoring elements. 








page 304 of 350 

6.16.1.5 End-to-End System Performance Monitoring 

The MPA function undertakes the responsibility of the monitoring of the activities with an 

impact at PDGS at system level. As such, the MPA function assesses the full system 

behaviour with respect to the mission requirements and the current HLOP. Therefore the 

MPA function will allow raising any potential deviation on the PDGS system operations with 

respect to the HLOP. 

As part of the end-to-end system performance monitoring, the MPA function will assess for 

the correct operations of: 

‣ Mission configuration control; 

‣ Planning chain; 

‣ Production chain; 

‣ Data-access chain. 


Due to the Sentinel-2 mission operational character (i.e. as a GMES Contributing Mission), 

the monitoring of the PDGS correct behaviour and safe operations are a critical aspect. 

Thus, the required 24x7 monitoring activities shall maximize the automation of recurrent tasks 

minimising the operator involvement. 

6.16.3 OPERATION SCENARIOS – OFF-LINE QUALITY CONTROL 

6.16.3.1 Configuration of the Quality Control Reporting 

This scenario stands for the expert-team driven configuration of the MPA function with 

respect to the systematically performed quality control activities, mainly the reporting. 

The quality control procedures evolve during the mission life-time according to the stage of 

the mission and the platform and payload healthiness evolution. As such, the MPA function 

must be agile and intuitive for the configuration change activities and naturally support the 

addition or modification of new quality control procedures. 

The quality control tasks performed during the commissioning phase may not be the same to 

the ones performed during the operational phase or close the end of mission, in which the 

potential degradation of the platform/payload may require different verifications. 

As such, the MPA function supports the expert-team in the configuration of the quality control 

activities via the adequate HMIs and tools envisaged to minimise this effort. 

The main envisaged use cases according to this operation scenario are: 

 

 

 

The quality control procedures configuration for the commissioning phase; 

The update of the quality control procedures during the operations; 

Specific addition of quality control procedures in support of anomalies investigation. 








page 305 of 350 

6.16.3.2 Generation of Quality Control Daily Reports 

This scenario stands for the autonomous generation of the daily quality control reports based 

on the overall production. 

The daily quality control reports can include amongst other: 

‣ Relevant statistics on the configured quality indicators (geometric, radiometric, 

defective pixels, etc); 

‣ Product-data surface classification (land, sea, ice, clouds, etc); 

‣ Percentage of passed/failed quality control checks; 

‣ List of product-data which is format-corrupted or with any anomaly; 

‣ Quality disclaimers, to provide information on the quality properties of the product data 

already available to the users; 

‣ Significant anomalies detected on the production that may require special attention 

and intervention. 

The MPA function is autonomously fed with the production data grouped in specific quality 

control (logical) datasets (cf. section 6.11) via the MMUS function (i.e. using its download 

manager). In addition, the MPA function can take advantage of the PDGS functions deployed 

at the same centre – MPAC – (cf. section 5.3.2.3) to make use of the available mechanisms 

for data circulation and access to the local archive. 

The MPA function automatic checks and reports generation can be complemented by 

additional visual inspection activities of a sub-set of product images performed interactively by 

the expert teams. 

The MPA function quality control daily reports are supplied to the expert teams and available 

to the POM for the precise up-to-date information on the behaviour of the production chain. 

6.16.3.3 Generation of Quality Control N-Day Cyclic Reports 

This scenario analogous the previous one stands for the autonomous generation of the cyclic 

quality control reports based on the overall production. The nature and scope of the cyclic 

reports is different than the daily ones, more focused on statistics over key Quality Indicators, 

which allow assessing the production / instrument response trends on the long-term. 

The cyclic quality control reports over a given cycle period can include amongst other: 

‣ Relevant summary of statistics on key quality indicators (geometric, radiometric, 

defective pixels, etc); 

‣ Percentage of passed/failed quality control checks; 

‣ Evolution in time of the MSI characterisation; 

The MPA function autonomously generates the cyclic reports according to configuration on 

schedule-driven basis. 

The MPA function quality control cyclic reports, as for the previous scenario, are supplied to 

the expert teams and available to the POM for the precise up-to-date information on the 

behaviour of the production chain and the MSI characterisation. 








page 306 of 350 

6.16.3.4 Second-Line Support-Desk 

This scenario stands for the management of expertise user support requests routed from the 

First-Line Support-Desks of ESA’s MMUS or of the CDS. 

The MPA function receives expertise support requests for investigation of potential anomalies 

observed by the users. Based on the support request the MPA operator possibly supported 

by expert teams defines and starts an investigation including: 

Registering and characterisation of the support request; 

Review of the available quality control reports relevant to the investigation; 

If needed, access to the related products via the MMUS data-access services and adhoc 

investigation on the reported anomaly by performing specific inspections and 

quality control checks. 

In case the investigation leads to highlighting a new problem (e.g. on the instrument 

configuration, on the PDGS configuration, on the system operations, etc) corrective actions 

are triggered (e.g. mission configuration change, system anomaly reporting, etc). 

The conclusions on the performed investigation are sent to back to the First-Line Support 

Desk having triggered the request (MMUS or CDS Support-Desks). 

6.16.3.5 Auxiliary Data Conformity Control 

This scenario stands for the autonomous verification of the PDGS new auxiliary data (OGCD 

and OBCD) before the official release (via the MCC function, cf. section 6.14) to the 

processing centres (OGCD) and to the FOS (OBCD). 

Some auxiliary data that are mandatory for the generation of Level-1 products (e.g. DEM or 

the GRIs) is verified (e.g. corrupted format) to avoid problems on the processing chain. 

Accordingly the MPA function performs the configured verification prior to the official release. 

The MPA function receives the Auxiliary Data and performs the configured compliance 

checks. If the performed checks are successful, the Auxiliary Data will be stamped as 

compliant and eligible for release, otherwise the distribution will be stopped to prevent 

problems on the processing chain. 

In addition, the MPA function can provide specific tools to support the expert teams on the 

auxiliary data verification activities (e.g. visualisation tools of the Global Reference Images - 

GRIs). 

Some use cases of this operation scenario are: 

Inspection and verification of the Global Reference Images (GRIs): the global 

reference images is consider as an external GIPP which will be gradually built through 

an appropriate selection of orbits followed by a precise geometric refinement 

performed on the basis of spatio-triangulation using Sentinel-2 data and an auxiliary 

database of ground control points; 

New DEMs version update when better accuracy available or due to heavy landscape 

modifications by natural disasters; 

 

Updates on the snow / ice cover global maps. 








page 307 of 350 

6.16.3.6 Expert Teams Reports Integration 

The MPA function is responsible of the integration of additional / external expert teams by 

undertaking the outcome of their performed quality control activities for a harmonised 

presentation. 

As such, the MPA function receives specific quality reports from different expert teams 

involved in the different assigned activities for cal/val or / and quality control according to the 

agreed interfaces. Thus, the MPA function autonomously gathers, ingests, and harmonises 

the reporting data coming from external sources. 

One use case for this scenario is the reporting information supplied by the Off-Line POD 

Service on: 

○ Analysis of the Sentinel-2 on-board navigation solution accuracy; 

○ Analysis the Sentinel-2 POD products accuracy with respect to their related timeliness 

and accuracy thresholds; 

○ Long term monitoring of the POD products and on-board navigation solutions. 

6.16.3.7 Access to the HKTM Data Decoded by the FOS 

This scenario stands for the HKTM parameters retrieval from the FOS as required in support 

of the other mission performance assessment activities. 

The MPA function supports the expert-team for the access to the decoded HKTM data 

(packets or parameters in engineering values) required as part of the off-line quality control 

and anomaly investigation activities in response to the MMUS/CDS Support-Desk inquiries. 

The FOS provides a data-access service to the decoded HKTM named EDDS that the MPA 

function will use as needed. The EDDS supports amongst others, interactive mechanisms for 

on-demand data retrieval or batch requests for cyclic data retrieval activities. 

Therefore this scenario stands for the HKTM parameters retrieval according to the following 

EDDS mechanisms (cf. document [RD-42]): 

‣ EDDS Client Application for interactive requests by humans; 

‣ Web browser for the upload of a batch request by humans and then a File / Email 

server for the autonomous reception of the batch data responses. 

6.16.4 OPERATION SCENARIOS – CALIBRATION AND VALIDATION 

6.16.4.1 Generation of Level-0/1 On-Ground Configuration Data 

This scenario stands for the generation and supply of the on-ground configuration data 

(OGCD) as required by the PDGS for the production generation activities covering up to 

Level-1C product data. 

Currently, the Ground Image Processing Parameters (GIPP) is the only OGCD managed for 

Level-1C product generation. The list of Level-0/1 GIPPs to be generated is provided in [RD- 

07]. 








page 308 of 350 

The calibration parameters updates (GIPP) are supplied to the MCC function for the release 

to the PDGS processing centres. 

6.16.4.2 Generation of Level-2 On-Ground Configuration Data 

This scenario is analogous to the previous one but related to the level-2 configuration. 

Accordingly the MPA function generates the on-ground configuration data for the data 

processing associated to the Level-2A hosted-processor. 

The list of Level-2 GIPPs and other configuration information data to be generated is TBD. 

The Level-2 calibration parameters are supplied to the MCC function for the release to the 

PDGS processing centres in which the L2 hosted-processor is deployed. 

6.16.4.3 Generation of the On-Board Configuration Data Updates 

This scenario stands for the generation / updates on the payload on-board configuration 

performed on need basis as result of the performed Cal/Val activities (cf. section 4.5.3.3.2 for 

a list of the on-board configuration managed). 

The MSI on-board configuration can be generated manually or automatically as result of the 

verification of predefined checks on the MSI generated production (e.g. NUC table generation 

will be performed automatically). 

The MPA function delivers to the MCC function for coordinated release the on-board 

configuration data (OBCD) updates according to the formats required by the FOS for uplink 

and activation. Typically the update on the on-board configuration is performed together with 

the on-ground configuration and as such, coordinated by the MCC function. 

The on-board configuration generated by the MPA function is: 

‣ The IPS tables (7) in SPF format; 

‣ The Thermal Control Module tables (TCM-NOM and TCM-STBY) in SPF format; 

‣ The Front-End Electronics table in SPF format; 

‣ The NUC table in OBSM format. 

6.16.4.4 Submission of MSI Calibration Requests 

This scenario stands for the operator driven human requests for specific MSI calibrations to 

be routed to the mission planning function as result of the performed Cal/Val activities. In 

case such calibrations become cyclic, the POM may assess their inclusion within the HLOP 

as part of the operations calibration plan. 

This scenario is not supported by an automatic electronic interface but the specification for 

calibrations and supply by the MPA Cal/Val expert-team to the mission planning operator 

previous authorisation of the POM (e.g. an email with the detailed description of the 

calibration requested). 








page 309 of 350 

6.16.5 OPERATION SCENARIOS – VERIFICATION OF THE INSTRUMENT 

DATA AND QUALITY CONTROL PROCESSORS 

6.16.5.1 New Processor Version Verification 

This operational scenario stands for the verification of a new processor version and its fine 

tuning prior to its official release and deployment. This scenario is complementary to the 

Reference Platform validation activities focusing on the fine tuning of the new processor 

version for the different processing centres and their associated processing scenarios. 


1) Reception of the new processor version (including a self installing package containing 

processor task executables, processor configuration files, associated documentation 

and installation checkout test data) from the RP function; 

2) Execution of the processor verification plan for the new processor version using 

collocated DPC function embedding IDP and OLQC functionalities; 

3) Delivery of the verification results to the RP function. 

The use case of this operation scenario is the verification of new versions of the elements 

composing the IPF (i.e. new IDP and OLQC functions versions). 

6.16.5.2 Investigation of Anomalies on the Processing Chain 

This operational scenario stands for the investigation activities on the processing chain after 

the detection of processing anomalies. 


1) Ad-hoc investigation of the processor behaviour on the collocated DPC infrastructure 

at the MPAC; 

2) Entering of an anomaly report via the RP function if a problem is identified at dataprocessor 

level. 

6.16.6 OPERATION SCENARIOS – END-TO-END SYSTEM PERFORMANCE 

MONITORING 

6.16.6.1 Interactive Monitoring 

This scenario stands for the operator-driven visualisation in real-time of the PDGS elaboration 

flows along mission-time such as: 

○ Satellite planning and configuration along time, planned and unplanned platform or 

payload unavailability periods; 

○ Data reception at the station providing the statuses of the demodulators and front-end 

processing activities along the acquisition segment; 








page 310 of 350 

○ Data processing and archiving activities providing the detailed timeline of all 

productions performed; 

○ The summary quality of every product at all levels, providing e.g. visibility over the 

missing lines and the products with degraded quality; 

○ Data circulation activities between centres providing the availability timelines in every 

centre archive; 

○ Simple or complex correlations between the above to highlighting malfunctions or 

system bottlenecks. 

6.16.6.2 Automated Monitoring & Reporting 

This scenario stands for the autonomous generation of user friendly well-formatted reports 

covering configurable periods over the mission database and summarising the PDGS 

performed activities and potential anomalies raised in the various elaboration areas including: 

○ Planning Performance 

This check aims at monitoring the performance of the mission planning chain. 

Accordingly it compares the MSI requested activities for observation and calibration 

contained in the mission plan generated by the PDGS wrt the scheduled activities by 

the FOS. In addition it performs statistics on the effective revisit over the planned areas 

with respect to the HLOP. 

○ Acquisition Performance 

This check aims to measure Sentinel-2 PDGS X-band acquisition chain performance. 

This is to check X-band acquisition stations performance comparing scheduled 

downlink data window and real acquired data. This check will provide a view of the X- 

band acquisition stations performance and highlight missing downlinked data window. 

○ Production Performance 

This check aims to detect gaps in the PDGS production chain and highlight potential 

anomalies in any of the processors. A comparison between expected and obtained 

production timeline will be done for each of the PDGS processors (L0, L1A, L1B, L1C, 

TCI) to raise any gaps in the production. Production gaps might be produced due to 

different reasons likely problems in the processors, bad input data (quality), missing 

mandatory inputs, etc. 

One by one production level timelines will be performed to get measurements on the 

overall PDGS and each data centre achieved production for a given time period (e.g. 

L0 – 99%, L1A – 98%, L1B – 60%, etc.). 

In addition, the MPA function verifies the effective cloud-free production achieved over 

the planned areas with respect to the HLOP. 

○ Data Circulation Performance 

This check aims to monitor data circulation of key data (e.g. orbit data, payload 

parameters, auxiliary data, etc.) among the PDGS centres. This is to monitor when the 

data is available at the source, and when it has been gathered by the different PDGS 









page 311 of 350 

centres using it. In consequence, it will be also checked that all PDGS centres are 

using same set of reference mission data. 

○ Archive Performance 

This check aims to monitor that all generated production is properly archived within the 

PDGS. PDGS generation reports and archive reports will be cross-checked to detect 

any inconsistency and highlight any missing product in the PDGS archive. 

○ Data Accessibility Performance 

This check aims to monitor the PDGS Data accessibility performance. The PDGS will 

verify that all archived products are available to the users through the Data Access 

function. This is mainly a cross-check comparison between the PDGS archive 

inventory with the data collections catalogue available to the users. 

Typical access statistics are generated (typically on a monthly basis) per data type and 

provides comprehensive statistics qualified by user base origin, sentinel-2 spacecraft, 

geographical zone (e.g. continents), data-age, retrieval latency, etc as appropriate and 

providing compound figures on the volumes downloaded (supported by the MMUS 

datawarehouse capabilities). 

○ End-to-End Performance 

This check aims at measure the PDGS end-to-end performance providing a complete 

and comprehensive view at system level over the global production and detected 

malfunctions. 

The reports can be generated automatically according to a defined schedule (e.g. daily, 

monthly) or on-demand by the MPA operator. 

The MPA reports are systematically used to summarise the end-to-end mission performance 

over all the PDGS subsystems. They are provided routinely to the POM for assessment as 

part of nominal reporting (cf. mission support services defined in section 4.10.3.2). 

6.16.6.3 Service Performance Reports to the CDS/CQC 

This scenario stands for the autonomous generation and supply of the Service Performance 

Reports to the CDS/CQC as defined in section 4.10.1.4. 

6.17 Monitoring & Control (M&C) Operations 


6.17.1.1 M&C Centre Scope 

The PDGS Monitoring & Control function will be responsible for ensuring that all the available 

resources (i.e. hardware, software and network) required by the PDGS for its nominal 

operations are available, ready and running under the expected conditions. The Monitoring & 

Control function will allow detecting anomalies that may involve working on problems in the 

functional chain or help finding the cause of any malfunction of any PDGS function. 







page 312 of 350 

Every PDGS centre will be in charge of performing its Monitoring & Control activities over its 

own deployed elements. All the elements required for the every centre local operations will be 

accordingly under surveillance. In case of any failure or malfunction, each the local support 

teams will be the problem/solving investigation front-line. 

Therefore the M&C function will be deployed into every federated centre customised for the 

role and the associated functions locally present. 

6.17.1.2 Horizontal Support to other PDGS functions 

The PDGS Monitoring & Control function will support other PDGS functions in the already 

described activities on execution environment monitoring. In addition, M&C function will be 

the hub of all PDGS functions logging activities. The M&C function will be flexible enough to 

cope with the different environment executions the different PDGS functions may require. 

Nowadays the M&C solutions are pretty standard and independent from the business domain 

(e.g. used in ground systems, in banking activities, and so on). The chosen M&C solution will 

be able to adapt to any other PDGS function execution environment. Many currently available 

M&C solutions allow such adaptation by configuration tailoring and/or specific modules. 

6.17.1.3 Client-Server Paradigm 

The M&C function will interact with other PDGS functions using a client/server paradigm. 

Different M&C artefacts (i.e. monitoring agents) will be deployed on every PDGS function 

platform to gather the relevant monitoring information and serve it to the M&C function serve 

side (i.e. the M&C console) for comprehensive presentation to the operator. 

The M&C agents gathers the relevant information according to configuration and send it to 

the M&C control panel, as such providing a global status to the operator and alert when 

required. Analogously, logs are managed by the M&C function as received from others; The 

PDGS functions will usually make use of a log client library for log messages delivery towards 

the M&C log server for comprehensive and centralised visualisation. 



○ Minimum operator intervention: The PDGS M&C function will only require operator 

intervention on critical errors and will be alerted accordingly; 

○ Maximum synergy with the Data Communications Operations on digital networks to 

allow an overall Monitoring & Control of the PDGS network end-to-end. 


6.17.3.1 M&C Artefacts Configuration 

This scenario describes the M&C artefacts deployment and configuration on each centre. 

Every time a new PDGS function is deployed on a given centre, new HW platforms are 








page 313 of 350 

installed, new network interfaces are used; the appropriated M&C artefacts are configured by 

the operations team. 


1) The configuration of the M&C agents: they are usually installed on the same platform 

to the new monitored elements. The M&C agents configuration typically includes the 

monitoring of the system processes status, the CPU usage, memory usage, network 

connectivity, bandwidth usage, disk usage, etc; 

2) The configuration of the alarms notifications in response to the M&C raised events; 

3) The logs configuration including the information sent (i.e. filtered by log severity), 

formatting issues, etc; 

4) The configuration of the M&C console (server side) to adapt to the specific centre 

work-flows; 

5) The configuration of the M&C central log tool (server side). 

This scenario is used when new PDGS functions are deployed in a given centre – The M&C 

artefacts will be accordingly configured with respect to the new PDGS functions and their HW 

platforms deployed in. 

6.17.3.2 Coordination with Data Communication Operations 

The M&C function will define the necessary interface, both at technical and procedural levels, 

to coordinate with the Data communications Operations Centre (cf. section 6.20) for 

troubleshooting purposes. In particular the Monitor & control function will be able to access 

reports and monitoring statistics of the Data communications Operations function. 

6.17.3.3 Monitoring & Reporting on the Execution Environment 

This scenario stands for the autonomous monitoring activities performed on every PDGS 

centre. The operator intervention is reduced to acknowledge the monitoring information when 

required (e.g. alarms). 

The M&C function will autonomously monitor the execution environment of the centre locally 

deployed PDGS functions. In case of function failure, HW / network failures, disks errors, 

network downtime, bad memory / CPU resources allocation, the M&C function will allow a 

prompt detection and the tracking of the relevant information needed to identify the source of 

problems. 


1) Monitoring data gathering via agents. The M&C agents perform systematic data 

monitoring gathering activities according to the configuration; 

2) Raising of alarms according to the agents gathered data. In case of execution 

deviation with respect to the configuration (e.g. log message received with severity as 

‘Fatal’); 








page 314 of 350 

3) Control viewing activities through M&C control panel. The M&C function displays the 

monitoring information in a comprehensive manner to highlight any problem or 

environment deviation from expected; 

4) Alarms notification. The M&C function notifies such alarm via different mechanisms 

(e.g. electronic mail, SMS, etc) according to the configuration; 

5) Reporting activities. The M&C function produces reports according to the detected 

anomalies. In addition it produces cyclic reports on the quality of service of the 

monitored elements including specific information on the different PDGS functions 

availability. 


○ Cyclic reports are generated to verify the working availability of every PDGS function 

allowing the calculation of different QoS parameters (e.g. MTBF); 

○ Network connectivity to a given interface is unavailable (e.g. towards the FOS). The 

M&C function control panel highlights such situation for a prompt intervention and 

avoid operations problems. 

6.17.3.4 Logs Visualisation 

This scenario stands for the operator-driven log visualisation activities. Accordingly the 

operator will be able to filter and visualise the desired information. 

The M&C function is the hub of all the logging activity on every centre. Accordingly the M&C 

function provides the required logging services to other PDGS functions (i.e. via client logs 

management library) and therefore they will be able to provide their logs to the M&C function. 

There will be a centralized access point to all the logs on every centre and as such, 

minimising operations effort. The operator will acknowledge the log messages when required 

(e.g. according to configured severity). 


1) The PDGS functions by making use of M&C log library sends their log messages. The 

log messages sent to the M&C function are configurable by severity on the producer 

side to avoid flooding the M&C log console; 

2) The M&C function gathers and displays log messages in a comprehensive human 

friendly way; 

3) The operator when required acknowledges the log messages displayed on the console 

(i.e. alarms). The M&C function provides filtering and searching capabilities to reduce 

operator effort. 

This operation scenario supports many other PDGS operation scenarios as most of the 

activities performed are logged accordingly. During routine operations it is expected the 

operator to only perform log visualisation activities in response to anomalies and as such, the 

M&C function must provide the adequate filtering and searching capabilities. 








page 315 of 350 

6.18 Reference Platform (RP) Operations 


As outlined in section 5.2.4.5, The RP function is globally in charge of HW and SW 

configuration control, system anomaly management, system validation and transfer to 

operation activities as required for maintenance and evolutions of the PDGS throughout its 

lifetime. 

Starting from this broad role, a number of separate activities can be derived and will be used 

as building-blocks when describing each RP operational scenario. 

Five main activities have been identified for the RP function: 

○ Hardware Inventory 

○ Software configuration control 

○ System anomaly management 

○ Sub-system testing 

○ System testing 

Each activity is described in more details in each of the following paragraphs. 

6.18.1.1 Hardware Inventory Activities 

The Hardware Inventory is the RP function in charge of managing the configuration control for 

all the HW items constituting the PDGS System. 

Main Hardware Inventory activities are: 

1) Register all PDGS HW configuration 

2) Retrieve all PDGS HW configuration 

3) PDGS HW configuration reporting 

The Hardware Inventory will be organized for registering and retrieval the PDGS HW 

configuration starting from the reception of a new PDGS CIDL (Configuration Item Data List) 

documentation and so it will be possible to have reports on: 

○ HW configuration of all PDGS centres and facilities 

○ Network infrastructure configuration 

○ HW configuration for each PDGS centres and facilities (e.g. relevant location into 

racks, details about HW) 

○ HW configuration for each PDGS functionality (as per PDGS functional breakdown) 

○ HW configuration of the Reference Platform itself 

The HW Inventory serves to maintain an accurate record of the current and planned status of 

the PDGS infrastructure in order to facilitate maintenance planning, capacity management 

and Change Proposal impact assessments on all operational systems. 








page 316 of 350 

6.18.1.2 Software Configuration Control Activities: 

The Software Configuration Control activities serve to record and verify the SW configuration 

status a related documentation of the various operated or maintained CIs (Configuration 

Items) within the PDGS. 

The SW configuration control is applicable only to the PDGS SW delivered and the control of 

the source code is in charge of the relevant development entity according to its internal 

methods/procedures and is out of the scope of current RP activity. 

Configuration Management shall set-up and maintain a system to control the configuration of 

all the delivered software pertaining to the CIs belonging to the SW Product Configurations of 

each operational platform at each of the various operational centres within the PDGS 

(including the Reference Platform itself). In particular, configuration control shall be applied to: 

○ Installation kits 

○ Configuration files (provided by MCC) 

○ Script files 

○ System Release Note 

Installation kits shall be maintained as media archived in dedicated drawers. Only the last few 

versions (e.g. the last 2 versions) shall be maintained on-line in the configuration 

management system. 

Documents delivered with the software, like Installation Procedures, User Manual, etc. are 

included in the relevant configuration baseline. 

Main activities are: 

1) SW configuration items identification: by following the PDGS SW Product Tree 

definition that will provide the formal hierarchal structure for defining relationship 

between configuration items (e.g. PDGS facilities) 

2) SW versioning system management (e.g. CVS-like) for storing, retrieving and 

comparing SW versions 

3) configuration verification: for verifying the “as built” SW product against the 

development configuration and generate the “as tested” SW product 

4) implementation of Data Management (DM) activities, i.e. creation, collection, review, 

delivery, storage and retrieval, and archiving of all CIs. 

6.18.1.3 System Anomaly Management Activities 

The System Anomaly Management activities are summarized hereafter: 

1) The RP operator is responsible for carrying out the test reports on the logbook the test 

procedure execution status and saves the whole scenario. The logbook will contain: 

○ the description of the problems encountered, 

○ the followed work around, 

○ the problem investigation results 








page 317 of 350 

2) When a problem is assessed a SPR (Software Problem Report) form will be filled and 

inserted into the anomaly database. 

3) The anomaly database will allow to perform at least the following activities: 

○ Insert new anomaly 

○ Update/modify an already existing anomaly 

○ Anomaly classification (minor, major or blocking problems) 

○ Anomaly status and plan (open, closed, to be closed at a certain date/release) 

○ Anomaly versus test procedure traceability 

4) The anomaly database will allow the RP operator to request reports on anomaly 

statistics (e.g. list of all open anomalies, list and sorting for anomaly classification and 

criticality, etc…). 

5) The RP operator will be able to perform an analysis of all encountered problems and 

provide: 

○ Test procedures metrics: a table which shows a test session results 

○ Anomaly metrics: the metrics relevant to the SPRs raised and opened during 

test activities 

○ Product metrics: PDGS subsystems product assurance reports 

6.18.1.4 System-Level Testing 

PDGS testing activities can involve the PDGS (and subsequently can be executed on the 

Reference Platform intended as a “representative PDGS”) at different level: 

○ PDGS System: set of integrated subsystems constituted to achieve a given objective 

by performing a specified set of functions. In this sense the PDGS is the system. 

○ PDGS Subsystems: a constituent part (of the PDGS system) with dedicated function(s) 

and specific interfaces of a complex whole defined as system: in this sense the 

Instrument Data Processing (IDP) or the On-line Quality Control (OLQC) represents an 

example of PDGS Subsystems. 

○ PDGS Facility: represents the combination of co-located subsystems required by a 

functional organization to perform an operational task. Concepts like Station(s) and/or 

Centre(s) - clearly devoted to exploit operational tasks - will be considered as physical 

entities grouping one or more PDGS Subsystems. 

PDGS system tests will systematically involve several PDGS functional sub-systems 

integrated together with potentially additional simulated ones according to the test coverage 

required. 

A realistic assumption is that RP operator will receive a new release at subsystem level and 

then will build a new PDGS Release at system level once verified on Reference Platform. The 

overall operation sequence for this activity can thus be summarised as follows: 

1) Select one or several documented IV&V system test procedures according to the 

testing coverage required. 









page 318 of 350 

2) As needed by the tests selected, a reference-qualified system-level configuration is 

assembled on the RP environment to simulate the relevant PDGS system-level context 

required to perform the tests. For instance, the RP environment will be configured as a 

CGS to validate a new version of the front-end-processor in integration; 

3) The required mission configuration will be retrieved from the MCC as relevant and 

installed on the RP environment if not already available; 

4) Whenever the tests are intended to validate new or upgrade systems, a new RP 

development configuration will be created with the new /upgraded systems replacing 

their old versions. At this point, the RP will be ready to support subsystem tests, either 

in reference-qualified or in the so-created development-configuration. 

5) System tests are performed and are reported upon as relevant 

As regarding the validation in integration of newly upgraded sub-systems (e.g. following 

corrective maintenance or evolution activities), one or several adequate system-tests will 

selected according to the specific role assumed at functional and/or physical level of the 

upgraded element(s) within the PDGS. 

6.18.1.5 Sub-System Level Testing 

In case a new PDGS Release which affects just a specific PDGS subsystem will be provided, 

the Sub-System Level Testing activity will be executed, by using the requested RP scalability. 

The overall operations sequence for this activity can be summarised as follows: 

1) Analyse new PDGS Release documentation in order to identify PDGS subsystems 

affected by the new PDGS version 

2) Select one or several documented IV&V subsystem test procedures according to the 

testing coverage required. 

3) Subsystem tests are performed and are reported upon as relevant 


The Reference Platform plays a primary role during the PDGS IVV (Integration, Verification 

and Validation) activities, but the scope of the current section is to identify and describe the 

RP operational scenarios in the PDGS operation phases, when PDGS system has been 

already deployed on-site (on PDGS Facilities target platforms) and has been validated for 

pre-operations. 

All other specific testing guidelines regarding the Reference Platform will be described under 

the PDGS IVV Plan. 


The following operational scenarios descriptions provide a step-wise decomposition of the 

various RP activities, referring to the previously defined RP activities as relevant. 

The proposed RP operational scenarios are: 

○ System Anomaly Management 







page 319 of 350 

○ System Updates 

○ Hardware replacement/deployment 

○ Mission Configuration validation 

○ System configuration reporting 

○ Operator Training 

6.18.3.1 System Anomaly Management 

During operations the PDGS operators will detect problems, (i.e. an anomalous behaviour of 

the system) and will use the RP function for the anomaly management. The RP operational 

scenario will be triggered by the reception of an anomaly and the following steps are identified 

for: 

1) Reception and handling of SW problems into the dedicated anomaly database. 

Anomalies are entered with all foreseen and defined attributes (e.g. criticality, referred 

PDGS subsystem, etc…); 

2) Anomaly is investigated on RP environment at sub-system level (see sub-system test 

activities). If it can be reproduced, jump to point 6; 

3) If anomaly cannot be reproduced a hardware problem may be suspected. Investigation 

is performed and if verified jump to scenario hardware replacement/deployment; 

4) For system-level anomalies, end-to-end system-test will be performed on RP 

environment (see system test activities) with a reference-qualified configuration and 

with an operational MCC configuration to investigate anomaly at system level; 

5) If anomaly cannot be reproduced a hardware problem may be suspected. Investigation 

is performed and if verified jump to scenario hardware upgrade; 

6) Once anomaly is identified system or sub-system maintenance actions are triggered 

accordingly; 

7) On availability of new system or sub-system deliveries correcting the problems, see 

system updates scenario. 

6.18.3.2 System Updates Management 

The availability of new PDGS Release can be considered as a recurrent operational scenario. 

It is worth noting that it is necessary to define in advance policies to decrease, as much as 

possible, global risks. 

Apart to the first delivery of an item that simply marks the start of its availability for the testing 

phases, new deliveries are possible as a consequence of two different situations: 

○ New releases due to scheduled successive deliveries 

○ Unscheduled release due to a previously detected anomaly 

The System Updates scenario will be triggered by the reception of a new PDGS Release and 

the RP operator will require and receive from the MCC function the last PDGS configuration 

version to run the tests. 





1) New PDGS Release is received and put under configuration control; 




page 320 of 350 

2) The effective availability date of a given Test Item will include the preliminary activities 

of installation and configuration on the RP; 

3) A development configuration will be set-up on the RP to simulate the relevant PDGS 

context required to perform meaningful tests with the upgraded element(s); 

4) System test activities will be performed on RP environment (see system test activities). 

Anomaly(ies), planned to be closed, will be verified and in case of unsuccessful 

scenario the anomaly management scenario will be executed; 

5) Otherwise the validated development configuration becomes qualified and candidate 

for deployment; 

6) Decision will be made to deploy upgraded system, and TTO (Transfer to Operation) 

action will be performed deploying the new reference-qualified configuration as 

preliminary configuration; 

7) Preliminary-configured system is monitored in operations at PDGS facilities, anomalies 

planned for closure are tested for and reports will be used by RP operator for the final 

assessment on the anomaly management database (see anomaly management 

activities); 

8) Possibly if new critical problems arise, the RP operator will decide to roll-back to 

previous RP configuration for reproducing problems and execute the anomaly 

management scenario. Otherwise the deployed preliminary configuration becomes the 

new operative configuration. 

6.18.3.3 Hardware Replacement/Deployment 

The PDGS System will take into account scheduled or not evolution that could affect the 

HW configuration due at least to following factors: 

○ HW updates due to S2B deployment 

○ HW configuration due to EDRS integration 

○ Network replacement 

○ HW migration and/or upgrades 

PDGS HW design should be driven by an evolution approach and the RP function can help 

in monitoring and controlling the PDGS HW system inventory. 

The RP scenario will be triggered by the reception of a new PDGS CIDL (Configuration Item 

Data List) documentation, which provides the HW and SW environment and full set of 

application SW that constitutes the new PDGS Release. 

1) RP operator receives a new PDGS CIDL; 

2) The New PDGS Release is put under Configuration Control; 

3) Verification of new HW platform, detailing all new HW items that are foreseen to be 

deployed on the PDGS target platforms; 

4) RP operator will execute the RP HW Inventory activities; 








page 321 of 350 

5) The upgraded system is inventoried in the RP environment for nominal inventory and 

configuration-control; 

6) RP operators will provide a summary report of HW items that constitute the new PDGS 

Release. 

6.18.3.4 Mission Configuration Validation 

Current scenario will be used by the MCC operators before deploying new critical mission 

configurations. 

It is reasonable to foresee possible improvements and implementations of the PDGS System 

(due to e.g. S2B system upgrades, EDRS integration, Network updates, failures 

managements, etc…). 

The MCC operator can request to the RP operator to exercise, simulate and test a new 

mission configuration by opportunely setting-up and using the RP. 

It corresponds to running an appropriate scenario on the RP environment using the specific 

MCC configuration dataset (e.g. files and parameters) to be validated with the referencequalified 

configuration (see system-test activities): 

1) The MCC operator requests to the RP one to validate a specific and pre-defined 

mission configuration; 

2) The RP operator receives the new mission configuration files and parameters and 

performs a RP set-up; 

3) Depending on mission configuration items the RP operator will execute the system or 

sub-system test activities; 

4) In case of raised anomalies the RP operator will run the system anomaly management 

scenario; 

5) Once the testing activities will be completed a mission configuration validation report 

will be sent to MCC operators; 

6) The MCC operators can request to RP operator to run the System Updates scenario. 

6.18.3.5 System Configuration Reporting 

The scenario is activated on-request by the RP operator for historical reporting on the system 

baselines changes, providing 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. 

This scenario is based on the following same steps: 

1) The RP operator generates a report including the exhaustive description of the current 

PDGS HW and SW baseline; 

2) The RP operator generates a change-log report on a specific sub-system, providing its 

current and past versions with the list of problems raised and resolved after each 

version. 








page 322 of 350 

6.18.3.6 Training and Rehearsal 

The training and rehearsal scenario has been introduced for anticipating such activities on the 

RP in case the PDGS target platforms (the on-site PDGS Facilities) are not yet available. By 

the way it can be justified by the long-term maintainability of the system, for training new 

operators on RP before they are sent on the deployed PDGS Facilities. 

The scenario will be triggered by a training plan or a rehearsal campaign. 


1) RP operator will receive a training plan and will ensure that there are no conflicts with 

the on-going testing activities; 

2) RP operator will negotiate the training time windows; 

3) RP will be set to a pre-defined configuration (e.g. the dedicated training one); 

4) PDGS operators will be hosted on RP for training, where it is assumed of having a 

training procedure documents and course manuals; 

5) RP switch-off from the training configuration. 

6.19 MSI Decompression Supply (MDS) Operations 


The MSI data decompression is preliminary activity performed as part of the MSI level-1 

products generation (cf. section 4.5.4.5.1 - Level-0 Consolidation and Level-1 Processing 

Logic). The MSI Level-0 data is processed by the MSI Decompression SW and therefore is 

accordingly integrated as part of the PDGS IDP function as part of its level-1 processing 

activities responsibilities. 

Therefore the MSI Decompression SW must be compatible with the PDGS platform definition 

(i.e. HW, OS, etc) is accordingly supplied to the IDP function for the needed integration 

activities. 


The MDS function will aim for the long-term maintenance of the MSI Decompression SW in 

support of the Long-Term Data Preservation objectives described in the section 4.5.1.6. 

Accordingly the MSI WICOM decompression software must evolve (i.e. to support new 

HW/OS platforms) coping with the PDGS system evolutions and maintenance activities that 

may be produced along the mission life-time and beyond (over 40 years). 








page 323 of 350 


6.19.3.1 Periodical / Scheduled New Version Delivery 

This operation scenario stands for the periodical and / or scheduled deliveries of new 

versions of the MSI Decompression SW according to the different PDGS milestones including 

both development and operations phases. 

The MDS function publishes on-line the new MSI Decompression SW versions according to 

agreed frequency update (e.g. one yearly delivery) or/and in support of the PDGS 

development phases (i.e. for integration within the IDP function in charge of the MSI level-1 

processing activities). 


1) The MSI Decompression SW supplier prepares a new version delivery (e.g. 

repackaging of the latest accumulative patches, migration to new HW/OS platforms); 

2) A regression tests campaigns are performed to verify and validate the new version; 

3) A Software Release Note of the new version is prepared; 

4) The new MSI Decompression SW is published on-line and an email is sent to the list of 

subscribed users; 

5) The new version is then downloaded and verified at the RP function to be included in a 

new release of the PDGS. 

6.19.3.2 Patch / Corrective Delivery 

This operation scenario stands for the on-request delivery of a MSI Decompression SW 

patch/corrective version in response to a raised anomaly. 

The MDS function receives a request to solve a (blocking) problem on the Decompression 

SW that restrains the normal operations. Accordingly, the RP function has raised an anomaly 

(cf. section 6.18.3.1- System Anomaly Management) and supplies all the needed information 

(i.e. test data to reproduce the anomaly) to the MDS function for the corrective actions. 


1) The RP function raises a previously verified anomaly on the MSI Decompression SW 

to the MDS function and supplies all the information required to reproduce it; 

2) The MDS function according to the defined service agreement (i.e. provide a corrective 

patch in less than 5 working days) analyses the problem and implements a solution; 

3) A Patch/Corrective delivery is prepared in the same manner as presented in the 

previous scenario; 

4) The new MSI Decompression SW is published on-line and an email is sent to the list of 

subscribed users; 

5) The new version is then downloaded and verified at the RP function to be included in a 

new release of the PDGS. 








page 324 of 350 

6.20 Network Communication Operations 


The Network Communication operations will be responsible for the overall operations of the 

digital network infrastructure of the PDGS (including the LAN, DCN, DDN, and FCN 

functions), ensuring that all available network resources required for the PDGS nominal 

operations are available, ready and running under expected conditions. 

In particular it will allow monitoring of ongoing operations, system status, load and 

performance of each site, providing real-time and historical monitoring tools. 

The network operations will rely on 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. 



○ The network operations will use as a reference model the current centralised service 

and procedures described in [RD-25]; 

○ In case the operations of these functions are split and allocated to different providers 

the same functions will be delivered by each provider and maximum synergy among 

these and between these and the ones of the M&C (cf. section 6.17) shall be achieved 


The operations scenarios are reused from [RD-25] (ODAD-NS service description) 

The Data Communications Operation function will provide also the proper functional and 

procedural interface to the Monitoring & Control Operations. 

In details: 

- the network operations will provide access to monitoring and network statistics of the 

Sentinel-2 PDGS network 

- an operator will be available for support to the Sentinel-2 PDGS during normal working 

hours/days (Mon-Fri, 8-18, TBC) 

- Specific contact point and details will be provided to the Sentinel-2 operations team for 

monitoring and troubleshooting purposes. 








page 325 of 350 

APPENDIX-A GMES PRODUCT REQUIREMENT ANALYSIS FOR 

SENTINEL-2 

A.1 Introduction 

This appendix provides a review of the identified needs of the GMES Services to be fulfilled 

by the Sentinel-2 provided products and outlines a rationale driving the product design in 

response. 

In this exercise, GMES needs are extrapolated from the following sources 

○ The requirements expressed in the DAP-R [RD-11] when relevant to Sentinel-2 type of 

sensor and the understanding of the requirements of existing GSPs and ESA funded 

GMES Service Element (GSE) projects (as precursors of future GMES Services) 

currently requiring Sentinel-2 type of data; 

○ The requirements expressed in the Sentinel-2 MRD [AD-01]; 

○ The GMES Data Policy; 

○ The extrapolation of the above requirements in view of the Sentinel-2 era, i.e. 

considering the specificities of the Sentinel-2 mission, the Data Policy and in particular 

the enhancements it will bring to the existing supply of Sentinel-2 type of data. 

A.2 DAP-R Analysis Logic 

As part of the GMES Space Component, the Earth Observation Data Access Portfolio (DAP), 

describes the European coordinated approach for supplying Earth Observation data to the 

GMES service providers. Moreover DAP provides indications concerning the data and 

condition under which data should be made accessible. 

The requirements of the DAP-R have been reviewed in view of deriving implications on the 

PDGS operations and design concepts to match the supply of data-products to the demand, 

based on the currently identified needs of the GMES Services for Sentinel-2 type of data. As 

it is expected that these requirements will evolve in time and will be enhanced with new 

National and scientific requirements, extrapolations have been made to place the DAP-R in 

the Sentinel-2 timeframe and according to the expected enhancements brought in by the 

mission compared to the present supply. 

The DAP-R requirements are currently expressed based on present EO missions and their 

respective product types in terms of semantic contents, timeliness and availability. As applied 

to Sentinel-2, the requirements have been filtered to cover the Sentinel-2 type of sensor 

(optical mission with resolution >=10 m) referred to in the DAP-R as High-Resolution (HR) 

sensors. 

The European Commission has identified a set of three Fast-track GMES core services (i.e. 

Land, Marine and Emergency) and two additional pilot services (Security and Atmospheric) 

for early operational implementation in 2008, funded under the European Commission FP7 

programme. Yet, in the vision of GMES, new services will spin-off (i.e. downstream services) 








page 326 of 350 

and other existing ones will evolve towards an operational scenario that will support Europe’s 

aim in accomplishing sustainable development and global governance of the environment. 

○ GEOLAND2 for the Land Monitoring Core Service (LMCS) 

○ MYOCEAN for the Marine Core Service (MCS) 

○ SAFER for the Emergency Response Core Service (ERCS) 

○ GMOSAIC for the Security Pilot Service (SEC) 

○ MACC for the Global Atmospheric Pilot Service (GAS) 

○ SIRS, contractor of DG-REGIO for the Urban Atlas (UA) project 

The above list will be updated regularly (e.g. downstream services or various EU Agencies 

may become eligible). 

Specific emphasis has been profuse during the analysis to requirements regarding: 

○ Level of processing; 

○ Geo-location accuracy; 

○ Area of interest and size; 

○ Data delivery constrains; 

○ Satellite tasking constrains; 

The complete results of the study are explained in the annex table. 

A.3 GMES Services Requirements Overview 

The DAP-R collects the needs of the following GMES services: 

○ Land services 

○ Emergency Services 

○ Security Services 

○ Marine services 

○ Atmosphere services 

A.3.1 

Land Services 

The aim of the Land Monitoring Core Service (LMCS) is to provide timely, systematic, 

autonomous, and independent coverage about the use of land resources and the changes of 

the land environment. The Land monitoring core service will support policy and decision 

makers at all levels and aid them in reviewing, monitoring and reporting on obligations under 

international treaties and implemented policies in the field of agriculture, water quality, soil 

protection, forest monitoring, urban development, biodiversity, etc. Three main components 

within the land services have been identified: 








page 327 of 350 

○ Local, covering urban areas, sites which rapidly change and areas with an high 

activity; 

○ Continental, for wall to wall inventory Europe for land use and land cover at HR and 

MR; 

○ Global, for land services which contribute to the understanding of global environment 

and changes and resource management; 

The Sentinel-2 mission will supply principally the Local and Continental component mainly 

because of the spatial resolution of the optical instrument (≥ 10 m). 

The land services with requirements having an implication on Sentinel-2 PDGS operations 

are: 

○ Fast Track FP7 Land Monitoring Core Service Projects (LMCS): 

o LMCS_001 – EEA-38 wall-to-wall coverage 

o LMCS_009 – High Risk Areas 

o LMCS_010 – Agro-environmental analysis 

o LMCS_012a – Europe land cover of forests, HR coverage 

o LMCS_003 – Seasonal/annual land change monitoring: Africa selected areas 

(HR) 

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

○ ESA GMES Service Element (GSE) Projects: 

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

areas (HR) 

o LGSE_003 – Forest Monitoring: REDD 

A summary of the needs from the LMCS as well as other land services is described hereafter 

as relevant to Sentinel-2 type of sensors: 

○ Acquisition tasking needs: 

Data requirements from the LMCS and Land services in general are mostly expressed 

as monitoring of a area of interest and revisit frequency requirements, or eventually, as 

coverage requirements. 

A systematic pre-defined Sentinel-2 data observation capability is thus necessary. 

Although these services may not systematically require all acquired data, the need for 

consistent, cloud-free and complete coverages (e.g. a cloud-free seasonal/annual 

mapping of Europe) imposes continuous and systematic observations to increase the 

probability of clear-sky observations. 





○ Data Access needs: 




page 328 of 350 

Main request form Land Services in terms of data access concern the access to a very 

large data volume (covering either wide areas or long multi-temporal sequences or 

both), nominally in a systematic manner with no ordering mechanism, but with no 

stringent timeliness requirements. 

Access to consistent and historical time series is essential for most of the land 

applications. Regarding the necessity of obtaining cloud free images, this should be 

achieved by the generation of cloud-free coverage. In more generic terms, the data 

access terminal could support the optimal (and minimal) selection of Sentinel-2 

products according to the strict coverage requirement defined (in terms of AOI, 

frequency, and cloud free criteria). 

This functionality should allow distribution of the data with low mapping frequency. 

○ Products and quality needs 

Although the level of maturity of DAP-R shows a general non homogeneity of 

performances and products demand, the main requested product extrapolated is the 

Level-1C, with an accuracy of 1/3 pixel dimension. Relevant is furthermore the 

requirements expressed on the cloud coverage which normally has to be less than 5%. 

In addition, the following drivers to the mission operations are highlighted: 

○ Systematic pre-defined long term satellite tasking capability; 

○ Capability to support generation of coverage data sets; 

○ Access to systematic medium-term data through subscription; 

○ Product quality stability monitoring, accurate radiometric calibration and traceability; 

○ On-line access to historical products; 

○ Mission data reprocessing capabilities; 

A.3.2 

Emergency Services 

The GMES Emergency Response Support Service (ERSS) will support at global level all 

stages of intervention cycle from early warning, to crises management and recovery in 

response to natural, environmental, technological and man-made emergencies (e.g. 

droughts, floods, storms, earthquakes, tsunami, volcano eruptions, landslides, fires, nuclear 

plant accidents, etc). The primary scope of the ERSS is to provide rapid mapping services 

(reference and damage assessment maps) to gather the useful information to know the 

incoming anomalous events and the following critical effects, the actual damages and to 

forecast and design the restore of normal life ordinary conditions. The purpose of the 

Emergency Response Services is therefore to reinforce the European capacity to respond to 

emergency situations. 





Two main mapping services have been identified: 




page 329 of 350 

○ Offline maps: which are maps either derived from pre-existing data or obtained by 

pre-event simulations containing cartographic and thematic information. 

○ On-line maps: which are maps either directly derived from in-situ data and/or EO 

images, acquired during the crisis or just after. They provide information about the 

event timing, location extent and level of damage. 

The Sentinel-2 mission will supply the following Emergency Services and Projects essentially 

for mapping purposes: 

○ Fast Track FP7 Emergency Response Core Service (ERSS): 

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

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

o ERSS_005 -Overview reference maps – small scale 

o ERSS_006b - Historical assets maps medium 

o ERSS_007b - Situation maps (Europe) 

o ERSS_010c_LDS&SPT - Burn Scar Mapping (Landsat, SPOT) 

o ERSS_010c_SPT - Burn Scar Mapping (SPOT) 

o ERSS_011a - Volcanic events outside Europe 

o ERSS_019 - Cross-cutting issues 

o ERSS_022 - Service Validation 

○ Emergency GSE Projects (EGSE): 

o EGSE_001 - Crisis and Damage Mapping – Non Charter 

o EGSE_002 - Situation Mapping 

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

o EGSE_004 - Thematic Mapping 

o EGSE_007 - Basic Mapping – Small Scale 

o EGSE_009 - Thematic Mapping – Medium Scale 

o EGSE_012 - Basic Mapping – Small Scale 

o EGSE_013 - Mapping of glacial lake outburst floods (GLOF) 

o EGSE_014 - RESPOND Basic mapping – small scale 

o EGSE_017 - Thematic mapping – medium scale 

o EGSE_021 -Basic mapping – small scale 

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

o EGSE_026 -Crisis and Damage Mapping – Non Charter 








page 330 of 350 

o EGSE_027 -Basic Mapping 

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

Scale 

o EGSE_032 - Crisis and Damage Mapping 

o EGSE_033 -Situation Mapping 

o EGSE_035 -Thematic Mapping- Context Mapping 

o EGSE_036 -Thematic Mapping- Medium Scale 

o EGSE_037 - Thematic Mapping- Large Scale 

o EGSE_039 - RISK-EOS: Burn Scar Mapping 



○ Data Access needs 

Timeliness is a key requirement in case of emergency, with NRT-3h delivery after 

sensing for new acquisitions. Some data shall be processed and disseminated in NRT, 

with less than 3 hours after sensing, resulting in the need to process the “on-demand” 

(i.e. according to the specific requested product) at the Receiving Ground Stations. 

Access to reference past products with stringent timeliness result in the necessity to 

ensure past products both already useable and ready to be disseminated and that can 

be generated “on the fly” from source Level-0 products if necessary. 


Data requirements are pre-defined for some monitoring activities but the main 

characteristic of these services is the need for rush satellite tasking capability to react 

quickly to crisis situations. During crisis or emergencies it would thus be justified that 

for reacting and tactical purposes, zones with high-risk (e.g. volcanoes, tropical zones 

prone to flooding, zones prone to fire, etc) will be handled in NRT mode in a preventive 

approach, together with the whole of Europe. 


There is a clear requirement for historical data for comparison with crisis data. L1B or 

L1A is often requested although it is unknown whether this choice is motivated by the 

fact the L1C is not advertised, or is believed to be available only on-request or after a 

significant delay. NRT timeliness is required for crisis data with regular daily post-crisis 

monitoring. 

Although L1C will be available on-line on the full mission archive (with possibly varying 

delivery latencies for data older than about a year), for historical L1A or L1B, it is 

proposed an on-line availability for a limited period (e.g. 1 or 2 months). For older data, 

the L1B products will be available from long-term storage. 





The requirement on the cloud coverage normally has to be less than 10%. 

Geometric accuracy requested varies from +/-10m to +/-50m. 




page 331 of 350 


○ Haste satellite tasking with asynchronous planning 

○ Pre-defined short-term planning capability 

○ Systematic NRT-3h processing and dissemination, to support post-event monitoring 

activities 

○ Capability to support “hosted user processing” 

○ Data discovery for reference products retrieval 

A.3.3 

Security Services 

The current needs for security services aim at identifying and developing products, 

methodologies and pilot services for providing geo-spatial information in support of EU 

external relation policies and to demonstrate the sustainability of GMES global security in the 

long term. 

Its current scope of the security service is to support intelligence and early warning and to 

support crisis management operations with the objective to deploy and validate those 

information services that contribute to support the planning for EU intervention during crises, 

citizen repatriation, etc. 

In terms of EO services requirements, the Security Services are similar to the emergency 

ones, with following exceptions: 

○ The area of interest is outside Europe and covers “hot spot critical”, areas mainly in 

Africa and middle-east, some in Eastern Europe. 

○ Most of the data will be used for surveillance and monitoring of critical areas in 

predefined acquisition and normal delivery mode. 

○ On-demand and near real time (NRT) data will be requested, but should not exceed 

the 20% of the total volume of data delivered. 

○ There are some basic information requirements on security and confidentiality for 

managing requests and delivering the products to the service provider. 

The Sentinel-2 mission will supply the following Security Services: 

○ 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 








page 332 of 350 

○ 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 



○ Acquisition tasking needs 

Security services generally require time-sampled data for monitoring purposes, but not 

necessarily all data systematically generated. Almost all services require a predefined 

satellite tasking, excluding ‘‘terrain analysis and mobility assessment’’ and ‘’postconflict 

damage assessment’’. 

Hence, an approach similar to the coverage datasets introduced in the Land service 

review is considered appropriate. 


The same requirements as for the Emergency Services are identified. In this case 

most of services requires explicitly ortho-rectified data while geolocation accuracy is 

variable and sometimes is still TBD, but actually very stringent. Furthermore quite 

important is the requirement on the cloud coverage which generally has to be less than 

25%. 


○ Systematic pre-defined long term satellite tasking capability; 


○ Access to systematic medium-term data through subscription; 


○ On-line access to historical products; 

○ Mission data reprocessing; 

○ Mapping frequency variable wrt. the service 

A.3.4 

Marine and Coastal Water Services 








page 333 of 350 

The marine and costal water services address global and regional needs for forecasting, 

monitoring and reporting on the ocean state. It addresses requirements from National and 

European policies, international conventions as well as European and international Agencies. 

Marine services usually require standard L2 products and archiving of images and ancillary 

information for pre-processing and later re-processing of the images. Data is usually required 

systematically and usually delivered in Near Real Time. The continuity of data supply from 

existing European and non European satellites is fundamental to guarantee the expected 

service quality. Most of the existing maritime products will continue to be received through 

existing channels and well established mechanisms. 

Although Sentinel 2 has been designed to be essentially a land use satellite, the availability of 

a blue band makes it very suitable for marine and coastal monitoring purposes. Current 

issues related to the global warming and the consequent sea level rise indeed, make 

Sentinel-2 image data very important for coastal region and areas monitoring. Sea level rise 

could also displace many shore-based populations: for example it is estimated that a sea 

level rise of just 20 cm could create 740,000 homeless people in Nigeria, Maldives, Tuvalu, 

and other low-lying countries are among the areas that are at the highest level of risk. 

Another important application could be the oil-spill pollution monitoring in cooperation with 

Sentinel-1 radar data. 

The Sentinel-2 mission could supply the following Maritime Services: 

○ MOS_001 - EMSA – CleanSeaNet 

○ MGSE_012 – Polar View: Glaciers Monitoring 

An overview of the specific Sentinel-2 needs from the LMCS services is described hereafter: 


Normally marine services ask for very rapid data delivery on a predefined area. 


Retrieve ocean colours preference to BOA quantities (Level 2A). 

Possible problems related to the sun-glint, so it is better to have NADIR viewing 

acquisition. 




○ Systematic NRT-3h processing and dissemination, to support post-event monitoring 

activities; 

○ Access to systematic NRT data through subscription. 








page 334 of 350 

A.4 Data Volume Estimate according to the DAP-R 

requirements 

According to the detailed analysis table (cf. A.6), an estimate of the data volumes required 

yearly by the current GMES services has been conducted. Starting from the areas to cover 

explicitly mentioned by the Services in [RD-11], the averaged values of satellite data 

requested have been calculated. 

The Sentinel-2 MSI Level-1C has been taken as baseline for the volume estimations (cf. [RD- 

05] for the unit estimates). 

Nominal data is foreseen to be delivered systematically on predefined task while the request 

of NRT data is more random, even if some possible NRT scenarios could be anticipated. 

In any case the requests for NRT data could strongly depend on natural or anthropic crisis 

events. 

Figure A-1 Natural Disasters Reported in the last 35 years 

Taking into account the statistical occurrence of natural and anthropic hazards an average of 

450 events yearly during the last 10 years have occurred affecting an area of 100.000 

squared km for each disaster. 

A possible request of 150 NRT data scene charter activations per year has been assumed as 

plausible for a total of 1000 GB of NRT data yearly. 








page 335 of 350 

Overall NRT/Nominal Data 

24% 

76% 

Nominal 

NRT 

Figure A-2 Overall Nominal/NRT Data foreseen 

The results of the analysis based on a year of possible supply scenario are shown in Figure 

A-3. Thus more than the 20% of the overall amount intended to the GMES services is 

foreseen to be delivered in NRT. 

Nevertheless the eventual scenario of processing by default all the Europe and the 

Mediterranean basin always in real-time, should ensure a considerable decrease of NRT data 

charter activations. 

In terms of scenes (290 x 290 km) needed to cover the interested areas, the number of 

requested images is around 1000 per year, in terms of tiles (100 x 100 km) is thus almost 

nine times greater. 








page 336 of 350 


NRT Data 

NRT 

MARINE 

Nominal Data 

SECURITY 

Nominal 

Repository 

Repository 

Nominal Data 

Nominal Data 

EMERGENCY 

LAND 

GMES SERVICES 

SERVICES NOMINAL [GB] NRT [GB] TOTAL [GB] 

LAND 1550 0 1550 

EMERGENCY 1600 1000 2600 

SECURITY 61 12 73 

MARINE 25 50 75 

TOTAL 3236 1062 4298 

Figure A-3 Yearly Data Volume Estimates derived from DAP-R 

A.5 Open Data Policy and the of Landsat Experience 

On April 2, 2009, the U.S. Geological Survey (USGS) LANDSAT Project delivered its 

500,000th free image for Fiscal Year (FY) 2009. A recent USGS policy change enabled 

LANDSAT data to be distributed at no charge via the internet. Prior to the policy change, the 

highest year of distribution was in FY2001 when approximately 25,000 scenes (185x185 km) 

were delivered. This phenomenal increase in distribution comprises an estimated 95 TB of 

data downloaded by users (from October to April). 

Although the USGS does not have detailed records since the mission's inception in 1972, 

there is good evidence that more data have been distributed in the first 6 months of 2009 than 

in the entire first 36 years of the LANDSAT missions combined. This trend seems to increase 

exponentially. 

On August 17, the one-millionth LANDSAT image scene has been downloaded reaching a 

total of almost 200 TB of data in less than one year. Figure A-4 shows the incidence of scene 

downloaded all around the world while Figure A-5 the distribution of the on-demand 

processing orders. 








page 337 of 350 

Figure A-4 ETM+ Standard L1T Downloads 


Figure A-5 ETM+ On-Demand Orders 







page 338 of 350 

Figure A-6 below depicts the age of the LANDSAT scenes downloaded (in years). 

Figure A-6 L1T Product age Downloads 

LANDSAT images are delivered in one TAR compressed file (180MB), with all the 9 bands 

included. Each band file is terrain corrected (L1T) in GEO-TIFF format. Currently, two are the 

LANDSAT platforms flying, LANDSAT 5, launched in 1984 and LANDSAT 7 in orbit since 

1999. 

The first one is able only to perform real time imaging without onboard recording, while 

LANDSAT 7 every day collect almost 300 scenes regularly available to the users within 24 

hours of the acquisition. 

Based on the LANDSAT experience, it is anticipated that the total amount of Sentinel-2 data 

requested, thanks to its open access policy, will be quite comparable with the one currently 

observed at USGS. 

Sentinel-2 images (290x290 km) are 2.5 times greater in terms of on-ground coverage and 25 

times larger in terms of data volume. 

A first estimate of 400TBytes per year is considered for Sentinel-2 by extrapolating that the 

coverage of an area of (100x100 km) with all Sentinel-2 bands will weight about 0.4 GBytes; 

multiplying this by one million of scenes, which is the LANDSAT actual demand, leads to 

400TBytes. 

To limit the downloaded volume, a global tiling with a tile size of (100km x 100km) is 

highlighted as a good compromise. In addition, a mechanism allowing band sub-setting is 

underlined as an interesting trade-off, considering that the most requested channels will be 

likely the four visible ones (representing about half of the volume) which should help reducing 

the download budget. 

Compared to current requirements expressed though the DAP (cf. section A.4), these 

extrapolated volumes are 100 times greater. 








page 339 of 350 

A.6 DAP-R Analysis Table 

The following table summarises the requirement of each service in terms of product semantics and access characteristics. A 

Sentinel-2 equivalent volume estimate is provided for reference for the volume computations (linked to the mapping frequency). 

Service 

Area 

Processing 

Level 

Ortho Accuracy 

Cloud 

Coverage Tasking Mapping 

Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

LAND AND TERRESTRIAL SERVICE 

LMCS_001 – EEA-38 wall-towall 

coverage 

EEA-38 + associated 

countries 5.8 million km2 

L1B, L3 

(orthorectified 

& satellite 

reflectance) 

yes 1/2 pixel < 5% Predefined 

LMCS_009 – High Risk Areas 6000 km2 L1B yes 1/3 pixel Predefined 

LMCS_010 – Agroenvironmental 

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 

LGSE_001 – Global Monitoring 

Food Security: Crop mapping: 

Africa selected areas (HR) 

LGSE_003 – Forest Monitoring: 

REDD 

EEA-38 demonstration sites 

73000 km2 

European selectes sites 

170000 km2 

L1B No 1/3 pixel Predefined 

L1B, L3 

(orthorectified 

& satellite 

reflectance) 

Every 3 Years - 2 

coverages during 

vegetation season 

Annually or 3 to 4 

per Year 

Annually or 3 to 4 

per Year 

290 

Normal for 

archive data 

Wall-to-wall land-cover mapping at European scale for implementation, review and 

monitoring of EU policies (e.g. water framework directive, biodiversity strategy, 

common agricultural, regional policies) and also for reporting obligations under 

international treaties (e.g. the Kyoto Protocol), in line with national land-cover / 

landuse 

inventories in the Member States. SAR data may be used as backup. Reference 

year 2009. Baseline: 2 data takes during vegetation season in reference year 

0.3 1-7 Days EU High Risks Areas. 4 data takes during vegetation season in reference year 

3.65 once Normal 

yes 1/2 pixel < 5% Predefined Every 3-5 years 8.5 Normal Coverage of Europe’s main forest areas 

Africa selected areas L1B yes 1/3 pixel < 5% Predefined Every year 

European selected areas 

3600 km2 

Africa: National coverage at 

MR and selected areas at HR 

of the following 

countries: Mozambique, 

Malawi, Zimbabwe, 

Ethiopia, Senegal and Sudan 

Areas in the tropical belt 

2-3 millions km2 

Spot View 

ortho 

500 per 

Year 

Normal 

yes 1/2 pixel < 10% Predefined Monthly 0.2 Normal 

L1B yes 1/3 pixel Predefined 

Yearly, new HR 

should be acquired 

every growing 

season 

L1B/C yes 1/3 IFOV Predefined 

One historical and 

one actual coverage 

(national / large 

regional) during 

dry season 

200 Normal 

150 Normal 

Environmental seasonal / annual change monitoring in development upon request 

from the user DGs (DEV, AIDCO, RELEX - plus high-resolution information on 

sites selected according to a statistically valid Area Frame Sampling scheme (AFS), 

as well as for hot-spot analysis. 

Selected sites among those identified by the Land Product Validation sub-group of 

CEOS for the validation of LR and MR biogeophysical parameters. 

Medium and high resolution crop mapping upon request from national and 

international users (FAO, WFP, Ministries of agriculture) - plus very high-resolution 

information on sites whereby field information cannot be collected 

Reduction of emissions from deforestation in developing countries for UNFCCC: 

300 – 500 HR – VHR scenes over tropical countries for large area coverage. In 

addition medium and low resolution multi-seasonal acquisitions to fill holes due to 

cloud coverage. Archived (40%) and newly (60%) acquired scenes, 

200 – 300 HR SAR images 

ESA UNCLASSIFIED – For Official Use © ESA 






page 340 of 350 

Service 

ERSS_001a – On-line Mapping 

for Europe (HR) - new data 

ERSS_002a – On-line Mapping 

for Rest of World (HR) - new 

data 

Area 

Europe and Mediterranean 

1.350.000 km2 

World 

2.0millions km2 

Processing 

Level 


L1A no ca. 10-30 m 

L1A no ca. 10-30 m 

Cloud 


Frequency 

On 

demand 

On 

demand 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Daily during crisis 70 

Daily during crisis 100 

Delivery 

< 16h new 

acqu. 

< 1.5h 

archived 

< 16h new 

acqu. 

< 1.5h 

archived 

INFO 

In response to meteorological, geophysical risks and complex humanitarian crisis. 

In response to meteorological, geophysical risks and complex humanitarian crisis. 

ERSS_005 – Overview reference 

maps – small scale 

Africa. Latin America, south 

est and central Asia 

6.450 millions km2 

L1B no 50m < 10% Predefined Once 322 Normal 

Small scale reference maps derived from archive (pre-event) data providing baseline 

mapping of infrastructure, settlements, topography, hydrology etc 

EMERGENCY RESPONSE SERVICES 

ERSS_006b – Historical assets 

maps medium 

ERSS_007b – Situation maps 

(Europe) 

ERSS_010c_LDS&SPT – Burn 

Scar Mapping (Landsat, SPOT) 

Europe L1B no 50m < 10% Predefined Once 500 Normal 

Europe : existing poorly 

mapped areas and disaster 

prone areas 

288.000 km2 

Spain, Italy, Greece 

240000 km2 

L1A/standard 

orthoready 

Landsat1G, 

Spot 1A 

yes 50m < 10% 

no 30m 

On 

demand 

Predefined 

On 

demand 

(just Spot) 

Once 14 Fast 48h 

For each frame: 3 

acquisition per year 

* 3 years 

One acquisition just 

before, another one 

during and the last 

one after summer 

12 Normal 

Medium scale thematic maps derived from archive (pre-event) data providing 

baseline mapping of ‘historical assets’ such as cultural data, population, land use and 

agriculture etc 

Medium scale situation maps derived from up-to-date data providing relevant 

thematic mapping of current situations in SAFER derived ‘hotspot’ areas 

Class: Mandatory Start Delivery: Kick off 12/2008 

Delivery of burnt scar maps based on high resolution EO data at the end of the fire 

campaign for an specific Area of Interest 

ERSS_010c_SPT – Burn Scar 

Mapping (SPOT) 

France 

20000 km2 

Level 1A no 10m 

On 

demand 

For each frame: 3 

acquisition per year 

* 3 yearsOne 

acquisition just 

before, another one 

during and the last 

one after summer 

1 Normal 

Delivery of burnt scar maps based on high resolution EO data at the end of the 

firecampaign for an specific Area of Interest 







page 341 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

ERSS_011a - Volcanic events 

outside Europe 

South America-So uth 

Pacific area 

10000 km2 

1B no




page 342 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

EGSE_003 - IDP (Internally 

Displaced People)/Refugee 

Support Mapping 

Africa (mainly Chad, 

Uganda, Sudan, DR Congo) 

1 million km2 

1A, 1B yes 15/50m < 10% 

On 

demand 

Once 50 Normal 

This service aims to supply products related to the mapping and management of 

Refugee and IDP camps. These services range from needs assessment and 

environmental impact maps which include information such as availability of 

resources (fuel, clean water..) to support to census databases. 

EGSE_004 - Thematic Mapping 

Africa, Latin America, 

South-East and Central Asia 

1 million km2 

1A, 1B yes 15/50m < 10% 

On 

demand 

Once 50 Normal 

Service aims to supply thematic maps of different scales to local authorities, NGOs, 

UN agencies involved in prevention, risk reduction and reconstruction planning. 

Thematic mapping products provide information on e.g. the current environmental 

situation, hazards, health status/situation etc. Health maps shall support organisations 

with information on humidity levels, distance from main water sources, population 

distribution, etc. They aim to support emergency outbreak scenarios as well as 

longer 

term health problems. 

EGSE_007 - Basic Mapping – 

Small Scale 

Africa Asia 

80000 km2 

1B no 50m < 10% Predefined Yearly (Monthly) 4 Normal 

Small scale baseline mapping of infrastructure, settlements, topography, hydrology 

etc. 

EGSE_009 - Thematic Mapping 

– Medium Scale 

Africa Asia 

6500 km2 

1B no 50m < 10% Predefined Yearly (Monthly) 0.325 Normal 

Thematic mapping of various domains covering topics like land cover/land cover 

change, agriculture crop monitoring, environmental application, 

settlements/population mapping, hydrology support etc. 

EGSE_012 - Basic Mapping – 

Small Scale 

Latin America 

500 km2 

1B yes 30m < 10% Predefined Yearly (Monthly) 0.025 Normal 

Small scale reference maps derived from archive (pre-event) data providing baseline 

mapping of topography, hydrology etc 

EGSE_013 - Mapping of glacial 

lake outburst floods (GLOF) 

Bhutan 

5000km2 

1B yes Specific Predefined 

Monthly (Lakes) 

In case of a known 

event daily 

mapping of all 

affected areas 

0.25 Normal 

The requirements given are based on the objective to perform a feasibility study on 

mapping (historical) glacial lake outburst floods using radar data and – as reference – 

optical data 

EGSE_014 - RESPOND Basic 

mapping – small scale 

Africa, Latin America, South 

East and Central Asia 

195000 km2 

1B yes 50m < 10% Predefined Once 10 Normal 

Small scale Basic maps derived from archive data providing baseline mapping of 

infrastructure, settlements, topography, hydrology etc 







page 343 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

EGSE_017 - Thematic mapping 

– medium scale 



4000 km2 

1B yes 50m < 10% Predefined Once 0.2 Normal 

Medium scale Thematic maps derived from archive data providing baseline thematic 

mapping such as natural hazard risk, population, land use and agriculture etc 

EGSE_021 -Basic mapping – 

small scale 



100000 km2 

1B yes 50m < 10% Predefined Once 5 Normal 

Small scale reference maps derived from archive data providing baseline mapping of 


EGSE_023 - In-Field Data 

Collection: small scale, large area 

Africa; Central and South 

America (incl. Caribbean); 

Central, South, and South- 

East Asia 

90000 km2 

1B no 50m 

On 

demand 

Daily for 2 weeks 

(for one event per 

year) 

4.5 NRT3h 

Deployment to disaster zone to provide real-time mapping to national and 

international emergency management and humanitarian aid agencies. 

EGSE_026 -Crisis and Damage 

Mapping – Non Charter 


South-East and Central Asia 

100000 km2 

1A/1B yes 50m < 20% 

On 

demand 

Once 5 

NRT1h, 

NRT3h 

Crisis and damage mapping products provide an assessment of the status or 

availability of infrastructure during and/or after crisis. This is achieved through the 

provision of EO or non-EO geoinformation and analysis in easy-to-use formats, 

covering areas between local and regional scales. 

EGSE_027 -Basic Mapping 

Chad, West Darfur 

500000km2 

Orhto ready yes 30m < 10% Predefined Once 25 Normal 

Large scale reference maps derived from new data. They will contain information on 



EGSE_031 UNOSAT – User 

South-East and Central Asia, 

Ambassador for UN users: Basic 

Middle East 

Mapping Small Scale 

1000000 km2 

1A yes 15m < 10% Predefined Once 50 Normal 

Core baseline maps providing topographic mapping for the area of interest coupled 

with infrastructure, logistics, gazetteers, political/administrative boundaries etc. Can 

be used as the basis for other mapping themes. This service provides basic mapping 

at small scales. 

EGSE_032 - Crisis and Damage 

Mapping 

Near real time damage maps. 

Ideally showing pre and post 

crisis event. 

50000 km2 

1A No 15m < 20% 

On 

demand 

Once 2.5 NRT3h Near real time damage maps. Ideally showing pre and post crisis event. 







page 344 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

EGSE_033 -Situation Mapping 



Middle East 

15000 km2 

1A No 15m < 20% 

On 

demand 

Once 0.75 Normal 

Provides up to date but very dynamic situation information such as security zones, 

climatic conditions, location of field operatives etc. Involves close one to one 

inputs with field staff. 

EGSE_035 -Thematic Mapping- 

Context Mapping 

Africa 

40000 km2 

1A No 15m < 20% Predefined Once 2 Normal 

Specific high resolution mapping of refugee camps and inclusion of camp data 

collected from the relief agencies. This service focuses on providing satellite 

imagery derived input to refugee/IDP camp management as databases and also 

includes the potential for in-field data collection. 

EGSE_036 -Thematic Mapping- 

Medium Scale 



Middle East 

10000 km2 

1A Yes 15m < 10% Predefined Once 0.5 Normal Thematic Mapping- Medium Scale 

EGSE_037 - Thematic Mapping- 

Large Scale 



Middle East 

500 km2 

1A yes 15m < 10% Predefined Once 0.03 Normal Thematic Mapping- Large Scale 

EGSE_039 – RISK-EOS: Burn 

Scar Mapping 

ENTENTE Zone except 

Corsica (France), South of 

Italy, Mainland Portugal 

220000 km2 

1A No 10m Predefined 

Monthly (in 

summer only) 

11 

NRT3H 

(25%) 

Normal (75%) 

Burn Scar Mapping 

SECURITY SERVICE 

SEC_002 - Crisis Indicators: 

Exploitation of natural resources 

Africa (approx 200 x 200 

Km2 covering North and 

South Kivu province in 

DRC) and part of Senegal 

(approx 500 x 500 km) 

1B yes 25m Predefined 

2-3 complete 

coverages in 3 year 

intervals 

7.5 Normal 

Crisis Indicator will be generated from a LandUse/LandCover classification 

combining HR optical data and SAR imagery, which will be linked to socioeconomic 

data. The indicators are generated with a frequency of 3 to 5 years from 

HR data and monthly from MR data 







page 345 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

SEC_002a - Crisis Indicator: 

Population pressure 

Harare, Zimbabwe (approx. 

60 by 60 km2) 

1B Yes 25m Predefined 

HR1 data: 3 annual 

updates. 

0.245 Normal 

The Crisis Indicator will be generated from a settlement classification combining 

VHR1 and HR1 optical data, which will be linked to socio-economic data 

SEC_002b - Crisis Indicators: 

Land degradation 

Eastern Zimbabwe and 

border areas of Mozambique 

and South Africa(approx 500 

x 500 Km2) 

1B Yes 25m Predefined 

HR1 data: 3 annual 

updates. 

12.5 Normal 

.The Crisis Indicator will be generated from a LandUse/LandCover classification 

combining HR2 optical data, which will be linked to socio-economic data. 

Forhotspot areas also HR1 will be used. 

SEC_003a – Critical assets 

monitoring 

Part of Africa, part of Asia 

and Part of South America 

100 km2 

1B Yes Variable < 20% Predefined < 0.1 




page 346 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

SEC_004b – Illegal Timber 

Logging 

Congo (Bandundu, Equateur 

provinces, Orientale 

province) 

10000 km2 

1B 

The lowest 

possible 

Predefined 

HR data: Half year 

beginning in spring 

2009 per 2 years; 

VHR data: every 

1 to 3 months per 2 

years. Namely: one 

HR acquisition on 

the area (area tbd, 

exact area can only 

be defined in 

collaboration with 

the user) every 6 

months. 2 HR per 

year per 2 year 

0.5 

Normal, on 

demand 

Monitoring of timber logging sites by means of optical and SAR HR and VHR data. 

The mapping frequency will be seasonal every 6 months (acquisition during the dry 

season). Possibly very limited "on demand" dataset will be used. 

SEC_004c – Illicit Crops 

Columbia AND/OR Peru 

3600 km2 

1A not 

calibrated 

no 

The lowest 

possible 

Predefined 

Twice a year in 

April (before 

harvest) and 

October 

0.18 Normal 

Identification and monitoring of illicit crop sites with HR and VHR optical data with 

mapping frequency of 6 months 

SEC_007a – Terrain analysis and 

mobility assessment 

Outside EU. High probability 

on Africa (unstable regions 

i.e. Darfur...) 

100 km2 

1B yes TBD 

On 

demand 

Two to three 

activation a year 

with about 3 maps 

for each activation 

< 0.1 

Within 12 to 

24 hours after 

data 

acquisition 

Rapid assessment for assets status to be performed in the occurrence of a crisis. This 

service chain addresses unexpected or, at least, unprepared crisis at the time of their 

occurrence 

SEC_008a – Damage 

Assessment for post conflict 

situation 

Global 

700 km2 

1B no 

On 

demand 

Once after event + 

corresponding 

archive scene 

< 0.1 Normal 

Production of a post-conflict damage assessment report derived by change detection 

on VHR/HR optical data and VHR radar data executed twice during the project 

SEC_008b – Support 

reconstruction missions after 

conflicts 

Global 

700 km2 

1B no Predefined 

Twice during each 

phase over the 

desired region 

< 0.1 Normal 

Monitoring of Reconstruction activities focussing on development and improvement 

of infrastructures based on VHR/HR optical data and VHR radar data executed twice 

during each project phase 







page 347 of 350 

Service 

Area 

Processing 

Level 


Cloud 


Frequency 

Size of 

L1C 

Compr. 

Data 

[Gbyte] 

Delivery 

INFO 

MARINE SERVICE 

MOS_001 - EMSA - 

CleanSeaNet 

MGSE_012 – Polar View: Glacier 

Monitoring 

European Seas 2 Yes Predefined 

Canada, Iceland, Northern 

Europe, 35000km2 

Daily Coverage ( 

Radar data) of each 

EU water for full 

maritime 

surveillance 

capability 

1B NA 10-30m On demand Monthly 2.1 Normal 

50 NRT3h EU Satellite surveillance service for oil spill monitoring and polluter identification 

A wide range of products are available ranging from glaciers inventory maps to 

glacier energy-balance models. 







page 348 of 350 

APPENDIX-B MSI SCENES OVERLAP ANALYSIS 

Begin of the Segment (A) definition: 

The following variables are defined: 

‣ L1 is equal to the first line of detector 1 (an odd one) on the track reference frame (in 

km); 

‣ L2 is equal to the first line of detector 2 (an even one) on the track reference frame (in 

km); 

‣ LD is equal to the first line of the product after coarse registration inter-detector (in 

km); 

‣ P is equal to the radiometric processing margin (in km); 

‣ BHD is equal to the B/H interdetector (in km, approx 47); 

‣ BHB is equal to the B/H interbands (in km, approx 14); 

‣ SCE is equal to the scene size (in km, approx 23); 

Scene no i 

interdetc. derg. (BHD) ~47km 

onboard scene (SCE) ~23km 

interband derg. (BHB) ~14km 

scene footprint 37km total 

L 

L 

LD 

L1=L2+BHD-BHB 

LD=L1+BHB+P or LD=L2+BHD+P 

Assumption: Introduce margins (additional N scene at the beginning of the segment). 

LD’, L1’ and L2’ are the new values with the new margin (N scenes), accordingly: 

LD’=L1’+BHB+P or LD’=L2’+BHD+P 

In this case, L2’=L2-N*SCE, which means that 








page 349 of 350 

LD’=L2+BHD+P-N*SCE or =L1+BHB+P-N*SCE 

End of the Segment (B) definition: 



km) of the last scene 


km) of the last scene 

‣ LF is equal to the last line of the product after coarse registration inter-dtc (in km) 

‣ P is equal to the radiometric processing margin (in km). 

Scene no k 

interdetc. derg. (BHD) ~47km 

onboard scene (SCE) ~23km 

interband derg. (BHB) ~14km 

L 

L 

LF 

L4=L3-BHD+BHB 

LF=L4 + SCE –P = L3- BHD+BHB + SCE – P 

Assumption: No scenes margin at the end 

The Junction of between two segments A/B: 



km) of the last scene (k) of segment A 


km) of the last scene (k) of segment A 








page 350 of 350 


km) of the first scene (i) of the segment B 


km) of the first scene (i) of the segment B 

L2=L4+SCE 

L1=L3+SCE 

Segment A ending line: 

(0) LF=L4+SCE-P = L3- BHD+BHB + SCE - P 

Segment B first line (with margins) 

(1) LD’=L2+BHD+P-N*SCE = L4+SCE+BHD+P-N*SCE 

(2) LD’=L1+BHB+P-N*SCE = L3+SCE+BHB+P-N*SCE 

It is required that: LD’

GSC Sentinel-2 PDGS OCD - Emits - ESA

Create successful ePaper yourself

Delete template?

Save as template?