Instrument Processing Facility Technical Specifications - emits - ESA

Instrument 

Processing Facility 

Technical 

Specification 

REF : S2-PDGS-TAS-DI-BPDP-CCTS-IPF 

ISSUE : 03 

DATE : 06/04/2012 

PAGE : 1 / 315 

Instrument Processing Facility 

Technical Specifications 

Written by Company Responsibility Date Signature 

C.Samson 

Thales 

Services 

IPF Technical Manager 

for TS 

06/04/2012 

A. Firoben Thales 

Services 

IPF Expert 06/04/2012 

R.Auriemma 

Verified by 

R.Joyeux 

Thales 

Services 

Thales 

Services 

OLQC Expert 06/04/2012 

Project Manager for TS 06/04/2012 

S. Bonnot TAS Technical Manager 06/04/2012 

Approved by 

A. Le Ber TAS Project Manager 06/04/2012 

Approval evidence is kept within the documentation management system. 

Documentation Information 

Submitted to ESA for 

Filename: 

Information Review Approval 

S2-PDGS-TAS-DI-BPDP-CCTS-IPF_03.doc 

This document may not be disclosed to a third party or reproduced without the prior written consent of Thales Alenia Space France 

All rights reserved, 2012, Thales Alenia Space




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 2 / 315 

CHANGE RECORDS 

ISSUE DATE § CHANGE RECORDS AUTHORS 

01 Draft 08/12/2011 First draft version for ESA review C. SAMSON 

A. FIROBEN 

R. AURIEMMA 

01 13/01/2012 First official version for PDR C. SAMSON 

A. FIROBEN 

R. AURIEMMA 

02 15/03/2012 Modifications after PDR review: 

- PDR-RID-134/MC-02: definitions and clarification of datastrip 

coverage in §2.1.2 

- PDR-RID-257/BL-65: clarification of performance & 

timeliness requirement traceability, S2PDGS-IPF-TRD-REQ- 

552 added for near-linearity law. 

- PDR-RID-261/BL-68: reference to scalability (S2-PDGS- 

SYS-830) reinforced through parent requirements 

- PDR-RID-263/BL-70: requirement S2PDGS-IPF-TRD-REQ- 

544 added about SW maintenance 

- PDR-RID-273/BL-71: IPF testing requirements added or 

clarified S2PDGS-IPF-TRD-REQ-549/-551/-022/-523/-048/- 

522 

- PDR-RID-274/EC-13: new § 3.2.1.3 with figures and 

clarifications on product workflows 

- PDR-RID-279/BL-72: requirements S2PDGS-IPF-TRD-REQ- 

545 to 548 added for swift integration into DPC. 

- PDR-RID-280/BL-73: §3.1.5 and S2PDGS-IPF-TRD-REQ- 

013 modified with RAM requirements, S2PDGS-IPF-TRD- 

REQ-553 added. Table on max input PU size per IDP-SC 

added in §3.2.3.5. 

- PDR-RID-281/EC-14: clarifications on RADIO_AB IDP-SC 

and new figures on IDP-SC workflows in § 3.2.1.3 

- PDR-RID-283/EC-15: all remarks/corrections in pdf 

document were taken into account 

- PDR-RID-285/EC-16: clarification of OLQC performances 

through S2PDGS-IPF-TRD-REQ-557 to 562 

- PDR-RID-286/EC-17: in §3.3.1 and 3.3.2.2 details given on 

Amalfi integration, Bridge, Summary status. S2PDGS-IPF- 

TRD-REQ-555 & 556 & 563 added 

C. SAMSON 

A. FIROBEN 

R. AURIEMMA 

N. BENECH 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 3 / 315 

- PDR-RID-287/EC-18: §3.3.2.2 updated with details on 

OLQC-GIPP and S2PDGS-IPF-TRD-REQ-491 a clarifications 

- PDR-RID-302/EC-21: clarifications/precision of each 

requirement referring to a partial DPM coverage. Table in 

Annex 2 added. 

- PDR-RID-316/EC-24: JPG2000 requirement on PVI format 

added in §3.2.7.7.1. 

- PDR-RID-406/BP-11& PDR-RID-450/MaC-12: FEP/DPC 

processing clarified 

* Other corrections: 

- Typos 

- "TBC" removal 

- § 3.5 removed from document ("Hosted" IDP-Sc for tile 

consolidation and granule aggregation). 

- Titles from §3.2.4 to 3.2.7 modified 

- S2PDGS-IPF-TRD-REQ-047 moved to §3.1.5 (ESA 

definition of Operational SW) 

- S2PDGS-IPF-TRD-REQ-045 rewording of JPEG2000 API 

- S2PDGS-IPF-TRD-REQ-046 removed (open source 

JPEG2000 benchmark) 

- S2PDGS-IPF-TRD-REQ-049/-267/-402: modified and 

moved. 

- S2PDGS-IPF-TRD-REQ-134: removed. 

- OLQC inspection tables updated in §3.3.2.1 

- References aligned on updated DPM documents 

03 05/04/2012 Modifications after pre TEB meeting 

- TCI in GML-JPEG2000 

- traceability to S2-PDGS-IDP-110 and S2-PDGS-OLQC-125 

enhanced 

- traceability to S2-PDGS-SYS-380/390/400 enhanc90 

- compliancy with PSD PDI clarified 

- Paragraph 3.2.2.1 "End to end input/ouput" added 

- list of TDS clarified 

- datablock definition clarified 

- Framing described 

C. SAMSON 

A. FIROBEN 

R. AURIEMMA 

N. BENECH 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 4 / 315 

TABLE OF CONTENTS 

CHANGE RECORDS ........................................................................................................................................ 2 

1. INTRODUCTION...................................................................................................................................... 11 

1.1 PURPOSE OF THE DOCUMENT............................................................................................................... 11 

1.2 DOCUMENT STRUCTURE ...................................................................................................................... 11 

1.3 DOCUMENTATION AND GLOSSARY ........................................................................................................ 11 

1.4 TERMINOLOGY..................................................................................................................................... 14 

2. SOFTWARE OVERVIEW ........................................................................................................................ 16 

2.1 FUNCTION AND PURPOSE ..................................................................................................................... 16 

2.1.1 Main functionalities .................................................................................................................... 16 

2.1.2 Image concepts.......................................................................................................................... 18 

2.1.3 Main characteristics of product levels........................................................................................ 20 

2.1.4 Product Data Item and Processing Unit definitions ................................................................... 22 

2.1.5 Instrument Processing Functionality Components .................................................................... 25 

2.1.5.1 IDP Software Components.................................................................................................................... 25 

2.1.5.2 OLQC Software Component.................................................................................................................. 26 

2.1.5.3 IDP-Orchestrator component................................................................................................................. 27 

2.2 ENVIRONMENTAL AND HW CONSIDERATIONS ........................................................................................ 27 

2.3 OPERATING ENVIRONMENT .................................................................................................................. 28 

2.4 RELATION TO OTHER SYSTEMS ............................................................................................................. 28 

2.5 CONSTRAINTS ..................................................................................................................................... 29 

3. IPF REQUIREMENTS.............................................................................................................................. 30 

3.1 COMMON IPF REQUIREMENTS ............................................................................................................. 30 

3.1.1 Functional requirements ............................................................................................................ 30 

3.1.2 Performance requirements ........................................................................................................ 33 

3.1.3 Operational requirements .......................................................................................................... 33 

3.1.4 Specific Resources requirements .............................................................................................. 34 

3.1.5 Design requirements and implementation constraints............................................................... 34 

3.1.6 Portability requirements ............................................................................................................. 37 

3.1.7 Software reliability requirements................................................................................................ 38 

3.1.8 Software maintainability requirements....................................................................................... 38 

3.1.9 Data definition and database requirements............................................................................... 38 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 5 / 315 

3.1.10 Human factors related requirements ......................................................................................... 39 

3.1.11 Delivery, Generation, Packaging & Deployment requirements ................................................. 39 

3.2 IDP-SC REQUIREMENTS...................................................................................................................... 41 

3.2.1 Generalities................................................................................................................................ 41 

3.2.1.1 Workflow design and IDP-SC breakdown.............................................................................................. 41 

3.2.1.2 List of IDP-SC........................................................................................................................................ 42 

3.2.1.3 Workflow description ............................................................................................................................. 50 

3.2.2 General Inputs/Outputs.............................................................................................................. 73 

3.2.2.1 End to end input/ouput .......................................................................................................................... 73 

3.2.2.2 Input/Output Image Data ....................................................................................................................... 78 

3.2.2.3 Input/Output Metadata........................................................................................................................... 78 

3.2.2.4 Input Ancillary Data ............................................................................................................................... 79 

3.2.2.5 Input Auxiliary Data ............................................................................................................................... 80 

3.2.3 Requirements common to all IDP-SC........................................................................................ 82 

3.2.3.1 Functional requirements........................................................................................................................ 82 

3.2.3.2 Performance requirements.................................................................................................................... 83 

3.2.3.3 Operational requirements...................................................................................................................... 84 

3.2.3.4 Specific Resources requirements.......................................................................................................... 84 

3.2.3.5 Design requirements and implementation constraints........................................................................... 84 

3.2.3.6 Portability requirements......................................................................................................................... 86 

3.2.3.7 Software reliability requirements ........................................................................................................... 86 

3.2.3.8 Software maintainability requirements................................................................................................... 86 

3.2.3.9 Data definition and database requirements........................................................................................... 86 

3.2.3.10 Human factors related requirements ................................................................................................. 86 

3.2.4 Requirements for L0c IDP-SC ................................................................................................... 87 

3.2.4.1 INIT_LOC_L0 ........................................................................................................................................ 87 

3.2.4.2 QL_GEO................................................................................................................................................ 91 

3.2.4.3 QL_CLOUD_MASK............................................................................................................................... 97 

3.2.4.4 FORMAT_IMG(QL JP2000) ................................................................................................................ 103 

3.2.4.5 FORMAT_ISP ..................................................................................................................................... 105 

3.2.4.6 FORMAT_METADATA(GR-L0c) ......................................................................................................... 108 

3.2.4.7 FORMAT_METADATA(DS-L0c).......................................................................................................... 111 

3.2.5 Requirements for L1A/B radiometric processing and L1A formatting IDP-SC ........................ 114 

3.2.5.1 UNFORMAT_SAFE(GR) ..................................................................................................................... 114 

3.2.5.2 UNFORMAT_SAFE(DS) ..................................................................................................................... 117 

3.2.5.3 UPDATE_LOC .................................................................................................................................... 118 

3.2.5.4 QL_DECOMP...................................................................................................................................... 124 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 6 / 315 

3.2.5.5 QL_CLOUD_MASK............................................................................................................................. 126 

3.2.5.6 INIT_LOC_ L1 ..................................................................................................................................... 126 

3.2.5.7 DECOMP............................................................................................................................................. 132 

3.2.5.8 RADIO_ AB ......................................................................................................................................... 135 

3.2.5.9 RADIO_FINALIZE ............................................................................................................................... 147 

3.2.5.10 FORMAT_METADATA(GR-L1A) .................................................................................................... 151 

3.2.5.11 FORMAT_METADATA(DS-L1A)..................................................................................................... 155 

3.2.5.12 FORMAT_IMG(L1A JP2000)........................................................................................................... 158 

3.2.6 Requirements for L1B geometric processing and formatting IDP-SC ..................................... 160 

3.2.6.1 GET_GRI............................................................................................................................................. 160 

3.2.6.2 UNFORMAT_GRI................................................................................................................................ 163 

3.2.6.3 INIT_VS_GEO..................................................................................................................................... 167 

3.2.6.4 RESAMPLE_TO_VS ........................................................................................................................... 169 

3.2.6.5 TP_COLLECT ..................................................................................................................................... 173 

3.2.6.6 TP_FILTER ......................................................................................................................................... 179 

3.2.6.7 SPATIO ............................................................................................................................................... 182 

3.2.6.8 GEO1B_FINALIZE .............................................................................................................................. 188 

3.2.6.9 FORMAT_METADATA(GR-L1B) ........................................................................................................ 191 

3.2.6.10 FORMAT_METADATA(DS-L1B)..................................................................................................... 195 

3.2.6.11 FORMAT_IMG(L1B_JP2000).......................................................................................................... 198 

3.2.7 Requirements for L1C IDP-SC................................................................................................. 201 

3.2.7.1 GET _TILE_LIST................................................................................................................................. 201 

3.2.7.2 TILE_INIT............................................................................................................................................ 203 

3.2.7.3 GEN_ORTHO_TOA ............................................................................................................................ 206 

3.2.7.4 TILE_FINALIZE ................................................................................................................................... 210 

3.2.7.5 MASK_S2............................................................................................................................................ 212 

3.2.7.6 FORMAT_IMG (L1C JP2000) ............................................................................................................. 215 

3.2.7.7 FORMAT_IMG (PVI & TCI) ................................................................................................................. 217 

3.2.7.8 FORMAT_METADATA(TILE-L1C) ...................................................................................................... 220 

3.2.7.9 FORMAT_METADATA(DS-L1C)......................................................................................................... 222 

3.2.8 Product generation performances requirement ....................................................................... 224 

3.2.8.1 L0c processing performance requirements ......................................................................................... 224 

3.2.8.2 L1A and L1B processing performance requirements .......................................................................... 225 

3.2.8.3 L1C processing performance requirements......................................................................................... 229 

3.2.8.4 Nominal processing up to Level1C...................................................................................................... 231 

3.3 OLQC-SC SPECIFIC REQUIREMENTS ................................................................................................. 236 

3.3.1 Generalities.............................................................................................................................. 236 

3.3.2 OLQC Inspections.................................................................................................................... 238 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 7 / 315 

3.3.2.1 Inspections .......................................................................................................................................... 238 

3.3.2.2 Inputs................................................................................................................................................... 259 

3.3.2.3 Outputs................................................................................................................................................ 261 

3.3.3 Requirements........................................................................................................................... 261 

3.3.3.1 Functional requirements...................................................................................................................... 261 

3.3.3.2 Performance requirements.................................................................................................................. 267 

3.3.3.3 Operational requirements.................................................................................................................... 268 

3.3.3.4 Specific Resources requirements........................................................................................................ 269 

3.3.3.5 Design requirements and implementation constraints......................................................................... 269 

3.3.3.6 Portability requirements....................................................................................................................... 270 

3.3.3.7 Software reliability requirements ......................................................................................................... 270 

3.3.3.8 Software maintainability requirements................................................................................................. 270 

3.3.3.9 Data definition and database requirements......................................................................................... 270 

3.3.3.10 Human factors related requirements ............................................................................................... 270 

3.4 IDP-ORCHESTRATOR SPECIFIC REQUIREMENTS .................................................................................. 270 

3.4.1 Generalities.............................................................................................................................. 270 

3.4.2 Requirements........................................................................................................................... 273 

3.4.2.1 Functional requirements...................................................................................................................... 273 

3.4.2.2 Performance requirements.................................................................................................................. 273 

3.4.2.3 Operational requirements.................................................................................................................... 274 

3.4.2.4 Specific Resources requirements........................................................................................................ 274 

3.4.2.5 Design requirements and implementation constraints......................................................................... 274 

3.4.2.6 Portability requirements....................................................................................................................... 274 

3.4.2.7 Software reliability requirements ......................................................................................................... 274 

3.4.2.8 Software maintainability requirements................................................................................................. 274 

3.4.2.9 Data definition and database requirements......................................................................................... 275 

3.4.2.10 Human factors related requirements ............................................................................................... 275 

4. COMMON REQUIREMENTS................................................................................................................. 276 

4.1 GENERAL REQUIREMENTS.................................................................................................................. 278 

4.1.1 High Level requirements.......................................................................................................... 278 

4.1.2 Software Quality Requirements ............................................................................................... 280 

4.1.3 Coding Standards Requirements............................................................................................. 280 

4.1.4 Data types and encoding rules Requirements......................................................................... 280 

4.1.5 HMI Requirements ................................................................................................................... 281 

4.1.6 Testing and IV&V requirements............................................................................................... 282 

4.2 COMMON SERVICES CONSTRAINTS REQUIREMENTS INCLUDING:........................................................... 287 

4.2.1 Data Circulation constraints requirements (coming from DC component) .............................. 287 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 8 / 315 

4.2.2 M&C constraints requirements (coming from M&C component) ............................................. 288 

4.3 REFERENCE PLATFORM CONSTRAINTS REQUIREMENTS INCLUDING :..................................................... 291 

4.3.1 Software configuration constraints requirements (coming from RP component) .................... 291 

4.3.2 Software building constraints requirements (coming from RP component) ............................ 292 

4.3.3 Software packaging constraints requirements (coming from RP component) ........................ 292 

4.3.4 Software delivery constraints requirements (coming from RP component) ............................ 293 

4.4 BASIC SERVICES CONSTRAINTS REQUIREMENTS INCLUDING : ............................................................... 297 

4.4.1 Network/DNS constraints requirements (coming from BS component)................................... 297 

4.4.2 Logging constraints requirements (coming from BS component)............................................ 297 

4.4.3 SW Deployment Service requirements (coming from BS component).................................... 298 

4.4.4 Access rights constraints requirements (coming from BS component)................................... 300 

4.4.5 BackUp constraints requirements (coming from BS component)............................................ 301 

4.5 COMMON REQUIREMENT DEVIATION.................................................................................................... 302 

5. TRACEABILITY ..................................................................................................................................... 307 

ANNEX 1: LISTS OF REQUIREMENTS, TBC, TBD.................................................................................... 308 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 9 / 315 

LIST OF FIGURES 

FIGURE 1: IPF FRAMEWORK IN THE OPERATIONAL CONFIGURATION (DPC-DRIVEN MODE)................17 

FIGURE 2: IPF FRAMEWORK IN THE STAND-ALONE CONFIGURATION. .................................................18 

FIGURE 3: ILLUSTRATION OF DATATAKE, DATASTRIP AND DATABLOCK. ............................................20 

FIGURE 4: IPF MACRO-COMPONENTS AND FUNCTIONALITIES (OLQC IS NOT REPRESENTED). ............22 

FIGURE 5: PROCESSING UNIT AND PDI-FE (EXAMPLE 1). ..................................................................24 

FIGURE 6: PROCESSING UNIT AND PDI-FE (EXAMPLE 2). ..................................................................25 

FIGURE 7: IPF IN THE FRAMEWORK OF PRODUCTION SERVICES..........................................................28 

FIGURE 8: IDP-SC (NOMINAL PROCESSING) AND GPP IAS RELATIONSHIP. .......................................50 

FIGURE 9: END TO END WORKFLOW (NOMINAL PROCESSING): IDP-SC BREAKDOWN ........................52 

FIGURE 10: END TO END WORKFLOW (NOMINAL PROCESSING): PARALLELIZED IDP-SC ...................53 

FIGURE 11: END TO END WORKFLOW (REPROCESSING): IDP-SC BREAKDOW.....................................55 

FIGURE 12: END TO END WORKFLOW (REPROCESSING): PARALLELIZED IDP-SC................................56 

FIGURE 13 L0C WORKFLOW: IDP-SC BREAKDOWN............................................................................58 

FIGURE 14 L0C WORKFLOW: PARALLELIZATION STRATEGY................................................................58 

FIGURE 15 L0C WORKFLOW: ILLUSTRATION OF IMAGE/METADATA FILES CIRCULATION ....................59 

FIGURE 16 L1A AND L1B WORKFLOW OVERVIEW..............................................................................62 

FIGURE 17 L1A & L1B WORKFLOW: SUB-WORKFLOWS CONTRIBUTION TO L1A, L1B GENERATION.63 

FIGURE 18 L1A&L1B WORKFLOW: IDP-SC BREAKDOWN AND PARALLELIZATION STRATEGY..........64 

FIGURE 19 L1A&L1B WORKFLOW: ILLUSTRATION OF IMAGE AND METADATA CIRCULATION ...........65 

FIGURE 20 L1A AND L1B REPROCESSING WORKFLOW: OVERVIEW....................................................67 

FIGURE 21 L1A AND L1B REPROCESSING WORKFLOW (SPECIFIC PART): IDP-SC BREAKDOWN AND 

PARALLELIZATION STRATEGY .....................................................................................................68 

FIGURE 22 L1A AND L1B REPROCESSING WORKFLOW (SPECIFIC PART): ILLUSTRATION OF IMAGE AND 

METADATA CIRCULATION............................................................................................................69 

FIGURE 23 L1C WORKFLOW: IDP-SC BREAKDOWN...........................................................................70 

FIGURE 24 L1C WORKFLOW: PARALLELIZATION STRATEGY...............................................................71 

FIGURE 25 L1C WORKFLOW: ILLUSTRATION OF IMAGE/METADATA FILES CIRCULATION....................72 

FIGURE 26: L1A AND L1B GRANULES COMPLETED WITH NO DATA ..................................................141 

FIGURE 27: OLQC-SC CONTEXT......................................................................................................237 

FIGURE 28: IDP-ORCHESTRATOR INTERFACES FOR THE STAND-ALONE CONFIGURATION. ................272 

FIGURE 29: WAY FOR ACTIVATION OF A COMPONENT.......................................................................294 

FIGURE 30: FACILITY RUN-TIME OVERVIEW......................................................................................296 

LIST OF TABLES 

TABLE 1: CHARACTERISTICS OF PRODUCT LEVELS..............................................................................21 

TABLE 2: LIST OF DETAILED PROCESSING MODEL DOCUMENTS. ........................................................26 

TABLE 3 : PROCESSING STEPS, DPM AND RELATED IDP-SC..............................................................49 

TABLE 4: LIST OF PRELIMINARY OLQC INSPECTIONS FOR L0C PRODUCT.........................................241 

TABLE 5: PSEUDO-CODE FOR L0C PRODUCT INSPECTIONS. ...............................................................245 

TABLE 6: LIST OF PRELIMINARY OLQC INSPECTIONS FOR L1A PRODUCT........................................246 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 10 / 315 

TABLE 7: PSEUDO-CODE FOR L1A PRODUCT INSPECTIONS (TABLE 6). .............................................250 

TABLE 8: LIST OF OLQC INSPECTIONS FOR L1B PRODUCT ..............................................................252 

TABLE 9: PSEUDO-CODE FOR L1B PRODUCT INSPECTIONS (TABLE 8)...............................................256 

TABLE 10: LIST OF PRELIMINARY OLQC INSPECTIONS FOR L1C PRODUCT. .....................................256 

TABLE 11: PSEUDO-CODE FOR L1C PRODUCT INSPECTIONS (TABLE 10)...........................................258 

TABLE 12: LIST OF OLQC PRELIMINARY INSPECTIONS COMMON TO ALL PRODUCT LEVELS .............258 

TABLE 13: PSEUDO-CODE FOR INSPECTIONS COMMON TO ALL PRODUCTS (TABLE 12)......................259 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 11 / 315 

1. INTRODUCTION 

1.1 Purpose of the document 

This document provides the Software Requirement Specification of the S2-PDGS 

Instrument Processing Facility. It answers to the S2 PDGS System Requirements and is 

linked to it via Upper and Lower Justification and Traceability Matrices. This technical 

Specification is completed by an Interface Control Document [CICD-IPF]. 

1.2 Document Structure 

This document is structured as follows: 

Chapter 1: 

Chapter 2: 

Chapter 3: 

Chapter 4: 

Chapter 5: 

Provides the current introduction, describing the scope and the structure of 

the document, and the list of applicable and reference documents; 

Describes the IPF components 

Provides the list of IPF requirements 

Presents the Requirements common to all the S2 core PDGS components. 

Contains the traceability matrix; 

1.3 Documentation and Glossary 

Acronyms used in the documentation are defined in S2 PDGS Glossary & definitions 

Document [S2-PDGS-TAS-DI-CMS-GLODEF] 

The list of Applicable and Reference documents is defined in the following tables: 

Applicable Documents 

Reflabel Reference Version Date Title 

SOW-IPF 

CICD-IPF 

S2-PDGS-TAS-DI-BP- 

IPF-SOW 5.0 03/04/2012 

S2-PDGS-TAS-DI- 

BPDP-ICD-IPF 3.0 06/04/2012 

Statement of Work for S2 PDGS IPF 

Project 

Interface Control Document 

Instrument Processing Facility 

AD-8 ECSS-E-ST-40 C 06.03.2009 ECSS Space Engineering Software 

PSD 

S2-PDGS-TAS-DI- 

PSD 

3.0 06/04/2012 Product Specification Document 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 12 / 315 

Reference Documents 


SMICD 

OCD 

SRD 

STCD 

NRTPOD- 

ICD 

S2-PDGS-TAS-DI-ICD- 

MICD 

GMES-GSEG-EOPG-TN- 

09-0008 

GMES-GSEG-EOPG-RD- 

09-0028 


09-0030 

GMES-GSEG-EOPG-IC- 

11-0022 

2.0 04/04/2012 Master Interface Control Document (MICD) 

2.2 15/12/2011 S2 PDGS Operations Concept Document 

2.2 15/12/2011 S2 PDGS System Requirement Document 

2.1 15/07/2011 S2 PDGS System Test Concept Document 

0.1 draft 25/03/2011 Sentinel-2 Core PDGS NRT POD ICD 

GRI-TN 

POD-FFS 

GPP- 

L1ABCPS 

(*) 

GPP- 

L1ABCPS 

(*) 

(*) 

(*) 

(*) 

(*) 

(*) 

(*) 


10-0071 

GMES-GSEG-EOPG-FS- 

10-0075 

0.1 draft 03/12/2010 Sentinel-2 Global Reference Images Generation 

GMES Sentinels Precise Orbit Determination (POD) 

1.1 28/02/2011 Service: OFL POD Service and NRT POD Facility File 

Format Specifications 

GS2-ST-SY-40-CNES 1.1 14/12/2009 SENTINEL 2 VIEWING MODEL 

GS2-NT-SY-50-CNES 1.0 12/06/2009 IMAGE GEOMETRIC MODELLING AND REFINING 

Processing Specification for Level 1A, 1B and 1C 

GS2-ST-GSGP-40-CNES 1.1 14/12/2009 

Production 

TECHNICAL SPECIFICATION LOCATION METHODS 

GS2-ST-GSIP-30-CNES 1.0 

FOR INVENTORY AND QUICKLOOK GENERATION 

01/06/2009 

SPECIFICATIONS 

IMAGE ALGORITHM SOFTWARE INIT_LOC_INV_S2 

METHOD SPECIFICATIONS FOR INVENTORY 

GS2-ST-GSIP-40-CNES 1.0 12/06/2009 

CLOUD COVER GENERATION. IAS CLOUD_INV_S2 


LOCATION METHODS FOR PRODUCTION 

09/06/2009 SPECIFICATIONS IMAGE ALGORITHM SOFTWARE : 

INIT_LOC_PROD_S2 

RADIOMETRIC PROCESSING METHODS FOR LEVEL 

GS2-ST-GSIP-60-CNES 1.0 10/06/2009 1 PRODUCTION: IMAGE ALGORITHM SOFTWARE 

RABPO_S2 

TECHNICAL SPECIFICATION LOCATION METHODS 


SPECIFICATION FOR INVENTORY AND LEVEL 1 

12/06/2009 

PRODUCTION IMAGE ALGORITHM SOFTWARE 

GEO_S2 

RESAMPLING METHODS SPECIFICATION FOR 

GS2-ST-GSIP-80-CNES 1.0 12/06/2009 LEVEL 1C PRODUCTION. IMAGE ALGORITHMIC 

SOFTWARE RESAMPLE_S2 

TECHNICAL SPECIFICATION 

GS2-ST-GSIP-90-CNES 1.0 12/06/2009 CLOUD MASK AND LAND/WATER MASK EBPTION 

FOR LEVEL 1C PRODUCTION. IMAGE ALGORITHMIC 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 13 / 315 


SOFTWARE MASK_S2 

(*) 

GROUND PROTOTYPE PROCESSOR INTERFACES 

GS2-IF-GSGP-60-CNES 1.0 02/06/2009 

REQUIREMENTS 

System DEM Description (GLOBE, filtered SRTM) 

GPP-DEM GS2-IF-GSGP-70-CNES 1.1 18/03/2010 

content and format 

(*) 

(*) 

(*) 

(*) 

(*) 

(*) 

(*) 

GS2-IF-GSIP-120-CNES 1.0 

OPERATIONAL AND INTERFACE REQUIREMENTS 

10/06/2009 FOR IMAGE ALGORITHMIC SOFTWARE DATATION 

AND LR EXTRACTION 


GS2-IF-GSIP-130-CNES 1.0 09/06/2009 FOR IMAGE ALGORITHMIC SOFTWARE 

INIT_LOC_INV_S2 

OPERATIONAL AND INTERFACE REQUIRE MENTS 

GS2-IF-GSIP-140-CNES 1.0 12/06/2009 FOR IMAGE ALGORITHMIC SOFTWARE CLOUD 

COVER INVENTORY NOTATION (CLOUD_INV_S2) 


GS2-IF-GSIP-150-CNES 1.0 07/06/2009 FOR IMAGE ALGORITHMIC SOFTWARE INIT_LOC 

PRODUCTION 


GS2-IF-GSIP-160-CNES 1.0 10/06/2009 

FOR IMAGE ALGORITHMIC SOFTWARE RABPO_S2 


GS2-IF-GSIP-170-CNES 1.0 12/06/2009 

FOR IMAGE ALGORITHMIC SOFTWARE GEO_S2 


GS2-IF-GSIP-180-CNES 1.0 12/06/2009 FOR IMAGE ALGORITHMIC SOFTWARE 

RESAMPLE_S2 


(*) GS2-IF-GSIP-190-CNES 1.0 09/06/2009 

FOR IMAGE ALGORITHMIC SOFTWARE MASK_S2 

GPP-DPM- 

IAS02 

GPP-DPM- 

IAS03_05 

GMES Sentinel-2 Ground Prototype Processor – 

GPP-DD-ACS-S2-0122 2.2 05/08/2011 IAS#02 “Datation&LR_Extraction” Detailed Processing 

Model 

GMES Sentinel-2 Ground Prototype Processor – IAS03- 

GPP-DD-MAG-S2-0123 2.2 15/07/2011 05 “Init_Loc_Inv_S2” & “Init_Loc_Prod” Detailed 

Processing Model 

GPP-DPM- 

IAS04 

GMES Sentinel2 Ground prototype processor – IAS#04 

GPP-DD-ACS-S2-0124 2.2 05/08/2011 

“cloud_inv_S2” detailed processing model 

GPP-DPM- 

IAS06 

GPP-DPM- 

IAS07 

GPP-DPM- 

IAS08 

GPP-DPM- 

IAS09 

GPP-DPM- 

IAS10 


GPP-DD-MAG-S2-0125 2.2 15/07/2011 

IAS#06 “Radio_S2” Detailed Processing Model 


GPP-DD-MAG-S2-0126 2.3 05/04/2011 

IAS#07 “Geo_S2” Detailed Processing Model 


GPP-DD-MAG-S2-0127 2.3 05/04/2011 

IAS#08 “Resample S2” Detailed Processing Model 


GPP-DD-ACS-S2-0128 2.2 05/08/2011 

IAS#09 “Mask_S2” Detailed Processing Model 

GPP-DD-MAG-S2-0129 2.1 10/04/2011 

GMES Sentinel-2 Ground Prototype Processor –3 IAS 

10 “JP2K Compression” Detailed Processing Model 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 14 / 315 


GPP-DPM- 

RESAMP 

GPP-DPM- 

GEOREF 

GPP-DPM- 

VMASK 


GPP-DD-MAG-S2-0143 2.2 05/04/2012 

Resampling Detailed Processing Model 


GPP-DD-MAG-S2-0144 3.1 10/04/2011 

Geolocation and Refining Detailed Processing Model 

GMES Sentinel-2 Ground Prototype Processor – Vector 

GPP-DD-MAG-S2-0145 2.1 10/04/2011 

Masks Detailed Processing Model 

CALVALPE2 GMES-GSEG-EOPG-PL- 

10-0054 

(*) GS2-ICD-GS-80-CNES 

GMES Sentinel-2 Calibration and Validation Plan for the 

1.0 30/06/2011 

Operational Phase 


Interface Control Document (XSD Set .zip) 

EOFFS- 

PDGS 


2010-0099 

Earth Observation GS File Format Standard – Tailoring 

1.0 28/02/2011 

for the Sentinel Missions PDGS 

GML 3.1.1 Application schema for Earth Observation 

HMA-GML OGC 06-080r2 0.9.0 18/06/2007 

products 

SAFE-TN 

GMESPH-ACS-TEC- 

TNO24-E 

GMES Products Harmonisation SAFE Implementation : 

1.1 25/12/2010 

Sentinel2 Support 

SAFE-SPEC GAEL-P264-DOC-0001- 

01-01 

1.0 25/07/2011 Sentinel Standard Archive Format for Europe 

GEN- 

PDGSIPF 


09-0016 

1.0 24/09/2009 GMES Generic PDGS-IPF Interface Specifications 

AMALFI- 

SUM 

GAEL-P264-SUM-001 3.3 10/2011 Amalfi User Manual 

DRB-SUM GAEL-P243-DOC-001 1.1 30/09/2008 Data Request Broker DRB API Handbook 

TDS-TN GPP-TN-DLR-S2-0140 3.0 16/09/11 Test Data Specifications 

MDS- 

SUM- 

MRCPBG 

COM(2005 

)_438final 

(*) included in GPP-ADL 

MAG-MRCPBG-MIMU- 

01-LAN 

6.0 10/11/11 

21/09/05 

MRCPBG v9.0 installation instructions and user 

manual 

DIRECTIVE OF THE EUROPEAN PARLIAMENT AND 

OF THE COUNCIL on the retention of data processed 

in connection with the provision of public electronic 

communication services and amending Directive 

2002/58/EC 

1.4 Terminology 

This paragraph clarifies the terminologies used in the following chapters. 

 

“L0c” or “L1x” may be used instead of “Level-0 consolidated” or “Level-1x” products 

(x=A,B or C) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 15 / 315 

 

If not specified, a level-1C product includes the L1C, PVI and TCI data 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 16 / 315 

2. SOFTWARE OVERVIEW 

2.1 Function and purpose 

2.1.1 Main functionalities 

The Level-0 and Level-1 Instrument Processing Facility (IPF) corresponds to a set of 

data processing software elements fulfilling the requirements of the Instrument Data 

Processing (IDP) function of the PDGS associated to MSI Level-0 and Level-1 data 

processing. The IPF also contains a set of essential quality checks performed on each 

product generated by the IDP thanks to the implementation of the On Line Quality 

Control (OLQC) function. 

In the operational configuration (or "DPC-driven configuration"), the PDGS Data 

Processing Control (DPC) component is in charge of performing the IDP function by 

orchestrating a set of Instrument Data Processing Software Components (IDP-SC) in 

order to generate the Level-0c up to Level-1C products. The DPC is also responsible for 

checking the quality of generated products by calling the OLQC Software Component 

(OLQC-SC) in the production workflows. 

The main goal of the IPF developments is to implement the IDP and OLQC functions. 

These developments will be integrated by the PDGS Prime Contractor (hereafter referred 

to as “TAS-F”) within the DPC environment. 

In order to test the complete workflow, the IPF also includes the development of a specific 

software, the "IDP-Orchestrator", that allows to test the end-to-end processing in isolation 

from the DPC (or "stand-alone configuration"). The IDP-Orchestrator software component 

will implement an end-to-end processing in a simplified (e.g. not fully optimized in term of 

processing timeline compared to the DPC environment configuration) workflow triggering 

all IDP-SC and OLQC-SC in a logical sequence. This software component will not be 

integrated into the DPC environment. 

In the DPC-driven configuration, the processing of raw Level-0 data to higher level 

products is performed by a sequence of IDP-SC followed by an OLQC function applied on 

each generated product (see Figure 1). The DPC orchestration is based on: 

Incoming inputs 

Processing sequence 

Priority rules (timeliness) 

HW resource 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 17 / 315 

DPC 

Orders/Configs 

AUX/ANC/IMG 

Reports 

IDP-SC 

L0c, L1A, L1B, L1C 


GIPP 

Reports 

OLQC-SC 


(OLQC-checked) 

IPF components 

Figure 1: IPF framework in the operational configuration (DPC-driven mode). 

In the stand-alone configuration, the set of IDP-SC and OLQC-SC are interfaced with 

the IDP-Orchestrator controlled by an Operator. The Figure 2 shows the IPF software 

components in orange and the components required for the stand-alone configuration in 

blue (for testing, verification and validation purposes). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 18 / 315 

Operator 

Reports 

Logs 

Orders 

IDP-Orchestrator 

(stand-alone mode) 


Aux/Anc/Img/Meta 

Reports 

Logs 


GIPP 

L0c/L1x PU 

Reports 

Logs 

IDP-SC 

OLQC-SC 




AUX/ANC/PU 

IPF components 

Testing components 

Figure 2: IPF framework in the stand-alone configuration. 

The interfaces of IPF components are fully described in [CICD-IPF]. 

2.1.2 Image concepts 

This paragraph identifies some important notions regarding image concepts: 

 

a granule is the product minimum indivisible partition (containing all possible 

spectral bands): 

‣for Levels 0c, 1A and 1B, the granules are sub-images of a detector, with a given 

number of lines along track; therefore a granule covers approximately 25 km 

across track and 23 km along track; 

‣for ortho-rectified products (Level 1C), the granules, also called tiles, are 100 

km 2 ortho-images in UTM/WGS84 projection; 

 

a scene is the gathering of the 12 L0c, L1A or L1B granules (one by detector) 

imaged at the same time, corresponding to an acquisition of approximately 290 km 

across track and 23 km along track; 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 19 / 315 

 

 

 

a datablock corresponds to several consecutive scenes with the same priority and 

downlinked in the same CGS during the same pass; therefore, there is no gap inside 

a datablock, and associated images match a continuous geographic area; 

a datastrip is a part of orbit corresponding to an acquisition of Sentinel-2 (for a 

given imaging orbit and acquired using a continuous MSI operation mode), 

downlinked on a given station and on a given pass; 

a datatake is a part of orbit corresponding to an acquisition, for a given imaging orbit 

and acquired using a continuous MSI operation mode. 

The following schema illustrates the notions of datatake, datastrip and datablock: 

there are 4 different datablocks, named 6, 7, 8 and 9; 

there is only one datastrip in CGS1, composed of datablock 7; 

 

there are two datastrips in CGS2, one composed of datablocks 6 and 8 (with a gap 

in the middle matching datablock 7, downlinked in another CGS), and a second one 

with datablock 9; 

there is a first datatake acquired during MSI mode 1 composed of datablocks 6, 7 

and 8, and a second datatake acquired during MSI mode 3 composed of datablock 

9. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 20 / 315 

MSI Mode 1: 

Data-take 1 

6 

Data-block 6: 

Nominal 

MSI Mode 1 

7 

Data-block 7: 

NRT 

NRT 

MSI MSIMode Mode2: 

2 

idle 

8 

8 

Data-block 8: 

Nominal 

MSI Mode 3: 

Data-take 2 

9 

CGS 1 

CGS 2 

Figure 3: Illustration of datatake, datastrip and datablock. 

2.1.3 Main characteristics of product levels 

The IDP-SC are the set of software that implements the processing required to generate 

S2-PDGS L0c, L1A, L1B and L1C product levels from S2-PDGS L0 non-consolidated 

product, auxiliary and ancillary data of a given datastrip sent by DPC. The Table 1 

presents the main charts of each product level. 

Each generated product of this table will be subject to quality check inspections through 

the use of OLQC-SC. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 21 / 315 

Product- 

Type 

Identifier 

L0 (PDGS 

internal) 

S2MSI0 

S2MSI1A 

S2MSI1B 

S2MSI1C 

Processing 

Level 

L0 

L0c 

L1A 

L1B 

L1C 

Outline Description 

MSI raw-image data and SAD raw 

data, L0 non consolidated 

components are taken as an input 

by the first level of IPF processing 

chain 

MSI raw-image data compressed in 

ISP format 

MSI uncompressed raw image data 

with spectral bands coarsely 

coregistered and appended Ancillary 

data 

Radiometrically corrected 

(calibrated) MSI image data with 

spectral bands coarsely coregistered 

and refined geometric 

model appended but not applied 

Ortho-rectified and UTM geo-coded 

Top-of-Atmosphere Reflectance with 

sub-pixel multispectral and multidate 

registration 

Granularity 

Per detector and 

on-board scene 

25km across-track x 

23km along-track 

Per detector and 

on-board scene 



Granules: per 

detector and alongtrack 

on-board 

scene size 



Along-track band 

co-registration is 

performed 

w.r.t. one reference 

band of the L0 

scene 

100km x 100km 

UTM tile 

Tiles are identified 

on a fixed world 

reference 

system based on 

UTM zones 

Table 1: Characteristics of product levels. 

At IPF/IDP level, the notion of overlapping scenes is not known; the scenes located at the 

extrema of a datablock are processed in any case (overlap or not). In particular: 

the full set of L0 non-consolidated granules as input of L0C processing are produced 

(including overlaping granules) 

for L1A, L1B and L1C processing, the production area is configured through GIPP 

(framing parameters) 

The Figure 5 presents the data processing workflow from the Instrument Source Packets 

up to the final products. The set of IPF functionalities is represented in macroscopic 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 22 / 315 

components (orange boxes), each one is based on a set of IDP-SC presented in the next 

sections. The OLQC functionality is not presented on this figure. 

ISP 

L0 non consolidated processing 

ISP 

Telemetry 

Analysis 

SAD 

Datation 

Low 

Resolution 

Extraction 

SAD 

Telemetry 

Analysis 

Products 

L0c L1A L1B L1C TCI PVI 

IPF 

(without OLQC) 

JPEG2000 

Compression 

JPEG2000 

Compression 

JPEG2000 

Compression 

JPEG2000 

Compression 

JPEG 

Compression 

Quick Look 

& 

Viewing 

Model 

Initialization 

& 

Cloud Cover 

Decompression 

& 

L1A 

Radiometric 

Corrections 

L1B 

Radiometric 

Corrections 

Geometric 


(Viewing 

Model 

Refinement) 

Tiling 

& 

Resampling 

& 

TOA 

Reflectance 

on tiles 

TCI 

& 

PVI 

processing 

Figure 4: IPF macro-components and functionalities (OLQC is not represented). 

2.1.4 Product Data Item and Processing Unit definitions 

The following sections will use the notion of Product Data Items (PDI) at different levels: 

granule/tile or datastrip. 

A PDI contains a set of PDI-FE as defined hereafter: 

PDI-FE: a PDI File Element is a single file that can be: 

PDI-FE-GR: A file at GRanule (or tile) level 

PDI-FE-DS: A file at Data Strip level 

PDI-FE-ATF: A single file which is an Along Track Fragment of a detector-based 

item (e.g. : concatenation of granule MSI data with processing margins …) 

A PDI-GR is a set of PDI-FE-GR relevant to the same granule (or tile). 

A PDI-DS is a set of PDI-GR with additional PDI-FE-DS relevant to the same datastrip. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 23 / 315 

A Processing Unit (PU) is the set of input/output of each IDP-SC or OLQC-SC and is a 

collection of set of PDI-FE. 

The 2 examples on Figure 5 and Figure 6 illustrate these definitions. 

On Figure 5: 

The input PU includes: 

a single file (PDI-FE-ATF) being concatenation of 3 granules and margins 

3 metadata files at granule level (PDI-FE-GR) 

the metadata at datastrip level (PDI-FE-DS) 

The output PU includes updated or created files: 

3 image files at granule level (PDI-FE-GR) 

3 updated metadata files at granule level (PDI-FE-GR) 

On Figure 6: 

The input PU in those examples include : 

4 granules image files (PDI-FE-GR) 

4 metadata files at granule level (PDI-FE-GR) 

the metadata at datastrip level (PDI-FE-DS) 

The output PU includes updated or created files: 

A single image file (PDI-FE-ATF) being a concatenation of 4 granules 

4 updated metadata files at granule level (PDI-FE-GR) 

Notes: 

these examples could be extended to a PDI-FE-ATF of any arbitrary along track 

length, 

output image file could be repackaged as a single PDI-FE-ATF file 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 24 / 315 

Output PU 

IDP-SC 

PDI-FE : image file 

PDI-FE : metadata file 

PDI-FE-ATF 

PDI-FE-GR 

Input PU 

PDI-FE-DS 

Figure 5: Processing Unit and PDI-FE (Example 1). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 25 / 315 

Output PU 

IDP-SC 

PDI-FE : image file 

PDI-FE : metadata file 

PDI-FE-ATF 

PDI-FE-GR 

Input PU 

PDI-FE-DS 

Figure 6: Processing Unit and PDI-FE (Example 2). 

2.1.5 Instrument Processing Functionality Components 

2.1.5.1 IDP Software Components 

Each IDP-SC performs a set of Processing Steps that implements the algorithms 

described in the Detailed Processing Models (DPM) documents originated from the ESA 

Ground Prototype Processor (GPP) project (in the GPP project, the DPM have been 

implemented into Image Algorithm Softwares - IAS). The list of DPM is given in Table 2. 

The set of PDGS IDP-SC are defined based on the DPM algorithms and timeliness 

requirement analysis. 

Id DPM title Reference 

DPM at GPP-IAS level 

[LR_EXTR-DPM] Datation and Low Resolution 

Extraction (Resampling to QL 

resolution part) 

GPP-DDMAG- 

S2-0122 

Issue/Revision: 2.2 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 26 / 315 

Id DPM title Reference 

DPM at GPP-IAS level 

[INIT_LOC-DPM] Init_Loc_Inv_S2 Init_Loc_Prod 

Detailed Processing Model 

GPP-DDMAG- 

S2-0123 

[CLOUD_INV- 

DPM] 

[JP2K-DPM] 

[RADIO-DPM] 

[GEO_1B-DPM] 

[RESAMPLE_1C- 

DPM] 

Cloud_Inv_S2 Detailed 

Processing Model. 

JP2K Compression Detailed 


Radio_S2 Detailed Processing 

Model 

GEO_S2 Detailed Processing 

Model 

RESAMP_S2 Detailed Processing 

Model 

[MASK_1C-DPM] Mask_S2 Detailed Processing 

Model 

[RESAMP-DPM] 

[GEOREF-DPM] 

[VMASK-DPM] 

DPM at function level 

Resampling Detailed Processing 

Model 

Geolocation and Refining Detailed 


Vector Masks Detailed Processing 

Model 


GPP-DD-ACS-S2-0124 

IAS04 - Issue/Revision: 

2.2 

GPP-DD-MAG-S2- 

0129 - 

IAS10 Issue/Revision: 

2.1 


0125 IAS06 - 



0126 IAS07 - 



0127 IAS08 - 


GPP-DD-ACS-S2-0128 

IAS09 - Issue/Revision: 

2.2 


0143 - 



0144 Issue/Revision: 

3.1 


0145 - 


Table 2: List of Detailed Processing Model documents. 

The Table in Annex 2 is listing the DPM sections covered by several IDP-SC. 

2.1.5.2 OLQC Software Component 

The OLQC-SC aims at fulfilling the OLQC function of the PDGS. The role of the OLQC-SC 

within the processing chain is to perform quality checks on the product data generated by 

the IDP. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 27 / 315 

The OLQC-SC is integrated in the PDGS as a single software component orchestrated 

within the processing chain by the DPC, in the same way as for any IDP-SC. From the 

DPC point of view, the OLQC-SC can be considered as an IDP-SC (i.e. the OLQC can be 

called by the DPC as any of the IDP-SC). The OLQC-SC will perform systematic 

production inspections for quality control verifications over the set of generated products 

before delivering the archive center. 

The software will be invoked by the DPC function on every new product data component 

generated by the IPF in a fully automated way. The outputs containing the inspections 

results will be accordingly archived and inventoried within the PDGS via the DPC. 

2.1.5.3 IDP-Orchestrator component 

The IDP-Orchestrator component is a test mean (stand-alone mode) that is used to 

orchestrate the IDP-SC components in order to demonstrate DPM end-to-end 

conformance for the IDP-SC. The IDP-Orchestrator, as a DPC stub, has the same 

interface with the IDP-SC than the DPC has with the IDP-SC. 

The list of IDP-SC to call, the calling sequence and the list of inputs/outputs files are 

defined in processor Task Tables (see definition in [CICD-IPF] and [GEN-PDGSIPF]). 

The role of the IDP-Orchestrator is to: 

Instantiate the Task Tables (Job Order generation) 

Execute the instantiated Task Table scenario 

Chain a set of Task Tables for end-to-end production 

2.2 Environmental and HW considerations 

The set of IPF software components to be developed will have to be integrated into the 

S2-PDSG HW environment, hereafter referred to as the Reference Platform, which has 

these minimal hardware characteristics: 

OS Red Hat Linux 6.2. 

Bi-Processors Intel Xeon 5650 2.66 GHz, 6 cores per processor 

2GB RAM per core 

SAN disks (with General Parallel File System GPFS) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 28 / 315 

IPF blade servers are sized so that they can host one concurrent IPF process for 

each core, leaving one core available for OS kernel and process (one Xeon X5650 

blade server can host up to 11 concurrent IPF processes). 

2.3 Operating Environment 

The IPF components will be integrated into the Production Services (see Figure 7). The 

Production Services are a set of software (mainly in Java and C++) running on a set of 

blade servers on a GNU/Linux based operating system, with an access to a shared SAN in 

order to store the processed images. 

Processing are essentially performed in an automatic manner upon data reception from a 

satellite (data-driven approach). 

Nevertheless, one (or possibly several) operator workstations allow to monitor and control 

the processing or to manually execute workflow (depending on the access rights). 

Production Services 

 

DPC orchestrator 

Instrument Processing 

Functionality 

 

IDP Orchestrator 

manage 

manage 

manage 

manage 

 

Data Exchange 

Manager 

 

Hosted Processing 

 

Telemetry 


 

Image Processing 

execute 

execute 

launch 

launch 

 

IPF Hosted Processing 

 

 

HP-SC 

HP-IAS 

 

HP-IAS 

use 

use 

 

PDGS-IAS 

use 

use 

 

OLQC-SC 

use 

 

DFEP 

 

S2_WICOM 

DECOMPRESSION 

 

JP2K 

COMPRESSOR 

 

AMALFI 

 

S2_WICOM 

DECOMPRESSION 

 

Figure 7: IPF in the framework of Production Services 

2.4 Relation to other systems 

The IPF components will be interfaced with the DPC of the Production Services. 

The detailed interfaces of each component are fully described in [CICD-IPF]. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 29 / 315 

2.5 Constraints 

The OLQC-SC shall make use of the CFI Amalfi-2 SW and shall run within very limited 

time and resources such as not to take more than 5% of the overall processing-chain 

budget. In addition, Amalfi-2 software used by OLQC-SC requires Java 6 Virtual 

Machine (JVM6) installed or higher version. 

The IDP-SC decompression of on-board MSI shall use the WICOM software delivered by 

the Agency as a CFI. 

The set of IDP-SC and OLQC-SC shall be compliant with the DPC interface as defined in 

[CICD-IPF]. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 30 / 315 

3. IPF REQUIREMENTS 

This section presents the IPF requirements as follows: 

Requirements common to all IPF components 

Requirements for the set of IDP-SC: 

Requirements common to all IDP-SC 

Requirements per IDP-SC 

Requirements for the OLQC-SC 

Requirements for the IDP-Orchestrator 

3.1 Common IPF Requirements 

The requirements listed in this paragraph are common to the IDP-SC and OLQC-SC (and 

IDP-Orchestrator if specified). 

For IPF testing, verification and validation purpose, a Test Data Set (TDS) will be delivered 

as a CFI to the IPF Contractor. This TDS will be generated from the TDS issued by the 

Ground Prototype Processor (GPP) project [TDS-TN]. The TDS delivered to the IPF 

Contractor will contain 2 sets of data: 

the main product levels reformatted for S2-PDGS as defined in [PSD]; 

the complementary data directly issued from the GPP, delivered “as is” in order to be 

used for testing and validations of intermediate processing steps. 

3.1.1 Functional requirements 

Reference S2PDGS-IPF-TRD-REQ-001 : 

The set of IDP-SC and OLQC-SC shall implement the geometric and radiometric 

correction algorithms allowing performing: 

the processing of MSI Level 0 data into higher level products: L0c, L1A, L1B, L1C, 

PVI, TCI, 

a set of quality inspections for each generated product. 

Parents: S2-PDGS-SYS-005, S2-PDGS-SYS-320, S2-PDGS-IDP-005, S2-PDGS-OLQC-005 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 31 / 315 

Reference S2PDGS-IPF-TRD-REQ-550 a : 

Each IDP-SC or OLQC-SC shall check the validity of its input dataset and shall exit with a 

specific error code in case of input not valid before any processing. 

The validity can be checked on the following non exhaustive list of inspections: 

Existence of the input data (e.g. input directory contains files, …) 

Integrity of the data (e.g. xml file are conform to xsd schemas, …) 

Inputs are conform to expected files (e.g. the set of GIPP input files are the correct 

ones required for the given IDP-SC, …) 

Parents: 


Each IDP-SC and OLQC-SC shall be able to extract the useful data for its processing from 

the whole set of input data (DEM tiles, Global Reference Image GRI interesting area, GIPP 

files…). 

Example: the IDP-SC in charge of geometric model refining shall extract the datastrip(s) of 

interest from the GRI and the useful tiles from the DEM. 

Parents: 


Any IDP-SC or OLQC-SC significant event shall be logged in real-time (without delay 

between the event and log message diffusion) and the event start and stop shall be 

indicated by specific messages. 

Parents: S2-PDGS-IDP-040, S2-PDGS-IDP-045, S2-PDGS-IDP-050 


The IDP-SC or OLQC-SC login messages shall be time-stamped. 



The IDP-SC and OLQC-SC shall dynamically construct the logging messages (i.e. no 

hard-coded value of logging attributes) and shall use one or several XML Log 

Configuration file in order to define the Log attributes and possibly modify them in an easy 

way. 

Log messages shall comply with detailed definition given in [CICD-IPF]. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 32 / 315 


The log messages shall be adapted to the level of knowledge of the destined user. For 

example the knowledge of the Exploitation team is based on Software User Manual (SUM) 

content; hence any Log message presented to this team shall be in the scope of SUM 

level content. 



Each IDP-SC or OLQC-SC shall have a trace mode of execution. In this mode, additional 

intermediate or trace files containing information for expert users or maintenance team will 

be generated during the execution. 

This mode shall be enabled from the "Breakpoint" tags of the Job Order Interface file 

(mode enabling and intermediate files listing). 

Parents: 

Reference S2PDGS-IPF-TRD-REQ-549: 

For each IDP-SC or OLQC-SC, metadata and image created or updated shall be 

compared and validated according to the RTDS metadata (intermediate metadata and/or 

product level metadata) 

Parents: 


Each IDP-SC or OLQC-SC, hereafter referred to as SC, shall have a STUB version. This 

preliminary SC version shall implement: 

the set of interfaces as defined in [CICD-IPF] with full compliancy 

the check and validation of input data (existence, integrity and conform to expected 

data per SC) 

the minimal logging capability and message such that to identify the start and stop of 

the main processing function of each SC 

a representative implementation of the Input and Output data volume and data 

management (in order to test disk access mechanisms) with expected number of 

files and file size per SC 

output metadata with naming conventions compliant with [PSD] befor TAR archiving 

(filename, pathname..) and as much as possible meaningful other data (i.e.: 

metadata values as close as possible to real use-case values): 

the possibility to configure through the set of SC interface: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 33 / 315 

o the volume of input data per SC (N granules, full datastrip…) 

o the processing time per SC 

Parents: 

3.1.2 Performance requirements 

Reference S2PDGS-IPF-TRD-REQ-008 a: 

The generation of a L1C product: 

on a datastrip with an along-track length of 6640km, 

by a chain of IDP-SC (including radiometric restoration and geometric refinement) 

and OLQC-SC enabled, 

shall be performed in less than 128 hours when the IDP-SC are sequenced on a singlecore 

of the Reference Platform HW environment without parallelization. 

Parents: S2-PDGS-IDP-080,S2-PDGS-OLQC-105 


The individual performance of each IDP-SC, OLQC-SC and end-to-end performance shall 

be measured on the same environment configuration: 

same HW platform (the so-called Reference Platform §2.2) 

same O/S 

same input data (same L0 data, same GIPP, same DEM, same GRI…) 

Parents 


The individual performance of each IDP-SC, OLQC-SC shall be benchmarked using the 

Reference Test Data Set (RTDS). 

Parents 

3.1.3 Operational requirements 

Requirements are derived per IDP-SC and OLQC-SC in next paragraphs. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 34 / 315 

3.1.4 Specific Resources requirements 

No specific requirement has been identified. 

3.1.5 Design requirements and implementation constraints 


Every IPF component shall be delivered as ESA Operational Software (in particular source 

code of IDP-SC in version 1 shall be delivered), except for the following (Non Operational 

Software) basic elements: 

Elementary and generic mathematical libraries (e.g. at the level of math.h or below) 

which are embedded elementary functionality of the (Linux) operating system or the 

like; 

Advanced and generic mathematical libraries for which the source code is made 

available (e.g. Numerical Recipes http://www.nr.com/); 

Generic image processing libraries for which the source code is made available (e.g. 

OSSIM http://www.ossim.org, ITK http://www.itk.org, etc.); 

Generic orbital calculations libraries for which the source code is made available or 

ESA’s Earth Observation CFI software (http://eopcfi.esa.int/); 

Kakadu JPEG2000 closed source code library http://www.kakadusoftware.com/ if 

this is the chosen solution on JPEG2000 compression/decompression for IDP-SC 

Parents: S2-PDGS-SYS-840, S2-PDGS-SYS-845 


Each IDP-SC or OLQC-SC shall be triggered by the DPC or IDP-Orchestrator through the 

following set of interfaces: 

Job Order file (list of input/output files, path for temporary files, configuration 

settings), 

IPF Processing configuration file (processing options), 

Logging messages (to monitor the status of the processing task: event, warning and 

errors), 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 35 / 315 

Report file (to describe in a self-explanatory way the relevant information of the 

performed processing: version of SW, functions call tree, name of generated file, job 

order,) 

Exit code (the status at the end of a task execution: OK, warnings or errors) 

Start/Stop (to start/stop the execution of a task) 

These interfaces shall be compliant with interfaces defined in [CICD-IPF]. 

Parents: S2-PDGS-IDP-015, S2-PDGS-IDP-030, S2-PDGS-IDP-040, S2-PDGS-IDP-045, S2-PDGS-IDP-050, S2-PDGS-IDP-055, S2- 

PDGS-IDP-090, S2-PDGS-IDP-125, S2-PDGS-IDP-110, S2-PDGS-OLQC-125 

Note: The Report file interface can also be called “Product Report” interface in the sense 

that this report contributes to the end-to-end Production Report file generated by the DPC 

for each product generation from a consolidation of these individual IDP-SC or OLQC-SC 

report files. 


The set of IPF software components to be developed shall run in the Reference Platform 

environment. 

Parent: S2-PDGS-SYS-855, S2-PDGS-DPC-385 


For each IDP-SC or OLQC-SC a single core CPU resource will be affected 

Parents: 


Execution of IDP-SC and OLQC-SC shall be possible on any core of the Processing 

Centre available without any specific configuration. In particular, in case of error, the IDP- 

SC or OLQC-SC should be re-launched on another core. 

Parents: S2-PDGS-IDP-110, S2-PDGS-OLQC-125 


Each IDP-SC and OLQC-SC shall free the HW resources (core and memory) after 

execution or after a failure. 


Note: the clean-up of (temporary or O/S) disk files is managed by the DPC, e.g. only at the 

end of a workflow if the whole processing was successful. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 36 / 315 

Each IDP-SC and OLQC-SC shall return an error exit code and a human readable error 

message on failure. 



The usage of processing resources with respect to the data-volumes processed shall have 

a near-linear law for each implemented IDP-SC or OLQC-SC. 

Parents: S2-PDGS-SYS-830, S2-PDGS-IDP-085 


The maximum RAM size that each IDP-SC or OLQC-SC can use shall be configured 

through the Processing Configuration interface [CICD-IPF]. 

The minimum RAM size that shall be allocated to an IDP-SC or OLQC-SC is 1 GB. 

The nominal RAM size that shall be allocated to an IDP-SC or OLQC-SC is derivate from 

Reference Platform HW, considering a uniform sharing of RAM between cores. 

Parent: S2-PDGS-SYS-830, S2-PDGS-IDP-110, S2-PDGS-OLQC-125 

Note : 

An uniform sharing of RAM between cores is considered as the optimal resource 

allocation strategy when IDP-SC are orchestrated by DPC : core resources are 

equally shared and could then be addressed without having to balance the total 

available RAM by blade (24 Gb with reference platform definition) between IDP-SC 

that do not require the same RAM resources. 

Minimal configurable RAM size (1GB) is not linked to IDP-SC but to DPC RAM 

balancing strategy if a non optimal resource allocation strategy has to be set up. 

With Reference Platform definition, nominal RAM allocation (for each IDP-SC or 

OLQC-SC) is then set by configuration to 2GB. 


Unitary verification tests shall be conducted on each developed component in order to 

validate the compliancy with interfaces defined in [CICD-IPF]. 

Parent: S2-PDGS-IDP-015 

The IDP-SC and OLQC-SC will be executed in the PDGS infrastructure that will be 

supported by a set of software relative to the IT management (IP Address, time 

management, access right management…). The related services must be integrated by 

the IDP-SC and OLQC-SC. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 37 / 315 


The IDP-SC and OLQC-SC shall use, systematically, the domain names to identify a 

computer on the LAN (the usage of IP addresses is forbidden). 

Parents: 


Each time a date is required in the processing (i.e.: to date a log message …), the IDP-SC 

and OLQC-SC shall retrieve the current date from the Operating system. 

Parents: 


Several user accounts belonging to the same user group shall be used to manage the 

IDP-SC/OLQC-SC installation and execution. 

Parents: 


The IDP-SC or OLQC-SC configuration parameters shall be stored in dedicated files in a 

specific repository in the IDP-SC/OLQC-SC directory tree. The list of these directories/files 

shall be provided in the IDP-SC and OLQC-SC installation Manual. 

Note: the Backup function will automatically gather the configuration parameters files. 

Parents: 

The restoration procedure will transfer automatically the back upped files in the target 

directories. The restoration procedure is performed when the IDP-SC or OLQC-SC are not 

running. 


The IDP-SC or OLQC-SC shall support to restart from back upped configuration 

parameters files. 

Parents: 

3.1.6 Portability requirements 


In case an IPF software components should use particular OS functionalities preventing 

from easy portability on a Linux version other than OS Red Hat Linux 6.2 prior agreement 

shall be requested by the IPF Contractor. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 38 / 315 

3.1.7 Software reliability requirements 


In case of degraded input data or hardware/software resource failure, any IPF software 

component shall not crash but continue the work, if possible, with a warning raised or exit 

with a comprehensive error code if work cannot continue. 

Parents: S2-PDGS-IDP-115 

3.1.8 Software maintainability requirements 


The maintenance of the IDP-SC, OLQC-SC and IDP-Orchestrator software components 

shall include: 

The use of configuration control mechanism for all SW items (source code, test data, 

configuration files…) 

The capability of compiling, linking and debugging all source code and SW libraries 

Parents: S2-PDGS-SYS-770, S2-PDGS-IDP-110, S2-PDGS-OLQC-125 

3.1.9 Data definition and database requirements 


The Test Data Set (TDS) delivered to the IPF Contractor shall be modified or adapted in 

order to generate a Reference Test Data Set (RTDS) suitable for the verification and 

validation of each IDP-SC and OLQC-SC. 

The IPF Contractor shall propose: 

the adaptations of TDS to perform in order to fit with PDGS validation needs (e.g. 

breakdown and adaptation of IAS test data into IDP-SC test data, adaptation of GPP 

product, intermediate IAS metadata and auxiliary files for PDGS metadata...); 

the definition of scientific tests based on RTDS to perform for scientific validations of 

the IDP-SC (e.g. radiometric denoising, geolocation performance...); 

the definition of quantitative measures to check the data quality match between the 

IDP-SC outputs and RTDS. The match shall be evaluated in terms of quantitative 

measurements (e.g. co-registration errors, pixel-to-pixel rms…). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 39 / 315 

the definition of test data intended to validate each IDP-SC and OLQC-SC timeline 

performances. 

Parents 

3.1.10 Human factors related requirements 


3.1.11 Delivery, Generation, Packaging & Deployment requirements 

The IDP-SC, OLQC-SC and IDP-Orchestrator will be delivered to the RP that will be in 

charge of software configuration management, software generation and packaging. 

The constraints imply by the RP must be integrated by the IDP-SC, OLQC-SC and IDP- 

Orchestrator for the delivery preparation. 


Each IDP-SC software shall be managed as an independent item in point of view of 

delivery, packaging & installation. 

Comment: in the next requirements of this chapter, the “IDP-SC” term shall be understood 

as for “each individual IDP-SC software”. 

Parents: 


IDP-SC, OLQC-SC and IDP-Orchestrator shall be compliant to ECSS-E-ST-40C [AD-8]. 

Parents: 


The IDP-SC, OLQC-SC and IDP-Orchestrator deliveries shall be free from virus and 

malicious code. 

Parents: S2-PDGS-RP-130 


An IDP-SC, OLQC-SC and IDP-Orchestrator shall be identified by his name and his 

version. The version shall permit to identify a major evolution or a minor evolution or a 

patch. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 40 / 315 


Before the first official delivery of IDP-SC, OLQC-SC and IDP-Orchestrator, the software 

shall be delivered one month before with operational generation and installation 

procedures. 

Parents: S2-PDGS-RP-015, S2-PDGS-RP-090 


Each software deliveries shall be accompanied with a software configuration file as 

defined by the ECSS [AD-8]. 

Parents: S2-PDGS-RP-015, S2-PDGS-RP-090 


Each software deliveries shall be accompanied with a release note. 

Parents: 


Each software deliveries shall be accompanied with: 

packaging tool and associated procedures that shall be used on the RP platform to 

generate the software executable and to package it. 

Installation tool that shall be used to deploy the software onto the target platform. 



IDP-SC, OLQC-SC and IDP-Orchestrator shall identify their dependencies for build and 

runtime goals. 



The packaging format shall be SRPM Source Package Manager and RPM Package 

Manager. 



The description of hardware resource shall be a part of the configuration package. 

Parent: S2-PDGS-SYS-805, S2-PDGS-SYS-806, S2-PDGS-SYS-810 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 41 / 315 


The software installation procedure shall permit to choose the target folder during the 

installation. 

Parent: 


The software installation procedure shall install separately the application software and the 

configuration files. 

Parent: S2-PDGS-RP-145, S2-PDGS-SYS-810 


The installation procedure shall permit to deploy several versions of the same component 

(application software or configuration): 

a single version is active at the same time 

Parent: S2-PDGS-RP-145, S2-PDGS-SYS-800, S2-PDGS-SYS-805 

3.2 IDP-SC requirements 

3.2.1 Generalities 

3.2.1.1 Workflow design and IDP-SC breakdown 

To each product level generation correspond a set of IDP-SC in charge of implementing 

some processing steps (PS) described in the DPM and implement in the GPP project 

though Image Algorithm Software (IAS). 

The breakdown of processing functionalities into IDP-SC was driven by functionality, 

metadata circulation, performance and scalability considerations. Hence the link between 

IDP-SC, Processing Step as defined in [OCD] and DPM/IAS may not be straightforward for 

the following reasons: 

A processing is not defined in DPM nor reference as a Processing Step in [OCD] 

(e.g. metadata formatting or reprocessing related processing such as 

UNFORMATING L0c data) 

A processing has been split into 2 IDP-SC for performance and scalability purpose 

(e.g. RADIO IAS has been split into RADIO-AB IDP-SC, the radiometric processing 

itself that can be highly parallelized, and RADIO_FINALIZE IDP-SC in charge of 

metadata updating that does not requires parallelization). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 42 / 315 

 

Several processing steps have been gathered into a single IDP-SC for practical 

development aspects (e.g. RADIO L1A and L1B radiometric processing into a 

single RADIO_AB IDP-SC) 

3.2.1.2 List of IDP-SC 

The Table 3 enumerates the Processing Steps required to generate a product level and 

related DPM as defined in § 4.5.4.5 of [OCD] from the Ground Prototype Processor 

project. This table also makes the link between the Processing Steps and the IDP-SC. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 43 / 315 

# Processing Step Related DPM IDP-SC IDP-SC description Level Comments 

PS-01 

PS-02 

PS-03 

Level-0 Viewing 

Model Initialization 

Preliminary QuickLook 

processing 

Preliminary Cloud 

Mask Processing 

[INIT_LOC-DPM] 

+ 

[GEOREF-DPM] 


+ 

[GEOREF-DPM] 

[CLOUD_INV- 

DPM] + 

[VMASK-DPM] 

INIT_LOC_L0 

QL_GEO 

QL_CLOUD_MASK 

Initialization of the viewing model 

for the QuickLook geometry, 

including ancillary data 

computation. 

Preliminary QuickLook 

resampling 

Coarse Cloud Mask processing in 

QuickLook geometry 

L0c 

L0c 

L0c 

L0c scenario 

PS-04 Ø [JP2K-DPM] FORMAT_IMG(QL JP2000) 

JPEG2000 compression of 

QuickLook images 

L0c 

Ø Ø Ø FORMAT_ISP 

Ø 

Ø 

[CLOUD_INV- 

DPM] + 

[VMASK-DPM] 

Ø Ø Ø 

FORMAT_METADATA (GR- 

L0c) 

FORMAT_METADATA (DS- 

L0c) 

Ø Ø Ø UNFORMAT_SAFE(GR) 

Ø Ø Ø UNFORMAT_SAFE(DS) 

Ø Ø [JP2K-DPM] QL_DECOMP 

Formats granule Image Source 

Packet (ISP) in SAFE format 

Finalizes L0 consolidated 

metadata at granule level and 

provide granule in SAFE format 

ready for archiving 

Finalizes L0 consolidated 

metadata at datastrip level in 

SAFE format 

Convert the Granule from SAFE 

format into internal format 

Convert the Datastrip from SAFE 

format into internal format 

Archived JPEG2000 QuickLook 

decompression 

L0c 

L0c 

L0c 

L1A 

L1A 

L1A 

Only for reprocessing 



DPM is not to be 

implemented but used as 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 44 / 315 


a reference for 

PS-03 

Preliminary Cloud 

Mask Processing 

[CLOUD_INV- 

DPM] + 

[VMASK-DPM] 

QL_CLOUD_MASK 

Coarse Cloud Mask processing in 

QuickLook geometry 

L1A 

decompression 


(L1A scenario) 

PS-05 

Level-1 Viewing 

Model Initialization 


+ 

[GEOREF-DPM] 


+ 

[GEOREF-DPM] 

[VMASK-DPM] 

UPDATE_LOC 

INIT_LOC_L1 

Ø Ø Ø GET_GRI 

Ø Ø Ø UNFORMAT_GRI 

Update L0 Location metadata 

from updated ancillary data 

or/and auxiliary data (GIPP). 

Update Location metadata with 

information specific to L1A 

product. 

Get the set of GRI covering the 

datastrip to be processed 

Convert GRI from user-defined 

format to internal format 

PS-06 Decompression Ø DECOMP MSI raw data decompression 

PS-07 

PS-09 

Level-1A Radiometric 


Level-1B Radiometric 


[RADIO-DPM] 

+ 


[VMASK-DPM] 

RADIO_AB 

Radiometric processing required 

for L1A and L1B 

L1A- 

L1B 

L1A 

L1B 

L1B 

L1A- 

L1B 

L1A- 

L1B 

Only : 

for contingency 

scenario (POD data or 

Datation refinement) 

for reprocessing 

Done in L1A but used for 

L1B 

Done in L1A but used for 

L1B. Includes JPEG200 

decompression 

Uses WICOM CFI 

Can be restricted to L1A 

radiometric corrections by 

configuration 

PS-07 

Level-1A Radiometric 


[RADIO-DPM] 

+ 

RADIO_FINALIZE 

 

Update metadata after 

L1A- 

L1B 

Can be restricted to L1A 

radiometric corrections by 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 45 / 315 


PS-09 

Level-1B Radiometric 


[INIT_LOC -DPM] 

[VMASK-DPM] 

 

radiometric processing 

Regroup data from 

distributed radiometric 

processing (e.g. mask 

combination at detector level) 

configuration 

PS-08 

Level-1A 

Compression 

[JP2K-DPM] 

FORMAT_IMG(L1A JP2000) 

Image data formatting (Jpeg2000 

by granule) 

L1A 

Ø 

Ø 

[CLOUD_INV- 

DPM] + 

[VMASK-DPM] 

Ø Ø Ø 

Ø 

Ø 

[GEO_S2-DPM] 

+ 


L1A) 


L1A) 

INIT_VS_GEO 

Update L0 granule metadata 

Process L1A masks at 

granule level (reprocessing 

only for cloud mask) 

Process cloud cover at 

granule level (reprocessing 

only) 

convert granule metadata 

from internal format to 

archive format 

Update L0 datastrip metadata: 

Finalize metadata at datastrip 

level 

convert datastrip metadata 



Initializations for Registration: 

Virtual Sensor geometry 

L1A 

L1A 

L1B 

Internal format for 

metadata should differ 

slightly from archive 

format (e.g.: temporary 

information used for 

processing optimization 

removed from product) 








Activated twice if both 

Image-GRI and 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 46 / 315 


PS-10 

PS-15 

PS-10 

PS-11 

PS-15 

PS-16 

PS-12 

Common Geometry 

Grid Computation for 

Image-GRI 

Registration 



VNIR/SWIR 

Registration 



Image-GRI 

Registration 

Resampling on 


Grid for Image-GRI 

Registration 



VNIR/SWIR 

Registration 

Resampling on 


Grid for VNIR/SWIR 

Registration 

Tie Points Collection 

for Image-GRI 

Registration 

[GEOREF-DPM] 

[GEO_S2-DPM] 

+ 

[GEOREF-DPM] 

[RESAMP -DPM] 

[GEO_S2-DPM] 

+ 

[GEOREF-DPM] 

[GEO_S2-DPM] 

+ 

RESAMPLE_TO_VS 

 

computing 

Masks projection in Virtual 

Sensor geometry 

Resampling in Virtual Sensor 

geometry. 

Includes: 

resampling grid computation 

image resampling 

L1B 

TP_COLLECT Tie points collection L1B 

TP_FILTER Tie points filtering L1B 

VNIR/SWIR registration 

are required 


Image-GRI and 


are required 

 

 

 


Image-GRI and 

VNIR/SWIR 

registration are 

required. 

Activated in a loop 

with TP_FILTER 

Function differ slightly 

between Image/GRI 

or VNIR/SWIR 

registration 

If erroneous Tie- 

Points/GCP due to false 

correlations filtering at 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 47 / 315 


PS-17 

Tie Points Collection 

for VNIR-SWIR 

Registration 

[GEOREF-DPM] 

ATF level is sufficient 

according to Image 

Quality criteria, 

TP_FILTER IDP-SC could 

be unused. 

PS-13 

PS-18 

PS-14 

PS-19 

Tie Points Filtering for 

Image-GRI 

Registration 

Tie Points Filtering for 

VNIR-SWIR 

Registration 

Spatiotriangulation for 

Image-GRI 

Registration 

Spatiotriangulation for 

VNIR-SWIR 

Registration 

[GEO_S2-DPM] 

+ 

[GEOREF-DPM] 

Ø Ø Ø 

Ø Ø Ø 

Ø 

SPATIO 

GEO1B_FINALIZE 


L1B) 


L1B) 

 

 

Spatiotriangulation 

Update metadata at datastrip 

level (refined model, 

geometric quality indicators) 

Update metadata after geometric 

processing (footprint update) 

Finalize L1B granule metadata: 

Process L1B masks at 

granule level 

Update L1A granule 

metadata with L1B 

information 

convert granule metadata 




level 

Update L1A datastrip 

metadata with L1B 

L1B 

L1B 

L1B 

L1B 


Image-GRI and 


are required 

















Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 48 / 315 


PS-20 L1B Compression [JP2K-DPM] FORMAT_IMG(L1B JP2000) 

PS-21 

PS-21 

PS-27 

PS-22 

PS-23 

L1C Tile Association 

L1C Tile Association 

ECMWF data 

processing 

L1C Resampling Grid 

Computation 

Resampling in L1C 

Geometry 


DPM] 


DPM] 

Ø 


DPM] + [VMASK- 

DPM] 

RESAMPLE_1C- 

DPM] 

GET_TILE_LIST 

TILE_INIT 

GEN_ORTHO_TOA 

TILE_FINALIZE 

PS-24 Mask Computation [MASK_1C-DPM] MASK_S2 

PS-25 L1C Compression [JP2K-DPM] FORMAT_IMG(L1C JP2000) 

PS-26 

TCI and PVI 


Ø 

FORMAT_IMG(TCI & PVI) 

information 

convert datastrip metadata 




by granule) 

Extract the list of tiles to process 

(intersection of Datastrip with 

UTM globe tiling) 

Processing of all the data that are 

shared and used by band 

processing (Reflectance Setup, 

ECMWF grid resampling in tile 

geometry, Update of metadata at 

tile level) 

In charge of orthorectification and 

conversion to TOA reflectance 

Collecting information processed 

by list of bands by 

GEN_ORTHO_TOA in order to 

update tile metatada. 

In charge of 

cloud mask generation 

land/water mask generation 


by tile) 

Jpeg2000 compressed True 

Color Image (TCI) generation 

Jpeg2000 compressed 

L1B 

L1C 

L1C 

L1C 

L1C 

L1C 

L1C 

L1C 




TCI and PVI are in GML- 

Jpeg2000 with 

georeferenced information 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 49 / 315 


PreView Image (PVI) 

generation 

Ø Ø Ø 

Ø Ø Ø 

FORMAT_METADATA(TILE- 

L1C) 

FORMAT_METADATA(DS- 

L1C) 

Update metadata at tile level 


level: update L1B datastrip 

metadata with L1C information 

and AUX data. 

Convert datastrip metadata from 

internal format to archive format 

L1C 

L1C 

Table 3 : Processing Steps, DPM and related IDP-SC 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 50 / 315 

The following figure presents, in nominal processing, the IDP-SC sequence with the IAS 

relationships: 

Figure 8: IDP-SC (nominal processing) and GPP IAS relationship. 

3.2.1.3 Workflow description 

This section presents several workflow processing as orchestrated by DPC. 

First, end to end workflows are defined both for nominal processing and reprocessing. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 51 / 315 

Then parallelization strategy and data/metadata circulation are presented at zoom level 

for: 

L0c processing, 

L1A/B processing 

L1C processing 

3.2.1.3.1 End to end workflow (nominal processing) 

The Figure 9 depicts a global view of IDP-SC chaining from level 0 up to level 1C product 

generation referred to as the end to end workflow for nominal processing. IDP-SC related 

to L1B optional geometric refining are identified on this figure. 

The Figure 10 shows in the end to end workflow for nominal processing the set of IDP-SC 

that are parallelized. 

Precise parallelization strategy and data/metadata circulation is detailed in the next 

sections 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 52 / 315 

Figure 9: End to end workflow (Nominal Processing): IDP-SC breakdown 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 53 / 315 

Figure 10: End to end workflow (Nominal Processing): parallelized IDP-SC 

3.2.1.3.2 End to end workflow (reprocessing) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 54 / 315 

The Figure 11 depicts a global view of IDP-SC chaining from archived level 0c up to level 

1C product generation referred to as the end to end workflow for reprocessing. IDP-SC 

related to L1B optional geometric refining are identified on this figure. 

The Figure 12 shows in the end to end workflow for reprocessing the set of IDP-SC that 

are parallelized. 

End to end Reprocessing workflow only differs from L0c to L1 nominal workflow by: 

UNFORMAT_SAFE IDP-SC which converts Archived L0c to internal format 

QL_DECOMP & QL_CLOUD_MASK in charge of coarse cloud mask reprocessing 

from archived compressed QuickLook. (coarse cloud masks are not stored in the 

L0c but required for L1 processing) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 55 / 315 

Figure 11: End to end workflow (Reprocessing): IDP-SC breakdow 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 56 / 315 

Figure 12: End to end workflow (Reprocessing): parallelized IDP-SC 

3.2.1.3.3 L0c workflow 

The L0c processing consists in initializing the geometrical viewing model, generating the 

QuickLook (QL) at 320m resolution images from compressed MSI data and computing the 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 57 / 315 

Cloud masks in QL geometry. The QL images are compressed in JPEG2000. The quality 

of the generated product is inspected by the OLQC function. 

The Figure 13 depicts the IDP-SC and OLQC-SC chain involved in L0c product 

generation. 

The level of parallelization is indicated on Figure 14: 

Group of bands parallelization capability ("band") 

Group of detectors parallelization capability ("detector") 

Group of granules parallelization capability ("group of granules") 

Along Track Fragment parallelization capability ("ATF") 

The Figure 15 illustrates images files (at full resolution and at low resolution for QuickLook 

processing), metadata at datastrip file and metadata at granule files circulation. 

Note: coherence between metadata files circulation and parallelization strategy: 

metatada at datastrip level is only updated by IDP-SC that are not parallelized 

metadata at granule level is not updated by IDP-SC parallelized by band. 


For L0c product generation, IPF shall implement the processing chain presented in Figure 

13 

Parents: S2-PDGS-SYS-005, S2-PDGS-IDP-005, S2-PDGS-IDP-130, S2-PDGS-IDP-135 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 58 / 315 

Figure 13 L0c workflow: IDP-SC breakdown 

Figure 14 L0c workflow: parallelization strategy 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 59 / 315 

Figure 15 L0c workflow: Illustration of image/metadata files circulation 

3.2.1.3.4 L1A & L1B workflow (nominal workflow) 

The L1A product generation consists in decompressing the whole set of MSI data into 

granules, computing the geometrical model and performing the first Radiometric 

processing (SWIR arrangement). The granules images are compressed in JPEG2000. The 

quality of the generated product is inspected by the OLQC function. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 60 / 315 

The L1B product generation consists in performing the main radiometric processing 

(equalization, defective pixel correction, restoration…) and refining the geometrical model. 

The granules images are compressed in JPEG2000 and the refined geometrical model 

parameters are appended to the metadata. The quality of the generated product is 

inspected by the OLQC function. 

When orchestrated by DPC, L1A and L1B processing share the same workflow (in 

particular the radiometric processing sub-workflow as presented on Figure 16. 

The Figure 17 illustrates which part of L1A & L1B workflow contributes to L1A, L1B (with 

and without geometric refinement) product generation. 

By default L1A & L1B workflow includes a single RADIO_AB parallelized by ATF in charge 

of both L1A & L1B radiometric processing (parallelization by band is not possible since this 

parallelization strategy does not comply with crosstalk corrections algorithms). 

For scalability purpose, when orchestrated by DPC, L1A & L1B radiometric processing 

could either be done in one shot (RADIO_AB: scenario "L1A and L1B” noted A&B on 

Figure 16) or split in two steps: the first one including crosstalk correction parallelized by 

ATF (RADIO_AB: scenario "L1A and L1B without deconvolution and denoising" noted 

A&B* on Figure 16), the second one including the time consuming restoration processing 

parallelized by band (RADIO_AB: scenario " Deconvolution and denoising only" noted 

B*->B on Figure 16). 

The Figure 18 shows the chain of IDP-SC involved in L1A and L1B product generation, 

starting from L0c IDP-SC outputs. The level of parallelization is also depicted: 


Group of detectors parallelization capability ("detector") 



Note: IDP-SC involved in L1B geometric correction are gathered in three blocks like 

illustrated on Figure 18 (GRI setup, Refining and Registration). When both IMAGE/GRI 

refining and VNIR/SWIR registration are set to enable, the first processing could be either 

refining or registration. (not represented on Figure 18). 

The Figure 15 illustrates the circulation of images files, metadata at datastrip file and 

metadata at granule files. 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 61 / 315 


For L1A and L1B product generation from L0c, IPF shall implement the processing chain 

presented in Figure 16. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 62 / 315 

Figure 16 L1A and L1B workflow overview 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 63 / 315 

Figure 17 L1A & L1B workflow: sub-workflows contribution to L1A, L1B generation 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 64 / 315 

Figure 18 L1A&L1B workflow: IDP-SC breakdown and parallelization strategy 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 65 / 315 

Figure 19 L1A&L1B workflow: Illustration of image and metadata circulation 

3.2.1.3.5 L1A & L1B workflow (reprocessing workflow) 

L1A & L1B Reprocessing workflow only differs from L1A & L1B nominal workflow by: 

UNFORMAT_SAFE IDP-SCs which converts Archived L0c to internal format 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 66 / 315 

QL_DECOMP & QL_CLOUD_MASK in charge of coarse cloud mask reprocessing from 

archived compressed QuickLook. (coarse cloud masks are not stored in the L0c but 

required for L1 processing) 

The Figure 20 depicts the IDP-SC and OLQC-SC chain involved in L1A&L1B reprocessing 

workflow highlighting the weak differences with the nominal L1A&L1B workflow. 

The level of parallelization for reprocessing specific IDP-SC is indicated on Figure 21 




Images files (at full resolution and at low resolution for QuickLook), metadata at datastrip 

file and metadata at granule files circulation are illustrated on Figure 22. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 67 / 315 

Figure 20 L1A and L1B reprocessing workflow: overview 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 68 / 315 

Figure 21 L1A and L1B reprocessing workflow (specific part): IDP-SC breakdown 

and parallelization strategy 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 69 / 315 

Figure 22 L1A and L1B reprocessing workflow (specific part): Illustration of image 

and metadata circulation 

3.2.1.3.6 L1C workflow 

The L1C processing consists in generating tiles from L1B granules and producing 

JPEG2000 tile images with relevant metadata and associated TCI and PVI, then to 

generate the corresponding data strip, with activation of the OLQC-SC for product quality 

checking. 

The Figure 23 depicts the IDP-SC and OLQC-SC chain involved in L1C product 

generation. 

The level of parallelization is indicated on Figure 24: 

List of bands parallelization capability 

Tile parallelization capability. 

The Figure 25 illustrates images files (at full resolution and at low resolution for PVI), 

metadata at datastrip file and metadata at granule files circulation. 





For L1C product generation (with PVI and TCI), IPF shall implement the processing chain 

presented in Figure 23. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 70 / 315 

Figure 23 L1C workflow: IDP-SC breakdown 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 71 / 315 

Figure 24 L1C workflow: parallelization strategy 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 72 / 315 

Figure 25 L1C workflow: Illustration of image/metadata files circulation 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 73 / 315 

3.2.2 General Inputs/Outputs 

This paragraph describes all the input data that can be found at IDP-SC entry and for 

each of them, the granularity of the data is given (granule/tile, datastrip or ATF). 

3.2.2.1 End to end input/ouput 

3.2.2.1.1 L0 non consolidated 

L0 non consolidated is produced by the DPC telemetry processor. It is the input of IDP L0c 

processing. 

L0 non consolidated includes: 

a metadata at datastrip level (one file), 

a metadata at granule level for each granule of the datastrip 

Instrument Source Packet (ISP) gathered by datablock for each detector and band 

(i.e. 156 files by datablock) 

Low Resolution images gathered by datablock for each detector and Quicklook band 

(i.e., considering 5 QuickLook bands, 60 files by datablock) 

Ancillary Source Packet (ASP) (SAD data associated to the datatake which includes 

the datastrip to process) 

3.2.2.1.2 L0c PDI at granule and datastrip level 

3.2.2.1.2.1 L0c PDI as output of L0c processing workflow 

L0 consolidated (L0c) PDI at granule and datastrip level are, as described in [DI-PSD], 

TAR containers of several files progressively built by the IDP-SC/OLQC-SC workflow and 

finalized by the DPC. IDP-SC and OLQC-SC generates most of the files included in the 

PDI container. Then, the DPC gathers those files in a TAR file. 

‣L0c PDI at datastrip level 

L0c PDI at datastrip level includes 

a metadata at datastrip level 

a folder containing Ancillary Data 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 74 / 315 

a folder containing QI Data (QuickLook and OLQC report) 

a SAFE manifest that describes the PDI structure 

a PDI-Id metadata file which is used by archive. 

Several IDP-SC are in charge of building and formatting the following components of L0c 

PDI at datastrip level: 

the Metadata a datastrip level which is built progressively by the set of L0c IDP-SC 

and finalized by FORMAT_METADATA(DS-L0c) 

the Ancillary Data folder which is formatted by FORMAT_METADATA(DS-L0c) 

the Quicklook files for which formatting is completed by FORMAT_IMG(QL_JP2000) 

the OLQC report which is generated by OLQC-SC. 

Then the DPC builds the PDI-Id metadata file and gathers all files (including the SAFE 

manifest) in the TAR container. 

‣L0c PDI at granule level 

L0c PDI at granule level includes: 

a metadata at granule level 

a folder containing Image data 

a folder containing QI Data (OLQC report) 



Several IDP-SC are in charge of building and formatting the following components of L0 

non consolidated PDI at granule level: 

the Metadata a granule level which is built progressively by IDP-SC and finalized by 

FORMAT_METADATA(GR-L0c) 

the Image Data folder which is formatted by FORMAT_ISP 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 75 / 315 


manifest) in the TAR container 

3.2.2.1.2.2 L0c PDI as input of L1 reprocessing workflow 

DPC extracts from L0 consolidated (L0c) PDI at granule and datastrip level TAR container 

the files that constitute the PDI and provide them (except SAFE manifest and PDI-Id 

metadata file) to the IDP-SC/OLQC-SC reprocessing workflow. 

3.2.2.1.3 L1A and L1B PDI at granule and datastrip level 

L1A and L1B PDI at granule and datastrip level are, as described in [DI-PSD], TAR 

containers of several files progressively built by the IDP-SC/OLQC-SC workflow and 



‣L1A/L1B PDI at datastrip level 

L1A/L1B PDI at datastrip level includes: 





Several IDP-SC are in charge of building and formatting the following components of 

L1A/L1B PDI at datastrip level: 

the Metadata a datastrip level which is built progressively by IDP-SC and finalized by 

FORMAT_METADATA(DS-L1A)/ FORMAT_METADATA(DS-L1B) 


Then the DPC builds the PDI-Id metadata file and gathesr all files (including the SAFE 


‣L1A/L1B PDI at granule level 

L1A/L1B PDI at granule level includes: 

a metadata at granule level 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 76 / 315 


a folder containing QI Data (OLQC report and Quality Masks) 



Several IDP-SC are in charge of building and formatting the following components of 

L1A/L1B PDI at granule level: 

the Metadata a granule level which is built progressively by IDP-SC and finalized by 

FORMAT_METADATA(GR-L1A)/ FORMAT_METADATA(GR-L1B) 

images files embedded in the Image Data folder which are formatted by 

FORMAT_IMG(L1A JP2000)/ FORMAT_IMG(L1B JP2000) 

Quality Masks for which formatting is completed by FORMAT_METADATA(GR- 

L1A)/ FORMAT_METADATA(GR-L1B) 




3.2.2.1.4 L1C PDI at tile and datastrip level and TCI PDI 

L1C PDI at granule and datastrip level and TCI PDI are, as described in [DI-PSD], TAR 

containers of several files progressively built by the IDP-SC/OLQC-SC workflow and 



‣L1C PDI at datastrip level 

L1C PDI at datastrip level include : 





Several IDP-SC are in charge of building and formatting the following components of L1C 

PDI at datastrip level: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 77 / 315 

the Metadata a datastrip level which is built progressively by IDP-SC and finalized by 

FORMAT_METADATA(DS-L1C) 




‣L1C PDI at tile level 

L1C PDI at tile level includes: 

a metadata at tile level 


a folder containing QI Data (OLQC report and Quality Masks) 



Several IDP-SC are in charge of building and formatting the following components of L1C 

PDI at tile level: 

the Metadata a tile level which is built progressively by IDP-SC and finalized by 

FORMAT_METADATA(TILE-L1C) 

images files embedded in the Image Data folder which are formatted by 

FORMAT_IMG(L1C JP2000) 

Quality Masks for which formatting is completed by FORMAT_METADATA(TILE- 

L1C) 


Then the DPC builds the PDI-Id metadata file and gathesr all files (including the SAFE 


‣TCI PDI (at tile level) 

TCI PDI (at tile level) includes: 

a TCI image 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 78 / 315 

IDP-SC are in charge of building and formatting the following components of TCI PDI: 

TCI imager file which is formatted by FORMAT_IMG(PVI & TCI) 

Then the DPC builds the PDI-Id metadata file and gathers all files in the TAR container. 

3.2.2.2 Input/Output Image Data 

MSI image data are packaged on-board in a set of instrument source packets called “on 

board scene”. These scenes correspond to a simultaneous observation of about 3.6 

seconds for all bands and all detectors, which means an approximate coverage on ground 

of 23km along track for each band and 25km across track for each detector. Up to Level 

1B, images data granularity is aligned on MSI image data (granules) while for L1C images 

data is aligned on tiles as described in Table 1. 

Image data can be defined at the granularity of PDI-FE-GR, PDI-FE-DS or PDI-FE-ATF 

(cf. § 2.1.4). 

3.2.2.3 Input/Output Metadata 

The metadata content per product level is based on the definition of [PSD]. 

Intermediate-level metadata files can be used, i.e. before formatting to a specific product 

level as required in [PSD]. 

Note: the TAR formatting defined in [PSD] is performed by the DPC and through the IPF 

requirements “compliancy with [PSD]” shall be understood as “compliancy with [PSD], 

except TAR archive formatting” 

3.2.2.3.1 Metadata at datastrip level 

A Metadata at granule level is associated to each processed datastrip 

Metadata at datastrip level is defined at the granularity of PDI-FE-DS. 

Metadata at datastrip level is progressively completed during processing up to be 

compliant with [PSD] for each Level. 

3.2.2.3.2 Metadata at granule level 

A Metadata at granule level is associated to each processed granule or tile. 

Metadata at granule level is defined at the granularity of PDI-FE-GR. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 79 / 315 

Metadata at granule level is progressively completed during processing up to be compliant 

with [PSD] for each Level. 

3.2.2.3.3 Input/Output Masks 

The masks are in GML format, they can be defined at the granularity of PDI-FE-GR, PDI- 

FE-DS or PDI-FE-ATF. 

3.2.2.3.4 Internal Frame file 

The frame file is an internal file defined at the granularity of PDI-FE-DS that describes the 

framing strategy for L1 coarse registration. 

3.2.2.4 Input Ancillary Data 

The ancillary data is composed of: 

System Ancillary Data: data generated on-board by the payload and the platform in 

support of the observation data, such as: 

Scene start time; 

Time correction value and the MSI On Board Time synchronization status; 

System operation information (i.e. observation mode, calibration mode, etc.); 

Instrument Ancillary Data: data generated on-board by the payload in support of the 

observation data, such as calibration, timing for each line acquisition, compression 

ratio, data validity flag (e.g. nominal SWIR detector temperature), needed to process 

the measurement data on ground. 

Satellite Ancillary Data: data acquired on-board by the satellite in support of the 

observation data, such as orbit position, velocity and time (generated by GPSR), 

attitude (generated by the AOCS sensors) needed to process measurement data on 

ground. 

Input Precise Orbit Determination (POD) data: These input data are optional (S2 

system degraded mode) and generated starting from the on-board satellite ancillary 

data (AOCS and GPS data). It will optionally be ingested in the L1A generation if the 

attitude information is not matching the expected accuracy. 

Ancillary data are defined at the granularity of PDI-FE-DS. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 80 / 315 

3.2.2.5 Input Auxiliary Data 

Auxiliary data are all additional input data used for generating a product, on top of the 

direct measurements from the payload and the platform (i.e. image and ancillary data). 

Auxiliary Data identifies all On-board and On-Ground auxiliary information relevant to 

product processing and characterization (such as Non Uniformity Coefficients NUC 

Tables) 

3.2.2.5.1 Input GIPP (general) 

The Ground Image Processing Parameters (GIPP) is a file associated to a processing 

component (e.g. an IDP-SC) to describe the set of parameters and their values. A GIPP is 

associated to a validity period since the parameters can be tuned during the PDGS 

lifetime. 

Each GIPP is composed of: 

A header section, identifying in a unique way the file containing: 

The satellite to which the GIPP is applicable (S2A, S2B or ALL); 

The GIPP provider; 

The GIPP type (type of the parameters); 

An applicability start date; 

An applicability end date (may be put to end of mission time); 

A version number. 

A data section containing the list of parameters for the selected type of GIPPs. 

GIPP are defined independently of the processed data granularity, even if some 

GIPP are related to the data (e.g. Viewing Directions given per detector column) 

3.2.2.5.2 Specific GIPP: Input DEM 

Input DEM are considered as a GIPP. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 81 / 315 

The Digital Elevation Model (DEM) is used in the processing chain for eliminating the 

terrain-induced displacements so as to transform image data and obtain orthorectified 

images. 

Two DEM layers are used: 

coarse DEM with a kilometric resolution 

DTED-1 DEM:SRTM_filtered and ACE2 (covering latitudes > 60°) DEM data will be 

used (see [OCD] § 4.3.9.2.5). 

Only the DEM-tiles covering the input image data are required. 

3.2.2.5.3 Specific GIPP: Input GRI 

Input GRI are considered as GIPP. 

The Global Reference Image (GRI) [GRI-TN] is a set of Sentinel-2 mono-spectral Level-1B 

products covering all land regions within the acquisition plan. The GRI is used during 

geometric processing to improve the geolocation accuracy and to reach the absolute geolocation 

accuracy and multi-temporal coregistration requirements. 

GRI data are defined as a L1B product compliant with [PSD]. 

3.2.2.5.4 Input ECMWF Data 

For further atmospheric correction processing, meteorological auxiliary data will be 

embedded within the Level-1C product that requires having the following ECMWF 

parameters available for processing: 

Total column Ozone (TCO3) [Kg/m2]; 

Total column water vapor (TCWV) [Kg/m2]; 

Mean sea level pressure (MSL) [Pa]; 

For each Level-1C image data tile there will be a correspondent ECMWF tile. 

ECMWF grids covering the data are required to generate ECMWF tiles. 

3.2.2.5.5 Input IERS data 

The International Earth Rotation & Reference Systems is publishing daily data bulletins 

about Earth orientation and Terrestrial reference system (Earth Pole position, UT1-UTC,). 

These data are required for the computation of the geometrical model. 

IERS data file is independent from the data granularity. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 82 / 315 

3.2.3 Requirements common to all IDP-SC 

3.2.3.1 Functional requirements 


The metadata generated by each FORMAT_METADATA IDP-SC (at granule/tile or 

Datastrip level) shall be compliant with Product Specification Documents [PSD], except 

TAR formatting. 

Parents: S2-PDGS-IDP-070, S2-PDGS-IDP-075 


Each IDP-SC taking an XML file as an input shall check the validity of the XML file against 

the related XSD schema. 

In case of XML non-conformance with XSD a specific error shall be raised by the IDP-SC. 



Each FORMAT_METADATA IDP-SC in charge of generating the metadata at datastrip 

level of each product level shall take as an input an XML file listing all the IDP-SC used to 

generate the product and for each IDP-SC, its version and the list of GIPP files. 



Each IDP-SC shall be robust to calibration datastrip (see [OCD] §4.5.4.10 and [OCD] 

Table 4-8), and shall have to: 

detect calibration datastrip (from metadata at datastrip level) which are not compliant 

with algorithm processing; 

switch OFF the algorithmic steps that are not compliant; 

fill required output with FAKE data if relevant; 

Exit with a specific code. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 83 / 315 

Note: Depending on calibration scenario, the processing have to be stopped at last at level 

1B (Radio only), e.g. for calibration mode when viewing directions do not intercept the 

earth. 

3.2.3.2 Performance requirements 


The validation of quality performance of the IDP-SC shall lead to: 

For images: 

For L0c image product validation : 

bitwise identical Quick Look images from IDP-SC as compared to RTDS (before 

JPEG2000 compression) 

Same geometric accuracy as compared to RTDS 

For L1A image product validation (before JPEG2000 compression): 

radiometrical difference = 0 as compared to RTDS 

geometrical difference = 0 as compared to RTDS 

For L1B image product validation (before JPEG2000 compression): 

radiometrical error < 0.86 Numerical Count at 3 as compared to RTDS 

geometrical difference = 0 as compared to RTDS 

For L1C image product validation (before JPEG2000 compression): 

radiometrical error < 0.86 Numerical Count + (geo diff) at 3 as compared to 

RTDS 

geometrical error = 0.3 pixels at 3 as compared to RTDS 

For metadata: 

Each generated XML product metadata shall be compliant with delivered metadata 

XSD schemes. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 84 / 315 

3.2.3.3 Operational requirements 


Each IDP-SC shall be able to run concurrently and independently of other IDP-SC or other 

instances of the same IDP-SC running on the same multi-core hardware server. 



Once triggered by the DPC or IDP-Orchestrator, each IDP-SC shall run autonomously 

without any operator intervention. 



Each IDP-SC shall provide status information over its processes and resources (i.e. log 

information, disk volumes usage, alarms, etc.) in real-time to the DPC function via the 

Logging interfaces [CICD-IPF]. 

Parents: S2-PDGS-IDP-105, S2-PDGS-IDP-110, S2-PDGS-OLQC-125 

3.2.3.4 Specific Resources requirements 


3.2.3.5 Design requirements and implementation constraints 


The implementation of IDP-SC in charge of JPEG2000 compression or decompression 

shall isolate the calls to JPEG2000 library in view of a possible replacement of Kakadu 

COTS by another JPEG2000 library. 

Parents: S2-PDGS-SYS-840, S2-PDGS-SYS-845 


Requirement deleted. 


Each IDP-SC shall internally manage a breakdown of input data in case the input volume 

exceeds the allocated RAM size (e.g stripping of the input data). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 85 / 315 

Parents: S2-PDGS-SYS-830 

Note: the maximal input PU size that a single launch of IDP-SC shall manage is detailed 

per IDP-SC in the table below: 

IDP-SC 

INIT_LOC_L0 

QL_GEO 

QL_CLOUD_MASK 

FORMAT_IMG(QL) 

FORMAT_ISP 

FORMAT_METADATA(GR L0) 

FORMAT_METADATA(DS L0) 

UNFORMAT_SAFE(GR) 

UNFORMAT_SAFE(DS) 

UPDATE_LOC 

QL_DECOMP 

INIT_LOC_L0 

DECOMP 

RADIO_AB 

RADIO_FINALIZE 

FORMAT_METADATA(GR L1A) 

FORMAT_METADATA(DS L1A) 

FORMAT_IMG(L1A) 

GET_GRI 

UNFORMAT_GRI 

INIT_VS_GEO 

RESAMPLE_TO_VS 

TP_COLLECT 

TP_FILTER 

SPATIO 

GEO1B_FINALIZE 

PU maximal size 

data volume equivalent to a datastrip of 20' downlink 

data volume equivalent to a datastrip of 20' downlink (all QuickLook bands of 

the twelve detectors) 


data volume equivalent to a datastrip of 20' downlink (all the QuickLook 

bands) 

data volume equivalent to a datastrip of 20' downlink (all the bands of the 

twelve detectors) 

data volume equivalent to a datastrip of 20' downlink (all the granules of all 

detectors) 



detectors) 



data volume equivalent to a datastrip of 20' downlink (all the QuickLook 

bands) 

data volume equivalent to a datastrip of 20' downlink (all the detectors) 

a volume corresponding to a detector of a datastrip equivalent to 20' of 

downlink 

data volume equivalent to a datastrip of 20' downlink (all the detectors) 



detectors) 


a volume corresponding to a detector of a datastrip equivalent to 20' of 

downlink 


aggregation mode : data volume equivalent to a datastrip of 20' downlink (all 

the detectors) 

decompression mode: a volume corresponding to a detector of a datastrip 

equivalent to 20' of downlink 


a volume corresponding to one detector (one band) of a datastrip equivalent 

to 20' of downlink 






data volume equivalent to a datastrip of 20' downlink (all the bands of all 

detectors) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 86 / 315 

FORMAT_METADATA(GR L1B) 

FORMAT_METADATA(DS L1B) 

FORMAT_IMG(L1B) 

GET_TILE_LIST 

TILE_INIT 

GEN_ORTHO_TOA 

TILE_FINALIZE 

MASK_S2 

FORMAT_IMG(TCI) 

FORMAT_IMG(L1C) 

FORMAT_METADATA(GR L1C) 

FORMAT_METADATA(DS L1C) 


detectors) 


a volume corresponding to one detector of a datastrip equivalent to 20' of 

downlink 


data volume equivalent to a tile (all bands) 








3.2.3.6 Portability requirements 

Not applicable 

3.2.3.7 Software reliability requirements 



3.2.3.8 Software maintainability requirements 


3.2.3.9 Data definition and database requirements 


3.2.3.10 Human factors related requirements 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 87 / 315 

3.2.4 Requirements for L0c IDP-SC 

Theses paragraphs present the requirement specific to the set of IDP-SC in charge of L0c 

product generation. 

3.2.4.1 INIT_LOC_L0 

INIT_LOC_L0 IDP-SC shall create L0 metadata location information from ancillary data 

and auxiliary data. INIT_LOC_L0 IDP-SC is in charge of: 

IERS data ingestion 

Viewing Model Loading 

Ancillary data computation 

L0 Granule footprint computation. 

No parallelization strategy is foreseen. 

3.2.4.1.1 Functional requirements 


INIT_LOC_L0 IDP-SC shall set location data in L0 metadata from ancillary data (e.g. SAD 

data) or/and auxiliary data (GIPP). 

INIT_LOC_L0 IDP-SC is in charge of: 

SAD data importing, 

IERS data ingestion (GIPP) 

Viewing Model Loading 

including location GIPP ingestion 

including metadata updating with QuickLook model 


Granule footprint computation 

Parents: S2-PDGS-IDP-005, S2-PDGS-IDP-020, S2-PDGS-SYS-005 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 88 / 315 


INIT_LOC_L0 IDP-SC shall be activated: 

by datastrip 



INIT_LOC_L0 IDP-SC shall implement algorithm processing based on (cf. Table 2): 

SAD data importing: 

[LR_EXTR-DPM] Module #N-02-01 

(SAD formatting in metadata part) 

IERS data ingestion: 


(IERS data ingestion part) 

Viewing Model Loading: 

[INIT_LOC-DPM] Module #N-01 (Inventory Use Case ) 

Ancillary data updating 

[INIT_LOC-DPM] Module #N-03 

(Ancillary data computing) 

Granule footprint updating 

[INIT_LOC-DPM] Module #N-02 (Granule footprint computation part, 

inventory use-case) 



Steps of INIT_LOC_L0 IDP-SC that shall be switched ON or OFF according to 

configuration parameters are: 

SAD data ingestion 

(default ENABLE) 



Granule footprint computation 

(default ENABLE), 




Note : Viewing model step is always mandatory. 


In accordance with activated step, INIT_LOC_L0 IDP-SC inputs shall be: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 89 / 315 

Processing Unit including all or part of: 

PDI-FE-DS : 

Metadata at datastrip level 

PDI-FE-GR : 

Metadata at granule level for each granule of the processed datastrip 

Auxiliary data: 

GIPP, at least: 

Spacecraft model 

Viewing directions 

INIT_LOC_L0 specific processing parameters (e.g.: along track step for ancillary 

data processing) 

IERS bulletin 

Coarse DEM (GLOBE) 

Ancillary data: 

Either SAD data 

Or Read from Metadata at datastrip level (ephemeris, attitudes, datation model, …) 



When relevant, INIT_LOC_L0 IDP-SC shall select from input GIPP the applicable 

parameters in accordance with band, detector and sensing TDI configuration. 



In accordance with activated steps, INIT_LOC_L0 IDP-SC output Processing Unit shall 

include all or part of: 

PDI-FE-DS : 

Updated Metadata at datastrip level 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 90 / 315 

PDI-FE-GR : 

Metadata at granule level for each granule of the processed datastrip (updated) 



INIT_LOC_L0 IDP-SC shall skip missing granules in the datastrip without error. Metadata 

at granule level are processed only if the granule is available in the datastrip. 


Note: According to downlink strategy, a datastrip could be discontinuous. 


The INIT_LOC_L0 IDP-SC shall implement a FAKE mode. In this mode: 

updated metadata structure are created (either for granule and datastrip metadata), 

location information in the metadata is identified as unavailable. 


3.2.4.1.2 Performance requirements 


A single execution of INIT_LOC_L0 IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, a datastrip equivalent to 10 minutes of 

downlink in less than 30 seconds with the following assumptions: 

Nominal scenario: All step activated, 

Along track step for ancillary data processing: 150km 

Parents: S2-PDGS-IDP-080, S2-PDGS-IDP-085, S2-PDGS-SYS-385, S2-PDGS-SYS-390, S2-PDGS-SYS-400 

Note: Along track step is set to 150km to have similar sampling distance along and cross 

track. 




downlink in less than one minute with the following assumptions: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 91 / 315 


Parents: S2-PDGS-IDP-080, S2-PDGS-IDP-085, S2-PDGS-SYS-380, S2-PDGS-SYS-400 

3.2.4.1.3 Design requirements and implementation constraints 


For scaling purpose, INIT_LOC_L0 IDP-SC shall be designed such as: 

"Ancillary data updating" step could be outer parallelized by datastrip (full swath) 

along track fragment, 

"Granule footprint updating" step could be outer parallelized by detector along track. 



For maintainability purpose, INIT_LOC_L0 IDP-SC shall be designed such as: 

INIT_LOC_L0 algorithmic steps that are shared with other IDP-SC (e.g. granule 

footprint computation) shall be designed as a library, 

Low level algorithm functions that are shared with other IDP-SC (e.g.: Direct 

Location on DEM) shall be designed as a library. 


3.2.4.2 QL_GEO 

QL_GEO IDP-SC is in charge of geometric processing in QuickLook geometry. 

It shall process: 

Granules footprint in Quicklook geometry 

detector images in QuickLook geometry (for the QuickLook bands only), including: 

Rescaling input image data to 320m 

Colocation grid computation 

Resampling rescaled images to QuickLook geometry 

Parallelization strategy foreseen: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 92 / 315 

By datablock (restriction of the datastrip to a continuous acquisition) 

By detector and by band 



QL_GEO IDP-SC shall implement for a list of band and for a list of detectors identified as 

input: 

Granules footprint in Quicklook geometry processing 

detector images Resampling in QuickLook geometry (for the Quicklook bands only): 

Rescaling input image data to QuickLook sampling distance 

Colocation grid computation 

Resampling rescaled images to QuickLook geometry 

Parents: S2-PDGS-IDP-005, S2-PDGS-SYS-005 


QL_GEO IDP-SC shall be activated: 

by datablock (restriction of the datastrip to a continuous acquisition) 

by list of detector, 

by list of band 



QL_GEO IDP-SC shall select from GIPP the rescaling filters in accordance with 

compression mode identified in metadata (compressed or uncompressed) 



QL_GEO IDP-SC shall implement algorithm processing based on (cf. Table 2): 



(Viewing Model, QuickLook Model and 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 93 / 315 

QuickLook Display Model loading part, 

inventory use-case) 

Granule footprint in QuickLook Geometry computation: 

[INIT_LOC-DPM] Module #N-02 (Granule footprint in QuickLook 

Geometry part) 

Colocation grid : 


Rescaling 


Resampling 


(collocation grid computation) 

(LR extraction) 

(Resampling) 



Steps of QL_GEO IDP-SC that shall be switched ON or OFF according to configuration 

parameters are: 

Granule QL footprint 

(default ENABLE for B10 only) 

QL image generation(collocation grid, rescaling and resampling processing) 



Note: When QL image generation is processed by detector and band, granule QL footprint 

only requires a parallelization by detector. Granule QL footprint computation should then 

be activated only for one band. Default band for Granule QL footprint is set to a 60m band. 


In accordance with activated step, QL_GEO IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-ATF 

LR decompressed images (one by band and detector for each datablock) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 94 / 315 

PDI-FE-GR : 

Metadata at granule level for each processed granule 





Rescaling filter 

Resampling filter 

QL_GEO specific processing parameters (e.g. grid step) 



Read from Metadata at datastrip level (ephemeris, attitudes, datation model, …) 



When relevant, QL_GEO IDP-SC shall select from input GIPP the applicable parameters 

in accordance with band, detector and sensing TDI configuration. 



In accordance with activated steps, QL_GEO IDP-SC output Processing Unit shall include 

all or part of: 

PDI-FE-ATF: 

images in QuickLook Display geometry (one by band and detector for each 

datablock) 

PDI-FE-GR : 

Updated Metadata at granule level for each granule of the processed datastrip 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 95 / 315 


The QL_GEO IDP-SC shall implement a FAKE mode. In this mode: 

a fake image (No_Data) is created (with image dimensions coherent with the 

expected ones). 

if granule footprint computation is ENABLE: 

updated metadata structure are created (either for granule and datastrip 

metadata), 

granule footprint in QL geometry information in the metadata is identified as 

unavailable. 




A single execution of QL_GEO IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, all the QuickLook bands of the twelve detectors 

of a datastrip equivalent to 10 minutes of downlink in less than 25 minutes with the 

following assumptions: 

Nominal processing scenario: All steps activated, 

Step for collocation grid: 500m 

QuickLook bands: 

3 bands at 10m SSD 

1 band at 20m SSD 


Rescaling filter : optimized bicubic 

Resampling filter : Order 5 spline 


Note: Sampling distance for footprint computation is roughly set to the half of coarse DEM 

ground sampling distance. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 96 / 315 



equivalent to the Reference Platform one, all the QuickLook bands of the twelve detectors 

of a datastrip equivalent to 20 minutes of downlink in less than 50 minutes with the 

following assumptions: 












equivalent to the Reference Platform one, a 10m SSD band of one detector of a datastrip 

equivalent to 10 minutes of downlink in less than 30 seconds with the following 

assumptions: 














Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 97 / 315 




equivalent to the Reference Platform one, a 10m SSD band of one detector of a datastrip 


assumptions: 












For scaling purpose, QL_GEO IDP-SC shall be designed such as: 

" Granule QL footprint computation" step could be outer parallelized by detector 


"QL image generation" step could be outer parallelized by detector along track 

fragment. 


3.2.4.3 QL_CLOUD_MASK 

QL_CLOUD_MASK IDP-SC is in charge of coarse cloud mask processing both in L0c 

workflow and L1A reprocessing workflow. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 98 / 315 

In L0c scenario, QL_Cloud_Mask: 

Generate the full-swath QuickLook by cross-track concatenation of detectors in 

Quicklook geometry 

Generate Coarse cloud mask in Quicklook geometry: 

In L1A scenario, QL_Cloud_Mask: 

Generate coarse cloud mask in Quicklook geometry from full-swath decompressed 

QuickLook images. 


by QuickLook full swath ATF 



QL_CLOUD_MASK IDP-SC shall implement for a Full Swath QuickLook Along Track 

Fragment identified as input: 

Cross-track concatenation of detectors (one image by band and detector) 

Generate the coarse cloud mask from the full-swath concatenated images: 

Sun angles grid processing, 

Reflectance conversion 

Cloud detection 

Cloud filtering 

Cloud vectorization 



QL_CLOUD_MASK IDP-SC shall be activated: 


by Full Swath QuickLook Along Track Fragment 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 99 / 315 


When parallelized by along track fragment, QL_CLOUD_MASK shall generate output 

without redundancy and with continuity after Along Track aggregation, defining the output 

data to produce according to the following parameters: 

total number of ATF 

current ATF index 



QL_CLOUD_MASK IDP-SC shall implement algorithm processing based on (cf. Table 2): 

Full Swath concatenation: 

[INIT_LOC-DPM] Module #N-07 (full paragraph except histogram 

computation) 

Sun angles grid processing: 

[CLOUD_INV-DPM] §5.3.1 

Reflectance conversion : 


Cloud detection 


Cloud filtering 


Cloud vectorization 


(Sun angles grid processing part) 

(QL Reflectance conversion: all but Sun angles 

grid processing part) 

(Cloud detection) 

(Cloud filtering) 

(vectorization step only) 



Steps of QL_CLOUD_MASK IDP-SC that shall be switched ON or OFF according to 


Full-swath concatenation 

(default DISABLE) 

Coarse Cloud mask processing 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 100 / 315 


QL_CLOUD_MASK IDP-SC shall be activated by configuration parameters in one of the 

following scenario: 

NOMINAL 

REPROCESSING 

(default) 


Note: Nominal scenario is used in L0 processing workflow when reprocessing is used in 

L1A workflow for reprocessing. 


QL_CLOUD_MASK “REPROCESSING” scenario activates only Coarse Cloud mask 

processing . Full –swath concatenation is set to DISABLE. 



QL_CLOUD_MASK “NOMINAL” scenario activates both Full-Swath concatenation and 

Coarse Cloud mask processing . 



In accordance with activated step, QL_CLOUD_MASK IDP-SC inputs shall be for Nominal 

Scenario: 


PDI-FE-DS : 


PDI-FE-ATF 

images in QuickLook Display geometry (one by band and detector for each 

datablock) 



Connection columns 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 101 / 315 

Absolute calibration coefficients 

QL_CLOUD_MASK specific processing parameters (e.g. erosion distance) 





In accordance with activated step, QL_CLOUD_MASK IDP-SC inputs shall be for 

Reprocessing Scenario: 


PDI-FE-DS : 


PDI-FE-ATF 

Decompressed QuickLook (one file by band for each datablock) 




QL_CLOUD_MASK specific processing parameters (e.g. erosion distance) 





When relevant, QL_CLOUD_MASK IDP-SC shall select from input GIPP the applicable 




In NOMINAL scenario, QL_ CLOUD_MASK IDP-SC output Processing Unit shall include: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 102 / 315 

PDI-FE-ATF: 

Full swath concatenated QuickLook images (one file by band and ATF) 

Coarse cloud mask vector (one file by ATF) 



In REPROCESSING scenario, QL_CLOUD_MASK IDP-SC output Processing Unit shall 

include: 

PDI-FE-ATF: 

Coarse cloud mask vector (one file by ATF) 




A single execution of QL_CLOUD_MASK IDP-SC shall process, on a single-core CPU 

with hardware equivalent to the Reference Platform one, a datastrip equivalent to 10 

minutes of downlink in less than one minute with the following assumptions: 


Solar angles grid step: 150km 




with hardware equivalent to the Reference Platform one, a datastrip equivalent to 20 

minutes of downlink in less than two minutes with the following assumptions: 

Nominal scenario: All steps activated, 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 103 / 315 


with hardware equivalent to the Reference Platform one, a full swath QuickLook ATF of 

4000 pixels Along Track in less than 20 seconds with the following assumptions: 






For maintainability purpose, QL_CLOUD_MASK IDP-SC shall be designed such as: 

Low level functions that are shared with other IDP-SC (e.g.: mask erosion) shall be 

designed as a library. 


3.2.4.4 FORMAT_IMG(QL JP2000) 

FORMAT_IMG(QL JP2000) IDP-SC is in charge of QuickLook compression in JPEG2000 

format. 


by band 

by datablock. 



FORMAT_IMG(QL JP2000) IDP-SC shall implement QuickLook images compression (one 

compressed image by band). 



FORMAT_IMG(QL JP2000) IDP-SC shall be activated: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 104 / 315 


by list of bands 



FORMAT_IMG(QL JP2000) IDP-SC shall implement algorithm processing based on (cf. 

Table 2): 

QL J2000 compression: 

[JP2K-DPM] Module #IAS-10-2 

(compression of an image) 



FORMAT_IMG(QL JP2000) IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-ATF 

List of Full swath concatenated QuickLook images (for each datablock, for all Full 

Swath QuickLook ATF of the datablock, one file by band) 



FORMAT_IMG(QL JP2000) specific processing parameters (e.g. compression 

parameters) 



FORMAT_IMG(QL JP2000) IDP-SC output Processing Unit shall include: 

PDI-FE-DS: 

Full swath concatenated QuickLook images (one file by band) 

Metadata at datastrip level (pointer to QuickLook image files) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 105 / 315 




A single execution of FORMAT_IMG(QL JP2000) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, all the QuickLook bands of 

a datastrip equivalent to 10 minutes of downlink in less than 30 seconds with the following 

assumptions: 

5 QuickLook bands 

Lossless compression 



A single execution of FORMAT_IMG(QL JP2000) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, all the QuickLook bands of 

a datastrip equivalent to 20 minutes of downlink in less than one minute with the following 

assumptions: 


Reversible compression 


3.2.4.5 FORMAT_ISP 

FORMAT_ISP IDP-SC formats granule Instrument Source Packets (ISP) in SAFE format 

[SAFE-TN]. 


by set of granules (defined, for each detector, by a list or by ATF). 



FORMAT_ISP IDP-SC, for the set of granules identified as input, shall provide: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 106 / 315 

ISP SAFE formatted fully compliant with [PSD] for each granule (compliancy with 

data part of PDI before TAR archiving). 

Parents: S2-PDGS-IDP-005, S2-PDGS-SYS-005, S2-PDGS-DPC-355 


FORMAT_ISP IDP-SC shall be activated: 

by list of detector 

either by Along Track Fragment 

or by a list a granule 

When activated by ATF, FORMAT_ISP shall process all available granules included in the 

ATF. 



SAFE packaged ISP generated for each granule by FORMAT_ISP IDP-SC shall be 

compliant with Product Specification Document [PSD] format (SAFE) for L0 ISP 

(compliancy with data part of PDI before TAR archiving). 

Parents: S2-PDGS-DPC-355 


FORMAT_ISP IDP_SC shall be robust to missing ISP relevant to a granule identified as 

input. 



FORMAT_ISP IDP-SC input Processing Unit shall include all or part of: 

PDI-FE-DS : 


PDI-FE-GR : 

Image Source Packets (gathered by band and detector for each datablock) 

Metadata at granule level for each granule 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 107 / 315 

GIPP : none 



FORMAT_ISP IDP-SC output Processing Unit shall include all or part of: 

PDI-FE-GR : (for each processed granule) 

SAFE packaged ISP for each granule 




FORMAT_ISP IDP-SC shall process, on a single-core CPU with hardware equivalent to 

the Reference Platform one, a datastrip equivalent to 10 minutes of downlink in less than 

1h 15 minutes. 



FORMAT_ISP IDP-SC shall process, on a single-core CPU with hardware equivalent to 


2h 30 minutes. 



A single execution of FORMAT_ISP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, 12 granules in less than 25 seconds. 

Parents: S2-PDGS-IDP-080, S2-PDGS-IDP-085, S2-PDGS-SYS-390,S2-PDGS-SYS-400 


A single execution of FORMAT_ISP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, 15 granules in less than 30 seconds. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 108 / 315 

3.2.4.6 FORMAT_METADATA(GR-L0c) 

FORMAT_METADATA(GR-L0c) IDP-SC finalizes L0 consolidated metadata at granule 

level and provides granule in SAFE format ready for archiving. 

FORMAT_METADATA(GR-L0c) IDP-SC is at least in charge of: 

Granule Cloudy pixel percentage computation. 

Providing a SAFE formatted granule. 


By set of granules (defined, for each detector, by a list or by ATF). 



FORMAT_METADATA(GR-L0) IDP-SC shall process for the set of granules identified as 

input: 

For each granule, 

Granule Cloudy pixel percentage computation, 

Technical quality indicators setting 

Provide a SAFE formatted fully compliant with [PSD] granule ready for archiving 

(before TAR formatting) 

Parents: S2-PDGS-IDP-005, S2-PDGS-IDP-070, S2-PDGS-SYS-005, S2-PDGS-DPC-355 


FORMAT_METADATA(GR-L0) IDP-SC shall be activated: 




When activated by ATF, FORMAT_METADATA(GR-L0) 

included in the ATF. 

shall process all granules 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 109 / 315 


FORMAT_METADATA(GR-L0) IDP-SC shall implement algorithm processing based on 

[DPM]: 

Granule Cloudy pixel percentage computation 

[CLOUD_INV-DPM]-§5.3.4 

(Cloudy pixel 

percentage computation part) 



Technical quality indicators are provided 

as percentage of degraded/missing MSI data in the granule 

As percentage of degraded/missing ancillary data during granule acquisition time 

Parents: 


Metadata at granule level generated by FORMAT_METADATA(GR-L0) IDP-SC shall be 

compliant with Product Specification Document [PSD] format (SAFE) for L0 metadata at 

granule level (before TAR formatting). 

Parents: S2-PDGS-IDP-070, S2-PDGS-DPC-355 


FORMAT_METADATA(GR-L0) IDP-SC shall gather SAFE formatted metadata at granule 

level and granule SAFE packaged ISP in a granule SAFE container fully compliant with 

Product Specification Document [PSD] format (SAFE) for L0 granule (without TAR 

formatting). 



FORMAT_METADATA(GR-L0) IDP-SC input Processing Unit shall include all or part of: 

PDI-FE-DS : 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 110 / 315 

PDI-FE-GR : 


SAFE packaged ISP for each granule 

PDI-FE-ATF : 

List of Coarse cloud mask vector (for the whole datastrip, by ATF) 

Auxiliary data 

GIPP : none 

Ancillary data 

Read from metadata at datastrip level 



FORMAT_METADATA(GR-L0) IDP-SC shall check that input masks provided by ATF 

include all the available granules to produce. 



FORMAT_METADATA(GR-L0) IDP-SC output Processing Unit shall include all or part of: 


Updated L0c Metadata at granule level in SAFE format 

PDI-GR 

SAFE formatted granule 



In FAKE mode, FORMAT_METADATA(GR-L0) IDP-SC shall at least: 

Generate a L0 Metadata at granule level with brief metadata set correctly which is 

compliant with PSD format [PSD] (before TAR archive formatting). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 111 / 315 

Provide the SAFE packaged granule 

Parents: S2-PDGS-IDP-070, S2-PDGS-IDP-115, S2-PDGS-DPC-355, S2-PDGS-IDP-110 



FORMAT_METADATA(GR-L0) IDP-SC shall process, on a single-core CPU with 


downlink in less than 1h 15 minutes. 



FORMAT_METADATA(GR-L0) IDP-SC shall process, on a single-core CPU with 





A single execution of FORMAT_METADATA(GR-L0) IDP-SC shall process, on a singlecore 

CPU with hardware equivalent to the Reference Platform one, 12 granules in less 

than 25 seconds. 



A single execution of FORMAT_METADATA(GR-L0) IDP-SC shall process, on a singlecore 




3.2.4.7 FORMAT_METADATA(DS-L0c) 

FORMAT_METADATA(DS-L0c) IDP-SC finalizes L0 consolidated metadata at datastrip 

level and provides a SAFE formatted datastrip. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 112 / 315 



FORMAT_METADATA(DS-L0c) IDP-SC shall 

Finalize metadata at datastrip level to be fully compliant with [PSD] (before TAR 

formatting). 

ASP (Ancillary Source Packet) SAFE formatting fully compliant with [PSD] (before 

TAR formatting). 

Provide a SAFE formatted fully compliant with [PSD] granule ready for archiving 

(before TAR formatting). 

Parents: S2-PDGS-IDP-005, S2-PDGS-IDP-070, S2-PDGS-SYS-005, S2-PDGS-DPC-355 


FORMAT_METADATA(DS-L0c) IDP-SC shall be activated: 

by datastrip 



FORMAT_METADATA(DS-L0) IDP-SC shall implement algorithm processing based on 

[DPM]: 

update metadata 

[CLOUD_INV-DPM]-§5.4 

(Cloud mask vectorization 

update metadata subsection) 



Metadata at datastrip level generated by FORMAT_METADATA(DS-L0c) IDP-SC is 

compliant with Product Specification Documentation [PSD] format (SAFE) for L0 datastrip 

(before TAR formatting). 



Steps of FORMAT_METADATA(DS-L0c) that shall be switched ON or OFF according to 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 113 / 315 

metadata processing (finalization and SAFE formatting) 

ASP SAFE formatting 



Parents: S2-PDGS-IDP-130, S2-PDGS-IDP-135, S2-PDGS-DPC-355 


FORMAT_METADATA(DS-L0c) IDP-SC gathers SAFE formatted metadata at datastrip 

level, QuickLook Files, auxiliary data and SAFE formatted ancillary data ASP, in a SAFE 

container for datastrip fully compliant with Product Specification Document [PSD] format 

(SAFE) for L0 datastrip (before TAR formatting). 



FORMAT_METADATA(DS-L0c) IDP-SC input Processing Unit shall include: 

PDI-FE-DS : 


QuickLook files 


GIPP : all GIPP used in L0 processing 

IERS bulletin 

DEM: reference to coarse DEM (Globe) used in L0 processing 


ASP 



FORMAT_METADATA(DS-L0c) IDP-SC output Processing Unit shall include: 

PDI-FE-DS : 

Updated L0 Metadata at datastrip level 

PDI-DS 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 114 / 315 

SAFE formatted datastrip 



In FAKE mode, FORMAT_METADATA(DS-L0c) IDP-SC shall at least: 

Generate an L0c Metadata at datastrip level with brief metadata set correctly which 

is compliant with PSD format (before TAR formatting). 

Provide the SAFE packaged datastrip 

Parents: S2-PDGS-IDP-070, S2-PDGS-IDP-115, S2-PDGS-DPC-355, S2-PDGS-IDP-110 



A single execution of FORMAT_METADATA(DS-L0c) IDP-SC shall process, on a singlecore 

CPU with hardware equivalent to the Reference Platform one, a datastrip equivalent 

to 20 minutes of downlink in less than 20 seconds. 


3.2.5 Requirements for L1A/B radiometric processing and L1A formatting IDP-SC 

Theses paragraphs present the set of IDP-SC in charge of L1A and L1B radiometric 

processing and L1A product formatting. 



3.2.5.1 UNFORMAT_SAFE(GR) 

UNFORMAT_SAFE(GR) IDP-SC is used only in the case of reprocessing to convert the 

SAFE L0c granules into internal format. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 115 / 315 

Foreseen parallelization is by group of granules (defined, for each detector, by a list or by 

ATF). 



Steps of UNFORMAT_SAFE(GR) IDP-SC that shall be switched ON or OFF according to 


Granule metadata SAFE unformatting 


ISP SAFE unformatting 




UNFORMAT_SAFE (GR) IDP-SC shall be activated: 




When activated by ATF, UNFORMAT_SAFE(GR) 

included in the ATF. 

shall process all available granules 

Parents: S2-PDGS-DPC-355, S2-PDGS-IDP-135 


UNFORMAT_SAFE (DS-L0c) IDP-SC shall be activated: 

by group of granules 



UNFORMAT_SAFE(GR) IDP-SC input Processing Unit shall include all or part of: 

PDI-GR 

SAFE formatted granule 

GIPP : none 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 116 / 315 


UNFORMAT_SAFE(GR) IDP-SC output Processing Unit shall include all or part of L0c 

product files, i.e.: 

PDI-FE-GR : 

Metadata at granule level for each processed granule 

Set of ISP (for all available bands) for each processed granule 




UNFORMAT_SAFE(GR) IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, a datastrip equivalent to 10 minutes of downlink 

in less than 2hours 30 minutes. 



UNFORMAT_SAFE(GR) IDP-SC shall process, on a single-core CPU with hardware 


in less than 5hours. 



A single execution of UNFORMAT_SAFE(GR) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, 12 granules in less than 50 

seconds. 



A single execution of UNFORMAT_SAFE(GR) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, 15 granules in less than 60 

seconds. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 117 / 315 

3.2.5.2 UNFORMAT_SAFE(DS) 

UNFORMAT_SAFE(DS) IDP-SC is used only in the case of reprocessing to convert the 

SAFE L0c datastrip into internal format. 

No parallelization is expected. 



UNFORMAT_SAFE(DS) IDP-SC shall unpack the SAFE formatted L0c at datastrip level : 

metadata at datastrip level, 

QuickLook Files, 

SAFE formatted ancillary ASP (Ancillary Source Packet) 



UNFORMAT_SAFE(DS) IDP-SC shall be activated: 

by datastrip 



UNFORMAT_SAFE(DS) IDP-SC input Processing Unit shall include: 

PDI-DS 

SAFE formatted datastrip 



UNFORMAT_SAFE(DS) IDP-SC output Processing Unit shall include: 

PDI-FE-DS : 


QuickLook files 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 118 / 315 


Ancillary Source Packet (ASP) 




A single execution of UNFORMAT_SAFE(DS) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, a datastrip equivalent to 20 

minutes of downlink in less than 20s seconds. 


3.2.5.3 UPDATE_LOC 

UPDATE_LOC IDP-SC contributes to PS-5 (Loading of Viewing Model for L1 processing). 

It is part of L1 processing. 




UPDATE_LOC IDP-SC shall update L0 metadata location information from updated 

ancillary data (e.g. POD data) or/and updated auxiliary data (GIPP). 

UPDATE_LOC IDP-SC is in charge of: 

SAD data importing (reprocessing only) 

POD data ingestion (degraded case only) 

Datation model refining (degraded case only), 

Updated IERS data ingestion (reprocessing only) 

Viewing Model Loading (including updated location GIPP ingestion) 

Framing definition for L1A, L1B and L1C product 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 119 / 315 



UPDATE_LOC IDP-SC shall be activated: 

by datastrip 



UPDATE_LOC IDP-SC shall implement algorithm processing based on (cf. Table 2): 

SAD data importing: 


(SAD formatting in metadata part) 

datation model refining: 


IERS data ingestion: 


(subsection on datation model computed by 

linear regression) 

(IERS data ingestion part) 


[INIT_LOC-DPM] Module #N-01 (Production Use Case ) 



(Ancillary data computing) 


[INIT_LOC-DPM] Module #N-02 (Granule footprint computation part, 

production use-case) 



UPDATE_LOC IDP-SC shall define L1A, L1B and L1C framing. 

The Framing Stragety is (TBC): 

for L1B processing: framing is defined such that, for each detector, band are coarse 

registrated taking into account inter-band baseline and radiometric margin (for at 

least decompression, deconvolution and denoising processing), 

for L1A processing : framing is defined to be superimpose to the L1B processing 

framing, 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 120 / 315 

for L1C processing : framing is derived from L1B framing adding a coarse acrosstrack 

registration (by cutting staggered extra-granules at datablock borders) 

L1A and L1B formatting: a coarse across-track registration is made by cutting extragranules 

at the borders of datablocks. 



Framing strategy is configured thru GIPP, indicating how many lines should be cut at 

datablock borders for each detector and band. 



UPDATE_LOC IDP-SC shall generate a Frame file which describes the framing strategy. 

This frame file includes at least : 

The framing definition for L1A, L1B and L1C. 

The list of staggered extra-granules to be cut for L1A and L1B formatting and L1C 

processing. 

Parents: 


UPDATE_LOC IDP-SC shall update the granule list of the datastrip in accordance with 

L1A/L1B processing framing strategy base on algorithm described in. [INIT_LOC-DPM] 

Module #N-02 (Identify granules part) 



Steps of UPDATE_LOC IDP-SC that shall be switched ON or OFF according to 


SAD ingestion 


POD data ingestion 

Datation model refining 


(default DISABLE), 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 121 / 315 








Note: Viewing model step is always mandatory. 


In accordance with enabled or disabled steps, UPDATE_LOC IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-GR : 

Metadata at granule level for each granule of the processed datastrip 


GIPP, at least 

IERS bulletin 



Update_LOC specific processing parameters (e.g.: along track step for ancillary 

data processing) 

IERS bulletin 



POD data (degraded case only) 

Exogenous Datation model (degraded case only) 

Datation information at ISP level (degraded case only) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 122 / 315 

SAD data (reprocessing only) 

Otherwise read from Metadata at datastrip level (ephemeris, attitudes, datation 

model, …) 



When relevant, UPDATE_LOC IDP-SC shall select from input GIPP the applicable 




In accordance with activated steps, UPDATE_LOC IDP-SC output Processing Unit shall 


PDI-FE-DS : 


Frame file 

PDI-FE-GR : 

Updated Metadata at granule level for each granule of the processed datastrip 



UPDATE_LOC IDP-SC shall skip missing granules in the datastrip without error. Metadata 

at granule level are processed only if the granule is available in the datastrip. 


Note: According to downlink strategy, a datastrip could be discontinuous. 


The UPDATE_LOC IDP-SC shall implement a FAKE mode. In this mode: 

updated metadata structure are created (either for granule and datastrip metadata), 

location information in the metadata are identified as unavailable. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 123 / 315 



A single execution of UPDATE_LOC IDP-SC shall process, on a single-core CPU with 



Nominal scenario: All step activated excepted SAD ingestion, POD data ingestion 

step and Datation refining step, 



Note: Along track step is set to 150km to have similar sampling distance along and cross 

track. 













degraded scenario :all step activated, 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 124 / 315 


For scaling purpose, UPDATE_LOC IDP-SC shall be designed such as: 

"Ancillary data updating" step could be outer parallelized by datastrip (full swath) 


"Granule footprint updating" step could be outer parallelized by detector along track 

fragment. 



For maintainability purpose, UPDATE_LOC IDP-SC shall be designed such as: 

UPDATE_LOC algorithmic steps that are shared with other IDP-SC (e.g. granule 

footprint computation) shall be designed as a library, 




3.2.5.4 QL_DECOMP 

QL_DECOMP IDP_SC is performed in case of L1A reprocessing only and used for 

JPEG2000 QuickLook image decompression. 


by band 

by datablock. 



QL_DECOMP IDP-SC shall implement QuickLook images JPEG2000 decompression (one 

compressed image by band to be decompressed). 



QL_DECOMP IDP-SC shall be activated: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 125 / 315 





QL_DECOMP IDP-SC inputs shall be: 

PDI-FE-DS: 

Full swath JPEG2000 compressed QuickLook images (one file by band and by 

datablock) 



QL_DECOMP IDP-SC outputs shall be: 


PDI-FE-DS : 

Full swath concatenated QuickLook images (one file by band and datablock) 




A single execution of QL_DECOMP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, all the QuickLook bands of a datastrip 


assumptions: 





A single execution of QL_DECOMP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, all the QuickLook bands of a 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 126 / 315 

datastripequivalent to 20 minutes of downlink in less than one minute with the following 

assumptions: 




3.2.5.5 QL_CLOUD_MASK 

QL_CLOUD_MASK IDP_SC is used in L0c processing (§ 3.2.5.5) but in case of L1A 

reprocessing, it will be called at L1A processing level. 

3.2.5.6 INIT_LOC_ L1 

INIT_LOC_L1 IDP-SC contributes to PS-5 (Loading of Viewing Model for L1 processing). 

It is part of L1 processing for both nominal and reprocessing use-case. 

It computes by detector the location metadata required by L1 product or L1 processing 

(e.g. detector footprint computation) 



INIT_LOC_L1 IDP-SC shall process for a list of detectors identified as input: 

Detector footprint computation, 

Technical Masks (Ancillary data quality mask) computation 

Projection of coarse Cloud mask from QuickLook geometry to Focal Plan geometry 

of each band 

For each granule of the detector: 

Granule cloudy pixel percentage computation (reprocessing only) 

Local technical quality indicator (Ancillary data) computation 


Note: INIT_LOC_L1 geometric processing requires the load of Viewing model. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 127 / 315 


INIT_LOC_L1 IDP-SC shall be activated: 

by datablock 

by list of detectors 



INIT_LOC_L1 IDP-SC shall implement algorithm processing based on (cf. Table 2):: 


[INIT_LOC-DPM] Module #N-01 (Production Use Case ) 

Detector footprint computation: 

[INIT_LOC-DPM] Module #N-02 (detector footprint computation part, 


Technical Masks computation: 

[INIT_LOC-DPM] Module #N-04 (Production Use Case- Ancillary data part ) 

Coarse Cloud mask projection in Focal Plan geometry: 

[INIT_LOC-DPM] Module #N-10 (Cloud Mask relocation) 

Granule cloud cover percentage computation 

[CLOUD_INV-DPM] Cloud Mask Vectorization (granule percentage of cloudy pixel 

computing part). 



Detector footprint generated by INIT_LOC_L1 IDP-SC shall be a set of polygons such that 

each polygon does not include a missing granule. 

Parents: 


Main steps of INIT_LOC_L1 IDP-SC shall be switched ON or OFF according to 

configuration parameters: 

Detector footprint computation 


Technical (Ancillary data) Masks computation 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 128 / 315 

Coarse Cloud mask projection in Focal Plan geometry 

Granule cloud cover percentage computation 





In accordance with activated step, INIT_LOC_L1 IDP-SC inputs shall be: 


PDI-FE-DS : 


Coarse Cloud Mask in QuickLook geometry 

PDI-FE-GR : 

Metadata at granule level for each granule of the processed detectors 


GIPP at least: 



INIT_LOC_L1 specific processing parameters (e.g.: step for detector footprint 

computation processing) 



Read from Metadata at datastrip level 



When relevant, INIT_LOC_L1 IDP-SC shall select from input GIPP the applicable 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 129 / 315 

In accordance with activated step, INIT_LOC_L1 IDP-SC output Processing Unit shall 


PDI-FE-ATF : (for each band of each processed detector) 

Detector footprint 

Cloud mask in Focal plan geometry 

Technical masks (ancillary data) 

PDI-FE-GR : (for each granule of each processed detector) 

Updated Metadata at granule level 



In FAKE mode, INIT_LOC_L1 IDP-SC shall generate detector footprint as the union of 

granule footprint. 





hardware equivalent to the Reference Platform one, all the twelve detectors of a datastrip 

equivalent to 10 minutes of downlink in less than 5 minutes with the following assumptions: 

Nominal processing scenario: All steps activated excepted cloudy pixel percentage 

computation at granule level step, 

Number of vertices for coarse Cloud mask in QuickLook geometry : 5000 

Step for detector footprint computation: 500m 












Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 130 / 315 

equivalent to 20 minutes of downlink in less than 10 minutes with the following 

assumptions: 








hardware equivalent to the Reference Platform one, two detectors of a datastrip equivalent 

to 10 minutes of downlink in less than 50 seconds with the following assumptions: 








hardware equivalent to the Reference Platform one, one detector of a datastrip equivalent 
















Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 131 / 315 









to 10 minutes of downlink in less than one minute with the following assumptions: 

Reprocessing scenario :all step activated, 






For scaling purpose, INIT_LOC_L1 IDP-SC shall be designed such as: 

"Detector footprint computation", “Coarse cloud mask projection in Focal Plan 

geometry”, "Technical Masks (ancillary data) computation" steps could be outer 

parallelized by band, 

“Granule cloudy pixel percentage computation” steps could be outer parallelized 

detector by along track fragment. 



When parallelized by along track fragment, INIT_LOC_L1 shall generate output without 

redundancy and with continuity after aggregation, defining the output data to produce 

according to the following parameters: 

total number of ATF 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 132 / 315 

current ATF index 



For maintainability purpose, INIT_LOC_L1 IDP-SC shall be designed such as: 

Init_LOC_L1 algorithmic steps that are shared with other IDP-SC (e.g. granule 

cloudy pixel percentage computation, detector foot print computation) shall be 

designed as a library, 




3.2.5.7 DECOMP 

DECOMP IDP-SC wraps WICOM CFI with IDP-SC generic interfaces. 



DECOMP IDP-SC shall implement, for a list of band of an ATF, 

For each band, MSI ISP decompression, 

For each band, Mission data Quality Masks (lost and degraded) generation 

For each granule, Local technical quality indicator (MSI data) computation 



DECOMP IDP-SC shall be activated: 


by ATF for a detector, 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 133 / 315 


DECOMP IDP-SC shall detect lost MSI data and stuff in accordance the decompressed 

image with No_Data. 



DECOMP IDP-SC implements through the integration of WICOM CFI: 

MSI ISP decompression: 

Mission data Quality Masks generation 

Stuffing decompressed image with nodata if MSI data are missing 

Local technical quality indicator (MSI data) computation 



When DECOMP is activated by ATF, Origin frame of each mask is set to the Upper-Left 

pixel of the first granule of the detector. 

Parents: 


DECOMP IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-ATF 

Nominal processing: Image Source Packets (gathered by band and detector for 

each datablock) 

PDI-FE-GR : 

Reprocessing only: Image Source Packets (gathered by band for each granule) 

Metadata at granule level for each granule of the processed ATF 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 134 / 315 


DECOMP specific processing parameters 

Ancillary data: none 



DECOMP IDP-SC output Processing Unit shall include all or part of: 

PDI-FE-ATF: 

Decompressed images (one file by band) 

Mission Data Quality Masks (degraded and lost) 

PDI-FE-GR : 

Updated Metadata at granule level for each granule of the processed ATF 



The DECOMP IDP-SC shall implement a FAKE mode. In this mode: 

Fake images (No_Data) are created for each required bands (with image 

dimensions coherent to the expected one ). 

A Mission data Quality Mask (Lost) is created 

Lost MSI data indicator is set to 100% for each granule. 




DECOMP IDP-SC shall process, on a single-core CPU with hardware equivalent to the 

Reference Platform one, all bands of a datastrip equivalent to 10 minutes of downlink in 

less than 3.9 hours. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 135 / 315 


DECOMP IDP-SC shall process, on a single-core CPU with hardware equivalent to the 

Reference Platform one, all bands of a datastrip equivalent to 20 minutes of downlink in 

less than 7.8 hours. 



A single execution of DECOMP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, all bands of a an ATF equivalent to 

12,2 granules in less than 80 seconds. 


Note: 12,2 granules are mandatory to generate 12 complete granules up to L1B according 

to radiometric margins. 


A single execution of DECOMP IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, all bands of a an ATF equivalent to 

15,2 granules in less than 100 seconds. 




DECOMP IDP-SC shall make use of WICOM CFI. 


DECOMP software should use Process Builder techniques for WICOM software 

encapsulation. 

3.2.5.8 RADIO_ AB 

RADIO_AB IDP-SC implements radiometric correction both for Level L1A and L1B. (PS- 

07 and PS-09) 



RADIO_AB IDP-SC shall implement for a detector Along Track Fragment identified as 

input: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 136 / 315 

Level 1A radiometric corrections: 

SWIR rearrangement for L1A (optional), 

L1A images writing 

•Blind pixels removal 

L1A masks computation 

•Saturated pixels mask 

•No data Pixel 

•Defective pixels 

Level 1B radiometric corrections: 

Inverse on-board equalization 

Dark signal correction 

Blind pixel removal 

•Offset correction 

•Non uniformity correction 

Cross talk correction 

•Optical cross talk correction 

•Electronical cross talk correction 

Relative response correction 

SWIR rearrangement 

L1B Mask generation 

•No data Pixel 

•Defective pixels 

Defective pixel interpolation 

No_Data pixel interpolation 

Deconvolution 

Denoising 

60m bands binning 

L1B Mask generation 

•Saturated pixels mask 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 137 / 315 


Note: L1B first radiometric corrections (inverse on-board equalization, dark signal 

correction, blind pixel removal, crosstalk correction and relative response corrections) are 

processed from L1A image without SWIR rearrangement whatever “SWIR arrangement for 

L1A” is set or not to ENABLE 


Radiometric corrections of RADIO_AB IDP-SC that shall be switched ON or OFF 

according to parameters provided as GIPP are: 

SWIR Rearrangement for L1A 


Equalization 

Dark Signal offset correction 

Dark Signal Non Uniformity correction 

Optical cross talk correction 

Optical cross talk correction 

Blind pixel removal (for L1A) 

Blind pixel removal (for L1B) 

Defective pixel mask 

No Data mask 

Saturated pixels mask 

Defective pixel interpolation 

(by band, default ENABLE for all bands) 










(only if defective pixel mask is ENABLE, 

default ENABLE) 

No Data interpolation (only if No Data mask is ENABLE, 

default ENABLE) 

Deconvolution 

Denoising 


(by band, default ENABLE for 10m bands 

only) 

(by band, default ENABLE for 10m bands 

only) 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 138 / 315 

Radiometric corrections to be activated according to GIPP activation parameters are listed 

in [RADIO-DPM] 


Note: SWIR rearrangement for L1B radiometric corrections is always enable and could not 

be switched to disable by configuration 


RADIO_AB IDP-SC shall be activated by configuration parameters in one of the following 

scenario: 

L1A_only 

L1A and L1B 

(default) 

L1A and L1B without deconvolution and denoising: 

Deconvolution and denoising only 



RADIO_AB “L1A_only” scenario activates all L1A radiometric corrections which are set to 

ENABLE by GIPP but no L1B radiometric corrections 



RADIO_AB “L1A and L1B” scenario activates all L1A and L1B radiometric corrections 

which are set to ENABLE by GIPP. 



RADIO_AB “L1A and L1B without deconvolution and denoising” scenario activates all L1A 

and L1B radiometric corrections which are set to ENABLE by GIPP except: 

Deconvolution 

Denoising 


L1B Saturated pixels mask generation 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 139 / 315 



RADIO_AB “deconvolution and denoising only” scenario activates only, when set to 

ENABLE by GIPP: 

Deconvolution 

Denoising 


L1B Saturated pixels mask generation 


Note: “L1A and L1B without deconvolution and denoising” and “deconvolution and 

denoising only” are defined to secure the operational processing by DPC scalability. 


RADIO_ABIDP-SC shall be activated by: 

by detector along track fragment for all RADIO_AB scenario 

for a list of bands (from 1 to 13 bands) for “deconvolution and denoising only” 

scenario 



RADIO_AB IDP-SC shall implement algorithm processing based on DPM: 

SWIR rearrangement: 

[RADIO-DPM] IAS06-08 

(SWIR Rearrangement) 

Inverse on-board correction: 


(Inverse on-board correction) 

Dark signal correction: 


(Dark Signal offset computation, Dark Signal 

. non-uniformity contributions computation and 

Image correction from Dark Signal) 

Blind pixel removal: 


(Blind pixel removal) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 140 / 315 

Cross talk corrections: 

[RADIO-DPM] IAS06-06 (Optical and Electronical crosstalk . 

corrections) 


(partially corrected pixel mask use-case) 

Relative response correction: 


mask generation (L1B): 


(Relative response correction) 

(mask generation) 

mask generation (L1A): 

[RADIO-DPM] IAS06-14 (mask generation except dilatation from 

deconvolution margin step) 

defective pixel interpolation: 


No_Data pixel interpolation 


Deconvolution 


Denoising 




(defective pixel interpolation) 

(No_Data pixel interpolation) 

(Deconvolution) 

(Denoising) 

(binning of 60m bands) 



RADIO_AB IDP-SC shall produce in output L1A and L1B images as Along Track Fragment 

images corresponding to a number of complete granules. 

L1A ATF is potentially completed with No_Data if required by L1A radiometric margin 

availability. 

L1B ATF is potentially completed with No_Data if required by L1B radiometric margin 

availability. 


Note: 

Figure below illustrates images granules that have been completed by No_Data at 

beginning and end of datastrip. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 141 / 315 

First ATF 

Input ATF of 3 granules 

and available radiometric 

margins 

ATF of 3 granules 

completed with No_Data 

L1A 

in memory 

L1B 

in memory 

Output 

L1A ATF 

Output 

L1B ATF 

‘inner’ ATF 



margins 


L1A 

in memory 

L1B 

in memory 

Output 

L1A ATF 

Output 

L1B ATF 

Last ATF 



margins 


completed with No_Data 

L1A 

in memory 

L1B 

in memory 

Output 

L1A ATF 

Output 

L1B ATF 

Figure 26: L1A and L1B granules completed with no data 


L1A (resp. L1B) No_Data Masks shall include ATF potential completion with No_Data 

when required by L1A (resp. L1B) radiometric margin availability. 



L1A masks shall not be dilated from L1B processing deconvolution margin. 

Parents: 


Dilation of L1B masks shall be DISABLE if deconvolution step is not enabled for the 

processed band. 

Parents: 


L1A and L1B masks shall be provided in GML format. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 142 / 315 

For each band, origin frame of each L1A (resp. L1B) mask is set to the Upper-Left pixel of 

the first L1A (resp. L1B) granule of the detector. 

Parents: 

Note: 

With that convention, for each band, the masks generated by ATF refer to the same origin 

to simplify further L1 processing steps. 


Except for “deconvolution and denoising” scenario, in accordance with activated steps, 

RADIO_AB IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-ATF : (for each band of processed ATF) 

On-board decompressed images (all available bands) 



SWIR detector arrangement parameters 

On-board equalization parameters 

On-ground equalization parameters 

Blind pixel List 

Defective pixel list 

Cross-talk corrections 

Deconvolution filters 

Noise model 

Denoising threshold 

L2 Norm coefficients (for denoising) 

Wavelet filters (for denoising) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 143 / 315 

Wavelet base (for denoising) 

Maximal signal coefficients (for denoising) 

RADIO_AB specific processing parameters 





For “deconvolution and denoising only” scenario, in accordance with activated steps, 

RADIO_AB IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-ATF : (for processed bands of processed ATF) 

Pseudo-L1B images (output of “L1A and L1B without deconvolution and 

denoising” scenario) 



Deconvolution filters 

Noise model 

Denoising threshold 

L2 Norm coefficients (for denoising) 

Wavelet filters (for denoising) 

Wavelet base (for denoising) 

Maximal signal coefficients (for denoising) 

RADIO_AB specific processing parameters 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 144 / 315 





When relevant, RADIO_AB IDP-SC shall select from input GIPP the applicable parameters 

in accordance with band, detector, sensing TDI configuration and NUC table Id. 



According to configuration parameters, RADIO_AB shall produce for L1A (resp. L1B): 

Either PDI-FE-ATF images files (one file by band) 

Or a set of PDI-FE-GR images files (one file by band and by granule) 



In accordance with activated steps, RADIO_AB IDP-SC output Processing Unit shall 


PDI-FE-ATF : (for each band of each processed ATF) 

According to configuration parameters, L1A ATF images (one file by available 

band) 

According to configuration parameters, L1B ATF images (one file by available 

band) 

L1A masks (defective pixels, saturated pixels, No_Data pixels) 

L1B masks (defective pixels, saturated pixels, No_Data pixels and Cross-talk 

partially corrected pixels). 

PDI-FE-GR : (for each band of each granule of processed ATF) 

According to configuration parameters, L1A granule images (one file by available 

band and by granule) 

According to configuration parameters, L1B granule images (one file by available 

band and by granule) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 145 / 315 



In FAKE mode, RADIO_AB IDP-SC shall generate in accordance with activated steps: 

PDI-FE-ATF : (for each band of each processed ATF) 

According to configuration parameters, L1A ATF No Data images (one file by 

available band) 

According to configuration parameters, L1B ATF No Data images (one file by 

available band) 

L1A No_Data pixel mask as expected ATF envelope (4 corners) 

L1B No_Data pixel mask as expected ATF envelope (4 corners) 

Empty masks for defective pixels, saturated pixels, and Cross-talk partially 

corrected pixels. 

PDI-FE-GR : (for each band of each granule of processed ATF) 

According to configuration parameters, L1A granule No_Data images (one file by 

available band and by granule) 

According to configuration parameters, L1B granule No_Data images (one file by 

available band and by granule) 

With No Data images dimensions coherent to the expected one for L1A and L1B images 

files. 




RADIO_AB IDP-SC shall process, on a single-core CPU with hardware equivalent to the 

Reference Platform one, one detector of a datastrip equivalent to 10 minutes of downlink 

in less than 40 minutes with the following assumptions: 

“L1A and L1B” scenario with all L1A and L1B radiometric steps activated 

defective pixels rate: 1/10000 

no data pixel rate: 1/10000 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 146 / 315 

saturated pixel rate: 1/10e6 

deconvolution and denoising for all 10m bands, 



RADIO_AB IDP-SC shall process on a single-core CPU with hardware equivalent to the 

Reference Platform one, all the twelve detectors of a datastrip equivalent to 10 minutes of 

downlink in less than 8,2 hours with the following assumptions: 








RADIO_AB IDP-SC shall process on a single-core CPU with hardware equivalent to the 

Reference Platform one, all the twelve detectors of a datastrip equivalent to 20 minutes of 






deconvolution and denoising for all 10m bands 



A single execution of RADIO_AB IDP-SC shall generate, on a single-core CPU with 

hardware equivalent to the Reference Platform one, an ATF of at least 12 complete 

granules in less than 170 seconds with the following assumptions: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 147 / 315 







A single execution of RADIO_AB IDP-SC shall generate, on a single-core CPU with 

hardware equivalent to the Reference Platform one, an ATF of at least 15 complete 

granules in less than 210 seconds with the following assumptions: 







3.2.5.9 RADIO_FINALIZE 

RADIO_FINALIZE IDP-SC contributes to PS-5 (Loading of Viewing Model for L1 

processing, PS-7 and PS-9 (L1A and L1B radiometric processing). 

When required, it summarizes the metadata processed by ATF by UPDATE_LOC, 

DECOMP, INIT_LOC_L1 and RADIO_AB IDP-SC and updates the metadata at datastrip 

level. 



RADIO_FINALIZE IDP-SC shall implement at datastrip level: 

ATF aggregation by detector: (for each band) 

Detector footprint at detector level generated by ATF aggregation 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 148 / 315 

Coarse cloud mask in Focal Plan geometry at detector level generated by ATF 

aggregation 

Technical Masks at detector level generated by ATF aggregation 

L1A radiometric masks at detector level generated by ATF aggregation 

L1B radiometric masks at detector level generated by ATF aggregation 

Metadata at datastrip level updating: 

Importing in metadata, Ancillary data generated by ATF 

Product footprint computation 

Radiometric processing synthesis 



RADIO_FINALIZE IDP-SC shall be activated: 

by datastrip 



RADIO_FINALIZE IDP-SC shall implement algorithm processing based on DPM: 

Masks and footprint aggregation: 

[VMASK-DPM] 

Product foot print computation 


(product footprint computation part, 


Radiometric processing synthesis: 

[RADIO_S2-DPM] IAS06-15 

(Metadata update) 



ATF aggregations tasks of RADIO_FINALIZE IDP-SC shall be switched ON or OFF 

according to configuration parameters: 

Ancillary data aggregation 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 149 / 315 

Detector Footprints aggregation, 

Coarse Cloud Masks aggregation, 

Technical Masks (Ancillary data quality masks) aggregation 

Technical Masks (Mission data quality masks) aggregation 

Radiometric masks aggregation 

(default DISABLE), 




Note: 

Ancillary data aggregation is set to ENABLE if UPDATE_LOC is parallelized by ATF 

Detector Footprint, Coarse Cloud masks and Technical Masks (ancillary data) 

aggregation is set to ENABLE if INIT_LOC_L1_LOC is parallelized by ATF, 

Technical Masks (mission data) aggregation is set to ENABLE if DECOMP is 

parallelized by ATF 

Radiometric masks aggregation is set to ENABLE if RADIO_AB is parallelized by 

ATF. 


In accordance with activated step, RADIO_FINALIZE IDP-SC inputs shall be: 

Processing Unit with all or part of 

PDI-FE-DS: 


PDI-FE-ATF : (for each detector : each ATF for each band) 

A list of Detector footprint by ATF 

A list of Cloud mask in Focal plan geometry by ATF 

A list of Technical masks (ancillary data) by ATF 

A list of Technical masks (mission data) by ATF 

A list of Radiometric masks by ATF 


GIPP 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 150 / 315 


Noise model 


A list of ancillary data by ATF 



When relevant, RADIO_FINALIZE IDP-SC shall select from input GIPP the applicable 




In accordance with activated step, RADIO_FINALIZE IDP-SC output Processing Unit shall 


PDI-FE-DS: 

L1A Metadata at datastrip level 

L1B Metadata at datastrip level 


Detector footprint 

Cloud mask in Focal plan geometry 

Technical masks 

Radiometric masks 




A single execution of RADIO_FINALIZE IDP-SC shall process, on a single-core CPU with 


downlink in less than 20 seconds. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 151 / 315 



A single execution of RADIO_FINALIZE IDP-SC shall process, on a single-core CPU with 




3.2.5.10 FORMAT_METADATA(GR-L1A) 

FORMAT_METADATA(GR-L1A) IDP-SC finalizes L1A metadata at granule level. 

It processes by detector a set of granules (defined by a list or by ATF) 



FORMAT_METADATA(GR-L1A) IDP-SC shall process for the set of granules identified as 

input: 

For each granule, L1A Masks at granule level processing, 

Coarse Cloud mask at granule level processing, 

Technical masks at granule level processing, 

L1A Radiometric Mask at granule level processing, 

If required, finalize metadata to be fully compliant with [PSD] (before TAR 

formatting). 


Note: 

Finalize metadata step is performing conversion into SAFE format as defined in [PSD] 

Finalize metadata step is performing metadata conversion into SAFE format as defined in 

[PSD]. Finalized metadata and image data are further gathered by DPC in a TAR 

container to be fully compliant with [PSD]. 

Finalize metadata step is defined: 

for evolutive purpose: impact of minor [PSD] format modifications should be 

restricted to impacting FORMAT_METADATA IDP_SCs, 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 152 / 315 

for evolutive purpose: an intermediate information (for processing needs) could be 

added for processing and finally removed by FORMAT_METADATA for delivery 


Metadata at granule level generated by FORMAT_METADATA(GR-L1A) IDP-SC is 

compliant with [PSD] Product Specification Documentation format for L1A metadata at 

granule level (before TAR formatting). 



FORMAT_METADATA(GR-L1A) IDP-SC shall be activated: 

by list of detectors 


or by a list of granules 

When activated by ATF, FORMAT_METADATA(GR-L1A) 

granules included in the ATF. 

shall process all available 



If an input granule of FORMAT_METADATA(GR-L1A) is identified in the Frame file as an 

extra-granule to be cut, FORMAT_METADATA(GR-L1A) shall : 

not process this granule without generating a failure status 

trace in log file that the granule has not been processed according to frame-file 

Parents: 


FORMAT_METADATA(GR-L1A) IDP-SC shall implement algorithm processing based on 

[DPM]: 

Masks at granule level computing 

[VMASK-DPM]-09 

(Intersection of polygon part) 

considering that mask at granule level is the intersection of input mask and granule 

polygon defined by its 4 corners. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 153 / 315 


Mask clipping at granule level by FORMAT_METADATA(GR-L1A) IDP-SC shall be 

switched on or off according to configuration parameters: 

Technical Masks 


Cloud Masks 

L1A Radiometric Masks 


(default ENABLE). 



In accordance with activated step, FORMAT_METADATA(GR-L1A) IDP-SC input 

Processing Unit shall include all or part of: 

PDI-FE-DS : 


Frame file (generated by UPDATE_LOC) 

PDI-FE-GR : 


PDI-FE-ATF : 

List of L1A radiometric masks (defective pixels, saturated pixels, No_Data pixels) 

List of Technical masks (mission data quality masks, ancillary data quality masks) 

List of Cloud mask 

GIPP : none 



FORMAT_METADATA(GR-L1A) IDP-SC shall check that input masks provided by ATF 

include all the granules to produce. 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 154 / 315 

In accordance with activated step, FORMAT_METADATA(GR-L1A) IDP-SC output 



Updated L1A Metadata at granule level 

Pixel level Quality indicators (masks at granule level) 

•L1A radiometric masks, 

•Coarse cloud masks, 

•Technical masks 



In FAKE mode, FORMAT_METADATA(GR-L1A) IDP-SC shall at least generate: 

A L1A Metadata at granule level with brief metadata set correctly which is compliant 

with [PSD] format (before TAR formatting). 




FORMAT_METADATA(GR-L1A) IDP-SC shall process, on a single-core CPU with 





FORMAT_METADATA(GR-L1A) IDP-SC shall process, on a single-core CPU with 





A single execution of FORMAT_METADATA(GR-L1A) IDP-SC shall process, on a singlecore 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 155 / 315 



A single execution of FORMAT_METADATA(GR-L1A) IDP-SC shall process, on a singlecore 






FORMAT_METADATA(GR-L1A) IDP-SC shall be considered as the L1A scenario of a 

generic FORMAT_METADATA(GR) L1 IDP-SC. 

Parents: 

3.2.5.11 FORMAT_METADATA(DS-L1A) 

FORMAT_METADATA(DS-L1A) IDP-SC finalizes L1A metadata at datastrip level. 



FORMAT_METADATA(GR-L1A) IDP-SC shall be considered as the L1A scenario of a 

generic FORMAT_METADATA_L1(GR) IDP-SC. 


Note: 

Finalize metadata step is performing conversion into SAFE format as defined in [PSD], 

(before TAR formatting, this last being performed by the DPC). 

This finalization step could include: 

Minor adaptations between internal datastrip metadata and delivered datastrip 

metadata (temporary information used for processing optimization removed from 

product, e.g. detector footprint) 

Other formatting tasks (to contain minor evolutions of PSD [PSD] to 

FORMAT_METADATA IDP_SCs), 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 156 / 315 

Metadata at datastrip level generated by FORMAT_METADATA(DS-L1A) IDP-SC is 

compliant with [PSD] format for L1A metadata at datastrip level (before TAR formatting). 



FORMAT_METADATA(DS-L1A) IDP-SC shall update in the metadata at datastrip level, 

the granule list in accordance with L1A formatting framing strategy. 

Parents: 

Note: 

Staggered extra-granules at datablock borders (used for L1B geometric improvement 

process) are removed from the granule list of the datastrip. 


FORMAT_METADATA(DS-L1A) IDP-SC gathers finalized metadata at datastrip level and 

L1A auxiliary data in a container to be fully compliant with [PSD] for L1A datastrip (before 

TAR formatting). 



FORMAT_METADATA(DS-L1A) IDP-SC input Processing Unit shall include: 

PDI-FE-DS : 




GIPP : all GIPP used in L1A processing 

IERS bulletin 

DEM: reference to coarse DEM (Globe) used in L1A processing 



FORMAT_METADATA(DS-L1A) IDP-SC shall be activated: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 157 / 315 

 

by datastrip 



FORMAT_METADATA(DS-L1A) IDP-SC output Processing Unit shall include: 

PDI-FE-DS : 

Updated L1A Metadata at datastrip level 

PDI-DS : 

Formatted L1A datastrip 


Reference S2PDGS-IPF-TRD-REQ-255a : 

In FAKE mode, FORMAT_METADATA(DS-L1A) IDP-SC shall at least generate: 

A L1A Metadata at datastrip level with brief metadata set correctly which is 

compliant with [PSD] (before TAR formatting). 




A single execution of FORMAT_METADATA(DS-L1A) IDP-SC shall process, on a singlecore 


to 20 minutes of downlink in less than 20s seconds. 




FORMAT_METADATA(DS-L1A) IDP-SC shall be considered as the L1A scenario of a 

generic FORMAT_METADATA_L1(DS) IDP-SC. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 158 / 315 

3.2.5.12 FORMAT_IMG(L1A JP2000) 

FORMAT_IMG(L1A JP2000) 

JPEG2000 format. 

IDP-SC is in charge of L1A granules compression in 


by set of granules (defined, for each detector, by a list or by ATF), 




FORMAT_IMG(L1A JP2000) IDP-SC shall implement L1A images JPEG2000 

compression (for each granule, one compressed image by band). 



FORMAT_IMG(L1A JP2000) IDP-SC shall be activated: 

by set of granules (defined, for each detector, by a list or by ATF) 




FORMAT_IMG(L1A JP2000) IDP-SC shall implement algorithm processing based on (cf. 

Table 2): 

JPEG2000 compression: 





If an input granule of FORMAT_IMG(L1A JP2000) is identified in the Frame file as an 

extra-granule to be cut, FORMAT_IMG(L1A JP2000) shall : 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 159 / 315 

Parents: 


FORMAT_IMG(L1A JP2000) IDP-SC inputs shall be: 


PDI-FE-DS : 



Either PDI-FE-ATF(for each band of processed ATF) 

L1A images (all available bands) 

or PDI-FE-GR(for each band of each granule ofprocessed ATF) 

L1A images (all available bands) 



FORMAT_IMG(L1A JP2000) specific processing parameters (e.g. compression 

parameters) 



FORMAT_IMG(L1A JP2000) IDP-SC output Processing Unit shall include: 

PDI-FE-GR (for each granule) 

L1A JPEG2000 compressed image (one file by available band) 




FORMAT_IMG(L1A JP2000) IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, all the bands of a datastrip equivalent to 10 

minutes of downlink in less than 7.3 hours with the following assumptions: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 160 / 315 

Reversible compression for all bands. 



FORMAT_IMG(L1A JP2000) IDP-SC shall process, on a single-core CPU with hardware 






A single execution of FORMAT_IMG(L1A JP2000) IDP-SC shall process, on a single-core 

CPU with hardware equivalent to the Reference Platform one, all bands of a 12 granules 

list in less than 2 minutes and 25 seconds with the following assumptions: 




A single execution of FORMAT_IMG(L1A JP2000) IDP-SC shall process, on a single-core 


list in less than 3 minutes with the following assumptions: 



3.2.6 Requirements for L1B geometric processing and formatting IDP-SC 

Theses paragraphs present the requirement specific to the set of IDP-SC in charge of L1B 

product generation (geometric quality improvement optional part and formatting part). 

3.2.6.1 GET_GRI 

GET_GRI IDP-SC is in charge of fine selection of GRI products to be used by Image-GRI 

registration processing. 

GET_GRI: 

Identify from the list of GRI relevant to the processed orbit (relative orbit number), 

those which intercept the datastrip 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 161 / 315 

For each GRI which intercept the datastrip, precise the list of granules which 

intercept the datastrip. 


none 



GET_GRI IDP-SC shall implement: 

The list identification of GRI relevant to Image relative orbit number which intercept 

the datablocks of the Image datastrip, 

For each identified GRI, updating the GRI metadata at datastrip level with the list of 

granules which intercept the Image datastrip. 



For GRI list identification, GET_GRI IDP-SC shall: 

Compute footprint of band used in Image-GRI registration as the union of detector 

footprints (using detector footprints associated to this band), 

Check the intersection of GRI product footprint and band footprint for all GRI 

relevant to Image relative orbit number. 



GET_GRI IDP-SC shall be activated: 

by datastrip 



GET_GRI IDP-SC inputs shall be: 


PDI-FE-DS: (for each GRI associated to the datastrip relative orbit number) 

GRI Metadata at datastrip level 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 162 / 315 

PDI-FE-GR : (for each GRI associated to the datastrip relative orbit number) 


PDI-FE-DS (for Image) 


PDI-FE-ATF (for Image) 

Detector footprint for band used by IMAGE-GRI registration 

Auxiliary data: none 



GET_GRI IDP-SC output 

list of GRI that intercept the datastrip 

Processing Unit: 

PDI-FE-DS : (for each GRI that intercept the datastrip) 

• Updated GRI metadata at datastrip level 




A single execution of GET_GRI IDP-SC shall process, on a single-core CPU with 





A single execution of GET_GRI IDP-SC shall process, on a single-core CPU with 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 163 / 315 

3.2.6.2 UNFORMAT_GRI 

UNFORMAT_GRI IDP-SC is in charge of unformatting GRI data. 

At least UNFORMAT_GRI: 

Decompress GRI images data (JPEG2000 decompression only for the GRI band 

used for registration) 

Aggregates masks provided at granule level (only for the GRI band used for 

registration) 

UNFORMAT_GRI implements two scenarios: 

GRI decompression only 

Mask aggregation only 


Decompression scenario: 

by ATF or list of granules 

Mask aggregation scenario: 

by detector 



UNFORMAT_GRI IDP-SC shall implement, for a band: 

GRI J2000 compressed granules decompression, 

aggregation by detector of the GRI masks provided by granule 



Steps of UNFORMAT_GRI IDP-SC that shall be switched ON or OFF according to 


decompression 

mask aggregation 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 164 / 315 



UNFORMAT_GRI IDP-SC shall be activated by configuration parameters in one of the 


decompression only 

mask aggregation only 



UNFORMAT_GRI “decompression only” scenario activates only decompression step. 



UNFORMAT_GRI “mask aggregation only” scenario activates only mask aggregation step. 



UNFORMAT_GRI “decompression only” scenario shall be activated: 

by GRI 

by GRI detector ATF 



UNFORMAT_GRI “mask aggregation only” scenario shall be activated: 

by GRI 

by list of GRI detectors 



When activated in “decompression only” scenario, UNFORMAT_GRI IDP-SC inputs shall 

be: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 165 / 315 

PDI-FE-DS: 


PDI-FE-GR : 

J2000 compressed GRI images (one by granule of the processed ATF) 




When activated in “mask aggregate only” scenario, UNFORMAT_GRI IDP-SC inputs shall 

be: 


PDI-FE-DS: 


PDI-FE-GR : 

masks (by granule of the processed detector) 




When activated in “decompression only” scenario UNFORMAT_GRI IDP-SC output 


PDI-FE-GR : (for one band) 

decompressed GRI images (one by granule of the processed ATF) 



When activated in “mask aggregate only” scenario UNFORMAT_GRI IDP-SC output 


PDI-FE-ATF : 

Masks Aggregated by detectors 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 166 / 315 




When activated in “decompression only” scenario UNFORMAT_GRI IDP-SC shall 

process, on a single-core CPU with hardware equivalent to the Reference Platform one, 

one band of all the GRI granules that intercepts a datastrip equivalent to 10 minutes of 


one 10m band granules decompression. 



When activated in “decompression only” scenario UNFORMAT_GRI IDP-SC shall 


one band of all the GRI granules that intercepts a datastrip equivalent to 20 minutes of 





A single execution of UNFORMAT_GRI IDP-SC activated in “decompression only” 

scenario shall process, on a single-core CPU with hardware equivalent to the Reference 

Platform one, 30 granules in less than one minute with the following assumptions: 


Parents: S2-PDGS-IDP-080, S2-PDGS-IDP-085, S2-PDGS-SYS-380, S2-PDGS-SYS-385, S2-PDGS-SYS-390, S2-PDGS-SYS-400 


When activated in “mask aggregation only” scenario UNFORMAT_GRI IDP-SC shall 

process, on a single-core CPU with hardware equivalent to the Reference Platform one, all 

the GRI detectors that intercept a 10 minutes of downlink in less than 20 seconds. 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 167 / 315 

When activated in “mask aggregation only” scenario UNFORMAT_GRI IDP-SC shall 

process, on a single-core CPU with hardware equivalent to the Reference Platform one, all 

the GRI detectors that intercept a 20 minutes of downlink in less than 40 seconds. 


3.2.6.3 INIT_VS_GEO 

INIT_VS_GEO IDP-SC is in charge of initializations at datastrip level for registration 

processing. 

According to L1B geometric processing configuration INIT_VS_GEO could be executed 

twice: 

One time for Image-GRI registration processing initialization 

One time for VNIR-SWIR registration processing initialization 

INIT_VS_GEO IDP-SC is at least in charge of: 

Virtual Sensor geometry definition from best available Viewing Model 

Virtual Sensor Along Track Fragment definition for further processing 

(RESAMPLE_TO_VS and TP_COLLECT IDP_SC). Those ATF definition shall 

exclude gaps in the datastrip 

No Parallelization strategy is foreseen. 



INIT_VS_GEO IDP-SC shall implement: 

Virtual Sensor geometry definition from best available Viewing Model, 

Virtual Sensor Along Track Fragment segmentation definition for further processing 



INIT_VS_GEO IDP-SC shall be activated: 

by datastrip 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 168 / 315 


INIT_VS_GEO IDP-SC shall implement algorithm processing based on DPM: 

virtual sensor geometry definition 

[GEO_S2-DPM] §5.4.3.1 

(common geometry) 



INIT_VS_GEO IDP-SC shall define a Virtual Sensor ATF segmentation (for further 

processing) from expected ATF number provided as parameter. 

This segmentation shall define ATF: 

without redundancy and with continuity. 

With similar along track length 



For Image-GRI Registration, INIT_VS_GEO IDP-SC shall define a Virtual Sensor ATF 

segmentation associated to each GRI. 



INIT_VS_GEO IDP-SC inputs shall be: 

Total expected Launch number (expected ATF number) 


PDI-FE-DE 


GRI metadata at datastrip level (for Image-GRI registration only) 





INIT_VS_GEO specific processing parameters 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 169 / 315 

DEM (SRTM class) 





INIT_VS_GEO IDP-SC outputs shall be: 

Virtual Along Track segmentations definition 

PDI-FE-DS : 

Virtual Sensor Viewing model 




A single execution of INIT_VS_GEO IDP-SC shall process, on a single-core CPU with 





A single execution of INIT_VS_GEO IDP-SC shall process, on a single-core CPU with 




3.2.6.4 RESAMPLE_TO_VS 

RESAMPLE_TO_VS IDP-SC is in charge of data resampling in previously defined virtual 

sensor geometry for both Image-GRI registration and VNIR-SWIR registration processing. 

RESAMPLE_TO_VS IDP-SC is in charge of 

Masks projection in Virtual Sensor Geometry 

Exclusion area mask building from union of projected masks 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 170 / 315 

Resampling grids computation 

Resampling images data in Virtual Sensor Geometry using computed Resampling 

grids. 


By Virtual Sensor ATF 

By detector 

By band : 

VNIR-SWIR registration scenario : two bands (one band of each focal plan) 

Image-GRI registration: one band for Image and one "band" for each GRI 

interception the processed ATF 



RESAMPLE_TO_VS IDP-SC shall, for one band and detector of a Virtual Sensor Along 

Track Fragment: 

Project in Virtual Sensor geometry L1B masks associated to the processed band, 

Merge the projected masks in a Masked area (not to be used area by further 

homologous points collecting) 

Resampling grid computation 

Resampling image in ATF virtual sensor geometry 



RESAMPLE_TO_VS IDP-SC shall be activated: 

By databloc and/or by GRI 

by virtual sensor ATF 

by detector (of one band) 

by band (one for Image and one for GRI or one for VNIR focal plan and one for 

SWIR focal plan according to Registration scenario) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 171 / 315 



RESAMPLE_TO_VS IDP-SC shall implement algorithm processing based on DPM: 

mask projection 

[GEO_S2-DPM] §5.4.3.2 (and [GEOREF-DPM]) 

resampling grid computation 

[GEO_S2-DPM] §5.4.3.2 (and [GEOREF-DPM]) 

image resampling 

[GEO_S2-DPM] §5.4.3.2 (and [RESAMP-DPM]) 

(resampling) 

(resampling) 

(resampling) 



Tasks of RESAMPLE_TO_VS IDP-SC that shall be switched ON or OFF according to 


Masked area processing 


When Masked area processing is DISABLE, L1B masks are not projected in Virtual 

Sensor Geometry. 



RESAMPLE_TO_VS IDP-SC inputs shall be: 


PDI-FE-DS 


GRI metadata at datastrip level (for Image-GRI registration only) 

PDI-FE-ATF : 

Radiocorrected Images 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 172 / 315 


RESAMPLE_TO_VS specific processing parameters 

DEM (SRTM class) 

Ancilliary data: 




RESAMPLE_TO_VS shall identify from Virtual Sensor Along Track Fragment 

segmentation definition and Launch number provided as parameters, the Virtual Sensor 

ATF to produce. 

Virtual Sensor ATF generated by all the RESAMPLE_TO_VS launches shall be 

continuous and without redundancy. 



When relevant, RESAMPLE_TO_VS IDP-SC shall select from input GIPP the applicable 




RESAMPLE_TO_VS IDP-SC outputs shall be: 


PDI-FE-ATF : 

Images resampled in Virtual Sensor geometry (either Image and GRI or VNIR and 

SWIR images) 

Masked area (not to be used area mask) 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 173 / 315 

RESAMPLE_TO_VS IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, a Virtual Sensor ATF of 24 granules in less than 

140 seconds with the following assumptions: 

resampling grid step: 45m 

resampling filter: Order 5 Spline 

Image-GRI registration with 10m bands 

VNIR-SWIR registration between one 10m and one 20m band 



RESAMPLE_TO_VS IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, a Virtual Sensor ATF of 30 granules in less than 

175 seconds with the following assumptions: 






3.2.6.5 TP_COLLECT 

TP_COLLECT IDP-SC is in charge of collecting Tie-Points (homologous point between 

SWIR and VNIR focal planes) or Ground Control Point GCP (homologous point between 

Image and GRI). 



by Virtual Sensor ATF 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 174 / 315 

TP_COLLECT IDP-SC shall implement for a detector of one band 

Identifying overlapping detectors of the second band, 

For each identified couple of detectors, 

Homologous points collecting by correlation 

erroneous collected Homologous points due to false correlations filtering, 

Local Density of filtered Homologous points comparison to an objective threshold 

Densification of filtered Homologous points 



Collected Homologous points shall not contain points in area identified by input mask as 

not to be used for collecting. 



TP_ COLLECT IDP-SC shall be activated: 

By datablock and/or by GRI 


by virtual sensor ATF 



TP_COLLECT IDP-SC shall implement algorithm processing based on DPM: 

couple of detectors identifying 

[GEO_S2-DPM] §5.4.3.3 

(matching) 

Tie-Points/GCP collecting 

[GEO_S2-DPM] §5.4.3.4 (partial- correlation part ) 

Tie-Points/GCP filtering 

[GEO_S2-DPM] §5.4.3.4 (partial- homologous points filtering part ) 

Local Density of filtered Tie-Points/GCP comparison to an objective threshold 

[GEO_S2-DPM] §5.4.3.4 (partial-Local density check part) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 175 / 315 

Tie-Points/GCP collection densification 

[GEO_S2-DPM] §5.4.3.4 (partial-densification part) 



TP_COLLECT IDP-SC shall be activated by configuration parameters in one of the 


Automatic densification 

Densification of input collection 

(default) 



TP_COLLECT “Densification of input collection” scenario activates: 

“Homologous points collecting by correlation” step if input collection is empty 

“Densification of filtered Homologous points” step if input collection is not empty 

Filtering step and local density check steps are DISABLE. 



TP_COLLECT “Automatic densification” scenario activates: 

“Homologous points collecting by correlation” step 

“Filtering erroneous correlation” step 

“Local density checks” step 

“Densification of filtered Homologous points” step 



TP_COLLECT “Automatic densification” scenario implements an iterative processing 

(loop), collecting and filtering homologous points, until local density check is satisfying. 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 176 / 315 

When activated in “Densification of input collection” scenario, TP_COLLECT IDP-SC 

inputs shall be: 


PDI-FE-ATF : 


SWIR images) 

List of filtered homologous point (could be empty) 




TP_COLLECT specific processing parameters (e.g.: correlation parameters) 



When activated in “Automatic” scenario, TP_COLLECT IDP-SC inputs shall be: 


PDI-FE-ATF : 


SWIR images) 




TP_COLLECT specific processing parameters (e.g.: correlation parameters) 



TP_COLLECT IDP-SC output Processing Unit shall be: 

PDI-FE-ATF : 

List of homologous tie-points 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 177 / 315 




A single execution of TP_COLLECT IDP-SC in “densification of input collection” scenario 

shall process (first iteration), on a single-core CPU with hardware equivalent to the 

Reference Platform one, an ATF of at least 24 complete granules in less than 20 seconds 

for both Image-GRI Registration and VNIR-SWIR Registration with the following 

assumptions: 

Initial grid node step : 250 pixels 

vignette size for correlation: 13x13 

search window for correlation: 5x5 






shall process (second iteration), on a single-core CPU with hardware equivalent to the 



assumptions: 




Densification up to the objective local density in two passes 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 178 / 315 


A single execution of TP_COLLECT IDP-SC in “automatic densification” scenario shall 


an ATF of at least 24 complete granules in less than 45 seconds for both Image-GRI 

Registration and VNIR-SWIR Registration with the following assumptions: 




Objective local: at least 100 filtered homologous points by granule 







shall process (first iteration), on a single-core CPU with hardware equivalent to the 



assumptions: 









shall process (second iteration), on a single-core CPU with hardware equivalent to the 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 179 / 315 


assumptions: 









A single execution of TP_COLLECT IDP-SC in “automatic densification” scenario shall 


an ATF of at least 30 complete granules in less than 60 seconds for both Image-GRI 

Registration and VNIR-SWIR registration with the following assumptions: 




Objective local: at least 100 filtered homologous points by granule 





3.2.6.6 TP_FILTER 

TP_FILTER IDP-SC is in charge of filtering previously collected Tie-Points (homologous 

point between SWIR and VNIR focal planes) or Ground Control Point GCP (issued from 

homologous point between Image and GRI). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 180 / 315 

Objective of TP_FILTER is to discard erroneous Tie-Points or GCP due to false 

correlations. 

Local Density of filtered Tie-Points/GCP is then compared to an objective threshold. If 

objective threshold is not reach, a densification loop is activated (locally denser collecting 

with TP_COLLECT, then TP_FILTER. 

TP_COLLECT/TP_FILTER loop can be activated twice in L1B workflow: 

one time for Image-GRI registration processing, 

one time for VNIR-SWIR registration processing 





TP_FILTER IDP-SC shall implement for for a detector of one band: 

Identifying overlapping detectors of the second band, 

For each identified couple of detectors, 

erroneous collected Tie-Points/GCP due to false correlations filtering at detector 

level, 




TP_ FILTER IDP-SC shall be activated: 

by GRI (for Image-GRI registration only) 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 181 / 315 


TP_FILTER IDP-SC shall implement algorithm processing based on DPM: 

couple of detectors identifying 

[GEO_S2-DPM] §5.4.3.3 

(matching) 

Tie-Points/GCP filtering 

[GEO_S2-DPM] §5.4.3.4 (partial- homologous points filtering part ) 


[GEO_S2-DPM] §5.4.3.4 (partial-Local density check part) 



TP_FILTER IDP-SC input Processing Unit shall include all or part of: 

PDI-FE-DS : 


PDI-FE-ATF : 

Lists of collected Tie-Points/GCP (one list by input ATF, input ATF combination 

represent all the detector) 


TP_FILTER specific processing parameters (e.g.: density threshold) 



Loop iteration number shall be a parameter of TP_FILTER IDP-SC 

Parents: 


Maximal iteration number shall be provided as GIPP. 

Parents: 


TP_FILTER IDP-SC output Processing Unit shall include all or part of: 

PDI-FE-ATF : 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 182 / 315 

Lists of filtered Tie-Points/GCP (one list by input ATF) 



TP_FILTER IDP-SC Exit Code value shall allow discriminating the three following cases: 

Case 1: local density is sufficient 

Case 2: local density is not sufficient 

Case 3: local density is not sufficient but maximal loop is reached 


Note: TP_COLLECT/TP_FILTER loop is activated only if TP_FILTER exit_code is Case 2 



A single execution of TP_FILTER IDP-SC shall process, on core CPU with hardware 


in less than 20s seconds. 


3.2.6.7 SPATIO 

SPATIO IDP-SC is in charge of refining the viewing model with Spatiotriangulation 

techniques. 

It processes according to a scenario from previously collected Tie-Points (homologous 

point between SWIR and VNIR focal planes) and/or Ground Control Point GCP (issued 

from homologous point between Image and GRI) 

No parallelization strategy is foreseen. SPATIO IDP-SC processes the whole datastrip in a 

single execution. 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 183 / 315 

SPATIO IDP-SC shall implement for a datastrip: 

Ground Control Points (GCP) (homologous points between Image and GRI) 

importing, 

Tie-Points (TP) (homologous points between SWIR and VNIR focal planes) 

importing, 

Viewing model refinement with Spatiotriangulation techniques from GCP and/or TP, 

Geometric refining quality indicators computing 

Metadata at datastrip level updating with refined viewing model. 



SPATIO IDP-SC shall be activated: 

by datastrip 



SPATIO IDP-SC shall implement algorithm processing based on [DPM]: 

Viewing model refinement: 

[GEO_S2-DPM] §5.4.3.5 

[GEOREF-DPM]N-05 

(Spatiotriangulation) 

(refining) 


[GEOREF-DPM]N-05 

(–final part: refiningresidues 

computation part) 

[GEO_S2-DPM] §5.3.3.1.5 

(postprocessor quality 

assessment node part) 

Metadata at datastrip level updating with refined viewing model 

[GEO_S2-DPM] §5.3.3.1.2 

(postprocessor 

geometric data node part) 

[GEO_S2-DPM] §5.3.3.1.3 

(partial – postprocessor 

viewing models initialization 

part) 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 184 / 315 

SPATIO IDP-SC shall be activated by configuration parameters in one of the following 

scenario: 

Image-GRI only 

VNIR-SWIR only 

Both (first pass: Image-GRI) 

Both (first pass: VNIR-SWIR) 

Both (last pass) 

(default) 



Steps of SPATIO IDP-SC that shall be switched ON or OFF by configuration parameters 

according to SPATIO scenario are. 

Ground Control Points (GCP) ingestion 


Tie-Points (TP) ingestion 





Note: 

Viewing model refinement with Spatiotriangulation techniques and metadata at datastrip 

level updating with refined viewing model are always enable. 


Metadata at datastrip level is updated with Geometric refining quality indicators when they 

are processed. 



For SPATIO “Image-GRI only” scenario, steps set to ENABLE are: 

Ground Control Points (GCP) importing, 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 185 / 315 


For SPATIO “VNIR-SWIR only” scenario, steps set to ENABLE are: 

Tie-Points (TP) importing, 




For SPATIO “Both (first pass: Image-GRI)” scenario, steps set to ENABLE are: 

Ground Control Points (GCP) importing, 



For SPATIO “Both (first pass: VNIR-SWIR)” scenario, steps set to ENABLE are: 

Tie-Points (TP) importing, 



For SPATIO “Both (last pass)” scenario, steps set to ENABLE are: 

Ground Control Points (GCP) importing (homologous points between Image and 

GRI), 

Tie-Points (TP) importing (homologous points between SWIR and VNIR focal 

planes), 




In accordance with scenario, SPATIO IDP-SC input Processing Unit shall include all or 

part of: 

PDI-FE-DS : 


PDI-FE-ATF : 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 186 / 315 

Filtered set of Tie-Points 

Filtered set of Ground Control Points 



SPATIO parameters 

precise DEM (SRTM class) 





When relevant, SPATIO IDP-SC shall select from input GIPP the applicable parameters in 

accordance with band, detector and sensing TDI configuration. 



SPATIO IDP-SC shall use the best available geometric model as input: 

if metadata at datastrip level describe a refined viewing model (by a previous call to 

SPATIO IDP-SC) that refined viewing model shall be used as input, either the initial 

viewing model is used. 



In accordance with activated step, SPATIO IDP-SC output Processing Unit shall include all 

or part of: 

PDI-FE-DS : 




In FAKE mode, SPATIO IDP-SC shall generate a metadata at datastrip level without 

refined viewing model (as if neither Image-GRI registration nor SWIR-VNIR registration 

have been processed). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 187 / 315 



A single execution of SPATIO IDP-SC in all scenario except "Both(last pass)" shall 

process, on a single-core CPU with hardware equivalent to the Reference Platform one, a 

datastrip equivalent to 10 minutes of downlink in less than 60 seconds with the following 

assumptions: 

Tie_Points or GCP density: 50 points by granule 



A single execution of SPATIO IDP-SC in "Both(last pass)" scenario shall process, on a 

single-core CPU with hardware equivalent to the Reference Platform one, a datastrip 

equivalent to 10 minutes of downlink in less than 120 seconds. 

Tie_Points density: 50 points by granule 

GCP density: 50 points by granule 



A single execution of SPATIO IDP-SC in all scenario except "Both(last pass)" shall 



assumptions: 

Tie_Points or GCP density: 50 points by granule 



A single execution of SPATIO IDP-SC in "Both(last pass)" scenario shall process, on a 

single-core CPU with hardware equivalent to the Reference Platform one, a datastrip 

equivalent to 20 minutes of downlink in less than 240 seconds. 

Tie_Points density: 50 points by granule 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 188 / 315 



SPATIO IDP-SC shall not implement optimizations techniques for GPU hardware 

described in Annex of [GEO_S2-DPM] 

Parents: 

3.2.6.8 GEO1B_FINALIZE 

GEO1B_FINALIZE IDP-SC is in charge of densificated detectors footprints computation. 


by band and detector 



GEO1B_FINALIZE IDP-SC shall process for a list of band of a list of detectors identified as 

input: 

densificated detector footprint computation 

The densified detector footprint shall be in accordance with L1C framing strategy. 



GEO1B_FINALIZE IDP-SC shall be activated: 

by list of band of a list of detectors 



GEO1B_ FINALIZE IDP-SC shall implement algorithm processing based on [DPM]: 

Densificated footprint computation: 

[GEO_S2-DPM] §5.3.3.1.3 


unitary footprint computation) 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 189 / 315 


Detector footprint generated by GEO1B_ FINALIZE IDP-SC shall be a set of polygons 

such that each polygon does not include missing data. 

Parents: 


GEO1B_ FINALIZE IDP-SC input Processing Unit shall include: 

PDI-FE-DS : 




GIPP at least: 

•Spacecraft model 

•Viewing directions 

•GEO1B_ FINALIZE specific processing parameters (e.g.: step for 

detector footprint computation processing) 






GEO1B_ FINALIZE IDP-SC shall use the best available geometric model as input: 

if metadata at datastrip level contains a refined viewing model, this refined viewing model 

shall be used as input otherwise the initial viewing model shall be used. 



GEO1B_ FINALIZE IDP-SC output Processing Unit shall include all or part of: 


Densificated Detector footprint 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 190 / 315 



In FAKE mode, GEO1B_ FINALIZE shall generate densificated detector footprints by copy 

of L1A detector footprints. 




A single execution of GEO1B_ FINALIZE IDP-SC shall process, on a single-core CPU with 



assumptions: 

Step for dense detector footprint computation: 45m 








assumptions: 





hardware equivalent to the Reference Platform one, one band of one detector of a 


assumptions: 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 191 / 315 


hardware equivalent to the Reference Platform one, one band of one detector of a 


assumptions: 



3.2.6.9 FORMAT_METADATA(GR-L1B) 

FORMAT_METADATA(GR- L1B) IDP-SC finalizes L1B metadata at granule level. 

FORMAT_METADATA(GR- L1B) IDP-SC is at least in charge of: 

Granule geometric information updating, 

L1B Radiometric Mask at granule level processing. 


By set of granules (defined, for each detector, by a list or by ATF). 



FORMAT_METADATA(GR-L1B) IDP-SC shall update L1A metadata at granule level for 

the set of granules identified as input: 

For each granule, Geometric information updating (four corners and center) 

For each granule, L1B Masks at granule level clipping, 

For each granule, promoting to L1B L1A Masks at granule level: 

Coarse Cloud mask at granule level, 

Technical masks at granule level, 

If required, finalize metadata to be fully compliant with PSD [PSD] (before TAR 

formatting) 


Note: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 192 / 315 



container to be fully compliant with [PSD] 


FORMAT_METADATA(GR-L1B) IDP-SC shall be activated: 




When activated by ATF, FORMAT_METADATA(GR-L1B) shall process all available 

granules included in the ATF. 



If an input granule of FORMAT_METADATA(GR-L1B) is identified in the Frame file as an 

extra-granule to be cut, FORMAT_METADATA(GR-L1B) shall : 



Parents: 


FORMAT_METADATA(GR-L1B) IDP-SC shall implement algorithm processing based on 

[DPM]: 

Masks at granule level computing 

[VMASK-DPM]-09 

(Intersection of polygon part) 

Granule geometric information updating: 

[GEO_S2-DPM] §5.3.3.1.3 


granule information node part) 



Metadata at granule level generated by FORMAT_METADATA (GR-L1B) IDP-SC are 

compliant with [PSD] format for L1B metadata at granule level (before TAR formatting). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 193 / 315 


Available masks at L1B granule level after FORMAT_METADATA(GR-L1B) IDP-SC 

processing shall be switched on or off according to configuration parameters: 

Technical Masks 


Cloud Masks 

L1B Radiometric Masks 





In accordance with activated step, FORMAT_METADATA(GR-L1B) IDP-SC input 


PDI-FE-DS : 



PDI-FE-GR : 

L1B Metadata at granule level 

L1A checked metadata at granule level for each granule 

Technical masks for each granule 

Cloud masks for each granule 


GIPP, at least : 

•Spacecraft model 

•Viewing directions 

•FORMAT_METADATA(GR-L1B) specific processing parameters 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 194 / 315 




FORMAT_METADATA (GR-L1B) IDP-SC shall check that input masks provided by ATF 

include all the granules to produce. 



FORMAT_METADATA (GR-L1B) IDP-SC shall use the best available geometric model as 

input: 

if metadata at datastrip level contains a refined viewing model, this refined viewing model 

shall be used as input otherwise the initial viewing model shall be used. 



In accordance with activated step, FORMAT_METADATA(GR-L1B) IDP-SC output 



Updated L1B Metadata at granule level 

Pixel level Quality indicators (masks at granule level) 

•L1B radiometric masks, 

•Coarse cloud masks, 

•Technical masks 



In FAKE mode, FORMAT_METADATA(GR-L1B) IDP-SC shall at least generate: 

A L1B Metadata at granule level with brief metadata set correctly which is compliant 

with [PSD] format (before TAR formatting). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 195 / 315 



FORMAT_METADATA(GR-L1B) IDP-SC shall process, on a single-core CPU with 





FORMAT_METADATA(GR-L1B) IDP-SC shall process, on a single-core CPU with 





A single execution of FORMAT_METADATA(GR-L1B) IDP-SC shall process, on a singlecore 





A single execution of FORMAT_METADATA(GR-L1B) IDP-SC shall process, on a singlecore 




3.2.6.10 FORMAT_METADATA(DS-L1B) 

FORMAT_METADATA(DS-L1B) IDP-SC finalizes L1B metadata at datastrip level. 




FORMAT_METADATA(DS-L1B) IDP-SC shall finalize L1B metadata at datastrip level to 

be fully compliant with [PSD] (before TAR formatting). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 196 / 315 

Finalized L1B metadata at datastrip level is an update of Finalized L1A metadata at 

datastrip level 



FORMAT_METADATA(DS-L1B) IDP-SC shall be activated: 

by datastrip 



FORMAT_METADATA(DS-L1B) IDP-SC gathers finalized metadata at datastrip level , 

L1A and L1B auxiliary data in a container to be fully compliant with [PSD] for L1B 

datastrip (before TAR formatting). 



FORMAT_METADATA(DS-L1B) IDP-SC shall update in the metadata at datastrip level, 

the granule list in accordance with L1A/B formatting framing strategy. 

Parents: 

Note : 

Staggered extra-granules at datablock borders (used for L1B geometric improvement 

process) are removed from the granule list of the datastrip. 


FORMAT_METADATA(DS-L1B) IDP-SC shall compute the datastrip footprint in 

accordance with L1B formatting framing strategy. 



The datastrip footprint generated by FORMAT_METADATA(DS-L1B) shall be a set of 

polygons such that each polygon does not include missing data. 

Parents: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 197 / 315 

FORMAT_METADATA(DS-L1B) IDP-SC shall implement algorithm processing based on 

[DPM]: 

Datastrip geometric information updating: 

[GEO_S2-DPM] §5.3.3.1.3 


product footprint part) 



FORMAT_METADATA(DS-L1B) IDP-SC input Processing Unit shall include: 

PDI-FE-DS : 


L1A checked Metadata at datastrip level 

Frame file 

PDI-FE-ATF : (for each band of each detector) 

Densificated Detector footprint 


GIPP : all GIPP used in L1A and L1B processing 

IERS bulletin 


DEM: reference to precise DEM (SRTM class) used in L1B processing 

list of GRI that intercept the datastrip (to be referenced) 



FORMAT_METADATA(DS-L1B) IDP-SC output Processing Unit shall include: 

PDI-FE-DS : 

Updated L1B Metadata at datastrip level 

Datastrip footprint 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 198 / 315 

PDI-DS : 

Formatted L1B datastrip 



In FAKE mode, FORMAT_METADATA(DS-L1B) IDP-SC shall at least generate: 

An L1B Metadata at datastrip level with brief metadata set correctly to be compliant 

with [PSD] (before TAR formatting). 




A single execution of FORMAT_METADATA(DS-L1B) IDP-SC shall process, on a singlecore 




3.2.6.11 FORMAT_IMG(L1B_JP2000) 

FORMAT_IMG(L1B JP2000) 

JPEG2000 format. 

IDP-SC is in charge of L1B granules compression in 


by set of granules (defined, for each detector, by a list or by ATF), 




FORMAT_IMG(L1B JP2000) IDP-SC shall implement L1B images JPEG2000 

compression (for each granule, one compressed image by band). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 199 / 315 


FORMAT_IMG(L1B JP2000) IDP-SC shall be activated: 

by set of granules (defined, for each detector, by a list or by ATF) 




FORMAT_IMG(L1B JP2000) IDP-SC shall implement algorithm processing based on (cf. 

Table 2): 






If an input granule of FORMAT_IMG(L1B JP2000) is identified in the Frame file as a extragranule 

to be cut, FORMAT_IMG(L1B JP2000) shall : 


trace in log file that the granule as not been processed according to frame-file 

Parents: 

Note : Frame file is generated by UPDATE_LOC IDP-SC 


FORMAT_IMG(L1B JP2000) IDP-SC inputs shall be: 


PDI-FE-DS : 



PDI-FE-ATF(for each band of processed ATF) 

L1B images (all available bands) 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 200 / 315 


FORMAT_IMG(L1B JP2000) specific processing parameters (e.g. compression 

parameters) 



FORMAT_IMG(L1B JP2000) IDP-SC output Processing Unit shall include: 

PDI-FE-GR (for each granule) 

L1B JPEG2000 compressed image (one file by available band) 




FORMAT_IMG(L1B JP2000) IDP-SC shall process, on a single-core CPU with hardware 






FORMAT_IMG(L1B JP2000) IDP-SC shall process, on a single-core CPU with hardware 






A single execution of FORMAT_IMG(L1B JP2000) IDP-SC shall process, on a single-core 


list in less than 2 minutes and 25 seconds with the following assumptions: 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 201 / 315 


A single execution of FORMAT_IMG(L1B JP2000) IDP-SC shall process, on a single-core 


list in less than 3 minutes with the following assumptions: 



3.2.7 Requirements for L1C IDP-SC 

Theses paragraphs present the requirement specific to the set of IDP-SC in charge of L1C 

production. 

3.2.7.1 GET _TILE_LIST 

GET _TILE_LIST IDP-SC is in charge of: 

Computing the list of tiles intersecting the datastrip footprint with a pre-defined Earth 

tiling 

Updating the metadata at datastrip level 

There is no parallelization strategy for this IDP-SC. 



GET_TILE_LIST IDP-SC shall implement the computation of UTM-based tiles intersecting 

the datastrip, given UTM-based tile coverage of the Earth and update the metadata file 

with the list of intersecting tiles. 



GET_TILE_LIST IDP-SC shall implement the algorithms based on (cf. Table 2): 

[RESAMPLE_S2-DPM] Module #08-1-01 


(Partial : tiles list node creation with for each tile, identifier) 

(Tile Selection) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 202 / 315 

(metadata at datastrip update) 



GET_TILE_LIST IDP-SC inputs shall be: 


PDI-FE-DS : 


Datastrip footprint 


GIPP 

List of tile covering the Earth 



GET_TILE_LIST IDP-SC outputs shall be: 

PDI-FE-DS : 

Updated Metadata at datastrip level (list of tiles to produce) 




A single execution of GET_TILE_LIST IDP-SC shall process, on a single-core CPU with 










Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 203 / 315 

A single execution of GET_TILE_LIST IDP-SC shall process, on a single-core CPU with 




3.2.7.2 TILE_INIT 

For each L1C tile, IDP-SC TILE_INIT is in charge of tile metadata creation and in charge 

of processing all data that are shared and used by band processing or that are band 

independent: 

Reflectance Setup : 

ECMWF grid resampling in tile geometry 

Update of metadata at tile level 

DEM quality mask projection 


by tile 



TILE_INIT IDP-SC shall implement for a L1C tile, the computation of: 

Reflectance Setup : 

Sun angles incidences grid computation 

Mean solar incidence computation, 

Setting Sun-Earth distance variation correction term for TOA reflectance 

computation 

For each band, noise model in TOA reflectance setup, 

DEM quality mask projection on L1C tile 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 204 / 315 

ECMWF L1C tile computation from spatial and temporal interpolation of raw 

ECMWF data 

Creation and update of metadata at tile level 



TILE_INIT IDP-SC shall be activated: 

by tile 



TILE_INIT IDP-SC shall implement the algorithms based on following DPM parts (cf. Table 

2): 

Reflectance setup: 


(Reflectance setup) 

DEM quality mask projection: 

[RESAMPLE_S2-DPM] §6.2.3.1.2 

Metadata update: 


(mask DEM_QUAL: TBD) 

(partial- update metadata at 

tile level part)) 



Tasks of TILE_INIT IDP-SC that shall be switched ON or OFF according to configuration 


DEM Quality projection 


ECMWF L1C tile generation, 




ECMWF L1C tiles are described by GIPP. This GIPP defines at least for each tile: 

the ECMWF grid GSD, 

the ECMWF grid dimensions, 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 205 / 315 

the ECMWF grid Upper-Left corner position in L1C ground geometry. 


Note: default ECMWF GSD is 12,5km 


ECMWF L1C tiles are processed from the two ECMWF data set on both side of datatake 

imaging starting time. 

Parents: 


TILE_INIT shall provide ECMWF tile in L1C geometry for all meteorological parameters 

defined in [PSD]. 

Parents: 


Each node of ECMWF L1C tile is processed by: 

estimation of ECMWF node position in input ECMWF data raw geometry (ground 

projection conversion) 

for the two ECMWF data set on both side of datatake imaging starting time: 

estimation of ECMWF parameters at estimated node position in input ECMWF data 

raw geometry by spatial bilinear interpolation of ECMWF data in raw geometry, 

temporal linear interpolation at datatake imaging starting time. 

Parents: 


In accordance with activated step, TILE_INIT IDP-SC inputs shall be: 


PDI-FE-DS: 




ECMWF processing parameters (at least ECMWF resampled grid definition) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 206 / 315 

TILE_INIT specific processing parameters 

DEM (DEM quality mask) 

ECMWF raw data 



In accordance with activated step, TILE_INIT IDP-SC output Processing Unit shall include 


PDI-FE-GR : (for processed tile) 

Created and updated Metadata at tile level 

DEM quality mask 

ECMWF L1C tile 




TILE_INIT IDP-SC shall process, on a single-core CPU with hardware equivalent to the 

Reference Platform one, each tile of a 300km datastrip in less than 20 seconds (by tile) 

with the following assumptions: 

ECMWF L1C tile GSD: 12,5km: 


3.2.7.3 GEN_ORTHO_TOA 

For each L1C tile, IDP-SC GEN_ORTHO_TOA is in charge of orthorectification and 

conversion to TOA reflectance. 

GEN_ORTHO_TOA is also in charge of processing that could be parallelized by band (for 

S2-PDGS scalability) 

GEN_ORTHO_TOA is, for a list of band, in charge of 

Detector footprint projection in L1C tile geometry 

L1B Masks defined by band projection in L1C tile geometry 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 207 / 315 


L1B granules in L1C geometry resampling 

Conversion to TOA radiance 


by tile, 

by list of band (scalability only) 



GEN_ORTHO_TOA IDP-SC shall implement for one L1C tile and for each band identified 

in input: 

Detector Footprint mask generation 

Incidences grid computation (satellite angles) 

LookUp Table (LUT) computation for further conversion to TOA reflectance 

L1B Masks in L1C tile geometry projection 


Resampling 

Conversion to TOA reflectance 



GEN_ORTHO_TOA IDP-SC shall be activated: 

by tile 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 208 / 315 


GEN_ORTHO_TOA IDP-SC shall implement algorithm processing based on DPM: 

Detector Footprint mask generation: 

[RESAMPLE_S2-DPM] Annex F 

[V-MASK-DPM] 

(conversion between geographic and 

UTM coordinates) 

(intersection) 

Satellite incidences grid computation 


LookUp Table (LUT) computation 


L1B Masks in L1C tile geometry projection 

[RESAMPLE_S2-DPM] Annex B §6.2.3.1.1 


[RESAMPLE_S2-DPM] Annex B §6.2.3.2 

Resampling 

[RESAMPLE_S2-DPM] Annex B §6.2.3.3 

Conversion to TOA reflectance 

[RESAMPLE_S2-DPM] Module #08-2-02-02 

(incidence computation) 

(reflectance computation) 

(masks already in input) 

(building reverse location grid) 

(Image resampling) 

(reflectance computation) 



Tasks of GEN_ORTHO_TOA IDP-SC that shall be switched ON or OFF according to 


Detector Mask generation 


L1B mask projection, 


Conversion to TOA reflectance, 


When conversion to TOA reflectance is DISABLE, Satellite angles and LUT shall not be 

processed. 



In accordance with activated step, GEN_ORTHO_TOA IDP-SC inputs shall be: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 209 / 315 

PDI-FE-DS: 


PDI-FE-ATF 

Detector footprint (for processed bands) 

L1B masks (for processed bands) 

L1B Radio-corrected images (for processed bands) 

PDI-FE-GR : 

Metadata at tile level (for processed tile) 



GEN_ORTHO_TOA specific processing parameters 

Precise DEM (SRTM class) 





When relevant, GEN_ORTHO_TOA IDP-SC shall select from input GIPP the applicable 




In accordance with activated step, GEN_ORTHO_TOA IDP-SC output Processing Unit 

shall include all or part of: 


Detector Masks (for processed bands) 

L1B projected masks (for processed bands) 

Satellite incidence angles grid (for processed bands) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 210 / 315 

LookUp Table for reflectance conversion (for processed bands) 

TOA reflectance images (for processed bands) 



In FAKE mode, GEN_ORTHO_TOA IDP-SC shall generate: 

PDI-FE-GR : (for each band of processed tile) 

TOA reflectance images(for processed bands) stuffed with NoData 

With No Data images dimensions coherent to the expected one for processed L1C tile and 

processed bands. 




GEN_ORTHO_TOA IDP-SC shall process, on a single-core CPU with hardware equivalent 

to the Reference Platform one, all bands of each tile of a 300km datastrip in less than 16 

minutes (by tile) with the following assumptions: 

resampling grid step: 45m for 10m and 20m bands 

resampling grid step: 60m for 60m bands 


Parents: S2-PDGS-IDP-080, S2-PDGS-IDP-085, S2-PDGS-SYS-380, S2-PDGS-SYS-385, S2-PDGS-SYS-390 and S2-PDGS-SYS-400 


GEN_ORTHO_TOA IDP-SC processing time shall be near-linear according to tile surface 

intercepted by detectors footprints 


3.2.7.4 TILE_FINALIZE 

For each L1C tile, IDP-SC TILE_FINALIZE is in charge of collecting information processed 

by list of bands by GEN_ORTHO_TOA in order to update tile metadata. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 211 / 315 


by tile 



TILE_FINALIZE IDP-SC shall at least: 

Compute percentage of degraded MSI data and degraded ancillary data, 

Update L1C tile metadata with, 

Incidences grid (satellite angles) 

LookUp Table (LUT) used for conversion to TOA reflectance 



TILE_FINALIZE IDP-SC shall be activated: 

by tile 



TILE_FINALIZE IDP-SC shall implement algorithm processing based on DPM: 

percentage of degraded MSI data and degraded ancillary data processing 

[RESAMPLE_S2-DPM] §5.5.3.2 

(report update) 



In accordance with activated step, TILE_FINALIZE IDP-SC inputs shall be: 


PDI-FE-DS: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 212 / 315 

PDI-FE-GR 

Metadata at tile level (for processed tile) 

Satellite incidence angles grid (for all available bands) 

LookUp Table used for reflectance conversion (for all available bands) 

MSI and ancillary data quality masks in L1C geometry (for all available bands) 




In accordance with activated step, TILE_FINALIZE IDP-SC output Processing Unit shall 



Updated metadata at tile level 




TILE_FINALIZE IDP-SC shall process, on a single-core CPU with hardware equivalent to 

the Reference Platform one, each tile of a 300km datastrip in less than 20 seconds (by 

tile). 


3.2.7.5 MASK_S2 



MASK_S2 IDP-SC shall implement for a tile: 

Input image rescaling to a common GSD 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 213 / 315 

Cloud classification (cloud free/opaque cloud/cirrus) 

Cloud classification filtering 

Land/Water classification 

Masks vectorization and export in GML format 

Metadata at tile level updating with 

Cloudy pixel percentage 

Cirrus corrupted pixel percentage 



MASK_S2 IDP-SC shall be activated: 

by tile 



MASK_S2 IDP-SC shall implement algorithm processing based on DPM: 

Image rescaling: 

[MASK_1C-DPM] §5.3.1 

(Input Data Resampling) 

Cloud classification 

[MASK_1C-DPM] §5.3.1.1 

Cloud classification filtering 

[MASK_1C-DPM] §5.3.2 

Land/Water classification 

[MASK_1C-DPM] §5.3.3 

Masks vectorization 

[MASK_1C-DPM] §5.3.4 

Cloudy/ Cirrus corrupted pixel percentage 

[MASK_1C-DPM] §5.3.4.1 

(cloud spectral detection) 

(cloud filtering) 

(Land/Water Spectral Classification) 

(mask Vectorization) 

(end of §: percentage of corrupted 

pixel computing part) 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 214 / 315 


Tasks of MASK_S2 IDP-SC that shall be switched ON or OFF according to configuration 


Cloud Masks processing 


Land/water Masks processing, 




In accordance with activated step, MASK_S2 IDP-SC inputs shall be: 


PDI-FE-DS: 



Images in TOA reflectance for 5 bands 

Metadata at tile level 



MASK_S2 specific processing parameters (e.g.: thresholds for cloud 

classification) 



In accordance with activated step, MASK_S2 IDP-SC output Processing Unit shall include 



Updated Metadata at tile level 

Cloud masks 

Land/Water masks 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 215 / 315 



MASK_S2 IDP-SC shall process, on a single-core CPU with hardware equivalent to the 

Reference Platform one, each tile of a 300km datastrip in less than 30 seconds (by tile) 

with the following assumptions: 

three 10m bands and two 20m bands rescaled to 60m 

rescaling filter: optimised bicubic 


3.2.7.6 FORMAT_IMG (L1C JP2000) 

FORMAT_IMG(L1C JP2000) IDP-SC is in charge of L1C tiles compression in GML- 

JPEG2000 format (GML header inserted in Jpeg2000 bitstream). 


by tile, 




FORMAT_IMG(L1C JP2000) IDP-SC shall implement L1C images GML-JPEG2000 

compression (one compressed image by band with a GML header in accordance with 

band resolution). 



FORMAT_IMG(L1C JP2000) IDP-SC shall be activated: 

by tile 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 216 / 315 


FORMAT_IMG(L1C JP2000) IDP-SC shall implement algorithm processing based on (cf. 

Table 2): 



(GML header creation) 






FORMAT_IMG(L1C JP2000) IDP-SC inputs shall be: 


PDI-FE-DS : 


PDI-FE-GR(for each band of processed tile) 

Metadata at granule Level (for geographic information to be embedded in GML- 

JP2000) 

L1C images (all available bands) 



FORMAT_IMG(L1C JP2000) specific processing parameters (e.g. compression 

parameters) 



FORMAT_IMG(L1C JP2000) IDP-SC output Processing Unit shall include: 

PDI-FE-GR (for each tile) 

L1C GML-JPEG2000 compressed image (one file by available band) 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 217 / 315 



FORMAT_IMG(L1C JP2000) IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, all bands of each tile of a 300km datastrip in 

less than 3 minutes and 30 seconds (by tile) with the following assumptions: 

. 



3.2.7.7 FORMAT_IMG (PVI & TCI) 

FORMAT_IMG IDP-SC is in charge of 

GML-Jpeg2000 compressed True Color Image (TCI) generation 

GML-Jpeg2000 compressed Pre-View Image (PVI) generation, with georeferenced 

embedded information 


by tile 



The FORMAT_IMG(PVI&TCI) IDP-SC shall generate, True Color Image (TCI) and Pre- 

View Images (PVI) from the visible bands located at 490nm (blue), 560nm (green) and 665 

nm(red) in L1C geometry. 



FORMAT_IMG(PVI&TCI) IDP-SC shall implement: 

For each three input bands: 

mapping full resolution input radiance on 8 bits according to a linear law, 

rescaling 8-bits mapped radiance to PVI GSD, 

full resolution radiance mapped on 8 bits compression in JPEG format 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 218 / 315 

downsampled radiance mapped on 8 bits compression in GML-JPEG2000 format 

(one file for all PVI bands with a GML header in accordance with PVI resolution) 



FORMAT_IMG(PVI&TCI) IDP-SC shall be activated: 

by tile 



TCI/PVI radiance mapping function on 8bits is defined by GIPP. 

Default parameters are 

No_DATA: 0 

Offset:1 (8bit mapped value for null radiance is1) 

Gain:254 (then 8bit mapped value for maximal radiance is 255) 

Parents: 


Linear function for input radiance on 8 bit mapping shall be computed from TCI/PVI 

radiance mapping function (on 8bits) and input images radiance mapping function (on 

16bits). 

Parents: 


PVI GSD and for each tile, PVI dimensions and PVI Upper-Left corner position in L1C 

ground geometry are defined by GIPP. 

Note: default PVI GSD is 320m 

Parents: 


According to PVI grid definition (GSD, dimensions and Upper Left corner position in 

L1Cground geometry), full resolution images rescaling to PVI images could include 

translations or clipping operations. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 219 / 315 


TCI Jpeg compression shall gather the three bands to compress in an unique Jpeg file in 

the usual RGB band order. 

Parents: 


PVI Jpeg2000 compression shall gather the three bands to compress in an unique GML- 

Jpeg2000 file in the usual RGB band order. 

Parents: 

Reference S2PDGS-IPF-TRD-REQ-456-a : 

FORMAT_IMG(PVI&TCI) IDP-SC shall implement algorithm processing based on DPM: 

Image rescaling: 




(GML header creation) 



Tasks of FORMAT_IMG(PVI&TCI) IDP-SC that shall be switched ON or OFF according to 


TCI processing 


PVI processing, 


Parents: S2-PDGS-SYS-050, S2-PDGS-IDP-135 


In accordance with activated step, FORMAT_IMG(PVI&TCI) IDP-SC inputs shall be: 


PDI-FE-DS: 



Images in TOA reflectance for 3 bands 

Metadata at tile level 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 220 / 315 



TCI_PVI_mapping: 8bit radiance mapping linear function 

PVI tile definition (GSD and for each L1C tile, dimensions and upper-left corner 

position) 

FORMAT_IMG(PVI&TCI) specific processing parameters (e.g.: TCI jpeg 

compression parameters, PVI Jpeg200 compression parameters) 



In accordance with activated step, FORMAT_IMG(PVI&TCI) IDP-SC output Processing 

Unit shall include all or part of: 


TCI GML-Jpeg2000 file 

PVI GML-Jpeg2000 file 




FORMAT_IMG(PVI&TCI) IDP-SC shall process, on a single-core CPU with hardware 

equivalent to the Reference Platform one, each tile of a 300km datastrip in less than 30 

seconds (by tile) with the following assumptions: 

PVI GSD: 320m. 


3.2.7.8 FORMAT_METADATA(TILE-L1C) 

FORMAT_METADATA(TILE- L1C) IDP-SC finalizes L1C metadata at tile level. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 221 / 315 


By tile. 



FORMAT_METADATA(TILE-L1C) IDP-SC shall complete the remaining metadata 

information at tile level to be fully compliant with [PSD] (before TAR formatting). 


Note: 



container to be fully compliant with [PSD]. 


FORMAT_METADATA(TILE-L1C) IDP-SC shall be activated: 

by tile 



In accordance with activated step, FORMAT_METADATA(TILE-L1C) IDP-SC input 


PDI-FE-DS : 


PDI- GR : 

all files relevant to processed tile (metadata, masks, …) 



In accordance with activated step, FORMAT_METADATA(TILE-L1C) IDP-SC output 



Updated L1C Metadata at tile level 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 222 / 315 


In FAKE mode, FORMAT_METADATA(TILE-L1C) IDP-SC shall at least generate: 

L1C Metadata at tile level with brief metadata set correctly and compliant with 

A 

PSD format [PSD] (before TAR formatting). 




FORMAT_METADATA(TILE-L1C) IDP-SC shall process, on a single-core CPU with 

hardware equivalent to the Reference Platform one, each tile of a 300km datastrip in less 

than 20 seconds (by tile). 


3.2.7.9 FORMAT_METADATA(DS-L1C) 

FORMAT_METADATA(DS-L1C) IDP-SC finalizes L1C metadata at datastrip level. 




FORMAT_METADATA(DS-L1C) IDP-SC shall finalize L1C metadata at datastrip level to 

be fully compliant with [PSD] (before TAR formatting). 


Note: 

Finalize metadata step is performing conversion into SAFE format as defined in [PSD]. 


FORMAT_METADATA(DS-L1C) IDP-SC shall be activated: 

by datastrip 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 223 / 315 


FORMAT_METADATA(DS-L1C) IDP-SC gathers finalized metadata at datastrip level , 

L1A, L1B and L1C auxiliary data in a container to be fully compliant with [PSD] for L1C 

datastrip (before TAR formatting). 



FORMAT_METADATA(DS-L1C) IDP-SC input Processing Unit shall include: 

PDI-FE-DS : 

L1C Metadata at datastrip level 



GIPP : all GIPP used in L1A, L1B and L1C processing 

IERS bulletin 


DEM: reference to precise DEM (SRTM class) used in L1B and L1C processing 

Reference to the list of GRI used for L1B refining 



FORMAT_METADATA(DS-L1C) IDP-SC output Processing Unit shall include: 

PDI-FE-DS : 

Updated L1C Metadata at datastrip level 

PDI-DS : 

Formatted L1C datastrip 



In FAKE mode, FORMAT_METADATA(DS-L1C) IDP-SC shall at least generate: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 224 / 315 

An L1C Metadata at datastrip level with brief metadata set correctly which is 

compliant with [PSD] (before TAR formatting). 




A single execution of FORMAT_METADATA(DS-L1C) IDP-SC shall process, on a singlecore 




3.2.8 Product generation performances requirement 

3.2.8.1 L0c processing performance requirements 


Sequenced L0c IDP-SC shall process L0c product, on a single-core CPU with hardware 


in less than 3 hours with the following assumptions, 

sequencial processing of IDP-SC on a single-core CPU, 

INIT_LOC_L0 processing with: 



QL_GEO processing with: 



QuickLook bands: 3 bands at 10m SSD, 1 band at 20m SSD and 1 band at 60m SSD 



QL_CLOUD_MASK processing with: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 225 / 315 



FORMAT_IMG(QL JP2000) processing with: 




3.2.8.2 L1A and L1B processing performance requirements 

3.2.8.2.1 L1B without registration 


In Nominal Processing, sequenced L1A and L1B IDP-SC shall process L1A and L1B 

product (without registration), on a single-core CPU with hardware equivalent to the 

Reference Platform one, a datastrip equivalent to 10 minutes of downlink in less than 29 

hours with the following assumptions, 


UPDATE_LOC processing with: 





Nominal processing scenario: All steps activated excepted cloudy pixel 

percentage computation at granule level step, 



RADIO_AB processing with: 

“L1A and L1B” scenario with all L1A and L1B radiometric corrections activated 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 226 / 315 





FORMAT_IMG(L1A JP2000) and FORMAT_IMG(L1A JP2000)processing with: 


GEO_1B FINALIZE processing with: 




In Reprocessing, sequenced L1A and L1B IDP-SC shall process L1A and L1B product 

(without registration), on a single-core CPU with hardware equivalent to the Reference 

Platform one, a datastrip equivalent to 10 minutes of downlink in less than 31h30 hours 

with the following assumptions, 



degraded scenario: All step activated, 


QL_DECOMP processing with: 












Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 227 / 315 

reprocessing processing scenario: All steps activated, 














3.2.8.2.2 L1B with Image-GRI registration 


In Nominal Processing, sequenced L1A and L1B IDP-SC shall process L1A and L1B 

product (with Image-GRI registration), on a single-core CPU with hardware equivalent to 


38 hours with the following assumptions, 











Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 228 / 315 














GEO_1B_FINALIZE processing with: 


UNFORMAT_GRI processing with: 


RESAMPLE_TO_VS processing with: 




TP_COLLECT processing with: 









Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 229 / 315 

SPATIO processing with: 



3.2.8.3 L1C processing performance requirements 

3.2.8.3.1 Tile processing (without formatting) 


Sequenced L1C IDP-SC (from TILE_INIT to MASK_S2) shall process without formatting, 

with hardware equivalent to the Reference Platform one, each tile of a 300km datastrip in 

less than 16 minutes and 30 seconds with the following assumptions, 

each tile is processed on a single-core CPU, 

at least one CPU is available by tile 

TILE_INIT processing with: 

ECMWF resampled data GSD: 12,5km: 

GEN_ORTHO_TOA processing with: 




MASK_S2 processing with: 




Sequenced L1C IDP-SC (from TILE_INIT to MASK_S2) shall process without formatting, 

on a single-core CPU with hardware equivalent to the Reference Platform one, a datastrip 

equivalent to 10 minutes in less than 36 hours with the following assumptions, 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 230 / 315 

L1C IDP-SC are activated either by datastrip or by tile 










3.2.8.3.2 L1C end to end processing 


Sequenced L1C IDP-SC shall process L1C product, with hardware equivalent to the 

Reference Platform one, for a 300km datastrip in less than 22 minutes and 30 seconds 


each tile is processed on a single-core CPU, 














Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 231 / 315 

FORMAT_IMG(L1C J2000) processing with: 

reversible JP2 compression 



Sequenced L1C IDP-SC shall process L1C product, on a single-core CPU with hardware 

equivalent to the Reference Platform one, for a datastrip equivalent to 10 minutes in less 

than 45 hours and 45 minutes with the following assumptions, 













3.2.8.4 Nominal processing up to Level1C 

3.2.8.4.1 Without registration 


Sequenced IDP-SC shall process L0c/L1A/L1B/L1C product (without Image-GRI 

registration), on a single-core CPU with hardware equivalent to the Reference Platform 

one, a datastrip equivalent to 10 minutes of downlink in less than 77 hours and 45 minutes 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 232 / 315 
































Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 233 / 315 





















3.2.8.4.2 With Image-GRI registration 


Sequenced IDP-SC shall process L0c/L1A/L1B/L1C product (with Image-GRI registration), 

on a single-core CPU with hardware equivalent to the Reference Platform one, a datastrip 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 234 / 315 

equivalent to 10 minutes of downlink in less than 86 hours and 45 minutes with the 

following assumptions, 






























Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 235 / 315 










GEO_1B_FINALIZE processing with: 


UNFORMAT_GRI processing with: 


RESAMPLE_TO_VS processing with: 




TP_COLLECT processing with: 




SPATIO processing with: 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 236 / 315 











3.3 OLQC-SC specific requirements 


The OLQC inspections are programmed through the so-called OLQC-GIPP (Ground 

Image Processing Parameters) describing the inspections to perform. 

The OLQC-SC is built upon the Amalfi-2 software [AMALFI-SUM], which is provided by the 

Agency as a Customer Furnished Item (CFI) and supports generic functionalities for 

product-data decoding and subsequent quality inspections. The Amalfi-2 software will be 

wrapped as a stand-alone processor within the OLQC-SC. Finally, the OLQC-SC will 

generate an XML output from the Amalfi-2 software that will be stored in a directory 

specified by the checklist (either QI_DATA or MPC or BOTH). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 237 / 315 

OLQC- 

GIPPs 



Reports 


Bridge 

Amalfi (CFI) 

Stand-alone 

OLQC 

Reports 

DPC 

or 

IDP-Orchestrator 

Reports 


AUX/ANC/PDI 

OLQC-SC 

IDP-SC 


Figure 27: OLQC-SC context. 

The Figure 27 depicts the OLQC-SC context to illustrate the input and outputs items. The 

OLQC-SC mechanism is based on the following sequence of processing steps: 

For any generated product L0c, L1A, L1B, L1C or PVI/TCI: 

1. The DPC systematically and automatically calls the OLQC-SC .The component is 

in Java language and called from command line shell or associated scripting 

languages.(by DPC) 

2. The OLQC-SC performs the quality inspection using the Amalfi-2 software 

according to the requirements expressed in the OLQC-GIPP. The OLQC-GIPP 

provided by Mission Performance Assessment (MPA) center contains the list of 

inspections to apply, grouped in thematic checklist for each PDI .The OLQC-GIPP 

are converted through a Bridge in order to fit with the Amalfi-2 software 

specifications required to perform the inspections (Amalfi configuration). The Bridge 

takes as input the OLQC-GIPP and produces two jar files : 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 238 / 315 

a. one JAR file containing mandatory information required by Amalfi to classify 

the data type (Item Classes). To fit with our goal, the development of the JAR 

file shall consider the following: 

 

 

If the inspection type is on the metadata then the check is performed 

by analyzing an xml file. This return to create an item ontology (owl 

file) that link the product to be inspected with the inspection plan 

if the inspection type is on image data a DRB schema has to be 

created (except if the format is supported by Amalfi) 

An example is provided with the LANDSAT CEOS add-on [AMALFI-SUM]. 

b. one JAR file containing the inspection definitions through an item ontology 

(owl file) describing the inspection plan. Each inspection plan contains the list 

of checks to perform and each check a description of the control. Examples 

are provided in the Amalfi CFI add-ons for Envisat product. 

The OLQC-GIPP is used to configure Amalfi. Each time the OLQC-GIPP is 

modified (update of values within a check, e.g. threshold values, or definition of a 

new check in existing check list), these JAR files shall be updated. 

3. The Amalfi generates an XML report, 

The Amalfi report will be split in various sub-reports, one per checklist and per PDI 

inspected to generate a summary report. This report will have to include: 

a. the name of the check list 

b. the version of the checklist; 

c. the name of the OLQC-GIPP defining the checklist and its inspections 

d. the name of inspected data (data strip identifier or granule identifier) 

e. the global quality check result: Passed or Failed; 

f. for each unitary check, the check identification and the check result: Passed 

or Failed; 

4. The inspected product item is sent back to the DPC for further handling 

3.3.2 OLQC Inspections 

3.3.2.1 Inspections 

The quality control checks performed include the following two types of inspections: 

Data format inspections: 

Checksum errors. 

Syntax verification. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 239 / 315 

Dataset completeness. 

Data content inspections: 

Check data value ranges. 

Physical value meaningfulness/compliance. 

The inspections will be applied to the different types of PDIs composing the Level-0c, -1A, 

-1B and -1C (cf. [PSD]): 

Metadata; 

Image Data; 

Preview Data; 

Ancillary Data (including inspections on payload and platform ancillary data); 

Auxiliary Data; 

Quality Indicators Data (inspection applied to those PDIs generated by IDP-SC 

during the processing). 

The inspections will be split in different categories: 

“Basilar” or “Sample Checks” aiming at sampling (probing) some specific items 

extracted from the product data for off-line assessment by the QCC component and 

deployed in the MPC Coordinating Center. 

”Informative Checks” aiming at characterizing/measuring the quality of the data; 

“Concluding Checks” with the purpose of summarizing the quality of the data with a 

concluding flag such as a Boolean "pass" or "fail", and at generating operator alerts 

in real-time in case of a failed status. 

The quality-check PDIs issued from informative or Concluding Checks will be part of the 

user-product structure as “Quality control check information” metadata defined in [PSD]. 

The quality-check report files issued from sample/basilar checks will not be embedded in 

the product structure. 

The OLQC-SC will finally consolidate a summary pass/fail status at the term of each 

checklist processing stating whether all the configured concluding checks have "passed" 

or whether at least one has "failed". The summary status will be systematically in the xml 

report. 

The XML report is stored according to the type of checklist in the appropriate directory. 

The possible directories are QI_DATA (as part of resulting PDI), MPC or BOTH. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 240 / 315 

The tables below present a list of inspections to be systematically performed per product 

level. This list can be consolidated if further inspections are required. 

The tables include the following columns: 

Product Level: type of the product 

Check Description: details on the scope of the QC (Quality control) check 

Input Data: input identification (metadata fields are based on [PSD] definitions) 

Metadata Output: output description 

Inspection Type: based on the data and/or metadata. For each QC check, the 

associated checks described (simple or complex) 

In addition to each inspection list table, a table describing the pseudo algorithms for each 

inspection is given where the first column describes the name of the check and the second 

column presents the associated pseudo-algorithm. 

Product 

Level 

L0c 

Check 

Description 

Check of 

consistency of 

the granules. 

Aims at 

ensuring that 

the corrupted 

ISPs are 

constantly 

below a 

threshold for 

each granule 

Check of 


the relative 

orbit 

Aims at 

ensuring that 

the level of 

degraded SAD 

is below a 

threshold for 

each datastrip 

Input Data 

(M): Metadata 

(D): Data Payload 

Level-0_Granule_ID: 

DEGRADED_MSI_DATA_PERCENTAGE 

(M) 

DEGRADED_ANC_DATA_PERCENTAG 

E (M) 

Metadata 

Output 

Success Flag 

(passed/failed) 

+ Number of 

degraded ISPs 

Success Flag 

(passed/failed) 

+ Number of 

degraded ISP 

Inspection 

Type 

Metadata 

(simple) 

Metadata 

(simple) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 241 / 315 

Product 

Level 

Check 

Description 

Check the 


the sensing 

time. This 

check aims at 

ensuring the 

correctness of 

the sensing 

time 

Check the 

number of 

missing lines 

as 

consequence 

of the ISP lost 

or degraded 

for each 

granule) 

Check the 


the Datation 

model. This 

check will 

inspect the 

quality 

indicators 

resulting from 

Datation 

process 

Check of 


the relative 

imaging and 

downlink orbit 

number 

Check of 

admissibility of 

the Attitude 

Quality 

Indicator (QI) 

provided in 

SAD 

Input Data 

(M): Metadata 


SENSING_TIME (M) 

Lost_Source_Packed_List (M): 

NUMBER_OF_SP_ERROR (M) 

DEGRATATION_TYPE(M) 

Time_Stamp (M): 

GPS_SYNC (M) 

TDOP_QUALITY (M) 

Quality_Indicators (M) 

RMOY (M) 

DOWNLINK_ORBIT_NUMBER (M) 

SENSING_ORBIT_NUMBER (M) 

ATTITUDE_QUALITY_INDICATOR(M) 

Metadata 

Output 

Success Flag 

(passed/failed 

Success Flag 


Success Flag 


Success Flag 


Inspection 

Type 

Metadata 

(simple) 

Metadata 

(simple) 

Metadata 

(simple) 

Metadata 

(simple) 

Table 4: List of preliminary OLQC inspections for L0c product 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 242 / 315 

Product 

Level 

L0c 

Check Name 

Corrupted_ISP_Checks 

Pseudo-Code 

data to check= DEGRADED_MSI_DATA_PERCENTAGE 

/*Read input*/ 

OPEN granule_metadata 

READ data_to_check 

/*Control operation*/ 

FOR each band, detector 

IF data_to_check LT threshold THEN 

output=PASSED+Number of degraded ISPs 

+ DEGRADATION_TYPE(string) 

ELSE 

output=FAILED +Number of degraded ISPs 

+ DEGRADATION_TYPE(string) 

Degraded_SAD_Checks. 

/*Store result into XML report*/ 

WRITE name of checklist 

WRITE output 

data to check= DEGRADED_ANC_DATA_PERCENTAGE 


OPEN datastrip _metadata 



IF data_to_check LT threshold THEN output=PASSED +Number of 

degraded SAD 

ELSE 

output=FAILED +Number of degraded SAD 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 243 / 315 

Product 

Level 

Check Name 

Sensing_Time 

Missing_Lines_Checks 

data to check= SENSING_TIME 



Pseudo-Code 

READ data_to_check from granule_metadata 

data_to_check_granule=SENSING_TIME 

READ START_DATE from DATA_STRIP_ID 

data_to_check_datastrip= SENSING_TIME 


IF data_to_check_ GE STARTDATE THEN output=PASSED 

ELSE 

output=FAILED 



WRITE output 

data to check= NUMBER_OF_SP_ERROR AND 

DEGRATATION_TYPE 





FOR each band 

Read DEGRADATION_TYPE 

Number of missing lines = NUMBER_OF_SP_ERROR*16 

IF data_to_check LT threshold THEN output=PASSED + Number of 

missing lines +DEGRADATION_TYPE 

ELSE 

output=FAILED + Number of missing lines+ DEGRADATION_TYPE 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 244 / 315 

Product 

Level 

Check Name 

Datation Model Check 

data to check= RMOY 

Pseudo-Code 


OPEN datastrip_metadata 




Output_rmoy=PASSED 

ELSE 

output_rmoy =FAILED 



WRITE output_rmoy 

data to check= GPS_SYNC 



L0c 


IF data_to_check is true THEN output_gps=PASSED 

ELSE 

output_gps=FAILED 

data to check= GPS_TDOP_QUALITY 





output_tdop=PASSED 

ELSE 

output_tdop=FAILED 

IF output_tdop AND output_gps AND output_tdop=PASSED 

THEN 

Output_tdop=PASSED 

ELSE outpu_tdop t=FAILED 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 245 / 315 

Product 

Level 

Check Name 

Relative_Orbit_Number 

Check 

Attidude_Quality_Indicat 

or Check 

Pseudo-Code 

data to check= 

DOWNLINK_ORBIT_NUMBER AND 

SENSING_ORBIT_NUMBER 






output=PASSED 

ELSE 

output=FAILED 



WRITE output 

data to check= Attidude_Quality_Indicator 





IF data_to_check LT threshold THEN output=PASSED 

ELSE 

output=FAILED 



WRITE output 

Table 5: Pseudo-code for L0c product inspections. 

Product 

Level 

L 1A 

Check 

Description 

Check the 


granule size to 

assess the 


the dimensions 

Check the 


granule footprint 

wrt the expected 

values 

Input Data 

(M): Metadata 


Raster_Dimension(M) 

 

DETECTOR_DIMENSIONS 

(M) 

PRODUCT_FOOTPRINT (M) 

Metadata 

Output 

Success Flag 


Success Flag 


Inspectio 

n Type 

Metadata 

(simple) 

Metadata 

(simple) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 246 / 315 

Product 

Level 

Check 

Description 

Check of 


Incidence and 

Sun Angles 

(corresponding 

the center of 

granule) 

Check the 

percentage of 

cloud coverage 

Check the 

processor 

version 

Check the value 

of the Ephemeris 

Quality Indicator 

and of the 

Planimetric 

Stability is 

below a 

threshold 

Check the 

Absolute 

Location value 

is below a 

threshold 

Check the list of 

fake 

decompressed 

sources frames 

Input Data 

(M): Metadata 


INCIDENCE_ANGLES (M) 

SOLAR_ANGLES (M) 

CLOUDY_PIXEL_PERCENTAGE (M) 

Production_Facility (M) 

SOFTWARE_VERSION (M) 

EPHIMERIS_QUALITY 

Planimetric Stability 

VALUE (M) 

Absolute_Location (M) 

VALUE (M) 

LIST_FAKE_DECOMPRESSED_SOU 

RCE_FRAMES (M) 

Metadata 

Output 

Success Flag 


Success Flag 


Success Flag 


Success Flag 


Success Flag 


Success Flag 


Inspectio 

n Type 

Metadata 

(simple) 

Metadata 

(simple) 

Metadata 

(simple) 

Metadata 

(simple) 

Metadata 

(simple) 

Table 6: List of preliminary OLQC inspections for L1A product 

Product 

Level 

Check Name 

Pseudo-Code 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 247 / 315 

Product 

Level 

L 1A 

Check Name 

Detector_Dimensio 

ns Check 

Product_Footprint 

Check 

Pseudo-Code 

Data to check= Detector_Dimensions 




FOR each band ,detector 


NC: nbr of columns, NR: nbr of rows 

FOR XX EQ 10,20,60 

IF BND=XXm THEN 

IF ( (NC EQ NC_XXm) AND (NR EQ NR_XXm) ) 

THEN 

output=PASSED 

ELSE 

output=FAILED 



WRITE output 

Data to check= Granule Footprint 





Ur: "Upper right", Ll: "Lower left" 

IF ABS((d(Ul,Ur)-25)




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 248 / 315 

Product 

Level 

Check Name 

Geometric _Header 

Check 

Perc_Cloud 

Coverage 

Check 

Processor _Version 

Check 

Pseudo-Code 

data to check= INCIDENCE_ANGLES AND SOLAR_ANGLES 


OPEN granule _metadata 



IF data to check GE 0 AND data_to_check LE threshold THEN 

output= PASSED 

ELSE 

output=FAILED 



WRITE output 

Data to check= CLOUDY_PIXEL_PERCENTAGE 





IF data to check GE 0 AND data_to_check LE threshold THEN 


ELSE 

output=FAILED 



WRITE output 

Data to check= SOFTWARE_VERSION 





IF data_to_check EQ "processor_version" THEN 

output=PASSED 

ELSE 

output=FAILED 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 249 / 315 

Product 

Level 

Check Name 

Ephemeris_Planim 

etric Check 

Absolute _Location 

Value Check 

List_Fake__Decom 

pression Check 

Pseudo-Code 

Data to check= EPHIMERIS_QUALITY AND Planimetric Stability 

value 





IF data_to_check EQ threshold THEN 

output=PASSED 

ELSE 

output=FAILED 



WRITE output 

Data to check= ABSOLUTE_LOCATION /VALUE 






output=PASSED 

ELSE 

output=FAILED 



WRITE output 

Data to check= 

LIST_FAKE_DECOMPRESSED_SOURCE_FRAMES, /*Read input*/ 




FOR each band 

Read FIRST,NUMBER_OF_SOURCE_FRAMES 

LAST =FIRST+ NUMBER_OF_SOURCE_FRAMES 

IF 0 LT FIRST GE value AND 0 LT LAST GE value 

where value is 144 for 10m , 72 for 20m 24 for 60m 

THEN output=PASSED + LAST 

ELSE 

output=FAILED + LAST 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 250 / 315 

Table 7: Pseudo-code for L1A product inspections (Table 6). 

Product 

Level 

L 1B 

Check 

Description 

All the 

inherited 

checks 

performed 

during the 

Level 1A and 

Level 0 

processing 

Check of the 


the Geometric 

Refining 

Input Data 

(M): Metadata 


Geometry_Refining_Quality (M) 

Image_Refining_Quality (M) 

VNIR_SWIR_Registration (M) 

Spatio_residual_Histrograms 

Metadata 

Output 

Success Flag 


Inspection 

Type 

Metadata 

(simple) 

Check on the 

Radiometric 

Quality 

Indicators. 

This 

inspections 

aims at 

reporting the 

radiometric 

quality by 

inspecting in 

each band the 

absolute, the 

cross band 

and the multi 

_temporal 

calibration 

accuracy 

Radiometric Quality 

ABSOLUTE 

CALIBRATION_ACCURANCY (M) 

CROSS_BAND_CALIBRATION_A 

CCURANCY (M) 

MULTI_TEMPORAL_CALIBRATIO 

N_ACCURANCY (M) 

Success Flag 


Metadata 

(simple) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 251 / 315 

Check on the 

radiometry. 

This inspection 

will calculate 

the SNR for all 

bands of 

granules. 

These 

granules will 

be selected 

based on the 

geographical 

criteria 

corresponding 

to a 

radiometrically 

homogeneous 

and uniform 

landscape. 

The method 

used for the 

calculating the 

SNR is 

described in 

section 3.3.2.7 

of 

[CALVALPE2] 

Granule image data (D) Report with 

SNR values 

to be sent to 

the MPC 

Data 

(complex) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 252 / 315 

. Check for 

discovering 

new possibly 

NO-DATA, 

SATURATED 

or 

DEFECTIVE 

pixels. 

 

A minimum of 12 granules per orbit 

(D) 

Success Flag 


)+map of 

discovered 

pixels (in 

case of 

failure) 

Data 

Payload(com 

plex) 

Table 8: List of OLQC inspections for L1B product 

Product 

Level 

L 1B 

Check 

Name 

GeometricRe 

fining Check 

Pseudo-Code 

Data to check= Image_Refining_Quality AND 

VNIR_SWIR_Registration AND 

Spatio_residual_Histrograms 





IF data_to_check LE threshold THEN 


ELSE 

output=FAILED 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 253 / 315 

Data to check= ABSOLUTE_CALIBRATION_ACCURANCY AND 

CROSS_BAND_CALIBRATION_ACCURANCY AND 

MULTI_TEMPORAL_CALIBRATION_ACCURANCY 

Radiometric_ 

Quality_Indic 

ators 





IF data_to_check LE threshold THEN 


ELSE 

output=FAILED 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 254 / 315 

Data to check=SNR 


READ granule image 


Check if Granule footprint is included in RHA (Radiometric 

Homogeneous Area, cf. CAL/VAL document [CALVALPE2]) 

IF Granule is in RHA 

THEN 

Compute SNR (cf. §3.3.2.7 in [CALVALPE2])” 


WRITE into Report 

ELSE WRITE “Granule not included” 

If The RHA is provided the approach should be the following: 

Data to check=SNR 



SNR Check 

/*Create RHA (Radiometric Homogeneous Area) coordinate array 

(extracted from CAL/VAL document*/ 

Array_RHA_UL_lt = UL latitude of RHA 

Array_RHA_UL_lg = UL longitude of RHA 

Array_RHA_LR_lt = LR latitude of RHA 

Array_RHA_LR_lg = LR longitude of RHA 

/*UL &LR coordinate of granule image extracted from metatada*/ 

Ul_lt=UL latitude coordinate of granule image 

Ul_lg=UL longitude coordinate of granule image 

LR_lt=LR latitude coordinate of granule image 

LR_lg=LR longitude coordinate of granule image 

/*Check granule included within RHA*/ 

Diff –UR_lt=[array-RHA-UL_lt]-UL_lt 

Diff –UR_lg=[array-RHA-UL_lg]-UL_lg 

Diff –LR_lt=[array-RHA-LR_lt]-LR_lt 

Diff –LR_lg=[array-RHA-LR_lg]-LR_lg 

/*Detect Position fulfilling condition For granule inclusion*/ 

FOR all RHA (i=0 to (Num RHA)-1) DO 

IF Diff UR_lt[i]>0 AND Diff UR_lg[i]




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 255 / 315 

Data to check= NO_DATA, SATURATED , DEFECTIVE 

The principle idea is that No data, Saturated and defective pixel 

location are indicated in the Data strip metadata 

Therefore the process is to 

1/ create a binary image from the granule image where considered 

pixels (No data for instance) are set to 1 and the other to 0 

2/ set to zero the pixels indicated in the metadata of the data strip 

3/ check if pixels with data count (DC) equal to 1 subsist 

/*Input*/ 

Granule_list = Select randomly 12 numbers amongst (num_max of 

granule per data strip). 

No_Data_array= binary image derived from the granule image 

where No data pixels are set to 1 and other to 0 

Saturated_array= binary image derived from the granule where 

Saturated pixels are set to 1 and other to 0 

Defective_array= Binary image derived from the granule where 

Defective pixels are set to 1 other to 0 

For each selected granule 


/*Check possibly new No Data pixels*/ 

IF DC(granule_image) EQ DC of No Data THEN No_Data_array = 1 

ELSE No_Data_array = 0 

/*Check with information from data strip metadata*/ 

No_Data_array(No data pixel's position from Data strip metadata) = 

0 

/*Check if No data subsist*/ 

Perform No_Data_array histogram 

IF DC of 1 exist THEN 

ouput_No_Data =FAILED+ "New NO DATA pixels exist" 

(No_Data_array gives the location of the new No Data pixels)+ 

"+Position in No_Data_array where DC=1 

ELSE ouput_No_Data = PASSED+"No new No DATA pixels" 

Data Anomaly 

/*Check possibly new Saturated pixels*/ 

IF DC (granule_image) GT DCmax THEN Saturated_array = 1 

ELSE Saturated_array = 0 (Saturated pixels of the granule image 

are set to 1 in Saturated_array) 


Saturated_array(saturated pixel's position from Data strip metadata) 

= 0 

/*Check if Saturated pixels subsist*/ 

Perform Saturated_array histogram 

IF DC of 1 exist THEN 

ouput_Saturated =FAILED+"New saturated pixels exist" 

(Saturated_array gives the location of the new Saturated pixels)+ 

"+Position in Saturated_array where DC=1 

ELSE ouput_Saturated = PASSED+"No new Saturated pixels" 

/*Check possibly new Defective pixels*/ 


IF DC (granule_image) LT DCmin THEN Defective_array = 1 ELSE 

Defective _array = 0 (Defective pixels of the granule image are set 


to 1 in Defective_array) 

All rights reserved, 2012, Thales Alenia Space 


Defective_array(defecive pixel's position from Data strip metadata) = 

0




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 256 / 315 

Table 9: Pseudo-code for L1B product inspections (Table 8). 

Product 

Level 

L 1C 

Check 

Description 

Check of 


Tile Position. 

This check 

aims assess 

that the geoposition 

and 

the dimension 

of the tile are 

in line with the 

expected 

geometry 

TCI and PVI 

generic 

inspections 

ECMWF data 

conformity and 

completeness 

check 

Input Data 

(M): Metadata 


(F): File 

Geoposition 

ULX,ULY 

XDIM,YDIM 

Size 

NROWS 

NCOLS 

File size (F) 

ECMWF auxiliary data (F) 

Metadata 

Output 

Success Flag 


Success Flag 


Success Flag 


Inspection 

Type 

Metadata 

(simple) 

Data Payload 

Format 

Table 10: List of preliminary OLQC inspections for L1C product. 

Product 

Level 

Check 

Name 

Pseudo-Code 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 257 / 315 

Product 

Level 

Check 

Name 

Data to check= Geoposition 




Pseudo-Code 



output_geopositiont=PASSED 

ELSE 

output_geoposition=FAILED 

L 1C 

Tile 

position 

and size 

PVI & TCI 

Check 

Data to check= Size 





FOR each band 

IF 100+δ GE XDIMxNROW GT 100 km AND 

IF 100+δ GE YDIMxNCOLS GT 100 km 

output_size=PASSED 

ELSE 

output_size=FAILED 

IF output_geoposition=PASSED AND output_size=PASSED THEN 

output=PASSED ELSE output=FAILED 



WRITE output 

Data to check= PVI AND TCI 


READ size_of_DataFileName 


If size_of_DataFileName 

is GT 0 

THEN 

output=PASSED 

ELSE 

output=FAILED 



WRITE output 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 258 / 315 

Product 

Level 

Check 

Name 

ECMWF 

Check 

Data to check = ECMWF 



Pseudo-Code 


IF Data to check is present 

THEN 

output=PASSED 

ELSE 

output=FAILED 


Write name of checklist 

Write output 

Table 11: Pseudo-code for L1C product inspections (Table 10). 

Product 

Level 

All 

Levels 

Check 

Description 

Check on 

product 

components 

syntax and 

semantics 

correctness 

Check of 


datastrip ID and 

Imaging 

Start and Stop 

time w.r.t. the 

expected value. 

Input Data 

(M): Metadata 


(F): File name 

All PDIs (F) 

DATA_STRIP_ID (F) 

Metadata 

Output 

Success Flag 


Success Flag 


Inspection 

Type 

Format 

Format 

Table 12: List of OLQC preliminary inspections common to all product levels 

Product 

Level 

Check 

Description 

Pseudo Code 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 259 / 315 

Product syntax 

Data to check= Check on Product components syntax & 

semantics correctness. 


READ data_to_check= List of PDIs into the product 

All 

Levels 

/*Control operation*/ (Check PDIs are coherent with technical 

specification) 

IF number of PDIs EQ expected number of PDIs per products 

AND 

IF PDIs structure in line with technical specification (All defined 

PDIs shall be present) 

AND 

IF Semantics of PDIs in line with technical specification (name of PDIs 

is coherent) 

AND 

IF Size of each PDIs is in line with technical specification (each PDIs 

has a pre-defined size or within a defined range) 

THEN PASSED ELSE FAILED 



Write output 

Data_Strip_ID 

Check. 

Data to check= DATA_STRIP_ID AND 

START_TIME_DATA_STRIP_ID AND STOP_TIME DATA_STRIP_ID 




IF data_to_check is in line with technical specification (in terms of 

naming conventions defined in [PSD]) AND 

Start_Time_Data_strip_id LT Stop_time_ datastrip_id 

THEN PASSED else 

output= FAILED 



Write output 

Table 13: Pseudo-code for inspections common to all products (Table 12). 

3.3.2.2 Inputs 

PDI 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 260 / 315 

The inputs of the quality control activities performed by the OLQC-SC are the PDI 

generated by the IDP-SC (cf. § 2.1.4): 

L0c, L1A, L1B, L1C or TCI PDI-FE-GR and PDI-FE-ATF (images data, metadata, 

mask) for inspections at granule level (one or several granules) 

L0c, L1A, L1B or L1C PDI-FE-DS (metadata, masks) for inspections at datastrip 

level 

OLQC-GIPP 

The OLQC-GIPP includes the following information: 

The checklist to be performed (simple/basilar, informative, concluding) for each 

type and level of input (granule or datastrip, tile, image data or metadata). The 

checklists are grouped in thematic checks 

The name of the single check, specifying the type (simple, informative, 

concluding) 

The criteria, making a check is either passed or failed, shall be indicated 

(threshold, Data value range, additional info ) 

A field: "CheckCode" is mandatory to insert a new check (when the attribute of the 

check is set to "new"). According to the check type, the field "CheckDrbXsd" could 

be necessary (i.e. a DRB schema to be specified) 

A field specifying the directory to store the report files related to a checklist: The 

three possible options are QI_DATA (for informative or concluding check), MPC 

(basilar or sample check) or BOTH. 

The OLQC-GIPP xml schema is defined in [CICD-IPF]. 

Amalfi-2 Add ons Tailoring 

In order to perform the quality check, OLQC-SC uses Amalfi-2 software as a standalone 

Java processor [AMALFI-SUM]. It can be run using regular command 

arguments (e.g. java -jar --submit --output , --shutdown) 

Globally Amalfi-2 stand-alone configuration is driven by the following inputs:: 

The path of the product to inspect 

The location of the output reports 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 261 / 315 

The DRB schemas related to the product to inspect 

The inspections definitions 

The DRB schemas and inspections definitions required to create Amalfi "add-ons" 

are specified in two separate JAR files: 

One containing the DRB schemas, i.e. creating a schema with the 

Structured Data File (SDF) annotations [AMALFI-SUM]. 

One containing the Amalfi-2 inspections, i.e. creating the ontology file 

(OWL file) that allows DRB API assigning automatically the schema to the data. 

The Amalfi-2 User Manual [AMALFI-SUM] and the examples delivered within Amalfi 

CFI provide the instructions how create an add-on. 

3.3.2.3 Outputs 

The outputs of the OLQC-SC will be a XML report with quality control checks, created on 

the basis of the Amalfi-2 output reports for each check list. An XML schema for OLQC 

report is provided in [CICD-IPF]. 

The Metadata quality control checks will be organized according to the product logic (cf. 

[PSD] in order to report the inspection results at two different levels: 

Product / Data-strip level; 

Tile / Granule level; 

3.3.3 Requirements 



The OLQC-SC shall be able to inspect a Sentinel-2 data strip at different levels: Level 0 

consolidated Level 1A, Level 1B or Level 1C. 

Parents: S2-PDGS-SYS-310, S2-PDGS-SYS-315, S2-PDGS-SYS-320, S2-PDGS-SYS-330, S2-PDGS-SYS-335 


The OLQC-SC shall be able to inspect a single or several Sentinel-2 granules (or tiles for 

Level 1C) at different levels: Level 0 consolidated, Level 1A, Level 1B or Level 1C. 

Parents: S2-PDGS-SYS-310, S2-PDGS-SYS-315, S2-PDGS-SYS-320, S2-PDGS-SYS-330, S2-PDGS-SYS-335 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 262 / 315 


The interfaces between the OLQC-SC and DPC shall be compliant with the definitions 

given in [CICD-IPF]. 

Parents: S2-PDGS-OLQC-010, S2-PDGS-OLQC-015, S2-PDGS-OLQC-095, S2-PDGS-OLQC-110, S2-PDGS-OLQC-120, S2-PDGS- 

OLQC-135 


The OLQC-SC shall log in real time each item inspected resulting in a global failed status. 

In case of failed status, a log message shall summarize the reason of the failed status and 

the log message text shall start with the OLQC_RESULT keyword in order to allow the 

DPC identifying those messages. 

Parents: S2-PDGS-OLQC-050, S2-PDGS-SYS-335, S2-PDGS-M&C-030, S2-PDGS-M&C-055 


The OLQC-SC shall be able to read and process any field of the Sentinel-2 product 

structure to perform the quality control checks. 

Parents: S2-PDGS-OLQC-055, S2-PDGS-SYS-310, S2-PDGS-SYS-315, S2-PDGS-SYS-320, S2-PDGS-SYS-330, S2-PDGS-SYS-335 


The OLQC-SC shall allow the configuration of quality checks to perform (i.e. perform a 

check or not) and the rules associated (i.e. range value, threshold, etc.). 

It shall accept several possible options according to the characteristics/specificities of the 

inspected data. 

Note: Example of variable fields: 

format; 

size; 

date and time of acquisition… 

Parents: S2-PDGS-OLQC-020, S2-PDGS-OLQC-060 


The OLQC-SC shall allow the configuration of quality checks based on the results of other 

lower-level checks. 

Parents: S2-PDGS-OLQC-070 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 263 / 315 

Note: for instance, the data-strip global status (Passed or Failed) depends on the results of 

each granule composing the data-strip; it can be Failed if a single granule has Failed, or if 

the percentage of granules in Failure is greater than a threshold… 


The OLQC-SC shall be remotely configured through the OLQC-GIPP. 



The OLQC-GIPP configuration shall contain: 

The checklist to be performed (simple, informative, concluding) for each type and 

level of input (granule or datastrip metadata, tile, image data). The checklist are 

grouped in thematic. 

The name of the single check, specifying the type (simple, informative, concluding) 

The criteria, making a check is either passed or failed, shall be indicated (threshold, 

Data range value, additional info) 

A field: "CheckCode" is mandatory to insert a new check (when the attribute of the 

check is set to "new").According to the check 's type , the field "CheckDrbXsd" could 

be necessary 

A field specifying the type of destination for each checklist: Three possible options 

are QI_DATA (for informative or concluding check), MPC (basilar or sample checks) 

or BOTH. 



If the parameter of the checklist indicates "QI_DATA", the OLQC-SC shall write the XML 

report in the QI_DATA directory of the PDI product. 

If the destination parameter indicates "MPC" the OLQC-SC shall write the report in the 

MPC directory specified in the Job Order file. 

If the destination parameter indicates "BOTH", the OLQC-SC shall write the report in the 

MPC directory specified in the Job Order file and in the QI_DATA directory of the PDI 

product. 

Parents: 


The OLQC_SC shall allow configuring and managing the different quality control checks 

as a set of checklists, each one defining one or more checks to be applied on a given 

product component or set of components. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 264 / 315 



The OLQC-SC shall be able to apply identical checks defined in a GIPP file to the different 

types of inspected data 


Note: Example of checks is: 

 

quality checks on the headers; 

 

 

data formats; 

range checks. 


The OLQC-SC shall be able to apply specific checks for each type of inspected data. 



The OLQC-SC shall allow applying one or more distinct checklists on every type of PDI by 

configuration. 



The list of check shall be grouped in thematic check lists. Each one defined and uniquely 

identified in the OLQC_GIPP 



The sample /basilar checks are subject of separate sample/basilar checklists. 


Reference S2PDGS-IPF-TRD-REQ-499-a : 

If the type of checklist is "Concluding" or "Informative" and the result of the xml report is 

"FAILED" the report shall be stored in both QI-DATA and MPC directories specified in the 

JobOrder file in order to allow the DPC to send the FAILED report to MPC for further 

analysis 

Parents: 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 265 / 315 

The OLQC-SC shall create an XML report for each datastrip or granule including: 

the name of the cheklist 

the version of the checklist; 

the name of GIPP-OLQC definining the cheklist and its inspections 

The name of inspected data (data strip identifier or granule identifier) 

The global (at data strip or granule level) quality check result: Passed or Failed; 

for each unitary check, the check identification and the check result: Passed or 

Failed; 

Parents: S2-PDGS-OLQC-025, S2-PDGS-OLQC-030, S2-PDGS-OLQC-035, S2-PDGS-OLQC-040, S2-PDGS-OLQC-045, S2-PDGS- 

SYS-165 


The OLQC-SC shall create one individual XML report file per Checklist 

Parents: 


The OLQC-SC shall finally consolidate a summary pass/fail status at the term of each 

checklist processing stating whether all the configured concluding checks have "passed" 

or whether at least one has "failed". The summary status will be systematically set in the 

xml report. 

Parents: 


The OLQC-SC shall be able to inspect a granule or a set of granules of each product level 

(at least 10 granules). 

Parents: 


The OLQC-SC shall be able to define and manage independent checklist configurations 

applicable to Sentinel-2A data, to Sentinel-2B data or to both, by configuration. 

Parents: S2-PDGS-OLQC-090, S2-PDGS-SYS-860 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 266 / 315 

The OLQC-SC shall apply all the quality controls for L0 consolidated product as described 

in Table 4. 



The OLQC-SC shall apply all the quality controls for L1A product as described in Table 6. 



The OLQC-SC shall apply all the quality controls for L1B product as described in Table 8. 



The OLQC-SC shall apply all the quality controls for L1C product as described in Table 10. 



The OLQC-SC shall apply all the quality controls for all products as described in Table 12. 



The OLQC-SC shall transform OLQC GIPP files according to the needs of Amalfi software. 

Parents: 


The OLQC-SC shall configure Amalfi every time an OLQC-GIPP is modified. 

Parents: 


The OLQC-GIPP shall allow introducing a new check in a checklist already defined. The 

new check will be a piece of code defined in the OLQC-GIPP that shall be handled by the 

OLQC-SC to update the inspection list performed by Amalfi. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 267 / 315 


The OLQC-SC shall manage the update of the criteria on which the check is based (range 

of value or threshold present in the OLQC-GIPP) 

Parents: 


The OLQC-SC shall transform reports generated by Amalfi software in the product quality 

control check information. 

Parents 









OLQC-SC performed at Datastrip level (whatever the product level: L0c, L1A, L1B or L1C) 

shall process, on a single-core CPU with hardware equivalent to the Reference Platform 

one, a datastrip equivalent to 20 minutes of downlink in less than 20 seconds. 



OLQC-SC performed at Granule level (whatever the product level: L0c, L1A or L1B) shall 


datastrip equivalent to 10 minutes of downlink in less than 1h50 minutes. 


Reference S2PDGS-IPF-TRD-REQ-559 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 268 / 315 

OLQC-SC performed at Granule level (whatever the product level: L0c, L1A or L1B) shall 


datastrip equivalent to 20 minutes of downlink in less than 3h40 minutes. 


Reference S2PDGS-IPF-TRD-REQ-560 

A single execution of OLQC shall process, on a single-core CPU with hardware equivalent 

to the Reference Platform one, 12 granules (whatever the product level: L0C, L1A or L1B) 

in less than 36 seconds. 




to the Reference Platform one, 15 granules (whatever the product level: L0C, L1A or L1B) 

in less than 45 seconds. 




to the Reference Platform one, a L1C tile in less than 20 seconds. 




The OLQC-SC shall run in an autonomous manner, i.e. without any operator intervention 

once triggered (by the DPC or IDP-Orchestrator). 



When the OLQC-SC finishes not nominally, it shall return an error message indicating the 

reason of the error. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 269 / 315 





The OLQC-SC shall be able to perform simultaneous data processing activities issued 

from distinct directives on the same hardware or on different hardware without 

interference. 



The OLQC-SC shall use Amalfi-2 software provided as a CFI by the Agency to perform the 

quality checks. 



The OLQC-SC specific product quality checks shall be performed using Amalfi-2 as standalone 

processor. 


Note: Amalfi provides add-ons mechanisms to add inspection and mission's extensions. 


The OLQC -SC shall allow specific quality checks using Amalfi add-ons capability. 



The OLQC-SC design shall allow the parallel execution of different instances of the same 

task or different tasks on the same HW. 



The OLQC-SC design shall allow performing quality checks on a new Sentinel-2 product 

structure by re-configuration. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 270 / 315 

Note: a change of Sentinel-2 product specification shall not require an update of OLQC 

software (no compilation). 


Not applicable. 










3.4 IDP-Orchestrator specific requirements 


In order to test the complete workflow, the IPF also includes the development of the IDP- 

Orchestrator that allows testing the end-to-end processing in isolation from the DPC. The 

IDP-Orchestrator software component will be able to trigger each IDP-SC and OLQC-SC 

individually or as a set of chained IDP-SC and OLQC-SC in a logical sequence. 

The Figure 28 shows the interfaces related to the IDP-Orchestrator: 

Interfaces with IDP-SC & OLQC-SC 

Interfaces with an Operator (HMI) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 271 / 315 

Interfaces with Task Tables 

Interface with local storage 

Operator 

Task Table 

Task Table 

Execution 

orders 

Execution 

status 

Task Table 

Job Order 

Processing Configuration 

IDP 

Orchestrator 

IDP-SC orchestration 

Start/Stop 

Logging 

Product Report 

Exit Code 



Input PU 

IDP-SC 

IDP-SC IDP-SC 

or 

OLQC-SC 

Ouptut PU 

PDIs input/outputs 

Auxiliary/Ancillary data 

Intermediate PDI-PU 

Aux/Anc data 

IPF Workflow PDIs 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 272 / 315 

Figure 28: IDP-Orchestrator interfaces for the stand-alone configuration. 

The interfaces with IDP-SC and OLQC-SC are the same as between DPC and IDP- 

SC or OLQC-SC. 

The interface with an Operator will allow to manually run each IDP-SC and OLQC- 

SC individually or chained. This HMI includes: 

A Start/Stop interface to launch the IDCP-SC or OLQC-SC; 

An Orders XML file interface to select and configure the IDP-SC or OLQC-SC to 

launch; 

The same Product Report, Exit Code and Logging interfaces as between the IDP- 

Orchestrator and IDP-SC or OLQC-SC; 

The interface with Task Tables XML file as defined in [GEN-PDGSIPF]; 

The interface with a local storage device for Input and Output data management. 

The launch of an IDP-SC or OLQC-SC by the Operator HMI (graphical user interface) will 

be operated through the following sequencing: 

1. Selection of a Task Table among a list of available Task Tables, allowing to activate 

an individual IDP-SC, or the OLQC-SC, or a set of IDP-SC and OLQC-SC chained 

for processing 

2. Activation of the processing by the operator and monitoring of execution 

a. The Start/Stop interface consists for the Operator in executing a command 

file with an Orders interfaces as argument 

b. The Orders XML file will indicate to the IDP-Orchestrator which Task Table to 

select from the local storage. 

c. The IDP-Orchestrator will instantiate a set of Job Order XML files (one for 

each IDP-SC or OLQC-SC) from the Task Table file 

d. The IDP-Orchestrator will start the IDP-SC or OLQC-SC thanks to the Start 

interface (command line with a Job Order as argument) 

e. The IDP-SC or OLQC-SC will start the processing and Logging. The Logs 

will be forwarded by the IDP-Orchestrator to the Operator through the 

Logging Interfaces. 

f. At any time, the Operator can kill the running process with the Stop interface 

command. This command will be forwarded by the IDP-Orchestrator through 

the Stop interface to the running IDP-SC or OLQC-SC 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 273 / 315 

3.4.2 Requirements 

g. At the end of execution, each IDP-SC and OLQC-SC will generate a Product 

Report file that will be forwarded by the IDP-Orchestrator up to the Operator. 

h. An Exit code will be returned and forwarded by the IDP-Orchestrator up to 

the Operator 



The IDP-Orchestrator shall allow running the end-to-end processing chain of each product 

generation by chaining the required set of IDP-SC and OLQC-SC. 

Particularly, the IDP Orchestrator shall be used by the IPF Contractor for integration 

testing, covering at least the following scenarios (by comparison and validation versus 

RTDS data): 

end to end processing from L0 to L1C (including L0c, L1A, L1B products) 

end to end reprocessing from archived L0c to L1C (including L1A and L1B 

products) 

L0c from L0 processing, L1A from L0c processing, L1B from L0c, L1C from L1B 



The IDP-Orchestrator shall allow running each of the IDP-SC and OLQC-SC for testing, 

verification and validation purpose in isolation from the rest of the PDGS. 



The interface between IDP-Orchestrator and IDP-SC or OLQC-SC shall comply with the 

interfaces defined in [CICD-IPF]. 

Parents: S2-PDGS-IDP-030, S2-PDGS-IDP-045, S2-PDGS-IDP-050, S2-PDGS-IDP-055 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 274 / 315 



The IDP-Orchestrator shall provide a graphical user interface for Task Table selection, 

activation and for IDP-SC and OLQC-SC execution monitoring. 

Parents: 





The IDP-Orchestrator shall run on the same Hardware platform (the so-called Reference 

Platform defined in §2.2) and Operating System as targeted for the IDP-SC or OLQC-SC 

development. 

Parents: 


The interfaces between the IDP-Orchestrator and IDP-SC or OLQC-SC shall be the same 

as between the DPC and IDP-SC or OLQC-SC. 

Parents: 


Not applicable. 










Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 275 / 315 










Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 276 / 315 

4. COMMON REQUIREMENTS 

This section introduces the main interaction of the Developed Software Component with 

the Common Services, Basic Services and Reference Platform components. Constraints 

from “common/basic/RP” components have been identified and translated into 

requirements. These requirements have been adapted to each SW Component and 

completed by more general requirements. 

R e la t i o n t o o t h e r c o m p o n e n t s ( e g . C o r e C o m p o n e n t s & C F I s ) 

S W 

C o m p o n e n t 

C o m m o n S e r v ic e s R e f e re n c e P la t f o r m B a s i c S e rv i c e s 

D C 

M & C 

S W c o n f 

M a n a g t 

A n o m a l i e s 

M a n a g t 

D N S 

T IM E 

M C C 

S W b u i l d 

M a n a g t 

A c ti o n s 

M a n a g t 

L O G 

M a n a g t 

A c c e s 

R i g h t s 

S W p a c k 

B u i l d 

D o c s 

M a n a g t 

A n t i V i r u s 

B a c k U p 

S W 

D e l i v e r y 

H W C o n f 

M a n a g t 

D e p l o y 

S e r v i c e 

H W 

I n v e n t o r y 

R P 

D e p l o y 

R P 

T e s t / S i m u 

The following requirements have been characterized: 

 

 

General requirements including: 

- High Level requirements 

- Software Quality requirements 

- Coding Standards requirements 

- Data types and encoding rules requirements 

- HMI requirements 

- Testing requirements 

Common Services constraints requirements including: 

- Data Circulation constraints requirements (coming from DC component) 

- M&C constraints requirements (coming from M&C component) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 277 / 315 

Reference Platform constraints requirements including : 

- Software configuration constraints requirements (coming from RP component) 

- Software building constraints requirements (coming from RP component) 

- Software packaging constraints requirements (coming from RP component) 

- Software delivery constraints requirements (coming from RP component) 

Basic Services constraints requirements including : 

- Network/DNS constraints requirements (coming from BS component) 

- Logging constraints requirements (coming from BS component) 

- SW Deployment Service requirements (coming from BS component) 

- Access rights constraints requirements (coming from BS component) 

- BackUp constraints requirements (coming from BS component) 

Note that because of Software re-use some common requirements could be not applicable 

or partially applicable (with adaptation and/or limitation). This is justified in a dedicated 

table at the end of this section. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 278 / 315 

4.1 General requirements 

4.1.1 High Level requirements 

REFERENCE S2PDGS-IPF-COM-TRD-REQ-005 : 

LINUX Red Hat version 6 and higher shall be used as the Operating System. 

Parents: 


The new component version shall provide a script/shell commands allowing to : 

Start it with option for coherency verification. For instance: availability for auxiliary 

files, accessibility of required database, etc... 

Soft shutdown the running instance: the running tasks are fully executed and the 

context is recorded. 

Hard shutdown the running instance in case of failure of the previous step : the 

running tasks are killed. 

Define new version as current version. 

Launch current version (with coherency checks in case of hard shutdown). 

Parents: 


The component shall provide a command/script (eg. component_name.sh) with the 

following possible arguments: 

version reports the current component version number, 

status : reports the component application software status as follows : 

stopped, running nominally, running degraded (with diagnostic), 

start : starts the application, 

stop : stops the application cleanly, 

abort :stops the application immediately, come what may, 

clean : restores the component data spaces to a state from which the 

application can be restarted, 

Parents: 


The components shall be able to use secured mechanisms provided through commercialbest-practice-technology 

to support sensible information exchange internally or among its 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 279 / 315 

distributed sites and external interfaces (e.g. with the FOS) (e.g. VPN, peer-to-peer 

encryption, https). 

Parents: S2-PDGS-SEC-010 


The design and configuration of the components shall be in-line with the CIS security 

guidelines in terms of operating-systems and reused software (e.g. of-the-shelf software 

commercial or public domain). 


Comment : The CIS provides Internet security benchmarks based on recognized 

best practices for deployment, configuration, and operation of networked systems 

(http://www.cisecurity.org). 


The design of the components shall allow adapting to software and hardware evolutions 

(e.g. OS system upgrade to minor/major release) : 

 

 

in a controlled cost manner (it means providing evolutivity) 

without unacceptable negative impacts on operations during the upgrade activities. 



The components shall perform preliminary consistency checks over the data received at 

their input interface before using or forwarding the data to external entities of S2 PDGS 

System. 



The components exposed to the public Internet shall have enabled and configured an 

host-based firewall according to the defined and implemented network access control 

measures. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 280 / 315 


Explicit confirmation shall be requested before command execution of all critical or 

time/resource consuming activities. 



The component shall use the S2-PDGS File Name Convention as defined in the ICDs 

Parents: 

4.1.2 Software Quality Requirements 

S2-PDGS being a software intensive system, ECSS-E-ST-40C and ECSS-Q-ST-80C are 

applicable to the engineering and PA processes of the project, according to the tailoring 

matrices provided in “Product Assurance Requirements, Annex 2 ref. GMES-GSEG- 

EOPG-RQ-09-0012, Issue 1, Rev 0”. 

The software quality requirements (including S2-PDGS-IVV-030) are already covered by 

ECSS-Q-ST-80C. No extra requirements have been identified. 

4.1.3 Coding Standards Requirements 

As required by ECSS, the software components will follow the coding standards of the IPF 

Contractor's company. 


The JIRA Anomaly number shall be clearly identified into the software source code when it 

has been corrected. Each source code file shall begin with a comment cartridge. This 

cartridge shall have an history part. Each correction shall be registered in the history part 

with its JIRA anomaly number. 

Parents: 

Note that coding standards shall be provided by the SW supplier company. 

4.1.4 Data types and encoding rules Requirements 


Data structures used at the interface shall be registered in the DDT tool 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 281 / 315 


The facility shall rely on the output of the DDT tool for their interface data structure 

encoding implementation. 

Parents: 


Facility configuration files shall be designed as ASCII data structure (eg. XML, XSD, …) 

and follows the corresponding encoding rules. 

Parents: 


Unless constrained by an external interface specification, ASCII structure shall be encoded 

following the XML standards 

Parents: 

4.1.5 HMI Requirements 

This section is only applicable for components providing an HMI (including a Web 

Interface) 


English language shall be used for information displayed. 



The following information shall be provided for the HMIs: 

Monitoring of on-going activities by progress bars or equivalent indicators able to 

provide elapsed & estimated completion times 

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

Preliminary syntax checks for data insertion 

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

Multiple window display 



Random movement through fields 

Context-sensitive menus 

Context-sensitive help 




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 282 / 315 



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

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

process has been initiated. 



The different provided HMIs shall provide privileged operators with an interactive capability 

to execute privileged operations possibly violating constraints/rules/criteria nominally 

forbidden to other operators. 


4.1.6 Testing and IV&V requirements 


All PDGS elements shall be available as stand-alone systems and accessible for testing 

purposes through a well defined interface protocol and HMI. 



The component shall provide a test harness that allows to perform testing of all the 

functionalities and all interfaces of the component as well as to support acceptance testing 

Parents: 


The test harness shall include the following tools: 

Test data preparation tools (TDP) 



Test data generation tools (TDG) 

Test data analysis tools (TDA). 




Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 283 / 315 

Parents: 


It shall be possible to perform end endurance testing at component and/or service level 

over a continuous period of 24 hours. 

Parents: 


The component test tools shall allow error situations simulation including data loss, 

corruption disconnection and reconnection. 

Parents: 


The S2-PDGS testing activities of every service/ components shall include regression tests 

in order to ensure that new upgrades will not impact the existing operational or already 

validated S2-PDG functionalities. 

Parents:S2-PDGS-IVV-040 


Regression testing of every service/components shall be designed to minimise human 

intervention as much as possible. 



The test specifications of every Centre/Services (TSPE) shall be supported by the 

definition of coherent and meaningful test scenarios (to be separately documented in the 

TSC), each one defining the testing environment and simulated input/output conditions 

necessary to cover the objectives of the testing. 



The definition of the different test scenarios of every service shall aim at rationalising the 

testing and minimising the test data generation effort by combining the usage of 

compatible scenarios for different tests. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 284 / 315 


The testing and in particular the test scenarios of every service -defined in the different 

Test Scenario Catalogue- shall allow the verification of every aspect of the S2-PDGS 

requirement at service/component level and operation baseline including at minimum: 

Functional aspects; 

Performance aspects; 

Endurance aspects; 

Error/contingency handling and recovery aspects; 

Operational usability aspects. 



Every test scenario defined in the dedicated Test Scenario Catalogue, shall define 

complete and coherent requirements on every needed Test Data Sets (e.g. needed 

sensing time correlation between data sets, specific features, etc) according to the specific 

needs specified in the TSPE of each test to be supported by the scenario. 



The Test Scenario Catalogue of every service shall be self-standing in providing all the 

necessary information allowing the generation/selection of the test data required in support 

of the testing. 



Every Test Data Set generated as part of IV&V activities shall be fully described in the 

different Test Data Catalogue with the following information (in relation to the Test 

Scenario Catalogue) : 

Test Data Set characterisation according to its nature (e.g. detailed mission timeline, 

specific features with detailed timings, relationships between TDS elements, etc); 

Test Data Set logical decomposition (e.g. auxiliary data, instrument data, time 

sequencing, etc); 

Test Data Set physical decomposition (i.e. directory and file names); 

Any other information required to install and use the Test Data Set. 



All Test Data Set, including simulated and real spacecraft and instrument data, shall be 

validated before their usage for testing activities. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 285 / 315 


The S2-PDGS testing for services/components shall support epoch settings with 

meaningful data for future/past time scenarios execution. 



The S2-PDGS testing for services/components shall allow interruption/resume of the test 

execution at logical breakpoints. 



Every anomaly observed during the testing activities shall be logged as a SPR and figure 

in the related Verification Report as reference. The criticality of SPRs shall be classified 

according to the criteria defined in Table 4-7 of the [STCD]. 



All SPR occurrences shall trigger a system correction action to the Component supplier 

following a swift preliminary investigation and confirmation of the problem source. The 

resolution of the reported problems shall be tackled in descending order of criticality 

(BLOCKING, MAJOR and MINOR). 



The test cases and test procedure statuses shall be classified according to the criteria 

defined in Table 4-5 and Table 4-6 of the [STCD] respectively. The statuses are 

systematically reported and maintained in the VDB. 



All S2-PDGS Components/Services shall be tested against [OCD] and [SRD] for the dual 

spacecraft constellation. Consequently and to cope with the phased S2-PDGS 

deployments regarding hardware sizing, the test scenarios (either for verification and 

validation phases) prior to the launch of Sentinel-2A shall cover the following aspects: 

Functional validation 

Performance validation according to the baseline operation scenario with S2A unit 

only; 

Performance validation with the baseline configuration to serve both units in 

compatibility with the hardware sizing deployed for the single Sentinel-1A unit (e.g. 

halving the relative operations over the S2A and S2B data flows in the simulated 

scenario) 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 286 / 315 



The applicable verification method associated to each service or centre requirement shall 

be defined in the related VCD according to the classification reported in Table 4-1 of the 

[STCD] 


REFERENCE S2PDGS-IPF-COM-TRD-REQ-460 a : 

The S2-PDGS IV&V activities shall be organised following an incremental strategy 

structured along a two levels bottom-up hierarchy towards end-to-end testing : (1) at 

Component level, and (2) at Upper-level (assembly of several S2-PDGS Components). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 287 / 315 

4.2 Common Services constraints requirements including: 

4.2.1 Data Circulation constraints requirements (coming from DC component) 


Component shall comply with Implicit Circulation interface, as specified in [DI-ICD-CS]. 

Dedicated transfer areas for circulation shall be identified. 

Parents: 


All directories to be used for data transfers by DC agent shall be configurable. 

Parents: 


Any node requiring DC services, shall allow installation on it of the DC agent, including the 

packages necessary for its functioning (e.g., Postgres, PHP), as specified in [DI-ICD-CS]. 

Parents: 


Any node requiring DC services shall provide the standard protocols that shall be used by 

the DC, according to the type of service requested, that is: 

File Transfer Protocols (SFTP, FTP, FTPS) 

Web Transfer Protocol (HTTP, HTTPS). 

Parents: 


Any node requiring DC media circulation services shall provide the hardware support for 

the media circulation, that is: 

USB ports (for USB HD) 

(TBC) Tape driver (for LTO) 

According to [DI-ICD-CS] 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 288 / 315 


Any node requiring DC services shall provide short-term storage capabilities to support the 

data circulation, sized according to the amount of data to be transferred in 1 hour (TBC) or 

to 300 GB (TBC), whichever the largest. 

Comment : 

The 300 GB limit is calculated as per DC requirements, that ask for the capability to hold in 

parallel 5 transfers of files bigger than 60 GB 

Parents: 


Any Linux node requiring DC services shall provide a kernel version delivering the inotify 

function. 

Parents: 

4.2.2 M&C constraints requirements (coming from M&C component) 


The log files to be exchanged or monitored with the M&C component shall be in syslog 

format, with the extension provided by M&C (Monitoring & Control) specific interface, as 

specified in the Common Services ICD ([DI-ICD-CS]). 

Parents: 


Logfiles to be exchanged with the M&C component shall contain the following fields, 

according to M&C interfaces specifications set forth in [DI-ICD-CS]: 

Fully qualified source process (i.e., including service, component, name, pid) 

Severity 

Date and time 

Status 

Other (refer to [DI-ICD-CS]) 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 289 / 315 


Any node to be monitored and controlled by M&C, shall allow installation on it of the M&C 

agent, including the packages necessary for its functioning (e.g., Postgres, PHP), as 

specified in [DI-ICD-CS]. 

Parents: 

REFERENCE S2PDGS-IPF-COM-TRD-REQ-175 a : 

Any network device, hw server and workstation to be monitored M&C shall be configured 

to have the snmp daemon started at boot time. 

Parents: 


Components shall provide a script, with interface compliant to applicable [DI-ICD-CS], that 

when invoked shall completely carry out, according to the parameter received in input: 

Start of the component/service 

Ordered shutdown (shutdown after completing on-going operations) of a 

component/service. 

Abort (immediate shutdown) of a component/service 

Parents: 


Components shall periodically send to the M&C, according to the interface method 

selected and specified in [DI-ICD-CS], an overall service status. The status shall be sent at 

least in the following circonstances : 

Start of the component/service 

Shutdown 

 

 

Change from functioning to degraded/failure mode 

After expiration of a configurable amount of time or after completion of a meaningful 

amount of work 

Parents: 


Components design shall provide the following information, to be used to complete the 

relevant section of the [DI-ICD-CS] ICD: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 290 / 315 

 

 

Definition of the alarms and warnings that shall be notified to, and acknowledged 

by, the operator 

Definition of a minimum set of parameters to be displayed in the M&C console 

synoptics, in order to assess proper functioning of the component/service. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 291 / 315 

4.3 Reference Platform constraints requirements including : 

4.3.1 Software configuration constraints requirements (coming from RP component) 


Configuration files shall be designed as ASCII data structure, use of XML is advised. 

Parents: 


Each component software shall comply with the rules described in the document “Product 

Assurance Requirements, Annex 2 ref. GMES-GSEG-EOPG-RQ-09-0012” in order to 

provide configuration files describing the roles and applications / functions. 

Parents: 


For every facility, the two different configurations : Integration configuration and 

Operational (RPM) Configuration shall be clearly identified to facilitate the deployment 

during the IVV activities and deployment. 

Parents: 


Each component software shall deliver all the generation procedures (User Manual or 

Installation Manual) including the configurations packages (spec files for RPM 

Configuration). 

Parents: 


Deliveries shall allow the build on a separate platform from the installation target i.e. the 

delivery tree and the execution tree can be on separate machines. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 292 / 315 

4.3.2 Software building constraints requirements (coming from RP component) 


For every software component, all the Internal and External dependencies shall be 

provided and identified in the design document: 

Libraries source code (in rpm format with version) 

Libraries binary code (in rpm format with version) 

Licences (for Build and Run Time environments) 

Note : Any exception shall be clearly justified and agreed with the TAS 

Parents: 


The delivery package shall be self-content and not dependant of the component 

development environment (no hard-coded path in the source code or in the generation 

procedure). 

Parents: 


The building process shall be automatic without any human interaction. 

Note : All necessary parameters/questions shall be set up into a configuration file at the 

beginning of the code generation. 

Parents: 

4.3.3 Software packaging constraints requirements (coming from RP component) 


Delivery shall be performed with separate RPM package files: 

one package for source files (including the build script to generate the binary package) 

one package for binary (including the script to deploy the package on a target machine) 

one package for configuration files 

one package for tests (test tools, simulators, test data, test stubs, test scripts,…) 

The configuration files package and the tests package shall be delivered only in case of 

significant changes. 

Note: Those four packages can be seen in different versions : 

The component is under provider control 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 293 / 315 

The component configuration can be managed and customized by the 

integration/operational team 

Parents: 


The packages shall be delivered with all their RPMs dependencies provided separately in : 

source code format 

and binary format 

Parents: 

4.3.4 Software delivery constraints requirements (coming from RP component) 


The components shall be remotely accessed by WAN function for warranty support or 

maintenance purposes. 

Parents: S2-PDGS-NET-125 


The activation of a specific component version shall be made using links in order to have 

an easily update of the various directories to the latest release generated. Cf. Figure 1-1. 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 294 / 315 

Figure 29: Way for activation of a component 


The packaging shall permit to deploy several versions of the same component (application 

software or configuration): 

 

 

a single version is active at the same time, 

a mechanism shall permit to select the active version. 

Parents: S2-PDGS-RP-145, S2-PDGS-SYS-800, S2-PDGS-SYS-805 


The packaging shall permit to define a configuration for each component and for each 

centre. 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 295 / 315 

A mechanism shall permit to upgrade data (database, …) of a component from a version 

to another one. 



The packaging shall permit to choose the target folder. No full path shall be hard- coded. 

Parents: 


The run-time environment of the facilities has to be made of the following directories: 

bin: to contain the binary files 

lib: to contain the libraries 

scripts: to contain the executables scripts to launch the different functionalities of 

the dedicated software 

conf: to contain the configuration files 

data: to contain the retrieved and locally generated data 

logs: to contain the log files generated by any script 

docs: to contain the documentation for the command lines and theirs parameters 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 296 / 315 

Figure 30: Facility run-time overview 


For every facility delivery, a Release Note shall be joined. It has to be entered in JIRA and 

has to contain: 

Names of added, modified and removed files. 

All the dependencies (Build and Run Time) 

Description of the Build process 

Checksum 

Script for migration of all the old databases to the new one. 

Reported/corrected anomalies 

Parents: 

Note : Template of the Release Note could be provided in order to automatize the import 

of listed information 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 297 / 315 

4.4 Basic Services constraints requirements including : 

4.4.1 Network/DNS constraints requirements (coming from BS component) 


No IP address shall be hard-coded 

Parents: 

4.4.2 Logging constraints requirements (coming from BS component) 


English language shall be used for logs produced. 



All the logs shall be referenced in Annex of the related CCSUM (Core Component 

Software User Manual) for every component. 

Parents: 


The log files shall be respected according to the following format: date –criticity –msg 

Date shall respect the ISO 8601 format 

Criticity shall be Error or Warning or Info or debug 

Parents: 


Comprehensive debug messages have to be included in every component. The objective 

is to facilitate the debug. 

Parents: 






Specification 


The debug log shall be able to be switched on/off. 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 298 / 315 

Parents: 

Packages 

repository 

RP 

Package 

building 

PDMC 

Miroring 

Package 

request 

Package 

request 

Deployment Pack 

(OS, components) 

Mirored 

Packages 

repository 

Station for 

Deployment 

CENTRE 

Target 

node 

4.4.3 SW Deployment Service requirements (coming from BS component) 

The remote installation will allow to remotely install operating system and components in 

every centre. The packages (.RPM) planned to be first produced in the Reference 

Platform, using the RP Core functions (cf. CCTS Reference Platform, ref. S2-PDGS-TAS- 

DI-CCTS-RP). Then, they will be transferred in a dedicated repository (the place where the 

package is made available). 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 299 / 315 

Packages 

repository 

RP 

Package 

building 

PDMC 

Miroring 

Package 

request 

Package 

request 

Deployment Pack 

(OS, components) 

Mirored 

Packages 

repository 

Station for 

Deployment 

CENTRE 

Target 

node 


The installation process shall be automatic without any human interaction. 

Note : All necessary parameters/questions shall be set up into a configuration file at the 

beginning of the code generation. 

Parents: 


Install of the components shall to be possible remotely. 

Parents: 


The remote installation of a component shall produce a log, in order to ensure the success 

of the operation. 

Parents: 


It shall be possible to install component software while another instance is running. 

Parents: 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 300 / 315 

4.4.4 Access rights constraints requirements (coming from BS component) 


The component shall implement access control mechanisms to any information held inside 

the S2 PDGS according to the access restriction applicable to the information. 



The components shall include the functionalities to record system activity and security 

relevant events including the relationship between user actions and system activity 

(logging) for minimum 6 months. 



The components shall be designed to require positive confirmation of the user/operator for 

dangerous commands or the erasure of important data files. 



The components shall allow the restriction of access to all its archived data based on user 

authentication and authorisation mechanisms. 



The components shall run with the necessary minimum level of privileges (standards 

operator with write access when necessary) and be designed to access the necessary 

minimum information and resources needed to its legitimate purpose (least privilege 

principle). 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 301 / 315 


The components shall implement well-defined access control measures at the level of 

network, system, application and data. 



The components shall not embed any hard-coded root and/or administrative passwords. 



The components shall handle all S2 PDGS users related information according to : 

EU directives on privacy (Regulation EC No 45/2001) 

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


4.4.5 BackUp constraints requirements (coming from BS component) 


The components shall apply a well-defined back-up strategy for operating system 

configuration, applications and data. 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 302 / 315 

4.5 Common requirement deviation 

This section justifies the common requirements deviation 

Common 

Id 

Requirement 

Compliance 

status 

(C,PC,NC,NA) 

C 

Clarification and Justification for the 

deviation 

S2PDGS-IPF-COM-TRD-REQ- 

005 

S2PDGS-IPF-COM-TRD-REQ- NA Requirement for IDP-SC/OLQC-SC launcher 

010 

S2PDGS-IPF-COM-TRD-REQ- PC Commands are launched by DPC and restricted 

015 

to [CICD-IPF] 


IPF does not support sensible information 

NA 

020 

exchange function. 

S2PDGS-IPF-COM-TRD-REQ- C 

025 


030 


035 

S2PDGS-IPF-COM-TRD-REQ- NA IPF is not exposed to public domain 

040 


045 


050 


055 


060 


065 


070 


075 


080 


085 


090 







Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 303 / 315 

095 


100 


105 


110 


115 


120 


125 


130 


135 


140 


145 


150 


155 


160 


165 


170 


175 


180 


185 


190 


195 


200 


205 

C 

C 

C 

C 

PC 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

C 

C 

NA 

NA 

PC 

C 

C 

C 

C 

C 

Only applicable to input data loss or incomplete 

Requirement for IDP-SC/OLQC-SC launcher 







Logs are specified in [CICD-IPF] 

Logs are specified in [CICD-IPF] 

Out of IPF scope 

Requirement for IDP-SC/OLQC-SC manager 

Restricted to Start/Stop as specified in [CICD- 

IPF] 

specified in [CICD-IPF] 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 304 / 315 


210 


215 


220 


225 


230 


235 


240 


245 


250 


255 


260 


265 


270 


275 


280 


285 


290 


295 


300 


305 


310 


315 

C 

C 

C 

C 

C 

C 

C 

NA 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

PC 

C 

C 

C 

The IPF is compliant with the log message 

format defined by Common Services M&C. Log 

format is defined in [CICD-IPF] 






Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 305 / 315 


320 


325 


330 


335 


340 


345 


350 


355 


360 


365 


370 


375 


380 


385 


390 


395 


400 


405 


410 


415 


420 


425 


C 

C 

C 

NA 

NA 

NA 

NA 

C 

NA 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 



IPF is automatically triggered by the DPC 








Specification 


ISSUE : 03 

DATE : 06/04/2012 

PAGE : 306 / 315 

430 


435 


440 


445 


450 


455 


460 

C 

C 

C 

C 

C 

C 






Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 307 / 315 

5. TRACEABILITY 

The matrix providing the traceability of the requirements elicited in section 3 with the S2-PDGS requirements are available in the 

DP S2-PDGS-TAS-DI-VDB : 

For the traceability from SRD to CCTS : document ref. S2-PDGS-TAS-MX-0025 

For the traceability from CCTS IPF to SRD : document ref. S2-PDGS-TAS-MX-0040 






Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 308 / 315 

ANNEX 1: LISTS OF REQUIREMENTS, TBC, TBD 

Reference S2PDGS-IPF-TRD-REQ-001................... 30 







Reference S2PDGS-IPF-TRD-REQ-008 a ................ 33 










































Reference S2PDGS-IPF-TRD-REQ-050 ................... 87 
































Reference S2PDGS-IPF-TRD-REQ-082 ................. 100 



Reference S2PDGS-IPF-TRD-REQ-085 a .............. 100 














This document may not be disclosed to a third party or reproduced without the prior written consent of Thales Alenia Space Fran 





Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 309 / 315 


Reference S2PDGS-IPF-TRD-REQ-100................. 105 
















































































































Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 310 / 315 


















































































































Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 311 / 315 


















































































































Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 312 / 315 


















































































































Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 313 / 315 
































List of TBC: To Be Confirmed and TBD: To Be Defined 

TBC, 119 

TBD, 204 






Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 314 / 315 

ANNEX 2: list of DPM sections covered by several parts of IDP-SCs and level of coverage 

DPM ID DPM § IDP-SC DPM § 

coverage 

[GEO_S2-DPM] §5.3.3.1.3 GEO1B_ FINALIZE 

full 

FORMAT_METADATA(GR-L1B) 

FORMAT_METADATA(DS-L1B) 

SPATIO 

[GEO_S2-DPM] §5.4.3.4 TP_COLLECT 

full 

TP_FILTER 

[RESAMPLE_S2-DPM] Module #08-1-04 GET_TILE_LIST 

TILE_INIT 

full 






Specification 


ISSUE : 01 

DATE : 06/01/2012 

PAGE : 315 / 315 

END OF DOCUMENT

Instrument Processing Facility Technical Specifications - emits - ESA

Create successful ePaper yourself

Delete template?

Save as template?