GMES Payload Data Ground Segment Architectural...

/104

Title: GMES Generic Operational Scenarios

Contract Ref.: ESA/Esrin Contract No. 19114/05/I-SB

Int. Ref.: GPDS-TN-ASF-PS-0002 Issue: 5 Rev.: 1

Proj. Ref.: P-E146/DGIENG-3476-05 Date: 20/04/2007

GMES Payload Data Ground Segment

Architectural Study


/104





Abstract This document is the output of the work performed by EADS ASTRIUM SAS with major

contributions from WERUM/DLR in the frame of the GMES Payload Data Ground Segment Architectural Study, related to:

WP-D-1000.1: PDGS OPERATIONAL SCENARIOS DEFINITION

It contains:

1. A description of the scope of the PDGS

2. An analysis of Sentinel SRD relevant for PDGS commonalities and differences

3. A description of end-to-end functions and operations relevant for GMES missions

4. A description of multi-mission operations.

This issue is an update of the document provided within the frame of the Phase 1 of the PDGS Architecture Study, and submitted to review during the Mid Term Review of the GMES PDGS Architecture Study.

It includes a number of amendments resulting from the review by the Agency in the frame of the Mid Term Review and the discussion and disposition of all RIDs issued at this occasion

It also contains updates of the operational scenarios for Sentinel-2 and Sentinel-3, reflecting the operational concepts for these missions established during the related definition studies.

/104





Table of Contents

1 Introduction................................................................................................................18

1.1 Document Scope.............................................................................................................. 18 1.2 Document Structure and Contents ................................................................................. 18 1.3 Normative and Informative Reference Documents ..................................................... 19

1.3.1 Normative Reference Documents.............................................................................19 1.3.2 Informative Reference Documents ...........................................................................19

1.4 Acronyms and Abbreviations ......................................................................................... 21 2 Scope of the PDGS ....................................................................................................22

2.1 The PDGS in the context of ESA operated EO Missions ................................................ 22 2.1.1 Overview.........................................................................................................................22 2.1.2 Sentinel-1 Ground Segment ........................................................................................23 2.1.3 Sentinel-2 Ground Segment ........................................................................................24 2.1.4 Sentinel-3 Ground Segment ........................................................................................25

2.1.4.1 Overview................................................................................................................25 2.1.4.2 External Interfaces................................................................................................25 2.1.4.3 Sentinel-3 PDGS Specificities ..............................................................................26

2.2 PDGS Domains and Functions ......................................................................................... 26 2.2.1 Acquisition, Processing, Archiving and Dissemination Functions.........................27 2.2.2 User Services Functions.................................................................................................28

2.2.2.1 Coordination & Control.......................................................................................28 2.2.2.2 User Access............................................................................................................29

2.2.3 Sensor Performance, Products and Algorithms (SPPA)..........................................30 3 Main PDGS Operations Concepts ............................................................................33

3.1 Operations Principles ....................................................................................................... 33 3.1.1 Operational Character of the Sentinels Missions ....................................................33 3.1.2 PDGS Operations Drivers..............................................................................................33

3.2 Order Handling and Mission Planning Concept ........................................................... 34 3.2.1 Sentinel-1 Order Handling and Mission Planning ....................................................34

3.2.1.1 Categories of Orders ...........................................................................................34 3.2.1.2 Overview of Ordering and Mission Planning Concept .................................35 3.2.1.3 Mission Orders (“Foreground Planning”) .........................................................37 3.2.1.4 Users’ Orders..........................................................................................................37 3.2.1.5 Emergency Orders ...............................................................................................38 3.2.1.6 Acquisition Orders ................................................................................................39 3.2.1.7 Generation of Mission Plans ...............................................................................39 3.2.1.8 Mission Planning Mechanisms ...........................................................................40 3.2.1.9 Mission Planning Operations Concept (one satellite configuration) .........41

/104





3.2.1.10 Mission Planning Operations Concept (multi-satellite configuration) .......43 3.2.2 Sentinel-2 Mission Planning Operations Concept ...................................................43

3.2.2.1 Observation modes .............................................................................................43 3.2.2.2 Imaging plans .......................................................................................................44 3.2.2.3 Direct downlink .....................................................................................................44 3.2.2.4 NRT...........................................................................................................................45 3.2.2.5 Mission plan ...........................................................................................................45 3.2.2.6 Sentinel-2 Mission Planning Timelines................................................................45

3.2.3 Sentinel-3 Mission Planning Operations Concept ...................................................46 3.2.3.1 Nominal Mission Planning Operations ..............................................................46 3.2.3.2 Mission Planning for the Fire Monitoring Payload...........................................47

3.3 Processing, Archiving and Dissemination Concept ..................................................... 47 3.3.1 Data Driven Concept...................................................................................................47 3.3.2 Sentinel-1 Processing and Dissemination Concept ................................................49 3.3.3 Sentinel-2 Processing and Dissemination Concept ................................................49 3.3.4 Sentinel-3 Processing and Dissemination Concept ................................................50 3.3.5 Synthesis of Processing and Dissemination...............................................................50

3.4 Interoperations Concept.................................................................................................. 53 4 Detailed Operations Scenarios ................................................................................54

4.1 Purpose .............................................................................................................................. 54 4.2 List of Scenarios ................................................................................................................. 54 4.3 Scenarios Description....................................................................................................... 57

4.3.1 Systematic Operations Scenarios...............................................................................57 4.3.1.1 A.1: Mission Orders Handling .............................................................................57 4.3.1.2 A.2: Ordering from Third Party Missions.............................................................60 4.3.1.3 A.3: Sentinel-2/Sentinel-3 Mission Planning......................................................60 4.3.1.4 Systematic Processing and Dissemination ......................................................62 4.3.1.5 A.5: Reprocessing.................................................................................................65

4.3.2 User Driven Scenarios....................................................................................................68 4.3.2.1 Orders for New Products.....................................................................................68 4.3.2.2 Emergency Orders Submission and Handling ................................................72 4.3.2.3 Orders from Archived Products .........................................................................79 4.3.2.4 B4: Sentinel/Third Party Missions composite orders (including processing and dissemination) .....................................................................................................................83 4.3.2.5 Transverse Scenarios ............................................................................................93

4.3.3 SPPA Scenarios...............................................................................................................98 4.3.3.1 C.1: Subscription to Calibration / Validation Products .................................98 4.3.3.2 C.2: Orders for Calibration / Validation Products ..........................................99

4.3.4 PDGS Monitoring Scenarios .......................................................................................101 4.3.4.1 D.1: PDGS Operating and Monitoring............................................................101

4.3.5 PDGS Maintenance Scenarios .................................................................................103 4.3.5.1 E.1: PDGS Grow-up – Addition of new Mission .............................................103

/104





Index of Figures

Figure 2.1-1: Overview of ESA's EO Ground Segment for Sentinel Missions ...................................22 Figure 2.1-2: FOS and PDGS Functional Breakdown into Domains and Functions ......................24 Figure 3.2-1: Orders Categories .............................................................................................................35 Figure 3.2-2: Overview of Sentinel-1 Ordering and Mission Planning Concept............................36 Figure 3.2-3: Progressive build-up of Sentinel-1 Mission Plan ............................................................37 Figure 3.2-4: Daily Planning Cycle (all times UTC) ..............................................................................42 Figure 3.3-1: Scope of Data Driven Processes.....................................................................................48 Figure 3.3-2: Processing and Dissemination Concept – Systematic Processing ...........................51 Figure 3.3-3: Processing and Dissemination Concept – User Order Driven Processing ...............51 Figure 3.3-4: Processing and Dissemination Concept – On-Demand Re-Processing..................52 Figure 3.3-5: Processing and Dissemination Concept – Archive extraction with L1B product

sub-setting..................................................................................................................................................53 Figure 4.3-1: Scenario A.1 - Mission Orders Handling .........................................................................57 Figure 4.3-2: Scenario A.3: - Sentinel-2/3 Mission Planning ...............................................................61 Figure 4.3-3: Scenario A.4.1 - Product Dissemination via Subscription ...........................................62 Figure 4.3-4: Scenario A.4.2 - L1B NRT Delivery via Subscription ......................................................64 Figure 4.3-5: Scenario A.2.3 - L2 NRT Delivery via Subscription.........................................................65 Figure 4.3-6: Scenario A.5 –Reprocessing ............................................................................................66 Figure 4.3-7: Scenario B.1.1 - Single User Order submission with planning, processing and dissemination.............................................................................................................................................69 Figure 4.3-8: Scenario B.1.4 – Order for download to a user station...............................................71 Figure 4.3-9: Scenario B.2.1 - Sentinel-1 Emergency Order Submission and Handling................74 Figure 4.3-10: Chronology for “red phone” requirement handling ................................................75 Figure 4.3-11: Scenario B.2.2 - Sentinel-2 Emergency Order Submission and Handling..............77 Figure 4.3-12: Scenario B.2.3 - Sentinel-3 Emergency Order Submission and Handling..............78 Figure 4.3-13: Scenario B.3.1 - Orders from Archived Products without processing ....................79 Figure 4.3-14: Scenario B.3.2 - Orders from Archived Products with processing ..........................81 Figure 4.3-15: Scenario B3.3 - Orderless on-line data provision .......................................................82 Figure 4.3-16: GMES PDGS/Partner Mission Composite Orders Submission – Scenario A1 .........84 Figure 4.3-17: GMES PDGS/Partner Mission Composite Orders Submission – Scenario A2 .........86 Figure 4.3-18: GMES PDGS/Partner Mission Composite Orders Submission – Scenario A3 .........87 Figure 4.3-19: GMES PDGS/Partner Mission Composite Orders Submission – Scenario B1..........89 Figure 4.3-20: GMES PDGS/Partner Mission Composite Orders Submission – Scenario B2..........90 Figure 4.3-21: GMES PDGS/Partner Mission Composite Orders Submission – Scenario B3..........92 Figure 4.3-22: Scenario B.4.1 – Encryption and Keys Generation and Handling..........................94 Figure 4.3-23: Scenario B.4.2 – POD Generation and Handling.......................................................96 Figure 4.3-24: Scenario B.4.3 – Auxiliary Data Management ...........................................................97 Figure 4.3-25: Scenario C.1 – Subscriptions to Cal/Val Products .....................................................99 Figure 4.3-26: Scenario C.2 - Orders for Calibration/Validation Products ...................................100 Figure 4.3-27: Scenario D.1 – PDGS Operating & Monitoring.........................................................102

/104





Index of Tables

Table 1.3-1: Normative References .......................................................................................................19 Table 1.3-2: Informative References .....................................................................................................20 Table 4.2-1: List of Scenarios ...................................................................................................................56

/104





Document Signature Table

Name Function Signature Date

Author Bernard Momméja Ground Segment Engineering

17/04/2007

Verification Mauro Semerano DATAMAT SM 20/04/2007

Approval

Document Status Sheet

Issue Date Comments

1.0 04/11/2005 Draft Issue for GMES PDGS Architecture Progress Meeting #1

2.0 22/11/2005 Revised issue for Review

3.0 03/03/2006 Revised issue for submission at the PDGS Architecture Study Mid Term review

4.0 02/06/2006 Revised issue including amendments resulting from RIDs issued by the Agency at the MTR and related agreed actions.

5.0 01/12/2006 Final issue for GMES PDGS Architecture Final review, including amendments resulting from:

o Handling of MTR RIDs

o Alignment of Operational Concept for Sentinel-2 and Sentinel-3

5.1 17/04/2007 Updated issue for GMES PDGS Architecture Phase 2 completion after Final Review, including the answers to the RIDs issued by the Agency and the RIDs dispositions decided during RIDs collocation meeting on 23rd March 2007.

/104





Document Change records made since last issue

Issue Reason for change Involved

Paragraph

Type of modification

2.0 Comments received during PM#1 Presentation at ESRIN on 11th November 2005

Chapter 4 Update of scenarios diagrams and related text

3.0 Comments received on Issue B from consortium members and ESA/ESRIN

All Update of the descriptive part of the document

Update of the description of operations concepts for order handling, mission planning, and products generation and dissemination

Update of scenarios diagrams and related text

Addition of new scenarios.

4.0 RID’s issued by the Agency at MTR and related agreed

actions. Details are listed below.

All document

RID D01-096: “SSPA” changed to “SPPA” where applicable

In addition:

o “DIQA” changed to “SPPA” where relevant

o “Data and Instrument Quality and Algorithms” changed to “Sensor

Performance, Products and Algorithms”

All Document

RID D01-126: “Help Desk” changed to “Help and Documentation Desk” where relevant

2.1.1 RID D01-097: Editorial

2.1.2 RID D01-114: Station names replaced by required locations. Station names also mentioned as assumed baseline.

2.1.2 RID D01-047: Reference to Data Access

Interoperable Layer for interactions with Partner Missions Ground Segments. Figure updated accordingly.

2.1.3 RID D01-002: Station names replaced by required locations.

2.1.3 RID D01-115: sentence added about the availability of a high bandwidth electronic link between the receiving stations, the FOS and the PDGS.

/104






Paragraph


2.1.3 RID D01-003: “Land airborne and in-situ

data removed”

2.2.1 RID D01-004: “remotely” replaced by “real time”

2.2.2.1 RID D01-127: Name “Help and Documentation Desk” and definition of

function amended

2.2.2.2 RID D01-007: “Data Access front-end” function added

3.1.1 RID D01-087: New paragraph added stating the operational character of the

Sentinels missions.

3.2.1.5 RID D01-011: Clarification that the requests database contains only orders / requests not yet satisfactorily completed.

3.2.1.6 RID D01-012: clarification of process followed in case of a user request loosing a conflict

3.2.1.7 RID D01-060: Clarification of contents of 28-day data take schedule split into two

parts

3.2.2.5 RID D01-013: addition of exception cases

3.3.5 RID D01-079: Figures 3.3-3 and 3.3-4 updated to remove systematic

archiving of L1B products resulting from users orders

4.2 RID D01-027: Note added stating that recovery actions are part of [DIL-11] « PDGS Operations and Utilisation

Concept ».

4.3.1.3 RID D01-029 : Clarification of Mission Planning concept for Sentinel-2

4.3.1.4.3 RID D01-089: Need for external auxiliary data for Precise Orbit Determination

added (text and figure)

/104






Paragraph


4.3.2.1.1

4.3.2.1.2

4.3.2.1.3

RID D01-031: Titles changed respectively

to:

« Single Orders (including planning, processing and dissemination) »

« Time Series Orders (including planning, processing and dissemination) »

« Coverage Orders (including planning,

processing and dissemination) »

4.3.2.3.1 4.3.2.3.2

RID D01-037: Titles changed to replace “reprocessing” by “processing”

4.3.4.1 RID D01-028: Figure and text updated to include Acquisition reports from

receiving Stations

4.3.4.1 RID D01-044: Figure updated to include Unavailability Statistics of Satellite(s) and Sensor(s)

5.0 Updated list of Informative Reference Documents

1.3.2

RID’s issued by the Agency at MTR and related agreed actions.

As listed below in this

table.

See below

2.2.1 [RID D01-008]: Definition of reprocessing extended to cover also reprocessing from archived L1 to L2

3.3.3 [RID D01-014]: Extended mode does not apply to Sentinel-3

3.2.2.5 [RID D01-015]: Sentence reworded as recommended by the Agency

3.2.2/3.2.3 [RID D01-016]: Extended mode confirmed for Sentinel-2 and does not apply to Sentinel-3

3.2.2 [RID D01-017]: Section on Sentinel-2 Mission Planning concept completely restructured and revisited to include NRT constraints, downlink to third party stations and emergency mission planning

3.3.2 [RID D01-018]: Added shipping address as typical information needed for dissemination

/104






Paragraph


3.3.3 [RID D01-019]: Introduction of NRT

concept for Sentinel-2 products processing and dissemination

3.3.3 [RID D01-020]: Included restrictions on systematic processing for Sentinel-2

4.2.1 [RID D01-023]: Table 4-2.1: L1B Products

NRT Delivery applicable also to Sentinel-2

4.2.1 [RID D01-024]: Scenario not applicable to Sentinel-2

4.2.1 [RID D01-025]: Scenario not applicable

to Sentinel-2

4.2.1 [RID D01-026]: Scenario not applicable to Sentinel-2

4.3.1.4.1 [RID D01-030]: Note added to state that

the sub-setting function and the definition of sub-setting parameters for each product type are TBD

4.3.2.2.2 [RID D01-036]: Emergency Scenario for Sentinel-2 revisited, in particular direct downlink and planning time – 12 hours

added

4.3.2.3.2 [RID D01-038]: Added “quality check” before dissemination to the users

4.3.2.4.1 [RID D01-041]: Added disclaimer stating that all Security and

encryption/decryption scenarios are TBC

4.3.4.1 [RID D01-043]: Added “acquired vs. planned”, “archived vs. planned

2.1.1 [RID D01-045]: Figure 2.1-1 updated to show “external auxiliary data” as additional external interface of the PDGS

2.1.2 [RID D01-046]: Clarification note added to state that SPPA Domain functions are

distributed

2.1.2 [RID D07-048]: Figure 2.1-2 updated to name differently Mission Planning functions in FOS and PDGS

/104






Paragraph


2.2.2.1 [RID D07-049]: Mission Planning also in

charge of on-board recording and downlink

3.1.2 [RID D07-050]: sentence about on-board autonomy removed

3.1.2 [RID D07-051]: Paragraph added to

mention operations costs optimisation thanks to sharing of PDGS for multiple missions

3.2.1.2 [RID D01-053]: New introductive section added to better introduce the

differences of operational concept between Mission Orders and orders submitted by users.

3.2.1.5 [RID D07-055]: Specific section added to address “acquisition orders”

3.2.1.4 [RID D01-056]: Distinction between orders focusing on single products and standing orders, the latter possibly requiring Order Desk assistance for their submission

3.2.1.2 [RID D01-057]: Foreground planning / Background planning concept explained

3.2.1.7 [RID D07-058]: Paragraph amended to indicate that priority selection by a user

is indirect via QoS specification

3.2.1.8 [RID D07-059]: new bullet added to indicate that the instrument data take schedule generated by the PDGS and sent to the FOS is always complete and self-contained (no “delta schedule”).

3.2.1.8 [RID D07-061]: Paragraph amended to clarify that the Downlink Plan and stations pass data are updated each working day

3.3.1 [RID D01-062]: Section reorganised and

reworded to make clear that the “Data Driven Concept” is the main concept, with “Order Driven” operations for archive orders being the only exception to that concept.

/104






Paragraph


3.3.2 [RID D01-063]: Text updated to make

clear that processing and dissemination do not see Mission Orders

3.3.2 [RID D01-064]: Text updated – Correspondence via time overlap

3.3.3 / 3.3.4 [RID D01-065]: On-demand orders for

dissemination via media of large volumes of data

3.4 / 4.3.2.4 [RID D01-069]: Interoperability Scenarios moved from section 3.4 to section 4.3.2.4

4.3.2.1.2 / 4.3.2.1.3

[RID-D01-070]: Involvement of Order Desk to support the Users in the specification of Time Series and Coverage Orders

4.3.2.4.1 [RID D01-073]: Added considerations

about re-planning of cloudy images

4.3.1.5 [RID D01-076]: Added optional dissemination of reprocessed Level 1B/Level 2 Products

4.3.4.2 [RID D01-077]: added “addition of

information to Web site”

2.1.4 [RID D01-083]: Implementation of Section 2.1.4 describing the Sentinel-3 Ground Segment

4.3.2.1.5 [RID D01-091]: Disclaimer added

4.3.2.2.2 [RID D01-092]: Scenario not applicable to Sentinel-3

4.3.2.3.3 [RID D01-093]: New scenario added for orderless data provision from on-line

archive

4.3.1.5 [RID D01-094]: Added reference to the fact that reprocessing is required to ensure long term data consistency.

2.2.3 [RID D01-099]: Added reference to

Instrument Performance Monitoring contribution to Mission Monitoring

2.2.3 [RID D01-100]: Added anomaly investigation and characterisation and PDGS configuration checks as part of

Routine QC activities

/104






Paragraph


3.3.5 [RID D01-101]: Figures 3.3-2 & 3.3-3

updated to show Systematic Products QC applying also to Level 0 Products + Browse products can be generated at Level 0 or Level 1B processing stage according to the type of instrument

4.3.2.5.2 RID D01-102]: New scenario added explaining the handling of POD

4.3.3.1 [RID D01-103]: Clarification that in the Sentinel-2/3 cases, Cal/Val products would be a subset of the systematically acquired products, thus not requiring

dedicated scheduling or specific processing.

4.3.3 [RID D01-104]: Definition of Calibration / Validation products amended

4.3.1.1 [RID D01-105]: Systematic Archiving of Cal/Val products

4.3.3 [RID D01-106]: Definition of Calibration / Validation user added

4.3.1.5 [RID D01-107]: Reprocessing covers also

level 2

4.3.2.5.3 [RID D01-108]: New scenario added explaining the handling of auxiliary data

4.3.1.5 [RID D01-109]: “Systematic Reprocessing” amended to read only

“Reprocessing”

4.3.1.5 [RID D01-110]: “Reprocessing” scenario moved to Section 4.3.1 “Systematic Operations Scenarios

4.3.4.1 [RID D01-113]: added downlink success

statistics

2.2.1 [RID D01-116]: Definition of acquisition function extended to include also the antenna / RF functions

2.2.1 [RID D01-117]: Definition of ingestion

amended to make clear that archiving is not part of it but interfaces with it.

2.2.1 [RID D01-118]: Definition of Production Requests Handling amended to cover also systematic processing.

/104






Paragraph


3.1.2 [RID D01-120]: Paragraph amended to

be made clearer

3.2.2.5 [RID D01-122]: Reworded to make clear that the cases of unpredictable unavailability should be rare

4.3.4 [RID D01-123]: Title changed to “PDGS

Monitoring Scenarios”

2.2.1 [RID D01-124]: Definition of Archiving amended

2.2.2.2 [RID D01-128]: Mention added that the General Web is the single gateway to

all users services

2.2.3 [RID D01-131]: User interface with User Support functions is provided via the Help and Documentation Desk

3.1.2 [RID D01-132]: Data Policy part of the Operations Drivers

4.3.1.1.1 [RID D01-133]: Text about where decryption takes place relaxed (i.e. either receiving station or processing facility at ingestion stage).

Alignment of Operational Concept for Sentinel-2 and Sentinel-3

4.3.2.3.3 New scenario added: Sentinel-3 Emergency Orders Handling for the Fire Monitoring Payload

5.1 RID’s issued by the Agency at PDGS Architecture Final

Review and related agreed actions.

As listed below in this

table.

See below

3.3.2 [RID FR-D01-01]: Text updated to remove the improper term “Systematic acquisitions” and replace by “Mission

Orders Driven Acquisitions”.

Clarification added that the same systematic processing concept applies also for data takes derived from background planning inputs.

/104






Paragraph


4.3.2.1.1 [RID FR-D01-02]:

Comments added in the text to state that transfer of Metadata, Browse products and annotations from APAD to Master Catalogue is not systematically triggered as part of the scenario.

Figures 4.3-7 and 4.3-9 updated

accordingly

4.3.2.1.4 [RID FR-D01-03]:

Assumption made that data takes downlinked to a user terminal are also downlinked to a PDGS station, so, no

metadata and browse products are sent back to the PDGS

Figures 4.3-8 updated accordingly

4.3.2.2.3 [RID FR-D01-04]: Paragraph amended to state that the programming of the Fire

Monitoring Payload shall not impact the Sentinel-3 nominal mission, since this is prevented by satellite design

4.3.2.4.1

4.3.2.4.2

4.3.2.4.3

[RID FR-D01-05]: Figures 4.3-16/17/18 updated. “Using DB populated by FOS deleted” and replaced with check via

the Master Catalogue

4.3.2.4.1 [RID FR-D01-06]: Clarification added that the coordinated delivery of products from PDGS supported missions on one hand and PDGS unsupported

missions on the other hand is outside the scope of PDGS functions, but is ensured via the Data Access Interface Layer (DAIL).

Figure 4.3-16 updated accordingly

4.3.2.4.1 [RID FR–D01-07]: Text amended and completed to make clear that user interface functions for composite order submission are part of the Data Access Interface Layer functions (DAIL).

Figure 4.3-16 updated accordingly

/104






Paragraph


4.3.2.4.2

4.3.2.4.3

[RID FR-D01-08]: Scenarios amended to

make clear that the submission of composite orders by a user is done through the HMA/DAIL, and not directly to the PDGS, since the PDGS does not allow ordering of products for missions not supported by the PDGS.

Figures 4.3-17 and 4.3-18 updated accordingly

4.3.2.4.4

4.3.2.4.5

4.3.2.4.6

[RID FR-D01-09]: Clarification added that in the HMA-compliant model, any request is received either directly from

the user or via the HMA and not via the G/S of Third Party Missions.

Figures 4.3-19, 4.3-20 and 4.3-21 updated accordingly

/104





1 Introduction

1.1 Document Scope

This document is the output of the work performed by EADS ASTRIUM SAS with major contributions from WERUM/DLR in the frame of the GMES Payload Data Ground Segment Architectural Study, related to:

WP-D-1000.1: PDGS OPERATIONAL SCENARIO DEFINITION

It contains:

1. A description of the scope of the PDGS

2. An analysis of Sentinel SRD relevant for PDGS commonalities and differences

3. A description of end-to-end functions and operations relevant for GMES missions

4. A description of multi-mission operations.

This is the Final Version of the document provided within the frame of the PDGS Architecture Study, and submitted to review during the Final Review of this study.

Further consolidation will however be required to maintain the consistency of the Generic Operational Scenarios with the possible evolution of operations concepts during the Phase B2 of the Sentinel system studies.

1.2 Document Structure and Contents

This report is structured as follows:

o The Chapter 1 (this chapter) introduces the scope of the document and its structure. It also lists Normative and Informative Reference Documents.

o The Chapter 2 describes the scope of the PDGS and its functional breakdown into thematic domains

o The Chapter 3 provides a high level presentation of the PDGS Concepts of operations for Order Handling and Mission Planning, Data Processing and Interoperations with third party missions

o The Chapter 4 includes the detailed description of the end-to-end operations

scenarios within the PDGS, illustrating for each scenario the main activities / tasks within the PDGS and the main exchanges of information between the PDGS elements and with elements outside the PDGS.

/104





1.3 Normative and Informative Reference Documents

1.3.1 Normative Reference Documents

The following documents are applicable and are referred to as NRD xx in the text:

NRD Document Reference Issue /

Revision

Document Title

Table 1.3-1: Normative References

1.3.2 Informative Reference Documents

The following documents are referenced for supporting information and are referred to as IRD xx in the text:

IRD Document Reference Issue /

Revision

Document Title

IRD 01 ES-RS-ESA-SY-0001 1.2 Sentinel-1 System Requirements Document

IRD 02 EO-FP/2004-09-976 GMES Sentinel-2 Definition Study

System Requirements Document

IRD 03 EO-FP/2004-07-953 GMES Sentinel-3 Definition Study

System Requirements Document

IRD 04 ES-RS-ASU-GS-0032 [GS-1] E Sentinel-1 Ground Segment Requirements Specification

IRD 05 ES-RP-ASU-SY-0004 [SY-6] B Sentinel-1 Requirement Analysis Report

IRD 06 ES-TN-ASU-GS-0006 D Sentinel-1 Mission Operations Concept Document

IRD 07 S2-RP-ASF-SY-0001 4 GMES Sentinel-2 - Preliminary Ground / Service Segment Requirements and Assumptions

IRD 08 S2-TN-VEG-GS-0001 4 Sentinel-2 Mission Operations and Utilisation Concept

IRD 09 S2-RP-ASF-GS-0001 Draft GMES Sentinel-2 - Mission Operations and Utilisation Scenario

/104





IRD Document Reference Issue /

Revision

Document Title

IRD 10 SEN3-ASP-TN-138 2.3 Sentinel-3 Ground and Service Segment Requirements and Assumptions

IRD 11 SEN3-ASP-RP-145 Sentinel-3 Mission Operations Concept Document

Table 1.3-2: Informative References

/104





1.4 Acronyms and Abbreviations

APAD Acquisition, Processing, Archiving and Dissemination

BER Bit Error Rate

CCSDS Consultative Committee for

Space Data Systems

CD-ROM Compact Disk Read Only Memory

CEOS Committee on Earth Observation Satellites

DAIL Data Access Interoperable Layer

D&D Design and Development

DT Data Take

EO Earth Observation

EOP-A Earth Observation Programme - Applications Department

FOCC Flight Operations Control Centre

FOS Flight Operations Segment

FR Final Review

FTP File Transfer Protocol

G/S Ground Segment

GMES Global Monitoring for

Environment and Security

GNSS Global Navigation Satellite System

HDDT High Density Data Tape

HMA Heterogeneous Missions Accessibility

HTTP Hyper Text Transfer Protocol

IAT Interactive Analysis Tool

IPF Instrument Processing Facility

IV&V Integration, Validation and Verification

L0 Level 0 (Product)

L1B Level 1B (Product)

LEOP Launch and Early Orbit Phase

M&C Monitoring & Control

MTR Mid Term Review

NRT Near Real Time

NTC Non Time Critical

OLC Ocean and Land Colour

PDGS Payload Data Ground Segment

POD Precise Orbit Data

POV Precise Orbit Vector

QoS Quality of Service

RF Radio Frequency

ROI Region of Interest

SAR Synthetic Aperture Radar

SFTP Secure File Transfer Protocol

SLST Sea and Land Surface Temperature

SPPA Sensor Performance, Products

and Algorithms

SSR Solid State Recorder

STC Standard Time Critical

TBC To Be Confirmed

TBD To Be Defined

TMTC TeleMetry TeleCommand

TPM Third Party Mission

USMP User Services and Mission Planning

UTC Universal Time Coordinated

/104





2 Scope of the PDGS

2.1 The PDGS in the context of ESA operated EO Missions

2.1.1 Overview

For the operations of EO Missions, ESA generally uses two operating entities, namely:

o a Flight Operations Segment (FOS) at ESOC with one or several TMTC stations at appropriate – generally high latitude – locations to provide sufficient coverage for

telecommands uploading to the spacecraft and HKTM downloading.

o A Payload Data Ground Segment, geographically distributed, with central means and facilities located at ESRIN/Frascati, and facilities for payload data reception, decryption if required, ingestion, processing, archiving and dissemination to the users at various locations in Europe and Canada.

The Figure 2.1-1 hereafter gives an overview of the generic ESA’s EO Ground Segment split into

the Flight Operations Segment (FOS) and the Payload Data Ground Segment (PDGS).

SentinelSatellitesSentinelSatellites

Sentinel Generic Ground Segment

FOS PDGSReceivingStation(s)

TMTCstation

LEOPNetwork X-Band

S-Band

S-B

and

Backup

EGSE

ServiceSegment

External Data

Sources

External Data

Sources

TMTC

Instrument Raw

Data

SentinelSatellites

Flight Operations Control Centre

Decryption, Processing, Archiving &

Dissemination

Users

Customised Services

Payload Data Reception

Users ServicesCoordination & Control

UserRequests

Sensor Performance, Products and

Algorithms

Basic Products

Basic Products

Data Access Interoperable Layer

Partner Missions Ground

Segments

Partner Missions Ground

Segments

External Instrument

Data

Auxiliary Data

External Auxiliary Data

Figure 2.1-1: Overview of ESA's EO Ground Segment for Sentinel Missions1

1 [RID D01-045]: Figure updated to show “external auxiliary data” as additional external interface of the PDGS

/104





Note:

The main intention of this figure being to show the GMES PDGS in its context, only the main internal interfaces are represented.

2.1.2 Sentinel-1 Ground Segment

For Sentinel-1, the Ground Segment will include:

o The Flight Operations Segment (FOS) composed of:

� the nominal Flight Operations Control Centre (FOCC) at ESOC/Darmstadt;

� a back-up FOS at Kiruna, providing redundancy of Mission Control System and

Flight Dynamics System functions required to maintain the satellite in safe state in case of planned or unforeseen unavailability of the primary FOS;

� the FOS ground communication network, and,

� the TMTC stations (including the nominal TMTC Ground Station at Kiruna, the back-up TMTC Ground Station at Svalbard (TBC) and the LEOP stations).

The Satellite simulator used for the preparation and validation of the operational

procedures, for the operators training, and for the operations rehearsal before launch is also part of the FOS.

o The Payload Data Ground Segment (PDGS), including:

� a network of receiving stations appropriate for fulfilling the mission requirements. Sentinel-1 requires three receiving stations2 respectively located at a Northern

latitude in Europe in order to provide a downlink opportunity for each spacecraft orbit, in Canada and in Europe. The current baseline then assumes stations respectively located at Svalbard (Norway), Prince Albert (Canada) and Matera

(Italy).

� facilities performing the decryption of raw data if they are received encrypted, their ingestion, the processing, archiving and dissemination of Level 0 and Level 1B products to the service segment and to users. The number and location of these facilities is TBD;

� a set of centralised facilities, nominally located at ESRIN/Frascati for overall

Coordination and Control, including Mission Planning and Orders Management, provision of users services and functions of Sensor Performance, Products and Algorithms.

Note that functions of the Sensor Performance, Products and Algorithms Domain are per essence distributed, i.e. some are instantiated at one place (e.g. as part of

the centralised facilities at ESRIN), some are instantiated at several places (e.g. routine products quality checks) and some of them may even be outsourced outside the PDGS (e.g. for Expert Support Laboratories contribution to products and sensors calibration/validation).3

The Sentinel-1 Ground Segment is interfaced with:

o The service segment, for the provision of basic products

o Users, for interactions with the users services and the provision of basic products

2 [RID D01-114]

3 [RID D01-046]: Clarification note added

/104





o Third Party receiving stations

o The Data Access Interoperable Layer (DAIL) for interaction with any partner mission G/S4.

The FOS and the PDGS are in turn split into functional domains, each of the functional domains providing lower level functionalities as identified on the Figure 2.1-2.

Payload Data Ground Segment

Flight Operations Segment

User Services and Mission Planning

Mission Control System Flight DynamicsFlight Dynamics Spacecraft Simulator

• Platform Model• Payload Model• Ground Segment Model

• Spacecraft Operational Database• Housekeeping TM Processing• Time Management• Telecommand• Spacecraft Mission Planning• On-Board S/W Management• Ground Station Network Interface• Off-line analysis• Authentication and Encryption

Ground Stations and Networks

• Orbit Determination, Prediction and Control

• AOCS Monitoring• AOCS Command Generation• Test and Validation

• TMTC Ground Stations• Network Data Interface Unit• Portable Satellite Simulator• Ground Communication Network

• General Web• Catalogue• On-line Ordering and Order Handling• Data Access Front-End• User Management• Instrument Mission Planning• Help and Documentation Desk• Statistics & Reporting

• Web• Catalogue• On-line Ordering• On-line Data Provision• User Profile

User AccessUser Access

Sensor Performance, Products and Algorithms

• Routine Quality Control• Product Quality Control• Product Calibration• Product Validation• Instrument Calibration• Processing and Instrument Data Files

Generation• Instrument Performance Monitoring• Algorithms and Instrument Processing

Facility Development• Instrument and Processing Facility

Maintenance & Evolution• User Support• Precise Orbit determination

Facilities Ground Segment

• Acquisition• Ingestion• Processing / reprocessing• Archiving and Inventory• Production Requests Handling• Dissemination and On-line Data

Provision• Circulation• Monitoring and Control

Figure 2.1-2: FOS and PDGS Functional Breakdown into Domains and Functions5

Notes:

o The PDGS Breakdown into domains and functions does not prefigure a physical layout, i.e. different functions within a domain may be instantiated at different geographical locations, or a given function may be instantiated at several places.

o Some functions, even if related to one single domain, are scattered over different domains. This is for instance the case for Monitoring & Control.

2.1.3 Sentinel-2 Ground Segment

The layout of the Sentinel-2 Ground Segment is basically similar to the Sentinel-1 one. Main differences are:

4 [RID D01-047]: DAIL Interface for interactions with Partner Missions Ground Segments

5 [RID D07-048]: Figure updated to name differently Mission Planning functions in FOS and PDGS

/104





o The network of ground stations used for payload data reception. Sentinel-2 requires receiving stations at the following locations6:

� One receiving station at a Northern latitude in Europe, providing a downlink opportunity during each spacecraft orbit

� One receiving station in Canada

� One receiving station in Europe

The selection of adequate locations for these receiving stations assumes the availability of an electronic link providing adequate bandwidth between the receiving stations, the FOS and the PDGS.7

o The external interfaces required for the collection of external auxiliary data8:

� Data provided by land observation instruments

� External atmospheric data.

2.1.4 Sentinel-3 Ground Segment9

2.1.4.1 Overview

The Payload Data Ground Segment (PDGS) for Sentinel-3 includes 2 Data Acquisition Stations: Kiruna & Svalbard, and one or several processing centres. The PDGS operates fully

automatically in a data driven way, without receiving any command. The PDGS functions are:

o Acquisition, Processing, Archiving and Dissemination of data :

� Product Generation of NRT, STC and NTC products up to Level 2 for Altimetry and NRT and NTC products up to Level 2 for OLC and SLST.

� Precise Orbit Determination : to generate more accurate orbit mainly for Altimetry

processing

� Product On-Line and Long-Term Archiving: able to deliver products on user requests,

� Product Dissemination in NRT to Ocean Modellers and Data Centres. Some additional users can subscribe the service.

o Coordination and Control:

� Supporting user downlink request over a specific user station for OLC/SLST crisis missions (TBC).

o User Access

o Sensor Performance, Products and Algorithms :

� ensuring calibration and long term consistency of data

2.1.4.2 External Interfaces

For the Sentinel-3 Mission, the PDGS implements the following interfaces:

6 [RID D01-002]

7 [RID D01-115]

8 [RID D01-003]: “Land airborne and in-situ data” removed (interface to the service segment)

9 [RID D01-083]: Implementation of Section 2.1.4 describing the Sentinel-3 Ground Segment

/104





o Interfaces with the Service Segment, i.e.:

� With the Altimetry Data Centre, to provide L4, L3 Altimetry products to users. This Data Centre receives continuously L2 Altimetry products from the PDGS. Data

Centres shall be also able to receive L1b Altimetry products on user request,

� With the OLC Data Centre, to provide at least L3 OLC products to users. This Data Centre receives continuously L2 OLC products from the PDGS.

� With the SLST Data Centre, to provide at least L3 SLST products to users. This Data Centre receives continuously from the PDGS L2 SLST products.

o Interfaces with Auxiliary data Provider(s), to receive meteorological auxiliary data

(basically ECMWF, SSALTO, IERS, JPL, …).

o Interfaces with OLC/SLST Specific User for OLC/SLST crisis missions (TBC), to allow a satellite downlink for crisis missions and to provide decryption keys (if required)

o Interfaces with Users to continuously deliver products to subscribers and to provide some requested products from the PDGS archive.

2.1.4.3 Sentinel-3 PDGS Specificities

The specificities of the Sentinel-3 PDGS are:

o A systematic acquisition, processing, archiving and dissemination of data in a data driven way, meaning that there is no commanding for the system or any sub-system to be planned before acquisition of the data from the satellite. The reception of data from the satellite activates automatic acquisition, high level processing, archiving and dissemination to subscribers / users.

o Time critical products shall be generated:

� NRT up to level 2 products for Altimetry, OLC and SLST instruments within less than 3 hours from sensing;

� STC up to level 2 products for Altimetry within 1 or 2 days from sensing.

o Non time critical products shall be generated:

� NTC up to level 2 products for Altimetry, OLC and SLST instruments with the highest

quality.

o Users’ requests are limited to instrument calibration mode request for CAL/VAL users and specific local data downlink requests.

Note:

In case of the GIREL instrument (Fire Monitoring Payload) on board Sentinel 3 satellite, the

user requests will be extended to GIREL instrument data acquisition requests and GIREL instrument data downlink to local stations requests.

o Mission output products are available via :

� Subscription: data are sent automatically to the users (“push” data distribution)

� on-line data access: the users can request archived data (“pull” data distribution).

2.2 PDGS Domains and Functions

Within the GMES Ground Segment, the PDGS is in charge of providing:

o Acquisition, Processing, Archiving and Dissemination Functions

o User Services and Coordination & Control Functions

/104





o Sensor Performance, Products and Algorithms Functions

The functions pertaining to each of these domains are detailed in the following sections.

2.2.1 Acquisition, Processing, Archiving and Dissemination Functions

Acquisition (Payload Data Reception)

The Acquisition (Payload Data Reception) function receives the payload data downlinked by the satellite. This might be either real time10 sensed data or data played back from an on-

board recorder. This function includes the reception at X-Band of the instrument telemetry, the low noise amplification of the RF signal, the frequency down-conversion11, the demodulation

of the downlinked data stream and the demultiplexing, synchronization and reconstruction of the payload data in Computer Compatible Format (CCF),

Ingestion

The Ingestion function receives the payload data, already in Computer Compatible Format (CCF), output from the payload data reception function.

The Ingestion functionalities include the reception of the payload data files, the decryption of the data if applicable, their quality assessment, the extraction of the relevant metadata and their transmission to the long-term archive12.

Processing:

The Processing function applies necessary processing algorithms and formatting to the payload data to produce the basic product(s) specified in the related user orders. The Processing function is also in charge of reprocessing.

Reprocessing is the activity to process past data from the archived Level 0 or Level 1 products,

using either more accurate auxiliary information (e.g. orbits) or/and an updated processor version. Reprocessing may encompass:

o Reprocessing to Level 1 starting from Level 0 archived products

o Reprocessing to Level 2 starting from Level 1 archived products.13

Archiving and Inventory:

The Archiving function ensures the long-term storage of the payload data, extracted products and auxiliary data according to the long-term storage policy (e.g. either only Level 0 products or all products)14. This function includes all operations to be put in place to store these data

and ensure their integrity, such as their transcription at regular intervals.

The Inventory function extracts and stores the metadata on the archived data in a suitable repository used to perform searches over the archive.

10 [RID D01-004]

11 [RID D01-116]: Definition of acquisition function extended to include also the antenna / RF functions

12 [RID D01-117]: Definition of ingestion amended to make clear that archiving is not part of it but interfaces

with it

13 [RID D01-008]: Definition of reprocessing extended to cover also reprocessing from Level 1 to Level 2

14 [RID D01-124]: Definition of Archiving amended

/104





Dissemination and On-line Data Provision

The Dissemination function delivers the final product to the end-user, by means of physical media, electronic distribution (e.g. ftp-push) or electronic server access (e.g. ftp-pull).

The Online Data Provision function provides an interface for authorised users to access mission(s) products and auxiliary data online. This function might include on-the-fly post-processing functionalities.

Circulation:

The Circulation function exchanges data among centres federated into a distributed GS. An example is the transmission of data from a receiving station to a long-term archive.

Production Requests Handling:

The Production Request Handling instantiates the actions required by the GS relevant sub-systems to retrieve, process, format and disseminate products to the end-users. The Production Requests Handling handles either systematic processing activities or is triggered by production requests received from the Order Handling function15.

Monitoring and Control:

The Monitoring & Control function ensures that all resources (hardware, software, network) required to operate the ground segment are operating nominally.

2.2.2 User Services Functions

2.2.2.1 Coordination & Control

Mission Planning:

The Mission Planning function defines the detailed payload sensing in function of individual observation requests from data users and the mission overall observation strategy

("foreground/background planning").

The Mission Planning function is also in charge of scheduling on-board recording and real-time downlink activities16.

Master Catalogue:

The Master Catalogue function keeps track of the lifecycle of a single product, from its request by a user, its planning, its reception, its transfer between centres and its archiving..

The Master Catalogue is an archive inventory and can therefore include different entries for each logical product, i.e. physical product instances featuring different receiving stations,

archiving centres or processor versions.

Order Handling and Production Planning:

The Order Handling function coordinates the process required to achieve final delivery of product data to data users, controlling and monitoring the required sequence of activities related to sensing, payload data reception, data transfer between centres, production and dissemination.

The Order handling issues acquisition requests towards the Mission Planning function and production requests towards the Production Request Handling function

15 [RID D01-118]: Definition of Production Requests Handling amended to cover also systematic processing.

16 [RID D01-049]: Mission Planning also in charge of on-board recording and downlink

/104





User Management:

The User Management function manages all information related to a user. This includes management of the account and related quotas for access to specific services.

Statistics and Reporting:

The Statistics and Reporting function compiles production statistics from all single functions to generate systematic reports for G/S operations and mission management. Such reports include statistics on the geographical distribution of products.

The Statistics and Reporting function is also in charge of monitoring and controlling the overall PDGS load and performance based on gathering of Monitoring and Control information from

the PDGS distributed facilities.

Help and Documentation Desk17:

The Help and Documentation Desk function is the central access point for users’ inquiries,

requests for relevant documentation and filing of complaints and coordinates all activities required for their handling and follow-up.

2.2.2.2 User Access

General Web:

The General Web is the single gateway (single sign-on) to all users services18. This function

provides an interface for the user to access a Guide to missions, satellites, sensors, and products supported within the ground segment, including documentation with detailed information about all user products, and information on satellite operations including periods

of unavailability.

The General Web function makes information available in formats suitable for browsing.

ESA Catalogue:

The Catalogue function provides an interface for the user to search and retrieve metadata and browse images on the products of the mission(s) operated by the ground segment.

The Catalogue is sometimes referred to as User Catalogue. It shows to the user the orderable

logical products (including existing products and products yet to be acquired, both already planned and potential acquisitions) and differs from the master catalogue in that it may not report all products within the archive e.g. filtering those with low quality or those flagged for limited visibility.

The catalogue organises products within collections and may restrict access to certain

collections towards special communities such as Cal/Val teams.

Online Ordering:

The Online Ordering function provides an interface for the user to place orders for the products of the mission(s) operated by the ground segment. The ordering may be for products that can be derived from already acquired data, planned acquisitions, and potential acquisitions yet requiring planning. The ordering should verify any constraints that

may be imposed on users, and report status and relevant information back to the user.

17 [RID D01-127]: Name and definition of function amended

18 [RID D01-128]: Mention added that the General Web is the single gateway to all users services

/104





Data Access front-end19

The Data Access front-end function provides the user interface for accessing data available on-line in the APAD domain.

User Profile:

The User Profile is the user visible part of the User Management function.

2.2.3 Sensor Performance, Products and Algorithms (SPPA)

The PDGS provides the following functions of the Sensor Performance, Products & Algorithms Domain:

o Routine Quality Control

o Product Quality Control

o Product Calibration

o Product Validation

o Instrument Calibration

o Processing and Instrument Data Files Generation

o Instrument Performance Monitoring

o Algorithm and Instrument Processing Facility Development

o Instrument and Processing Facility Maintenance & Evolution

o User Support

o Precise Orbit Determination

Routine Quality control:

Routine Quality Control is the activity aimed at performing the routine quality control of any product generated in the PDGS and at monitoring the quality parameters for the detection of

any instrument/data anomaly. It includes the following main tasks: systematic screening of L0 data, systematic quality control of final products, data ingestion in the long-term database, end-user product quality control and Reporting.

The Routine Quality Control also covers:

o the anomaly investigation and characterisation, which requires specific resources and facilities.

o routine checks on the PDGS configuration and parameters which might impact the data product quality (e.g. Auxiliary data Files delivery, update and dissemination)20

Product Quality Control:

Product Quality Control is the activity aimed at ensuring that the mission products meet the product quality specifications, as stated by the Mission Requirements, during the mission life-time. In includes the verification of the product quality and the long-term product quality assessment and monitoring.

19 [RID D01-007]: Data Access front-end function added

20 [RID D01-100]: Added anomaly investigation and characterisation and PDGS configuration checks as part of

Routine QC activities

/104





Product Calibration:

Product Calibration is the process of quantitatively defining the system responses to known, controlled signal inputs.

Product Calibration is initially performed during the instruments commissioning phase. The activity shall however be maintained throughout the instrument life-time.

Product Calibration is mostly based on the comparison between on-ground and data derived measurements. On-ground measurements generally require specific ground equipment (e.g. transponders in the case of SAR and Altimetry). In some cases, on-ground measurements are replaced by measurements derived from models or performed by other sensors (in this case

calibration becomes inter-calibration).

Product Validation

As defined by the CEOS, Product Validation is: “The process of assessing, by independent means, the quality of the data products derived from the system outputs”.

Usually, product validation corresponds to the geophysical validation, usually applied to Level-2 (or higher) products. The products validation program shall be applied through the

complete life of the mission.

Instrument calibration

Instrument Calibration is the process of characterising and adjusting if necessary the instrument operating settings. It consists in external and internal calibration.

Processing and instrument data files generation

Processing and Instrument Data Files Generation is the activity to create, update and

maintain under configuration control the processing auxiliary files (used by the ground processor to generate data products) and the instrument data files (containing instrument characterisation settings that can be modified with these Look-up Tables).

Instrument Performance Monitoring

Instrument Performance Monitoring is the activity performed to derive statistical analysis of instrument performance parameter series to determine long-term trends and identify non-

conformances. Monitoring of instrument performance is a routine activity, performed throughout the sensor life-time. It is mainly based on the analysis of mission data and products. This analysis can made either systematically or on specific data sets. Together with the long-term products quality monitoring, Instrument Performance Monitoring contributes largely to the Earth Observation Mission performance Monitoring21

Algorithm and Instrument Processing Facility Development

Algorithm and Instrument Processing Facility Development is the activity to develop the data processing algorithms and to implement them in the processing facility within the PDGS

environment.

Instrument Processing Facility Maintenance and Evolution

Instrument Processing Facility Maintenance and Evolution is the activity to maintain and ensure evolution of the processing facility.

User Support

21 [RID D01-099]: Added reference to Instrument Performance Monitoring contribution to Mission Monitoring

/104





User Support groups all the activities in interface with users regarding the quality of products, i.e. reporting on products quality, information on quality disclaimers, products quality feedback from users, handling of inquiries and complaints. The interface of users with the User Support functions is provided via the Help and Documentation Desk22.

Precise Orbit determination

Precise Orbit Determination is mentioned for completeness purpose, since this is generally a

service provided by an external entity. It encompasses the transmission to the Precise Orbit Determination service provider of raw data required to compute precise orbit information (generally GPS or GNSS pseudo range data) and the gathering, archiving and handling of Precise Orbit Vector data in return.

22 [RID D01-131]: User interface with User Support functions is provided via the Help and Documentation Desk

/104





3 Main PDGS Operations Concepts

3.1 Operations Principles

3.1.1 Operational Character of the Sentinels Missions23

The PDGS shall support the operations of the ESA Legacy Missions and Sentinel missions in the frame of GMES (Global Monitoring for Environment and Security), a joint initiative of the European Commission (EC) and the European Space Agency (ESA), designed to establish a European capacity for the provision and use of operational information.

The operational character of the Sentinel missions implies the “provision of services in a

routine, long-term and continuous fashion, with a consistent quality and a very high level of availability”.

This implies that the overall system set-up and the PDGS in particular shall:

o Be continuously available and robust with back up systems in case of failures (dependability and continuity).

o Be able to ensure timely delivery of Level 1B/Level 2 to the users (timeliness);

o Ensure a high level of quality and stability of the products that it delivers.

3.1.2 PDGS Operations Drivers

It shall be possible to operate and maintain the PDGS easily and in an efficient way, with

respect to technical performances and costs. It is recognised that current EO systems require a too large number of operators, thus leading to excessive operations staff costs24.

Many technical and operational measures contribute to the automation of ground operations, to the improvement of their efficiency and thus to significant operational cost savings:

o data and orders driven rather than schedule driven data processing, which means that payload data are processed, archived and disseminated as they are received on ground without requiring operators for checking that operations are progressing according to a

predefined schedule;

o implementation of means or facilities to automate operations such as cloud cover annotations, image registration or products quality control;

o systematisation of data acquisitions for most Sentinel missions. In the Sentinel-1 case, systematic mission acquisitions subject to foreground planning are deemed to cover an average of about 80 % of all acquisitions; in the case of Sentinel-2 and Sentinel-3,

systematic acquisitions over predefined areas of interest are the baseline and user requested acquisitions are only rare exceptions (extended mode for Sentinel-2, fire monitoring payload activation for Sentinel-3). The mission planning process is then simplified, requiring less operator time than if it would have to handle a large number of individual and possibly conflicting users’ acquisition requests25.

23 [RID D01-087]: New paragraph added stating the operational character of the Sentinels missions.

24 [RID D01-050]: Removed sentence about on-board autonomy

25 [RID D01-120]: Paragraph amended to be made clearer

/104





o generalisation of the dissemination of products via subscriptions instead of handling of single products orders, and extended online access to selected products and auxiliary data which allow containment of the Order Desk personnel26;

o electronic distribution of products rather than distribution on media

o privileged access to Master Catalogue and Archive allowed to the actors in the Products Calibration and Validation process, without the need for them to be treated as standard

users.

o data policy: the management of access privileges and accounting are driven by applicable data policy27.

In addition, the fact that one single PDGS will be used to support many missions, including Legacy Missions and new Sentinel missions is also one major contributor to the reduction of operational costs. Sharing systems between missions optimises maintenance (less systems to maintain) and training (no waste of time for training on different systems) while also allowing to define mission transverse staff positions (such as system or database administration staff).28

3.2 Order Handling and Mission Planning Concept

3.2.1 Sentinel-1 Order Handling and Mission Planning

3.2.1.1 Categories of Orders

The following Figure 3.2-1 shows the different categories of orders. Each order can be

classified with respect to:

o The area to be covered:

� Strip line i.e. the region of interest (ROI) covered corresponds to one of the possible swaths of the instrument; in this case, the order can be entirely fulfilled with one single acquisition

� coverage, i.e. the ROI to be covered must be split into strips to fulfill the order.

o The repetitivity of the order:

� Single order (one shot), i.e. the order is completed when the defined ROI has been covered once;

� Time series, i.e. the ROI must be covered several times within a user specified period of time. Such orders are therefore defined with a time validity period and a repetitivity period within this time interval (e.g. twice per month during 6 months).

o The associability of the order:

� Mono-mission orders, addressing one single mission

� Multi-mission orders, allowing fulfillment of the order with data from different missions

It is expected that most Mission Orders will be Time series coverage orders.

26 [RID D01-052]: Already addressed in previous versions

27 [RID D01-132]: Data Policy part of the Operations Drivers

28 [RID D01-051]: Paragraph added to mention operations costs optimisation thanks to sharing of PDGS for

multiple missions

/104





Figure 3.2-1: Orders Categories

3.2.1.2 Overview of Ordering and Mission Planning Concept2930

Fort Sentinel-1, a fundamental distinction has to be made between Mission Orders and Users Orders, in the sense that:

o Mission Orders do not go through the ordering loop (on-line ordering � order handling); on

the contrary, they are inserted directly in the Mission Planning as acquisition requests by the mission planning officer acting on behalf of the mission manager.

o User Orders (submitted by users) go through the on-line ordering � order handling �

mission planning loop with possible feedback to the user.

This concept is illustrated by the Figure 3.2-2 which shows also an activity of the Mission Planning officer to insert additional acquisition requests on top of mission orders and users’ orders. This is background planning which aims at filling gaps in the mission plan in order to optimise the use of the available resources.

Thus, the Mission Plan is progressively built on the basis of inputs from the mission planning officer (mission orders for foreground planning, users’ orders and eventually additional orders which are part of the background planning strategy).

The progressive build up of the Mission Plan is shown on Figure 3.2-3.

29 [RID D01-053]: New introductive section added to better introduce the differences of operational concept

between Mission Orders and orders submitted by users.

30 [RID D01-057]: Foreground planning / Background planning concept explained

Mission Order

User Order

Single

Time Series (Standing)

Stripline

Coverage

AREA REPETITIVITY

Mono-Mission

Multi-Mission

ASSOCIABILITY

/104





Order Handling

Mission

Orders

Order Desk

On-line Ordering

Order Handling

Foreground Mission Planning

SimpleOrders

Complex Orders

(Coverage, Time Series)

User Orders Planning

Background Mission Planning

Data Takes & Downlink Plans

Generation

Figure 3.2-2: Overview of Sentinel-1 Ordering and Mission Planning Concept

/104





Foreground PlanningMission Orders

Users Orders

Background Planning

Figure 3.2-3: Progressive build-up of Sentinel-1 Mission Plan

3.2.1.3 Mission Orders (“Foreground Planning”)

Most of the acquisitions performed by the Sentinel-1 satellites will be based on so called

“Mission Orders” that are orders of “general interest” answering the objectives of the mission. These orders are directly implemented by the mission planning officer in the mission planning following directives from the mission management. These orders are given a high priority level so that they can be superseded only by orders having a still higher priority, i.e. Cal/Val orders and emergency orders. Consequently, only a limited percentage of the system resources remains available for orders submitted by “external” users. It is currently estimated that in the

Sentinel-1 case, Mission Orders should use around 80% of the system capacity, while the remaining 20% would be for users’ orders. These are however not fixed ratios which are likely to evolve during the mission lifetime.

The products resulting from Mission Orders are made available via a subscription mechanism. Subscriptions are defined by the Agency, in order to cover the needs of a large community of users for products sharing common characteristics (i.e. a given geographical area or the

combination of a given geographic area and of a given time span, e.g. data takes over Atlantic Ocean in spring time). Once a subscription is defined, users can join it. The capability for users of subsetting products subscribed to (i.e. restricting the geographical area or periodicity of delivery) is envisaged but yet to be confirmed.

3.2.1.4 Users’ Orders

At any time, Sentinel-1 users are given the capability to submit new orders. Users’ interactions

for orders submission happen via the “on-line ordering” function. While simple orders (i.e. orders focusing on single products – including geo-temporal requests) would in principle not

/104





require any assistance from Order Desk staff, more complex orders like standing orders (time series orders or coverage orders) would benefit from the assistance of Order Desk skilled personnel (see also Figure 3.2-2)31. The role of the Order Desk for such “complex” orders is first

to understand the actual needs from users and then to provide advice for a best choice of the orders parameters. If the Order Desk assistance is required, limitations in working hours have to be taken into account, i.e. assistance from the Order Desk or Help and

Documentation Desk is provided during working days / working hours only.

Once an order is submitted and committed, a user should not be allowed to modify it. Some exceptions may however be envisaged, e.g. the capability for time series orders to restrict or extend the order validity period. The nominal way for a user to modify an order shall remain to cancel the order and submit a new one.

For the submission of their orders, users are provided with a set of ordering options in

compliance with the agreed order model and depending on the type of order considered, i.e. strip line or coverage order and on the parameters of the order (single or joint, one single instance or time series orders). These include default parameters for the order.

From an operational standpoint, a distinction is made between:

- On one hand orders requiring new data takes, that require scheduling of instrument

operations and thus involve both the PDGS and the FOS

- On the other hand orders for products from archived data that do not imply any plan generation and involve only the PDGS.

3.2.1.5 Emergency Orders

In addition to mission and user orders, emergency orders are orders submitted in the frame of

an exceptional procedure (e.g. the International Charter) after the nominal cut-off time is elapsed, and which therefore require a specific operational procedure to be implemented, in order for them to be taken into account even if the FOS/PDGS Mission planning loop has already been initiated.

They are responding to the following requirement:

“The PDGS shall support emergency ordering, mission planning and satellite tasking within timelines shorter than those applicable to nominal operations.

- The time between placement of an emergency order and the resulting sensing request

being available for uplink to the S/C shall not exceed 3 hours if the emergency order is

placed during normal working hours:

- The time between the sensing request being available for uplink to the S/C and the actual

uplink to the S/C, as a selectable option for emergency orders, shall not exceed 6 hours if

the sensing request becomes available during normal working hours.”

Note :

In the above emergency scenario, it is desirable that emergency requests are satisfied without

deletion of other already existing requests, except for those in direct conflict with the emergency request.”

31 [RID D01-056]: Distinction between orders focusing on single products and standing orders, the latter

possibly requiring Order Desk assistance for their submission

/104





3.2.1.6 Acquisition Orders

“Acquisition orders” are a particular type of orders submitted by privileged users, e.g. entities

operating an X-Band receiving station. In the case of such ”acquisition orders”, only instrument operations scheduling and downlink planning are required. “Acquisition orders” do not result in any processing and dissemination activity within the PDGS.

3.2.1.7 Generation of Mission Plans

As stated above, the generation of mission plans concerns only orders for products requiring

new data takes. These mission plans have several objectives:

- Maintain a long term view of all SAR acquisitions planned over a period covering up to more than one year, including acquisitions resulting from mission orders;

- Provide users with an early assessment of the feasibility of their orders;

- Generate a consolidated data take schedule covering a given time span (i.e. 28 days);

To fulfil these objectives, the mission planning relies on two main components:

- The requests data base: it is the living reference for all users orders submitted and not yet completed. It maintains the links between the orders and the associated data takes. Once an order is satisfactorily completed, the corresponding requests are removed from the requests data base32.

- The data take schedule built incrementally as new orders are submitted.

32 [RID D01-011]: Clarification that the requests database contains only orders / requests not yet satisfactorily

completed.

/104





3.2.1.8 Mission Planning Mechanisms

The generation of the data take schedule is based on a set of mission planning rules and mechanisms.

First, the feasibility of any new user order requiring a new acquisition is assessed against planning constraints, such as the availability of the required on-board resources, the compatibility with the on-board memory constraints, and the capability to download the related raw data to one of the designated receiving station.

According to the order parameters specified by the user, one or several alternatives for data take scheduling may exist over the order validity period.

The provisional scheduling of the data take, i.e. the selection of the best alternative is then performed taking into account the relative priorities of orders. The mission planning system allows different priority levels for users’ orders. For a given order, the user does not select directly a priority, but rather a Quality of Service level from which the priority level of the order is derived. The Quality of Service can be defined respectively for acquisition (e.g. emergency, urgent or standard) and for processing and dissemination (e.g. real time - meaning real-time

downlink to a user receiving station -, NRT, urgent, standard). Whether only one Quality of Service will be allowed for a given user, or a user will be given the capability to select different QoS levels for his/her order among the different levels available is a data policy issue. In the latter case, a quota system (TBC) should prevent users from systematically choosing the best possible QoS from the allowed set, i.e. the “cost” of an order would then depend on the acquisition and downlink QoS specified by the user.33

For the incorporation of acquisition requests into the data take schedule, the mission planning applies then the following conflicts resolution rules:

- If the new request has a higher priority than the older one with which it is in conflict, the request with the lower priority will be relegated to a data acquisition opportunity later within the user specified time frame;

- If the new request has the same priority as the older one, the request submitted later will be the one relegated (“first-come- first-served” principle);

- If the new request has a lower priority than the older one, the mission planning will

attempt to schedule the new request using a next data take opportunity.

In all cases when a request is loosing a conflict, this request will remain active as long as its validity date is not reached. The request is kept in the requests database and the user is informed that the conflict has been lost. The mission planning operator coordinates with the user in order to find a work around solution allowing to satisfy the request (e.g. increase of priority, extension of validity date). It is the user sole decision to cancel the request if no satisfactory solution can be found.34

Those end-user requests for products whose earliest data acquisition opportunity cannot be

accommodated within the specified acquisition-timeliness capabilities of the Sentinel-1 mission, would be removed from the mission planning master schedule and reported back to the PDGS to permit the end-user to be informed and, if necessary and possible, to re-submit the product order. If the request is at the highest level of priority or was submitted by a

33 [RID D01-058]: Paragraph amended to indicate that priority selection by a user is indirect via QoS

specification

34 [RID D01-012]: clarification of process followed in case of a user request loosing a conflict

/104





privileged category of end-user, the Mission Planning Team will be notified to allow a manual intervention to be made over the automatic process of conflict resolution.

When ranking the acquisition requests according to their priorities, the mission planning can

be led to increase the priority of some requests under specific conditions in order to allow them better resistance to relegation in case of conflicts with other requests. This can for instance be the case for acquisition requests which are part of time series orders, i.e. once a time series order has started to generate acquisition requests, this allows to ensure that the remaining part of the acquisition requests will not be cancelled due to too low priority.

3.2.1.9 Mission Planning Operations Concept (one satellite configuration)

The main drivers for the Mission Planning Concept and for the related PDGS interactions with FOS result from a compromise between operational constraints, simplicity and efficiency of the Mission Planning design and operations, end-to end availability and timeliness requirements.

The concern of reducing operations costs leads to plan operations requiring human attendance only during working days – working hours, i.e. automated operations can run

unattended up to 64 hours (e.g. from Friday 4:00 pm UTC until Monday 8:00 am UTC). There can be exceptions to this, i.e.:

o longer unattended periods (due for instance to a Bank Holiday prior to or after a week-end) will be avoided.

o On-call support over nights or week-ends can be foreseen to face contingencies and allow the handling of emergency requests submitted e.g. in the frame of the

International Charter.

To satisfy the objectives of simplicity and efficiency for Mission Planning design and operations, the following principles are applied:

o The Instrument Data Take schedule generated by the PDGS and sent daily to the FOS is always complete and self-contained. The part of it (i.e. the 4 first days) which is handled by the FOS to be translated into telecommands and uploaded to the

spacecraft is conflict free. Even in the case of emergency orders, the PDGS always generates and sends to the FOS a complete schedule, i.e. there is no concept of “delta schedule” superseding only one part of the original schedule35.

o Upload of the Instrument Command Plan schedule each working day, covering in every case a time span of 96 hours, i.e. the satellite autonomy with respect to SAR Instrument operations varies between 48 hours and 96 hours (worst case on Mondays, where only 48 hours of SAR operations would still be available on-board).

o One single “Mission Planning Loop” each working day between the PDGS and the FOS

o Definition of cut-off points for the submission of users requests (routine, normal, emergency) and subsequent accounting i.e. quota consumption depending on the time span between submission and upload (TBC).

o Reduction of the time between schedule uplink and start of instrument operations, in order to decrease the time between submission and data sensing for a last minute order.

35 [RID D01-059]: new bullet added to indicate that the instrument data take schedule generated by the PDGS

and sent to the FOS is always complete and self-contained (no “delta schedule”).

/104





An overview of a possible daily planning cycle resulting from the above considerations is given by the Figure 3.2-4 below.

Day n+2: loaded

Day n+3: loaded

08 am 11 am 02 pm 05 pm

Cut-off time for the submission of acquisition orders to happen between current Day 8. a.m. UTC. and next Day 8. a.m. UTC

Data Take Schedule Generation by PGS

FOS Mission Planning Operations

Time slot for uplink

Day n+2: loaded

Day n+1: loaded Day n+1: being executed

Day n: being executed

Data Take Schedule loaded on-Board

Day n+4: loaded

Day n+3: loaded

Day n+2: being executed

Start of daily data take schedule execution on-board : 08:00 p.m.

12 hours: minimum achievable time between order submission and related data take (if a data take opportunity exists shortly after 08:00 pm)

Day n+3 loaded

Day n+4: loaded

Day n+5: loaded

08 am. 11 am 02 pm 05 pm 08 pm08 pm 08 am. 11 am 02 pm 05 pm 08 pm

Figure 3.2-4: Daily Planning Cycle (all times UTC)

This daily planning cycle is executed on working days only. For instance, 08:00 a.m. UTC could

be the start time of daily mission planning activities, performed conjointly by PDGS and FOS, for the generation by PDGS of a consolidated data take schedule for the next 96 hours (starting in fact on current day at 08:00 p.m.) and of a provisional data take schedule for the subsequent 24 days.

In fact, the data take schedule sent by the PDGS to the FOS will always cover 28 days of payload operations, split into two parts36:

o For the first 96-hours, the schedule is complete, i.e. it includes a conflict-free schedule of payload acquisitions and a complete on-board recording and

downlink schedule covering 4 days of operations. This is the part of the schedule that is used by the FOS and translated into telecommands uplinked to the satellite.

o The remaining part of the schedule (subsequent 24 days) includes a provisional data take schedule which is not necessarily conflict-free. At this stage, it does not include on-board recording and downlink schedules.

The 28-day plan can also be used by the FOS to try and schedule manoeuvres outside

payload activity periods. For this purpose, longer term visibility on payload activity can be

36 [RID D01-060]: Clarification of contents of 28-day data take schedule split into two parts

/104





given to the FOS for manoeuvre planning (e.g. one-year updated once a month). The detail of these plans shall be very limited, i.e. just time intervals where payload activity is foreseen (without details on instrument, mode, etc.).

The downlink plan sent to the receiving stations will cover at least a one-week period, thus allowing longer periods of unavailability. However, like the Instrument Data Take schedule, the downlink plan is updated each (working) day, thus allowing to take into account the latest available orbit parameters (for accurate pointing of the antennas) and the latest information on receiving stations availability (e.g. in case of pass conflict with another satellite handled by the same station)37.

3.2.1.10 Mission Planning Operations Concept (multi-satellite configuration)

The orbit phasing of the two Sentinel-1 satellites is chosen so that the two Sentinel-1 satellites will be on the same orbit, at least 20 minutes apart. The operational interest (and cost) of introducing a more complex mission planning concept really optimising the use of the global space resource for the sake of better answering user needs must be traded off considering the actual time when two satellites will be effectively operated conjointly.

The baseline will be to consider a mission planning concept optimising globally the usage of the space resource (i.e. a data take request is not assigned a priori to either satellite). This will

allow more flexibility for the introduction of users’ requested acquisitions, providing more sensing opportunities than in the one-satellite case and thus decreasing the probability of conflicts and the operators’ workload.

3.2.2 Sentinel-2 Mission Planning Operations Concept38

3.2.2.1 Observation modes

There are two different observation modes at satellite level:

Nominal mode: In this mode, the satellite is pointing toward Nadir and ensures two simultaneous missions: a routine (or default) imaging plan, and an emergency imaging plan.

Extended mode39: In this mode, the satellite is pointed off-Nadir. This mode is basically used to acquire images according to the emergency imaging plan.

37 [RID D01-061]: Paragraph amended to clarify that the Downlink Plan and stations pass data are updated

each working day

38 [RID D01-017]: Section on Sentinel-2 Mission Planning concept completely restructured and revisited to

include NRT constraints, downlink to third party stations and emergency mission planning

39 [RID D01-016]: Extended mode confirmed for Sentinel-2

/104





3.2.2.2 Imaging plans

The imaging plans may then be defined at system level according to two different schemes:

Routine imaging: Routine imaging consists in a list of areas to be imaged on a systematic basis. It is always performed in Nominal mode. The routine imaging plan

can be updated on a fortnightly basis. Acquired images (or strips) are downlinked to ground according to a FIFO policy, except for those data which will be used to generate NRT products, and which shall be downlinked at the beginning of the first visibility following their acquisition, or in the special case of direct downlink

Emergency

imaging:

Emergency imaging consists in a list (or set) of images which shall be acquired with the lowest possible latency. Images shall be acquired only once. The imaging plan is uplinked outside of nominal imaging plan uplink sessions, and the images shall be downlinked to ground on the first visibility following their acquisition. The time between order reception

on ground and plan uplink shall be less than 12 hours. Emergency imaging may take place in extended mode, but not necessarily.

3.2.2.3 Direct downlink

Direct downlink consists in simultaneous image data acquisition and downlink, with data being downlinked to the ground as they are being acquired by the instrument, with a minimum latency (20s goal, 60s threshold).

The principles for direct downlink are the following:

o If the satellite is in visibility of the local user station on which to perform direct downlink, and is not in visibility of a core station, acquired data are immediately downlinked to the local user station, and remain in the mass memory for downlink on a core station. They will be downlinked as part of the FIFO when the satellite is in visibility of a core station.

o If the satellite track crosses an intersection between the visibility circles of the local user station and of a core station, direct downlink shall be ensured anyhow, but since downlinked image data will also be received by the core station, they need not be downlinked later on, and therefore need not be stored in the mass memory. This

means that they can be deleted immediately after direct downlink. This also means that if data towards the local user station are encrypted, the encryption key shall be known to the core station. If data towards the local user station are unencrypted, they are also unencrypted towards the core station.

o The case of competition between a NRT data take (for a core station) and a direct downlink data take is detected during the mission plan elaboration. The mission

planning officer is notified. The priority is thus given to the NRT data take. The data take previously in direct downlink will be downlinked on a core station according to FIFO strategy and could be redirected towards the user station if required.

/104





3.2.2.4 NRT

Near Real Time products (NRT) refers to products being available within less than 3 hours after

image sensing. It requires that data be downlinked to the ground at the beginning of the first visibility following their acquisition, and that they are subject to a fast (or accelerated) ground processing.

3.2.2.5 Mission plan

The mission plan is computed by the ground segment on the basis of:

o systematic acquisition of predefined areas of interest;

o on-demand acquisition of identified areas of interest;

o Specific downlink strategies relating to the characteristic of the data take (standard, NRT, direct downlink, additional downlink) or resulting from e.g. addition of a new receiving station, “forced” downlink to a station different from the one nominally

foreseen for instance in emergency situations, handling of NRT acquisitions40.

Ground intervention for the scheduling of downlink sessions cannot be avoided, since the number of receiving stations and their availability cannot be predicted far in advance. Both predicted and unpredicted unavailability of a receiving station may cause rescheduling of the downlink schedule. Predicted unavailability encompasses maintenance operations, pass

conflict with another satellite, management of pass interferences. It is expected that for the two latter cases a long term priority policy will allow to solve conflicts enough in advance to avoid last minute downlink rescheduling. Unpredicted unavailability can essentially be caused by an outage and will necessitate urgent rescheduling of the downlink41. For downlink

scheduling the ground segment will periodically communicate to the satellites the available downlink times per orbit and per receiving station (based i.e. on orbit identifier), assigning data takes to downlinks, based on simple rules like FIFO (“first sensed – first downlinked”), except for emergencies, in order to reduce the time between data acquisition and downlink.42 Such a downlink schedule would not need to be uploaded daily, but should be

periodically updated e.g. on a weekly basis, in line with the orbit predictions performed by FOS.

3.2.2.6 Sentinel-2 Mission Planning Timelines

Given the considerations above, two cases are considered for Sentinel-2 Mission Planning, i.e. nominal mission planning and emergency mission planning for the planning of observations in extended mode.

3.2.2.6.1 Nominal Mission Planning

For nominal mission planning, the updates of the data take schedule on board are performed on a fortnight basis.

40 [RID D01-013]: addition of exception cases

41 [RID D01-122]: Reworded to make clear that the cases of unpredictable unavailability should be rare

42 [RID D01-015]: Sentence reworded as recommended

/104





When uplink of an updated mission plan is necessary, the objective is to target an uplink by the FOS of the instrument data take schedule while the FOS is manned. This is not a major constraint since visibilities over Kiruna station which is used for TC uplink occur during working

hours.

So, the concept is similar to the one for Sentinel-1, with the two main differences:

o Planning performed each fortnight instead of each working day

o More flexibility for uplink

3.2.2.6.2 Emergency Mission Planning

For emergency mission planning, the requirement is to generate and upload a data take schedule within 12 hours from the submission of the emergency request.

In emergency situations, two cases shall be considered:

o Emergency request coming in during working hours

o Emergency request coming in outside working hours.

In the first case, it’s assumed that the limit time for the emergency request is at the latest 3

hours before the last uplink opportunity (during working hours). This constraint allows the request to be taken into account if it comes in before 13:00 pm. This lets 3 hours for PDGS and FOS to perform the mission planning loop, consisting for the PDGS in incorporating the emergency request in the data take schedule and for the FOS in translating the mission plan into telecommands.

The second case is quite similar, except that unplanned mission planning operations would be

required. This imposes personnel to be available on call and able to resume mission planning operations as quickly as possible, including during nights and week-ends.

3.2.3 Sentinel-3 Mission Planning Operations Concept43

3.2.3.1 Nominal Mission Planning Operations

The Mission Planning concept for Sentinel-3 is based on the fact that the Sentinel-3 satellites are performing systematic acquisitions over the respective areas of interest defined for each instrument. So, the mission plan is repetitive, but for cal/val requests.

Cal/Val users have the capability to submit requests for instrument calibration in the form of

acquisition requests in calibration mode. It is expected that such calibration requests will occur every 2 weeks for the OLC instrument and every TBD for the SLST instrument.

Mission Planning is then performed weekly and covers two weeks of instrument activities, including the specific acquisitions for calibration. Mission Planning is also in charge of generating the downlink plan whereby:

o All acquired instrument data shall be downlinked at each orbit to one of the Sentinel-3

reference ground stations (i.e. nominally Kiruna and Svalbard for Kiruna blind orbits);

o Mission Planning shall be able to plan additional downlink of local data to users’ stations for users who subscribed to such service. In such case, the local downlink plan is included in the systematic mission plan generated each week.

43 [RID D01-014/016]: Extended mode does not apply to Sentinel-3

/104





The main issue in Sentinel-3 Mission Planning is the management of downlink activities according to the current availabilities of receiving stations and to the specific requests for downlink of local data over users’ stations.

3.2.3.2 Mission Planning for the Fire Monitoring Payload

This section describes the Mission Planning concept related to the operations of the Fire Monitoring Payload (GIREL instrument) on board the Sentinel-3 satellite. It is assumed that the Fire Monitoring mission is restricted to the European area, during the hot season (e.g. from April to October) defined as "fire-monitoring season" in this paragraph. Note that all orbits over European regions provide a visibility from the TMTC Ground Station used for space control. This means that the fire-monitoring requests can be satisfied within the next orbit in

the area of interest, providing that no request conflict appear between several simultaneous fire areas.

During the fire monitoring season, fire monitoring requests are received by the PDGS from

different European Fire Fighting Operational Centres or from a common User Request Management Centre. In case a common User Request Management Centre for fire-monitoring requests would exist, this would allow to specify a standard format for the fire-monitoring requests sent to the GS, and thus avoid the conflict resolution within the PDGS. Otherwise, fire monitoring requests issued by the different fire fighting operational centres

would need to be manually processed by a PDGS operator.

The fire monitoring payload is permanently in emergency mode, which means very stringent timelines for the handling of fire monitoring requests and all subsequent activities. The PDGS

shall be able to handle requests for fire monitoring payload acquisitions and downlink to local users’ within half an hour. This requires an availability of operators 7 days/week, 24 hours/day during the fire monitoring season.

3.3 Processing, Archiving and Dissemination Concept

3.3.1 Data Driven Concept

The main driver for processing, archiving and dissemination operations is the data driven

concept.

The main feature of the “data driven” concept is that the availability of the data itself triggers the payload data handling on ground rather than any ‘master’ schedule. So, there is no need

for a centralised Coordination and Control to schedule processing, archiving and dissemination at given times, but rather these are run automatically and autonomously as soon as data are received at the receiving stations.

The main advantages of the “data driven” concept are:

o A large autonomy of acquisition and processing elements;

o A minimised risk of failures propagation: a temporary failure in Coordination & Control does not prevent remote facilities to continue working properly;

o A better autonomy with respect to satellite triggered activities: decisions taken at satellite level (e.g. which data takes are downlinked where) do not need to be reflected in a ground activities schedule;

o An increased Ground Segment availability: a temporary unavailability of the Coordination and Management system or of communication lines does not impact the availability of the processing and dissemination function.

So, the “data driven” concept applies to all systematic production activities triggered by the availability of new acquired instrument raw data at input of the production chain.

/104





The Figure 3.3-1 illustrates the scope of the data driven processes within the PDGS, highlighting the input data that trigger the processes in the different cases.

NRT Processing

Systematic Processing

Acquisition

IngestionDecryption

NRT L0 Processor

NRT User

IngestionDecryption

L0 Processor

L1B Processor

Sub-setting (Optional)

User

L0 Product Archive

(long term)

L1B Product Archive

(long term

User Product Archive

(short term

L1B Processor

Sub-setting (Optional)

L1B Processor User

NRT Mission Products Generation

Routine Mission Products Generation

Off-line MissionProductsGeneration

Products Reprocessing

Encrypted Instrument Source packets

NRT L1B Processor

Quality Control

Dissemination

Quality Control

Dissemination

SubscriptionList

Scope of Data Driven Processes

SubscriptionList

Source Packets

Source Packets

Production Request

Production Request

Figure 3.3-1: Scope of Data Driven Processes

An exception to the “Data Driven Concept”: Orders driven operations44

Even though systematic activities are “data driven”, non systematic ones remain “orders driven”, i.e. orders held in the central Coordination & Control and translated into “production

requests” trigger the non systematic activities for processing and dissemination. This concerns the possible reprocessing (if required) and dissemination following a user order and the periodic reprocessing of L0 or L1 data to higher levels following an update of the processing algorithms or of auxiliary data. In such case, in order to perform processing and distribute products to the right location, the processing and dissemination facilities need a minimum set of data (i.e. production requests) allowing correlation of instrument data takes (and then

products) to user orders. In such case, operations are triggered by the production requests rather than by the incoming of new data.

44 [RID D01-062]: Section reorganised and reworded to make clear that the “Data Driven Concept” is the main

concept, with “Order Driven” operations for archive orders being the only exception to that concept.

/104





3.3.2 Sentinel-1 Processing and Dissemination Concept

In the case of Sentinel-1, the two following scenarios are considered:

o Mission Orders Driven Acquisitions4546:

In the case of instrument acquisitions driven by Mission Orders, the complete process encompassing payload data reception, ingestion, decryption, processing, archiving, quality control and dissemination is data driven, i.e. the reception of raw data at the receiving station triggers the entire chain. This systematic processing concept applies to

NRT as well as to non NRT products. The complete chain can perform entirely autonomously without having to rely on any external input, except for dissemination. Dissemination is then based on subscription lists produced by the User Services and Coordination & Control. These include the dissemination addresses and subs-setting parameters. There is no necessity for synchronism between central coordination & control and remote processing facilities, i.e. the subscription lists are pre-existing and can be

retrieved asynchronously.

Note that the same systematic processing concept applies also for data takes derived from background planning.

o Users Orders47:

In the data-driven approach for users’ orders, the PDGS will need to identify for each data take the user orders and subscriptions it is relevant for via checking of time overlap.

As well, the dissemination requires specific information conveyed in the production requests, such as:

o In case of electronic dissemination: ftp address or e-mail address to inform the user about the availability of the product once it has been generated

o In case of dissemination via media: shipping address48


In the Sentinel-2 case, processing, archiving and dissemination will be systematic and data driven. An option to reduce the processing and dissemination load is to restrict systematic processing based on data quality (e.g. no production of cloudy data), or on subscription basis (so some data shall be processed from a lower data level only on-request)49.

The distribution of products to the Service Segment will nominally use the subscription mechanism, i.e. each entity in the Service Segment will be seen as a subscriber.

For Sentinel-2, three levels of service are identified:

o Near Real time: dissemination within 3 hours from sensing

o Non NRT but still time critical: dissemination within 1 day from sensing

45 [RID D01-063]: Text updated to clarify that the Processing and Dissemination does not see Mission Orders

46 [RID FR-D01-01]: Text updated to remove the improper term “Systematic acquisitions” and replace by

“Mission Orders Driven Acquisitions”

47 [RID D01-064]: Text updated – Correspondence for users orders via time overlap

48 [RID D01-018]: Added shipping address as typical information needed for dissemination

49 [RID D01-020]: Included restrictions on systematic processing for Sentinel-2

/104





o Non time critical: dissemination within 1 week from sensing

In order to comply with stringent timelines for NRT processing and dissemination, it might prove necessary to collocate the processing and dissemination with the receiving station in order to

save time that would be needed to circulate Instrument Source Packets from the receiving station to the Processing and Dissemination facility50.

Processing shall be fully systematic, systematic based on quality (e.g. no production of cloudy

data), or on subscription basis (so some data shall be processed only on-request from a lower data level)

An option for products dissemination would be to make the PDGS to Service Segment interface work in “pull mode”, i.e. delivery of new Sentinel-2 L1b products would not be systematic, and the Service Segment would periodically query the PDGS to search for new products over a given area of interest. This implies a search function via the catalogue and

on-line access to products.

A service to distribute huge volumes of data to users or service segment entities not having a dissemination interface via a high bandwidth dissemination network still needs to be considered. Operationally, this service would be provided off-line, i.e. users would submit orders for bulk dissemination via media of archived data (“archive orders”). However, given

the operational load and manpower cost induced by such a service, the latter shall be considered as an exceptional service made available to privileged users only51.


As for Sentinel-2, the dissemination of Sentinel-3 products will be based on the subscription

mechanism, with dissemination on media remaining the exception The PDGS to Service Segment interface should be simpler than for Sentinel-2 since the operational character of the service for oceanographic data implies well defined and stable rules for the dissemination of products to predetermined locations (modellers and/or data servers) on the basis of the product types and geographical location of the products.

3.3.5 Synthesis of Processing and Dissemination

The following Figures illustrate the Processing and Dissemination operations concept for:

- Systematic data driven processing and dissemination, following reception of data at the receiving stations (Figure 3.3-2)

- User Order driven processing and dissemination (Figure 3.3-3)

- On-demand re-processing from archived data (Figure 3.3-4)

- Archive extraction with L1B product sub-setting (Figure 3.3-5).

50 [RID D01-019]: Introduction of NRT concept for Sentinel-2 products processing and dissemination

51 [RID D01-065]: On-demand orders for dissemination via media of large volumes of data

/104





• Ingestion• Decryption• Ingestion• Decryption

• Signal Acquisition• Amplification• Frequency Down-

Conversion• Demodulation



L0 ProcessingL0 Processing

L0 Products Formatting &

Archiving


Archiving

L0 pro

ductDecrypted

ISP’s

Encry

pted

ISP’s

Raw Instrument Telemetry

Auxiliary data for Processing

Subscription Lists

L1B ProcessingL1B Processing

L1B Product Archiving

L1B Product Archiving

Product Dissemination


L1BproductL0 product

Browse Product Systematic Products Quality

Control

Systematic Products Quality

Control

Decryption Keys

SAR BrowseProduct

L1B product

Quality Annotations ��

Master Catalogue

L1B product


Control


Control

Subscription Lists


Master Catalogue

Figure 3.3-2: Processing and Dissemination Concept – Systematic Processing52

• Ingestion• Decryption• Ingestion• Decryption





L0 ProcessingL0 Processing


Archiving


Archiving

L0 pr

oduc

tDecrypted ISP’s

Encryp

ted

ISP’s

Raw Instrument Telemetry

Auxiliary data for Processing

Subscription Lists

L1B ProcessingL1B Processing Product Dissemination


L0 productBrowse Product Systematic

Products Quality Control


Control

Decryption Keys

SAR BrowseProduct

L1B product


Master Catalogue

L1B product


Control


Control

Production Requests


Master Catalogue

Production Requests

Figure 3.3-3: Processing and Dissemination Concept – User Order Driven Processing5354

52 [RID D01-101]: Figure updated to show Systematic Products QC applying also to Level 0 Products + Browse

products can be generated at Level 0 or Level 1B processing stage according to the type of instrument

/104





L0 product

Auxiliary datafor Re-Processing

incl. Additional Auxiliary Data e.g.

POD Production

Request

L1B ProcessingProduct

Dissemination


Control

L1B

pr

oduc

tQuality Annotations ��

Master Catalogue

Production Request

Catalogue Search

L0 Product Archive

Extraction

Production Request

L1B

pr

oduc

t

Figure 3.3-4: Processing and Dissemination Concept – On-Demand Re-Processing55

53 RID D01-079: Figure 3.3-3 updated to remove systematic archiving of L1B products resulting from users

orders

54 [RID D01-101]: Figure updated to show Systematic Products QC applying also to Level 0 Products + Browse

products can be generated at Level 0 or Level 1B processing stage according to the type of instrument

55 RID D01-079: Figure 3.3-4 updated to remove systematic archiving of L1B products resulting from users

orders

/104





L0 product

Production Request

Product Sub-setting

L1B Product Temporary Archiving


L1Bproduct


Control

L1B

pr

oduc

t

Production Request

Catalogue Search

L0 Product Archive

Extraction

Production Request

L1B

pr

oduc

t

Long-Term

Archive

Figure 3.3-5: Processing and Dissemination Concept – Archive extraction with L1B product sub-

setting

3.4 Interoperations Concept

Whilst a Sentinel mission can stand alone in its own right, its interoperation with other missions

would provide added benefits and significant value-added product opportunities to the users.

Therefore, the PDGS shall be designed in such a way that it can be interoperated with the ground segments of other missions. This interoperability capability would facilitate coordinated data streams for instance for the generation of multi-frequency products.

One area of interoperability is the capability offered to users to submit “joint orders” in view of

the coordinated delivery of products from interoperating missions (the generation of resulting value added products is outside the responsibility area of the GMES PDGS).

In order to ensure interoperable operations, interfaces between the two systems are required. At the first level, interoperability requires interfaces between the two systems for:

o Seamless access to interoperable catalogues

o Submission of Joint or Multi-mission Orders

o Coordinated Delivery of products

The candidate Sentinel/Partner Missions Interoperability Scenarios are described in section 4.3.2.3.356.

56 [RID D01-069]: Interoperability Scenarios moved from section 3.4 to section 4.3.2.4

/104





4 Detailed Operations Scenarios

4.1 Purpose

The purpose of this section is to provide a detailed description of operations scenarios within the PDGS for a number of typical use cases. The description of operations scenarios is intended to:

- List the main hypotheses taken into account to establish the scenario

- Detail for each scenario the chronological sequence of operations or actions performed

by the PDGS in each functional domain, i.e. User Services, Facilities Ground Segment, and

Sensor Performance, Products and Algorithms Domain (SPPA);

- Identify and characterise the data or information exchanged between functional

domains;

- Identify and characterise the data or information exchanged between the PDGS and the

outside world, e.g. satellite, FOS, users;

For each scenario, a sequence diagram is provided, together with a brief textual description highlighting the main operations / tasks and the main information exchange.

4.2 List of Scenarios

The following table provides an overview of the scenarios described in this chapter, indicating

the applicability of each scenario to the Sentinel satellite missions (Sentinel-1, -2 and -3) and to the legacy missions.

Applicability SCENARIOS

Sent-1 Sent-2 Sent-3 Legacy

Missions

A: Systematic Operations Scenarios

A.1 Mission Orders Handling X X

A.2 Ordering from third party missions X TBD

A.3 Sent-2/Sent-3 Mission Planning X X

A.4 Systematic Processing and Dissemination

A.4.1 Products Dissemination via Subscriptions X X X X

A.4.2 L1B NRT Delivery via Subscription X X57 X X

A.4.3 L2 NRT Delivery via Subscription X X

A.5 Reprocessing X X X X

B: User Driven Operations Scenarios

B.1: Orders for New Products

B.1.1: Single orders (including planning, processing and dissemination)

X 58 X

57 [RID D01-023]: L1B products NRT delivery applicable for Sentinel-2

/104





Applicability SCENARIOS

Sent-1 Sent-2 Sent-3 Legacy

Missions

B.1.2: Time series orders (including planning, processing and dissemination)

X 59 X

B.1.3: Coverage orders (including planning, processing and dissemination)

X 60

B.1.4: Orders for direct downlink to a user station

X X X X

B.1.5: Sentinel Multi-mission orders (including planning, processing and dissemination)

X

(TBC)

X

(TBC)

X

(TBC)

B.2: Emergency Orders

B.2.1: Sentinel-1 Emergency orders X

B.2.2: Sentinel-2 Emergency Orders X

B.2.3: Sentinel-3 Emergency Orders for Fire Monitoring

X

B.3 Orders from archived products

B.3.1 Without processing X X X X

B.3.2 With processing X X X X

B.3.3 Orderless Data Provision from Archive X X X X

B.4: Sentinel/Third Party Missions composite orders

(including planning, processing and

dissemination)

X partially

applica

ble

partially

applica

ble

B5: Transverse Scenarios

B.5.1 Encryption and Keys Generation and Handling

X X X

B.5.2 POD Handling X X X

B.5.3 Auxiliary Data Management X X X

C: SPPA Scenarios

C.1 Subscription to Calibration Products X X X X

C.2 Orders for dedicated Calibration Products X X

D: PDGS Monitoring Scenarios

D.1: PDGS Operating and Monitoring X X X X

E: PDGS Maintenance Scenarios

E.1: PDGS Evolution X X X X

Table 4.2-1: List of Scenarios

58 [RID D01-024]: Confirmed that this scenario is not applicable to Sentinel-2



/104





Since the purpose of this document is to present the overall concept of operations within the PDGS in the GMES era, only nominal operations scenarios are described.

In case of non-nominal situations such as emergencies and failure cases, a set of recovery actions is needed to return back to a nominal behaviour. Such cases are not described in the present [DIL-01], but are the subject of [DIL-11] “PDGS Operations Concept”.61

61 [RID D01-027]: Note added stating that recovery actions are part of [DIL-11] « PDGS Operations Concept ».

/104





4.3 Scenarios Description

4.3.1 Systematic Operations Scenarios

4.3.1.1 A.1: Mission Orders Handling

The scenario for the handling of Mission Orders is presented on Figure 4.3-1.

It has to be noted that the same scenario applies in the case of single mission orders (one shot orders covering only one strip line), time series mission orders, coverage mission orders, or any combination thereof. So, the figure and the text refer to a generic scenario applicable to all types of mission orders.

PDGS

Mission Management User Services

Order HandlingMission Planning

Data Library (LTA)Dissemination

Instrument ParametersPQC

IngestionDecryption

Requests HandlingProcessing

MMUS MMFI

Station ControlData Recording

MMFI Station SPPAFlight

Operations Segment

Sentinel-1 Satellites

Mission Order Implementation Mission Order

PlanningData Take Schedule (Daily Update)

Sensing Request

ProductsQuality Checks

Instrument Parameters

Commands Generation & Authentication

SensingUplink

Downlink

Downlink Plan

Raw data Reception

Circulation (encrypted ISP’s)

Data Take Quality Check Data

L0/L1B Products

Metadata & Browse Products

Annotations

IngestionDecryptionProcessing

Replay Keys (from FOS)

InstrumentParameters Generation

Statistics Generation

Statistics

Statistics Consolidation

Mission Order Fulfilment Statistics

A.1: Mission Orders Submission & Handling

Detailed Mission Operation Plan

Uplink Report

L0/L1B Product Archiving

Figure 4.3-1: Scenario A.1 - Mission Orders Handling

4.3.1.1.1 Assumptions

The main assumptions taken into account in this scenario are as follows:

o Mission Orders Definition

Mission Orders are defined by EOP-A:

/104





� A priori to answer the global objectives of each Sentinel mission, i.e. systematic coverage of a given region of interest in a given instrument mode at a given time interval.

� A posteriori to respond to the common needs of a community of users for systematic and periodic acquisitions over a given region of interest.

o Mission orders and subscriptions:

Mission orders are defined independently of subscriptions, although it is likely that both mission orders and subscriptions will be linked via a common interest on the user side. From the operations scenarios standpoint, mission orders are defined first, subscriptions

are defined at the same time or later, but there is no necessity to link them. Similarly, there is no one-to-one relationship between Mission Orders and Subscriptions. For instance, a Mission Order can generate several subscriptions, or a subscription may be related to several Mission Orders. Similarly, subscriptions can also encompass products that are generated from users’ orders in addition to products resulting from Mission Orders.

o Geographical coverage and time period for Mission Orders:

Most Mission orders will be defined as time series / coverage orders, i.e. they will concern a large Region of interest (wider than one single swath) and will have a repeat period. However, the description in this scenario neither makes any assumption, nor introduces any restriction on the type of mission orders that are handled.

In the case of time series orders, one mission order will generate multiple acquisition

requests.

At the time of implementation of the time series mission order, the mission planning incorporates in the data take schedule as many acquisition requests as possible, according to:

� The repeat period specified by the mission operator;

� The time period covered by the time series order;

� The possible conflicts with other time series mission orders or with higher priority orders already in the long term mission plan.

The follow-on process for mission orders takes into account the fact that multiple instances of acquisition requests will exist at different times, and so the time series acquisition requests will be instantiated in successive releases of the data take

schedule.

As for time series mission orders, one single coverage mission order will generate multiple acquisition requests, that all together will allow to achieve the specified coverage.

So, at the time of implementation of the coverage order, the mission planning will include in the mission plan the complete set of acquisition requests allowing

achievement of the specified percentage of the coverage within the specified time span (e.g. 80% within one month).

The corresponding acquisition requests are incorporated in the short term plan (96 Hours) as they become eligible for execution within the next planning period.

o PDGS/FOS roles:

The responsibility of computing stations pass data lies with the PDGS, which uses orbit

information provided by the FOS. This may be either the reference orbit parameters or predicted orbit parameters (TBD).

The same applies for the management of the replay keys, i.e. they are generated inside a specific facility hosted by the FOS, but their transmission to the receiving stations is under the responsibility of the PDGS.

/104





The generation, management and distribution of crypto keys are described in a specific scenario (B.5.1).

o Management of Precise Orbit Data:

In order to simplify the receiving stations interfaces, all GNSS pseudo range data are always downlinked to the same ground station. Since the agreed baseline for Sentinel-1 is that the primary receiving station used for downlink will be the Svalbard station (because it provides visibility on all orbits), GNSS pseudo range data will always be downlinked to the Svalbard station. Consequently, only this station would need to have an interface with the selected (TBD) POD service providers.

o Decryption

The current baseline for Sentinel-1 is that the decryption of instrument source packets takes place where processing also takes place, i.e. not at the receiving station. Consequently, instrument source packets are circulated in encrypted form from the receiving station to the facilities ground segment.

Alternatively, decryption could be performed at the receiving station. This would allow

immediate check on downlinked payload data and avoid possible delays and complexity in detecting and fixing problems. However, in this case, instrument source packets may require to be re-encrypted before being circulated to where processing takes place, according to the rules enforced by the security policy62.

4.3.1.1.2 Scenario Description

In the present scenario, Mission Orders are directly implemented in the Mission Planning by the Mission Operator following directives from mission management.

The acquisition request(s) resulting from the mission orders are incorporated in the long term mission plan, if there is no conflict of priority with other mission orders or higher priority orders already in the plan.

Once the set of acquisitions corresponding to the mission order are due for execution during the next planning period (i.e. next 28 days), these acquisition requests are firmly scheduled. The data take schedule incorporating the acquisition request (i.e. 28-day plan) is passed to

the FOS. In this schedule, the first 96 hours are due for uplink the same day during a late afternoon pass over the primary TMTC station. The subsequent 24 days are used by the FOS to optimise the scheduling of satellite manoeuvres in such a way that minimum impact on the already scheduled data takes is ensured, and as back-up if for some reason the PDGS is not in a position to generate or send further updates of the data take schedule.

Using the information provided by the SPPA (instrument parameters), the FOS generates the

corresponding telecommands. They are authenticated, merged with all other platform and payload telecommands covering the same 96-hour time span and uplinked to the spacecraft.

In parallel, the PDGS computes the downlink plan and provides the receiving station to which the raw data for the planned requests will be downlinked with the data necessary to handle the pass. The station pass data are computed using the orbit parameters (predicted orbit or

reference orbit – TBD) provided by the FOS.

Once the satellite has performed the data sensing, the corresponding instrument raw data are downlinked in encrypted form or in clear to the selected receiving station.

The receiving station performs the reception of the instrument raw data, extracts the GNSS raw data from the source packets and transmits them to the Precise Orbit Determination

62 [RID D01-133]: Text about where decryption takes place relaxed (i.e. either receiving station or processing

facility at ingestion stage).

/104





service provider, and circulates the still encrypted raw data to where facilities ground segments performing ingestion, decryption and processing are located.

The instrument raw data are then ingested, optionally decrypted using the replay keys

distributed by Mission Planning, and processed first to Level 0 and then to Level 1B.

Both Level 0 and Level 1B products are then permanently archived in the long term archive.

Metadata and browse products are generated and circulated to the master catalogue.

In parallel, quality checks are performed by the SPPA and quality annotations are generated to supplement the metadata.

The process for submission and handling of time series mission orders is similar to the one for

single orders.

4.3.1.2 A.2: Ordering from Third Party Missions

The process for ordering from Third Party Missions is as described in Section 4.3.2.4.

4.3.1.3 A.3: Sentinel-2/Sentinel-3 Mission Planning63

At this time, since Sentinel-2 and -3 Definition Study Phases are still on-going, the scenario for Sentinel-2 and Sentinel-3 Mission Planning is based on a number of hypotheses that still need to be consolidated.

The main assumptions taken into account in this scenario are as follows:

o Sentinel-3 satellites will perform on-board autonomous acquisitions based on the a-priori knowledge of the areas to be sensed. Based on this assumption, the role of the PDGS in mission planning should be restricted to scheduling the downlink sessions and distributing the replay keys, whereby it is assumed that one single key per downlink sessions will be used.

o In the Sentinel-2 case, the mission planning is less automated. Systematic mission orders

are implemented by the mission officer on behalf of the mission management. The scenario is then similar to scenario A.1. The acquisition scenario is repeated from one orbit cycle to the next one. Some variations in the acquisition scenario can be accommodated, in order to take into account the seasonal variations of some parameters like the sun illumination. Thus, a new data take schedule needs to be uplinked at periodic time intervals.

So, the scenario illustrated by Figure 4.3-2 below makes the distinction between systematic operations (bottom of the figure) and non-systematic operations potentially requested to refresh the on-board schedule of acquisitions.

63 [RID D01-029] : Clarification of Mission Planning concept for Sentinel-2

/104





PDGS





IngestionDecryption


MMUS MMFI



Operations Segment

Sentinel-2/3 Satellites

ProductsQualityCheck

SensingDownlink

Downlink Plan

Raw data Reception



L0/L1B Product


Annotations


Replay Keys

Downlink Plan Generation

Replay Keys GenerationReplay Keys

Orbit parameters

A.3: Sentinel-2/3 Mission Planning

L0/L1B ProductArchiving

Mission Management Directives

Instrument Operations Planning Data Take Schedule (Periodic Update)

Sensing Request

Instrument ParametersCommands Generation & Authentication


Uplink ReportUplink

Non

Sys

tematic

(onc

e

eac

hTBD orb

itcy

cle)

Rou

tine

Ope

ration

s(D

aily)

Figure 4.3-2: Scenario A.3: - Sentinel-2/3 Mission Planning

/104





4.3.1.4 Systematic Processing and Dissemination

4.3.1.4.1 A.4.1: Product Dissemination via Subscriptions

In the case of Mission Orders, the normal way for the end users of receiving products will be via subscriptions, although subscriptions, as explained earlier, do not relate exclusively to subscriptions.

The definition of a subscription results from an analysis of common requirements from several users to systematically receive products sharing common characteristics (e.g. covering a specific geographical area). The Mission Management will then define the types of products,

geographic areas and time validity period available for each subscription, and advertise this via the users services. Before joining a subscription, users will need discussing their data needs and get the authorisation from mission management. So, the fact for a user to join a subscription will be a matter of personal interaction with the Help and Documentation Desk or Order Desk.

This is illustrated by Figure 4.3-3 below, which highlights in red the specific operations and

information exchanges linked to the subscriptions. Note that the part in black is the same as for the previous scenarios.

PDGS

End User / Service

Segment

User ServicesOrder Handling

Mission Planning



MMUS MMFI



Operations Segment

SentinelSatellites


Sensing

Downlink

Payload data Reception



L0/L1B Products


Annotations


Subscription Advertising (via users services)

Registration to subscription

Product Formatting (including sub-setting)


A.4.1: Subscription mechanism

Subscription Definition

Subscription List

Archiving

IngestionDecryption


End User ProductQualityCheck

Figure 4.3-3: Scenario A.4.1 - Product Dissemination via Subscription

The principle is that the Mission Management defines the subscriptions made available to the users or service segment. These are advertised to users via the Users Services, thus users are able to register or not to those products available via subscriptions.

The registration to a subscription by a user will include the definition of:

/104





o The user delivery address

o The specification of the subset of the subscription in which the user is interested

Users registrations to products available via subscription are handled by the Order Handling

and Production Planning that generates a subscription list. This subscription list is modified upon one of the following events: registration of a new user, modification of the specifications from users (e.g. Change of definition of the “area of interest”), cancellation of user subscription. The subscription list is then passed from the User Services to the Ground Segment Facilities performing dissemination.

No processing as such is performed, i.e. the matching of the subscribed products to the user

defined criteria like area of interest is performed by sub-setting the original Level 1b products. At this stage, the existence of the sub-setting functions and the definition of the sub-setting parameters made available for each product type are TBC64.

4.3.1.4.2 A.4.2: L1B NRT Delivery via Subscription

In the case of NRT Delivery, the main difference with respect to the previous case is that the product dissemination takes place directly after processing in order to ensure a 3-hour maximum time between sensing and dissemination.

Thus, all operations that are not directly necessary from the user standpoint can be parallelised with the dissemination (i.e. archiving.

One option (still TBD) would be to adopt a simplified processing approach, saving the processing steps that are not strictly necessary for the generation of the “user product”.

Once available, the user L1B product is subject to sub-setting (TBC), formatting and dissemination to the address specified by the user.

64 [RID D01-030]: The sub-setting function and related sub-setting parameters per product type are currently

TBD.

/104





PDGS

End User / Service

Segment


Mission Planning



MMUS MMFI



Operations Segment

Sentinel-2/3 Satellites


Sensing

DownlinkPayload data ReceptionCirculation

(encrypted ISP’s)

Data Take Quality Check DataMetadata & Browse Products

Annotations



L0/ L1B Products

A.4.2: L1B NRT Delivery via subscription

Product Quality Check Results

Archiving




Subscription List

Max

Tim

e: 3

hou

rs



IngestionDecryption


Figure 4.3-4: Scenario A.4.2 - L1B NRT Delivery via Subscription

4.3.1.4.3 A4.3: L2 NRT Product Delivery via Subscription

This case is applicable to Sentinel-3 only (TBC).

As shown on Figure 4.3-5, it requires additional steps performed by the MMFI, i.e. Level 2

Processing following immediately the L0/L1B processing.

For some products – e.g. radio-altimetry Level 2 products in the Sentinel-3 case, the processing to Level 2 requires precise orbit determination. This relies on additional auxiliary data from external sources like atmospheric and ionospheric parameters and GNSS ephemeris. The timely availability of this auxiliary data is then a prerequisite for processing and delivery within NRT constraints for these products65.

It is also assumed that sub-setting if required will be included at the stage of the Level 2 processing. So, product formatting and dissemination can proceed immediately after Level 2

product generation.

65 [RID D01-089]: Need for external auxiliary data for Precise Orbit Determination added (text and figure)

/104





PDGS

End User / Service

Segment


Mission Planning



MMUS MMFI


MMFI Station SPPAAuxiliary

Data Provider (s)

Sentinel-3 Satellite

A.4.3: L2 NRT Delivery via subscription

Basic ProductsQualityCheck

Sensing

Downlink

AcquisitionCirculation (encrypted ISP’s)



Annotations


Product Formatting


L0/ L1B Products

Basic Product Quality Check Results

L0/L1B Archiving




Subscription List

L2 ProcessingL2 Product for QC

L2 Product Quality Check Result

L2 ProductsQualityCheck

L2 Product

IngestionDecryption



External auxiliary data for processing incl. e.g. atmospheric and ionospheric parameters & GNSS Ephemeris data

Figure 4.3-5: Scenario A.2.3 - L2 NRT Delivery via Subscription

4.3.1.5 A.5: Reprocessing6667

Reprocessing campaigns nominally take place after the end of the Commissioning Phase and

after a major processor upgrade (or a major change in the processing setting or auxiliary data information). The scope of the reprocessing exercise is the harmonization of EO Mission Data Set for the maintenance of the long term record. The long term record provides then the ability to monitor long term geophysical variations through maintenance of required levels of accuracy, continuity, calibration, stability, and documentation. So, long term data consistency is ensured68.

In the satellite area, reprocessing of long term record is a prerequisite for the study of long-standing phenomena (e.g. climate studies).

The EO Mission reprocessing exercise nominally occurs:

o Shortly after the end of the commissioning phase, as initial calibration, characterisation and validation feedback is converted in a first product improvement.

66 [RID D01-109]: “Systematic Reprocessing” amended to read only “Reprocessing”

67 [RID D01-110]: “Reprocessing” scenario moved to Section 4.3.1 “Systematic Operations Scenarios”

68 [RID D01-094]: Added reference to the fact that reprocessing is required to ensure long term data

consistency.

/104





o After important changes to the processing algorithms (including changes to file formats and Auxiliary Data File). During the exploitation phase, the algorithm evolution process results in regular major updates at a frequency of once per 1 to 1.5 years.

o After a peculiar on-board or on-ground anomaly/event (usually short reprocessing period).

The purpose of the reprocessing is to bring past data products at the same level of quality and format of the current data set or better. In that sense, the reprocessing of an EO data set can be:

o Partial (identified time periods: specific mission phases, cycles, etc);

o Complete (whole mission);

o Reprocessing of Level-1 products shall start from archive Level-0 data;

o Reprocessing of Level-2 products may start from Level-1 archive data.;

o Reprocessed data shall replace the previous products version in the data catalogue.

The scenario for reprocessing is then illustrated by Figure 4.3-6 below which shows the case

of reprocessing to Level 1B or Level 269 from archived Level 0 products.

A.5: Reprocessing

PDGS





MMUS MMFI


MMFI Station SPPA

Reprocessing Decision

L0 Product Extraction from Archive

Catalogue Update

Production Request

L0 to L1B / L2 processing

L0 ProductAuxiliary Data

L1B/L2 ProductProduct Quality Check

L1B/L2 Product

ProductArchiving

Processing Centre Selection

IngestionDecryption


Reprocessing Planning

Reprocessing Status ReportingProduct Formatting (including sub-setting (TBC)



Optional Dissemination of reprocessed products

Figure 4.3-6: Scenario A.5 –Reprocessing70

The main peculiarities in this scenario are the following:

69 [RID D01-107]: Reprocessing covers also Level 2

70 [RID D01-076]: Added optional dissemination of reprocessed Level 1B/Level 2 Products.

/104





o Reprocessing decision: the latter is made at Mission management level. It is then assumed that reprocessing is not initiated through standard orders, but that a specific reprocessing schedule will be established taking onto account the availability of the

resources (computer hardware) required to perform reprocessing.

o The figure shows that reprocessing is initiated through a set of production requests directed toward the Production Requests Handling function in the centre(s) in charge of reprocessing. However, how and where the production requests are generated is TBD at this stage.

o Before processing starts, it must be ensured that:

� The adequate versions of the instrument processors have been installed and thoroughly tested where the reprocessing takes place;

� The valid set of auxiliary data is available from SPPA.

Reprocessing then takes place according to the following steps:

o Extraction of L0 data from archive according to the reprocessing specifications

contained in the production requests;

o Reprocessing to Level 1B and Level 2 as appropriate

o Update of metadata fed into the master catalogue

o Product Quality Control by the SPPA function, and generation of quality annotations appended to the metadata

o Possibly, regeneration of browse products (TBC), depending on the instrument (i.e. in the Sentinel-1 SAR case, browse products are a sub-product of Level 1B, but for some other instruments, it might be that browse products will not be regenerated as result of

L1B reprocessing)

o Re-archiving of the reprocessed Level 1B or Level 2 product (the new version replaces the older one).

It has to be noted that in the case of reprocessing, dissemination via subscriptions should not

be automatic as in the case of normal processing. However, reprocessed products may be optionally disseminated.

/104





4.3.2 User Driven Scenarios

4.3.2.1 Orders for New Products

4.3.2.1.1 B.1.1: Single orders (including planning, processing and dissemination)71

This scenario is illustrated by Figure 4.3-7.

The main differences with the previous scenarios are the following:

o With respect to Scenario A.1:

o the order is submitted by the user, and not implemented directly in mission planning by the mission planning officer. In case of an order requiring acquisitions requests in conflict with acquisition requests having a higher priority, alternative acquisition opportunities can be attempted if the user order parameters have been specified with enough flexibility. Otherwise, the user is advised that his/her order is not feasible, and he/she is invited to change the

parameters of the order in order to get a chance of it being satisfied.

o The “Order Handling and Production Planning” facility of the MMUS generates a production request including the priority for processing, the processing parameters (if any) and the information required for the dissemination, e.g. dissemination address.

o With respect to Scenarios A.2 and A.3:

o At the dissemination stage, no sub-setting should be required, since it is anticipated that the L1B product generated will match exactly the user defined region of interest (except if the acquisition request has been merged with another one). Dissemination can then take place just after product formatting.

o Metadata and Browse Products are not systematically sent back to the User Services Coordination and Control to feed the Master Catalogue. This is in particular because, while L0 products will be systematically archived, L1B products will not72.

71 [RID D01-031] : Title changed to « Single Orders (including planning, processing and dissemination) »

72 [RID FR-D01-02]: Comment added in the text to state that Metadata, Browse products and annotations

transfer from APAD to Master Catalogue is not systematically triggered as part of the scenario.

/104





PDGS


Mission Planning



MMUS MMFI



Operations Segment


Order Submission

Order Handling & Mission Planning

Data Take Schedule (Daily Update)

Sensing Request



Sensing

Uplink

Downlink

Downlink Plan & Replay Keys

Payload Data ReceptionCirculation

(encrypted ISP’s)


L0 ProductsL1B Products (TBC)

Metadata & Browse Products (TBC)

Annotations


Replay Keys


End User / Service

Segment

FormattingDisseminationL1B Product

Production Request

L0/L1B Products Archiving

B.1.1: Single users orders (including planning, processing and dissemination)


Uplink Report

IngestionDecryption


Figure 4.3-7: Scenario B.1.1 - Single User Order submission with planning, processing and

dissemination

4.3.2.1.2 B.1.2: Time series orders (including planning, processing and dissemination)73

The process for submission and handling of time series users’ orders is similar to the one for single orders, except the fact that the Order Desk may be involved to support users in the

specification of their Time Series Orders. The role of the Order Desk in this context is to understand the real users’ needs and possibly negotiate with the users to increase the probability of success of the order fulfilment. The Order Desk staff would then enter directly the users’ time series orders in the Order handling System74.

In the case of time series orders, one order corresponds to multiple acquisition requests.

At the time of submission of the time series order, the mission planning incorporates as many acquisition requests as feasible, taking into account:

o The repeat period specified by the user

o The time span covered by the time series order

o The possible conflicts with other time series orders or with higher priority orders already in the long term mission plan.

73 [RID D01-031] : Title changed to « Time series Orders (including planning, processing and dissemination) »

74 [RID D01-070]: Involvement of Order Desk to support the Users in the specification of Time Series Orders

/104





The follow-on process is identical to the case of single orders, with the only exception that multiple instances of acquisition requests will exist at different times, and so the time series acquisition requests will be instantiated in successive releases of the data take schedule.

The process for processing and dissemination is as for single orders.

4.3.2.1.3 B.1.3: Coverage orders (including planning, processing and dissemination) 75

The process for submission and handling of coverage users’ orders is similar to the one for time series mission orders, involving the Order Desk to support users in the specification of their coverage orders76.

As for time series mission orders, one single coverage order will generate multiple acquisition requests, that all together will allow to achieve the user specified coverage.

So, at the time of submission of the coverage order, the mission planning will attempt to implement the specified coverage by including in the mission plan multiple acquisition requests allowing completion of the specified percentage of the coverage within the

specified time span (e.g. 80% within one month).

The corresponding acquisition requests are incorporated in the short term plan (96 Hours) as they become eligible for execution within the next planning period.

After sensing, the follow-on process is identical to the two cases described above.

75 [RID D01-031] : Title changed to « Coverage Orders (including planning, processing and dissemination) »

76 [RID-D01-070]: Involvement of Order Desk to support the Users in the specification of Coverage Orders

/104





4.3.2.1.4 B.1.4: Orders for direct downlink to a user station

This scenario relates to the case of a user submitting an order requiring a new acquisition, whereby the Instrument raw data are not downloaded to a PDGS receiving station but to a

user station.

The scenario is described on Figure 4.3-8.

PDGS


Mission Planning



MMUS MMFI SPPAFlight

Operations Segment

SentinelSatellites

Order Submission Order Handling &

Mission PlanningData Take Schedule (Daily Update)

Sensing Request


Sensing

Uplink

Downlink Plan & Replay Keys

Replay Keys


End User

B.1.2: Users Orders for Download to Users Stations


Uplink Report

IngestionDecryption


User receiving Station

• Instrument data Reception

• Decryption

• Processing• Dissemination

Downlink

Auxiliary Data

L0 Products Repatriation

Figure 4.3-8: Scenario B.1.4 – Order for download to a user station

The red lines on the Figure indicate the specificities:

o At the time of order submission, the user will specify a station identifier for the downlink of data. It is assumed here that the station is already known by the system, i.e. the station characteristics (latitude, longitude, altitude, reception mask, etc…) have been transmitted through the “station capability” file. As well, the station availability information is available (available slots for downloads).

o Once the data take schedule has been computed, the PDGS will compute the downlink plan for the user station. This downlink plan is transmitted to the station together with the pass data (AOS and LOS time and azimuth/elevation angle) and with the decryption keys themselves encrypted with the station public key.

o The downlink of instrument raw data corresponding to the user order is made directly to the user station. Here, we do not make any hypothesis on whether this data is

downloaded only to the user station, or also to one of the PDGS receiving stations.

o The user terminal associated to the user station performs the raw data reception, decryption and processing and it is also in charge of the dissemination to the local

/104





users (if for instance the owner of the station is an operator who has signed an agreement with ESA to disseminate products to local customers). The processing makes use of auxiliary data fetched on-line from the SPPA domain.

o The assumption is made here that the user terminal includes an instrument processor capable of generating products in accordance with the basic products specification for the concerned mission, i.e. the terminal hosts a generic instrument processor.

o According to the agreements made with ESA, the following can then occur:

� Either the data takes received at the user terminal are downlinked twice, i.e. once to the user terminal and once to a PDGS receiving station77.

� Or the user terminal repatriates back L0 products to the PDGS, in order for them to be archived centrally. This assumes a specifically agreed or common format for L0 products exchange.

4.3.2.1.5 B.1.5: Sentinel Multi-mission orders (including processing and dissemination)

This scenario covers the case of ordering composite products from different Sentinel satellites (e.g. Sentinel-1 and Sentinel-2).

It has to be noted that its is still TBD at this stage whether the PDGS shall provide such a “multi-

mission” products ordering capability or whether this capability should only be provided via the Service Segment78.

Since only Sentinel-1 will provide the capability to users to order individual (or time series, or

coverage) products while in the Sentinel-2 and Sentinel-3 cases, all acquisitions will be systematic, the possible scenarios for Sentinel multi-mission ordering are:

o Either via catalogue search of collections of archived products matching common criteria (e.g. same region of interest and sensing date within a given time interval): in this case, the scenario is equivalent to ordering archived products identified via the catalogue. A composite user order is then split into individual orders for each of the Sentinel missions’

products collections and translated into production requests directed towards the centre(s) holding the corresponding archives.

o Or via catalogue search for e.g. Sentinel-2 and/or Sentinel-3 products matching user defined criteria and ordering of Sentinel-1 products as per scenarios B.1.1 through B.1.3 described earlier.

o Or via subscription, assuming that there will be global subscriptions, i.e. subscriptions encompassing products from different Sentinel missions.

4.3.2.2 Emergency Orders Submission and Handling

4.3.2.2.1 B.2.1: Sentinel-1 Emergency Orders

Emergency orders are defined as orders submitted after the nominal cut-off time for the

submission of orders (for instance 08:00 am UTC– TBC), thus requiring an emergency procedure to be put in place in order to allow the order to be taken into account after this cut-off time and the corresponding acquisition requests to be uplinked within timelines shorter than in the nominal case.

The requirement (“red phone” requirement) for such emergency orders is the following:

77 [RID FR-D01-03]: Assumption made that data takes downlinked to a user terminal are also downlinked to a

PDGS station, so, no metadata and browse products are sent back to the PDGS

78 [RID D01-091]: Disclaimer added

/104





“The GS shall support emergency ordering, mission planning and satellite tasking within timelines shorter than those applicable to nominal operations:

o The time between placement of an emergency order and the resulting sensing

request being available for uplink to the S/C shall not exceed 3 hours if the emergency order is placed during normal working hours;

o The time between the sensing request being available for uplink to the S/C and the actual uplink to the S/C, as a selectable option for emergency orders, shall not exceed 6 hours if the sensing request becomes available during normal working hours.”

Consequently, in the worst case, it can be assumed that the emergency order will be submitted after a conflict free schedule has already been generated by the PDGS and used by the FOS to generate the corresponding payload telecommands.

This will then require an updated data take schedule to be computed by the PDGS and sent to the FOS, with the following assumptions:

o Since emergency orders will have the highest priority level, they will in case of conflict

supersede any order of lower priority;

o The PDGS will identify the list of orders in conflict with the emergency order and cancel them from the plan. The rescheduling of cancelled requests will then be attempted during the next planning session (i.e. Nominally the next day)

o The PDGS will regenerate a complete Data Take schedule covering the next 96 hours of payload activity.

o This Updated Data Take Schedule will be sent to the FOS that will reiterate the generation and authentication of telecommands before uplink.

At the processing stage, Metadata and Browse Products are not systematically sent back to the User Services Coordination and Control to feed the Master Catalogue. This is in particular

because, while L0 products will be systematically archived, L1B products will not79.

The process and the related exchange of information are illustrated by Figure 4.3-9 below.

79 [RID FR-D01-02]: Comment added in the text to state that Metadata, Browse products and annotations

transfer from APAD to Master Catalogue is not systematically triggered as part of the scenario.

/104





PDGS

Emergency On-Call

Officer (ECO)


Mission Planning



MMUS MMFI



Operations Segment


Data Take Schedule (Regular Daily Update)

Sensing Request


Uplink

Downlink Plan

Replay Keys


Emergency OrderSubmission

Updated DataTake ScheduleComputation

Sensing Request

Instrument Parameters Commands Generation & Authentication

Downlink Plan Update

Replay Keys Update


Data Take Schedule


Uplink Report


SensingDownlink

Payload Data Reception



L0 ProductsL1B Products (TBC)

Metadata & Browse Products (TBC)

Annotations


FormattingDisseminationL1B Product

Production Request

L0/L1B Products Archiving

Max

Tim

e: 3

hou

rs

B.2.1: Sentinel-1 Emergency Orders Handling

IngestionDecryption


Figure 4.3-9: Scenario B.2.1 - Sentinel-1 Emergency Order Submission and Handling

The Figure 4.3-10 illustrates the chronology of operations for handling of emergency orders, in comparison with the chronology for “normal” orders. The two cases of the “red phone” requirement are represented.

/104





Working HoursData Take Schedule Generation by PDGS

FOS Mission Planning Operations Uplink Opportunities

Orders Submission cut-off time (e.g. 08:00 a.m. UTC)

On-board execution Start

Non Working Hours

Tc + 12 hours

Nominal Case

Nominal DT Schedule Generation by PDGS Nominal FOS Mission

Planning Operations

Uplink Opportunities

On-board execution Start

Emergency Case 1

Emergency DT Schedule Generation by PDGS Emergency FOS Mission

Planning Operations

Emergency Order Submission cut-off time

Tc

Max. 3 hours

TeEmergency Case 2

Nominal DT Schedule Generation by PDGS Nominal FOS Mission

Planning Operations

Emergency DT Schedule Generation by PDGS Emergency FOS Mission

Planning Operations

Nominal Plan Uplink

Emergency Order Submission

TeUplink Opportunities

Max. 6 hours

Figure 4.3-10: Chronology for “red phone” requirement handling

In the first case, the emergency order is submitted during normal working hours, less than 3 hours before the nominal plan foreseen for uplink of the schedule to the spacecraft.

Consequently, less than 3 hours remain available for the PDGS and FOS to perform an update of the data take schedule – under the assumptions listed earlier -, to generate the command plan and to authenticate and/or encrypt the commands before their uplink.

In the second case, the emergency order can be submitted at any time during normal working hours. The requirement states that the schedule containing the emergency acquisition request shall be uplinked within 6 hours after submission of the emergency order. The figure shows the case where the emergency order is submitted practically at the nominal

time foreseen for uplink. Then, the assumption is made that the uplink takes place nominally, and that the update of the data take schedule is performed in parallel. Thus, PDGS and FOS operations need to be extended outside nominal working hours, in order to target an uplink at the earliest possible time following the series of blind orbits over Kiruna. Note that this case imposes more constraints on the FOS than on the PDGS, i.e. the FOS needs to schedule an additional uplink session (night or morning pass) in order to ensure that the 6-hour requirement

is complied with.

Notes:

o if the delta schedule has to be uplinked during the last late afternoon pass (which is around 6:00 pm UTC), the requirement allows the emergency order to be submitted

/104





until around 12:00 am GMT, which is only 2 hours later than the cut-off time for normal orders

o if the delta schedule cannot be uplinked during the last late afternoon pass and since

the latter is normally followed by 5 blind orbits, this would mean waiting 500 Minutes before the next uplink opportunity. Compliance with the 6-hour requirement would then require using a back-up TMTC station (e.g. Svalbard) for the uplink.

4.3.2.2.2 B.2.2: Sentinel-2 Emergency Mission Planning8081

In the case of Sentinel-2, the baseline operations for mission planning consist in establishing a long term planning of observations over defined areas of interest. The sensed areas of interest are not deemed to change frequently, so that in most cases the areas of interest defined for one orbit cycle remain valid for the next orbit cycle. The current baseline is to update the

mission plan on-board only each fortnight.

Emergency imaging consists in a list (or set) of images which shall be acquired with the lowest possible latency. Images shall be acquired only once. The imaging plan is uplinked outside of nominal imaging plan uplink sessions, and the images shall be downlinked to ground on the first visibility following their acquisition. This means that such images may be downlinked in

direct downlink mode (including towards a user receiving station) or after playback from the on-board memory.

The time between order reception on ground and plan uplink shall be less than 12 hours. Emergency imaging may take place in extended mode, but not necessarily.

For emergency mission planning, the requirement is to generate and upload a data take schedule within 12 hours from the submission of the emergency request.

Two cases shall be considered:

o Emergency request coming in during working hours

o Emergency request coming in outside working hours.

In the first case, it’s assumed that the limit time for the emergency request is at the latest 3 hours before the last uplink opportunity (during working hours). This constraint allows the request to be taken into account if it comes in before 13:00 pm. This lets 3 hours for PDGS and

FOS to perform the mission planning loop, consisting for the PDGS in incorporating the emergency request in the data take schedule and for the FOS in translating the mission plan into telecommands.

The second case is quite similar, except that unplanned mission planning operations would be required. This imposes personnel to be available on call and able to resume mission planning operations as quickly as possible, including during nights and week-ends. It may occur that in

this case, a back-up TMTC station e.g. Svalbard will be needed to ensure the uplink latency.

The scenario is illustrated by Figure 4.3-11.

80 [RID D01-092]: Scenario not applicable to Sentinel-3

81 [RID D01-036]: Emergency Scenario for Sentinel-2 revisited, in particular direct downlink and planning time –

12 hours added.

/104





PDGS

Emergency On-Call

Officer (ECO)


Mission Planning



MMUS MMFI


MMFI Station SPPA

FOS

Sentinel-2

Satellites

Uplink

Emergency OrderSubmission

Data Take Schedule Computation

Sensing Request



Downlink Plan Circulation

Replay Keys


Data Take Schedule & Downlink Plan


Uplink Report

Sensing

Downlink

Min

Tim

e: 3

Hou

rs/ M

ax T

ime:

12

hour

s

B.2.2: Sentinel-2 Emergency Orders Handling

IngestionDecryption


Downlink Plan Generation

Replay Keys Distribution

User Receiving

Station

Downlink


4.3.2.2.3 B.2.3: Sentinel-3 Emergency Mission Planning for the Fire Monitoring Payload

During the Fire Monitoring Season (defined as being the period from April to October over Europe), the PDGS shall be able to handle emergency requests for activation of the Fire Monitoring Payload (GIREL). These requests are either generated individually by each European Fire Fighting Operational Centre, or coordinated through a common User Request Management Centre (TBD).

In the first case, conflicts between requests from different Fire Fighting Operational Centres may occur and will have to be solved by the PDGS. In the second case, requests are assumed to be conflict free (conflicts are resolved before being issued towards the PDGS).

The fire monitoring data acquisition requests have the following characteristics:

o They do not impact the nominal Sentinel-3 mission

o It shall be possible to downlink fire monitoring data to local stations in parallel of the regular downlink on the nominal Ground Station.

o The fire monitoring acquisition plan and related downlink plan shall be generated within very limited time (TBD minutes after request reception) in order to allow uplink to the satellite for the next orbit over the area of interest. Note that if the actual satellite position is already over Europe, such time may be very short.

o If not solved previously at a common User Request Management Centre, the conflicts shall be solved by the PDGS using TBD rules.

/104





o The updated mission plan shall be checked by an operator and validated before transfer to the FOS. However, no impact of Fire Monitoring Payload programming on the Sentinel 3 nominal mission shall occur, since this is prevented by satellite design82.

The corresponding scenario is illustrated by Figure 4.3-12.

PDGS

Fire Fighting Operational

Centres


Mission Planning



MMUS MMFI


MMFI Station SPPA

FOS

Sentinel-3

Satellites

Uplink

Emergency RequestsSubmission

Conflicts Identification & Resolution

Sensing Request



Downlink Plan Circulation

Replay Keys (TBC)


Data Take Schedule & Downlink Plan


Uplink Report

Sensing

Downlink

Max

. 30

Min

utes

(if

are

a to

be

sens

ed a

cces

sibl

e du

ring

the

next

or

bit)

B.2.3: Sentinel-3 Emergency Orders Handling (Fire Monitoring Payload)

IngestionDecryption


Mission & Downlink Plans Generation

Replay Keys Distribution (TBC)

Direct Receiving

Station

Downlink


82 [RID FR-D01-04]: Paragraph amended to state that the programming of the Fire Monitoring Payload shall not

impact the Sentinel-3 nominal mission, since this is prevented by satellite design.

/104





4.3.2.3 Orders from Archived Products

4.3.2.3.1 B.3.1: Orders from Archived Products without processing83

This scenario covers all orders for Sentinel-1, -2, and -3 products and legacy mission products identified via the master catalogue, whereby an archived L1B product or a collection of archived L1B products are likely to satisfy the users specifications.

It is illustrated by Figure 4.3-13 below.

PDGS

End User / Service

Segment


Mission Planning



MMUS MMFI


MMFI Station SPPA

Catalogue Search

L1B Product Extraction from Archive


Matching Search Results

Order Submission

Production Request


Request Handling

B.3.1: Orders from archived products without processing

IngestionDecryption


End User ProductQualityCheckQuality Check Results

Figure 4.3-13: Scenario B.3.1 - Orders from Archived Products without processing

Following catalogue search of products matching user defined criteria, the user submits an order for one single or a collection of products available in the Long Term Archive.

The Order handling and Production Planning component translates the order into one or

several production requests addressed to the local order handling system.

Matching products are then extracted from the archive. Before dissemination, they may be subject t to sub-setting in order to match exactly the user defined areas of interest, i.e. only a subset of the archived L1B product is then formatted, subject to Product Quality Check and eventually disseminated to the user.

83 [RID D01-037] : « reprocessing » changed to « processing »

/104





4.3.2.3.2 B.3.2: Orders from Archived Products with processing84

This scenario, depicted by

Figure 4.3-14, differs from the previous scenario in that it involves reprocessing from an archived L0 product. This may be required if for instance:

o The L1B product is not available in the archive for any reason

o A new set of auxiliary data is required

o The processor has been upgraded

o The L0 needs to be reprocessed with e.g. more accurate orbit data, for instance precise orbit data that were not available when the product has been processed for the first time.

The initial process of catalogue consultation and identification of archived L0 products is

identical to that in the previous scenario.

The user order is translated by the Order Handling and Production Planning component into a set of production requests, including the user’s specifications for processing and dissemination.

L0 products to be reprocessed are extracted from the Long Term Archive and made available

to the processing component. Possibly, updated auxiliary data are used.

Then, processing takes place. The processed L1B products are subject to quality checks before being made available for dissemination.

It is assumed that in this scenario, no sub-setting is required, since the processing will process only the user defined portion of the L0 product (based on latitude / longitude data, or on nominal time, absolute time and track/frame – including shifted frame- indication specified by the user). So, before dissemination, only formatting and product quality checks85 are needed.

After dissemination, the new L1B product generated is archived, either only temporarily to account for possible users’ complaints, or permanently in the Long Term Archive.

84 [RID D01-037] : « reprocessing » changed to « processing »

85 [RID D01-038]: added quality check before dissemination to the users

/104





PDGS

End User / Service

Segment


Mission Planning



MMUS MMFI


MMFI Station SPPA

Catalogue Search

L0 Product Extraction from Archive


Matching Search Results

Order Submission

Production Request

L0 to L1B processing

L0 ProductAuxiliary Data ( if required)

L1B Product

Product Formatting

Product Quality Check

Product Quality Check Results

UserProductArchiving

Processing Centre Selection

B.3.2: Orders from archived products with processing

IngestionDecryption


Figure 4.3-14: Scenario B.3.2 - Orders from Archived Products with processing

4.3.2.3.3 B.3.3: Orderless Data Provision from Archive86

Orderless data provision from archive is likely to be the most common way of getting products. The on-line archive will allow to store a large amount of TBD products, including freshest Level 1B, 1C or Level 2 products and auxiliary data like those required for processing

or Precise Orbit Data.

The scenario is described by Figure 4.3-15.

86 [RID D01-093]: New scenario added for orderless data provision from on-line archive

/104





PDGS


Mission Planning



MMUS MMFI


MMFI Station SPPA

Catalogue Consultation

Matching Catalogue Records

End User / Service

Segment

Accounting data

B.3.3: On-line Data Retrieval (Orderless Data Provision)

IngestionDecryption


Products Selection Request Routing

to on-line archive

Product Retrieval

Product Quality Control

Products Dissemination (pull)

Figure 4.3-15: Scenario B3.3 - Orderless on-line data provision

The process starts with a catalogue consultation by the user, who, on the basis of the criteria he/she specifies, identifies products suitable for his/her application. We make here the hypothesis that the results of the user’s queries allow identifying whether products are available on-line or not, and whether products have been generated with the adequate set

of auxiliary data (e.g. orbit data with the required accuracy for Sentinel-3 products).

In case suitable products are not available on-line, the user has to submit an order for archive extraction and dissemination without (Scenario B.3.1) or with (Scenario B.3.2) complementary processing.

In case of suitable products are available on-line, the selection of a set of catalogue search

results should redirect the user to the on-line archive where the products are available. Products are then retrieved on-line, and quality checked. In-between, on-the fly post-processing may take place (TBC).

The dissemination of products occurs in “pull” mode, i.e. the user has to initiate the transfer of products via a protocol like SFTP or SHTTP.

Except for free products (like e.g. auxiliary data), accounting data are generated (based on

e.g. the volume of data transferred from the PDGS to the user computer) and sent to the user services in order to be charged to the user account.

/104





4.3.2.4 B4: Sentinel/Third Party Missions composite orders (including processing and dissemination)87

The Interoperability Scenarios described below are resulting from the following requirements:

4.3.2.4.1 Scenario A1

Requirement The PDGS shall be able to handle multi-mission user requests originating

through its user services, but requiring acquisitions and data processing also from other missions. This shall distinguish the following cases.

o Only order handling is handled by the PDGS dispatching the part of the order tasked to the other mission in an interoperable format. All other functions are provided by the other mission G/S, including the coordinated delivery of data either directly to the user or to the PDGS

It is noted that this scenario covers two cases:

o The case of joint or “composite” orders, requiring acquisitions over the same region of interest by two different missions within a limited period. In this case, the composite order is decomposed into two elementary orders, one for each mission;

o The case of a mono-mission order dispatched to a third-party mission, e.g. because the primary candidate mission cannot satisfy the order within the set of constraints specified by the user.

Note also that in the case of the third party mission providing data from an optical satellite (in

view for instance of SAR product / Optical product fusion), the feasibility analysis of the order on the partner mission side shall take into account meteorological and climatology parameters in order to guarantee the best probability of a successful (i.e. cloud free) data take.

As well, once the (optical) product from the partner mission is available, it should be the partner mission responsibility to ensure that it is of adequate quality, including cloud coverage

quote below the threshold defined at the time of submission of the order. If not, it should be the partner mission GS responsibility to re-plan the data take until a successful product is obtained, within the requestor defined constraints (e.g. time span)88.

Thus, the composite order can be considered as successful only if all products involved in the order are delivered and of adequate quality.

The interfaces and information exchange timelines between the PDGS and the partner

mission G/S resulting from this scenario are illustrated by the Figure 4.3-16 below.

87 [RID D01-069]: Interoperability Scenarios moved from section 3.4 to section 4.3.2.4

88 [RID D01-073]: Added considerations about re-planning of cloudy images

/104





PartnerSystem G/S

POD ServiceUsers

SentinelS/C

SentinelGS

Composite Order

Feasibility check via Master catalogue

Archived, planned, future opportunities

Select future opportunity

Order Acceptance

Planning

Order confirmation

Data Take Scheduling

Data Take

SAR & GNSS & attitude Data Downlink

GNSS Pseudo Range Data (if any)

POV

Processing

Planning

Partner Mission Order

Partner Mission Order Confirmation

Data Take

Processing

Partner Mission Product (alternative 1)

Reference Orbit Data

Interoperable Catalogue access

Sentinel Product (alt. 1)

Partner Mission Product Product (alternative 2)

Packaging

PartnerSystem S/C


Instrument Data Data Downlink

HMA/DAIL

Joint Products (alt. 2)

Sentinel Product (alt. 2)

Figure 4.3-16: GMES PDGS/Partner Mission Composite Orders Submission – Scenario A189

In this case, the PDGS and the partner mission ground systems shall have interfaces with the Data Access Interface Layer (DAIL)90 in order to allow:

- Joint PDGS/Partner Mission Catalogue consultations via an interoperable catalogue

system to identify joint acquisitions opportunities. Note that at this level of pre-planning, the DAIL will use reference orbit data for the partner mission.

- Transmission by the DAIL to the GMES PDGS and to the partner mission G/S of the

respective product orders and reception by the DAIL of the partner mission order confirmation for the sake of coordinated order confirmation information towards the user.

Notes:

a) By definition, it is out of the scope of the PDGS to allow ordering of products for missions not supported by the PDGS. An extra element, the Data Access Interface Layer (DAIL) is supporting the User interface functions for the submission of

89 [RID FR-D01-05]: Figure Updated. “Using DB populated by FOS deleted” and replaced with check via the

Master Catalogue

90 [RID FR–D01-07]: Text amended and completed to make clear that user interface functions for composite

order submission are part of the Data Access Interface Layer functions (DAIL).

/104





composite orders. The DAIL will in particular implement the user interfaces and interfaces with the Ground Segments of each supported mission.

b) Coordinated delivery of products from mission supported by the PDGS on one

hand (e.g. Sentinel) and missions not supported by the PDGS is outside the PDGS scope. In this case (alternative 2 for products delivery described in Figure 4.3-16), the coordinated delivery is ensured via the DAIL with which the PDGS has specific interfaces (in this case, a dissemination interface).91


Requirement The PDGS shall be able to handle multi-mission user requests originating in through its user services, but requiring acquisitions and data processing also from other missions. This shall distinguish the following cases.

o Order handling and ground station acquisition, processing and delivery are handled in the PDGS using M&C data provided by the G/S of the other mission (TBC)

The sequence diagram corresponding to this scenario is represented on Figure 4.3-17 below.

91 [RID FR-D01-06]: Clarification added that the coordinated delivery of products from PDGS supported

missions on one hand and PDGS unsupported missions on the other hand is outside the scope of PDGS

functions, but is ensured via the Data Access Interface Layer (DAIL).

/104





Partner Mission G/S

POD Service

UsersSentinel

S/CSentinel

GS

Composite Order



Order acceptance

Planning

Order confirmation


Data Take

Instrument & GNSS & attitude Data Downlink

GNSS Pseudo Range Data

POV

Sentinel + Partner Mission ProcessingJoint Products

Planning




Interoperable Catalogue access

Downlink Information (station pass data, decryption keys)

Partner Mission Data Downlink

Auxiliary Data for Processing

Partner Mission S/C


Data Take


HMA/ DAIL


With respect to Scenario A1, additional interfaces between the GMES PDGS and the Partner Mission Ground Segment are required:

o the GMES PDGS requires from the Partner Mission G/S all information necessary to handle the downlink of the partner mission raw data at the GMES PDGS receiving stations. This includes in particular station pass data (azimuth / elevation data,

AOS/LOS times) and, if required, the keys needed for the decryption of the partner mission satellite raw data stream.

o The GMES PDGS will then receive the raw data directly down linked from the partner mission satellite, and process this data up to Level 1B using auxiliary data provided by the partner mission Ground Segment.

This case would imply in particular that the GMES PDGS should be (if needed) equipped with

a decryption facility able to decrypt partner mission raw data and a Partner Mission


Master Catalogue

93 [RID FR-D01-08]: Scenario amended to make clear that the submission of composite orders by a user is

done through the HMA/DAIL, and not directly to the PDGS, since the PDGS does not allow ordering of

products for missions not supported by the PDGS.

/104





instrument processor. In the case of SAR (Sentinel-1), this would require two SAR Processors (Sentinel-1 and Partner Mission) capable of being installed behind a common interface.


Requirement The PDGS shall be able to handle multi-mission user requests originating

through its user services, but requiring acquisitions and data processing also from other missions. This shall distinguish the following cases.

o Order handling and ground station acquisition are handled in the PDGS using M&C information in support to acquisition provided by the GS of the other mission, and forwarding the instrument data to the other missions GS for processing and delivery (TBC)

This case corresponds in fact to the use of GMES PDGS receiving stations for the reception of

raw data from partner missions’ satellites. The sequence diagram corresponding to this

scenario is represented on Figure 4.3-18 below.

Partner Mission G/S

POD ServiceUsers

Sentinel S/C

Sentinel GS

Composite Order



Order acceptance

Planning

Order confirmation


Data Take

SAR & GNSS & attitude Data Downlink


POV (Sentinel-1 only)

Partner Mission Processing

Partner Mission Product

Planning



Data Take


Interoperable Catalogue Access

Downlink Information (station pass, data, decryption keys - TBC)

Partner Mission Instrument Data Downlink

Partner Mission Instrument Raw Data

Sentinel Processing

Sentinel Product

Partner Mission S/C



HMA/DAIL



Master Catalogue

/104





The difference with respect to the previous case lies in the fact that for the partner mission

data, the GMES PDGS would perform only reception of the partner mission raw data, but the remainder of the production and delivery process for partner mission products would be done at the partner mission Ground Segment.

The differences with respect to the previous case are then:

o Since the GMES PDGS performs only the reception of the partner mission satellite instrument raw data, the control information needed from the partner mission G/S is

limited to the pass data for the receiving station. Under the assumption that the instrument raw data received from the partner mission satellite do not need to be decrypted before their retransmission to the partner mission G/S, no exchange of decryption keys is necessary. As well, since no processing of the partner mission data is done at the PDGS, there is no need for exchanging auxiliary data.

o a specific interface to forward the partner mission instrument data received at the

GMES PDGS Stations to the Partner Mission Ground Segment is needed; This requires a common format or an agreed exchange format between the two cooperating missions.

4.3.2.4.4 Scenario B1

Requirement

The PDGS shall be able to receive orders for Sentinel satellites data as part of multi-mission user orders placed through the G/S of another mission. This shall distinguish the following case:

- Order handling, mission planning, PDGS acquisition and processing and delivery for Sentinel data are all handled by the PDGS. Delivery

can either be directly to the user in a coordinated fashion or can be to the other mission G/S

This scenario is very similar to a user ordering scenario, whereby the recipient of the processed products is the partner mission Ground Segment.

The sequence diagram corresponding to this scenario is represented on Figure 4.3-19 below.

95 [RID FR-D01-08]: Scenario amended to make clear that the submission of composite orders by a user is

done through the HMA/DAIL, and not directly to the PDGS, since the PDGS does not allow ordering of

products for missions not supported by the PDGS.

/104





Partner Mission G/S(*)

POD Service

UsersSentinel

S/CSentinel

GS

Composite Order

Check catalogue / feasibility checkArchived, planned,

future opportunities


Order acceptance

Planning

Order confirmation


Data Take

Payload & attitude Data Downlink


Precise Orbit Data

Joint Products (alt. 1)

PlanningSentinel Order

Sentinel Order Confirmation

Data Take


Interoperable Catalogue Access

Sentinel Product (alternative 1)

Processing Processing

Sentinel Product (alternative 2)

Delivery Packaging

Partner Mission S/C

Payload & attitudeData Downlink

(*) Note:

The Partner Mission G/S is seen by the PDGS through the HMA.

Figure 4.3-19: GMES PDGS/Partner Mission Composite Orders Submission – Scenario B1

This case relates to the submission of a multi-mission order via the Partner Mission Ground Segment. In this scenario, from the GMES PDGS standpoint, the Partner Mission Ground Segment interface is seen through the HMA/DAIL interface96. The scenario is in fact the reverse

of Scenario A1. In this case, interfaces between the two systems (GMES PDGS and Partner Mission G/S through the DAIL) should allow:

- Transmission by the GMES Ground Segment of Sentinel satellite reference orbit data to the

partner mission G/S or HMA/DAIL.

- Joint GMES PDGS/Partner Mission Catalogue consultations via an interoperable catalogue

system

- Transmission by the Partner Mission G/S via the DAIL to the GMES PDGS of a Sentinel

product order, and reception by the Partner Mission Ground Segment / DAIL of Sentinel

product order confirmation for the sake of coordinated order confirmation information towards the user, which is then forwarded to the user by the Partner Mission G/S or DAIL.

96 [RID FR-D01-09]: Clarification added that in the HMA-compliant model, any request is received either directly

from the user or via the HMA.

/104





- Reception at the Partner Mission G/S of Sentinel product for the sake of coordinated

delivery to the user (in case of no delivery of Sentinel product to the user directly by the GMES PDGS).

So, in the HMA-compliant model, any request is received by the GMES PDGS either directly from the user or via the HMA. Therefore, this does not create a specific scenario for the GMES

PDGS.


Requirement

The PDGS shall be able to receive orders for Sentinel data as part of multi-mission user orders placed through the G/S of another mission. This shall distinguish the following case:

- Order handling and mission planning are handled by the PDGS, all other

functions are handled by the other mission G/S which is provided with the required M&C information in support to G/S acquisition and

processing;

This scenario is equivalent to the direct downlink to a user station.

The resulting interfaces and information exchange timelines between the GMES PDGS and the

partner mission Ground Segments are illustrated by the Figure 4.3-20 below.

Partner Mission G/S

POD Service

UsersSentinel

S/CSentinel

GS

Composite Sentinel /Partner Mission Order




Order acceptance

Planning

Order confirmation


Data TakePayload & Attitude Data Downlink

POV

Joint Products

PlanningSentinel Order



Interoperable Catalogue / access to Partner Mission Catalogue

Sentinel Product Processing

Delivery Packaging


Auxiliary data for processing

Downlink Information (station pass, data, decryption keys)

POV for off-line processing


Partner Mission S/C

Data Take

Payload & Attitude Data Downlink


L0 Product Repatriation


/104





In this case, only order handling and mission planning for the Sentinel part of a Sentinel /Partner Mission composite order would be performed on the GMES PDGS side. So, in particular, the partner mission G/S would perform Sentinel raw data reception, decryption

and processing, and deliver the multi-mission products to the requesting users in a coordinated manner.

This case would require implementing a number of interfaces between the GMES PDGS and the partner mission G/S, for the transmission of all the information needed by the partner mission to perform:

o The reception of the Sentinel instrument data (stations pass data)

o Their decryption (replay keys and replay indexes)

o Their processing (auxiliary data), that should be fetched by the partner mission G/S from on-line data provision (preferably via anonymous FTP).

Conversely, the partner mission G/S would have to send back to the GMES PDGS:

o as a minimum the metadata to feed the catalogues;

o optionally, the level 0 products to feed the Long Term Archive held in the PDGS (data

repatriation). In such a case, an agreed exchange format or a common archive format should be used.


Requirement The PDGS shall be able to receive orders for Sentinel data as part of multi-mission user orders placed through the G/S of another mission. This shall distinguish the following case:

- Order Handling, mission planning and acquisition are handled by the

PDGS, for the data to be forwarded to the other mission G/S for

processing and delivery supported by the required M&C information for processing.

The resulting interfaces and information exchange timelines between the GMES PDGS and the

partner mission Ground Segments are illustrated by the Figure 4.3-21 below.

/104





Partner Mission G/S

POD Service

UsersSentinel

S/CSentinel

GS

Composite Sentinel/Partner Mission Order




Order acceptance

Planning

Order confirmation


Data TakeSAR & GNSS & attitude Data Downlink

Precise Orbit Vector

Joint Products

Planning

Sentinel Order


Data Take


Interoperable Catalogue / access to Partner Mission Catalogue

Sentinel Product Processing


Delivery Packaging


Auxiliary data for processing

Sentinel Instrument Data (raw or L0 – TBD)

POV for off-line processing

Partner Mission S/C


In this case, order handling, mission planning and raw data reception for the Sentinel part of a

Sentinel/Partner Mission composite order would be performed on the GMES PDGS side. The partner mission G/S would perform processing of Sentinel products (up to Level 1B) and delivery of the multi-mission products to the requesting users in a coordinated manner.

The interfaces between the GMES PDGS and the Partner Mission G/S required in this case would include:

- From GMES PDGS to Partner Mission G/S: auxiliary data for processing, fetched via the on-line data provision function97

- From Partner Mission G/S to GMES PDGS: L0 products on request (data repatriation, using an agreed exchange format or a common archive format).

97 This makes the hypothesis that data transferred from the GMES PDGS to the partner mission one

are already decrypted and screened. If only raw data would be transmitted, it would be

necessary in addition to transmit to the partner mission G/S the replay keys and replay indexes (in

order to allow decryption); conversely, in this case, the partner mission G/S performing Level 0

data processing would be required to transmit metadata back to the GMES PDGS.

/104





4.3.2.5 Transverse Scenarios

This section presents a set of generic scenarios that explain the internal mechanisms within the PDGS for specific operations.

4.3.2.5.1 B.4.1: Encryption and Keys Generation and Handling

Note: At this stage, all scenarios related to security, including scenarios describing the

encryption and decryption mechanisms are TBC, pending in particular the outcomes of the

GMES E2E Security Study running in parallel with the PDGS Architecture Study98.

Baseline assumptions:

o The scenario for Encryption and Keys Generation and Handling is generic and applies to Sentinel-1, -2 and -3 missions.

o The ground to space link for commands uplink is not encrypted, but all uplinked

commands are authenticated and some of them need being encrypted. This is the case for commands including encryption keys.

o The downlinked instrument raw data can optionally be encrypted; the downlinked data are then organised in such a manner that a part of the data (e.g. Packet headers) is not encrypted; this data contains the information (i.e. replay or downlink

ID) allowing correlation of the instrument raw data with a given deciphering key.

o A decryption key is associated with:

o A complete downlink session, i.e. all data downlinked to a given receiving station during a pass are encrypted using the same key

o A replay, which is part of a downlink, i.e. data to be downlinked during a pass are organised in replays grouping several data takes with one dedicated key

associated to each replay. This is only feasible if the grouping of data takes into replays is deterministic and performed on-ground (Sentinel-1 case). In this case, several replay keys can be associated to a single downlink session.

o Once all data pertaining to a replay or a downlink session has been decrypted, the corresponding key is not used any longer and shall be sanitised

o Keys are generated dynamically and randomly by a specific facility (Key

Management Facility) which resides within the FOS. The same key is never used twice, i.e. the length of the key allows a sufficient number of different keys to be generated to cover the whole mission lifetime.

o The circulation of keys to where decryption takes place is the responsibility of the PDGS.

Based on these assumptions, Figure 4.3-22 describes the scenario for the generation and

handling of keys.

98 [RID D01-041]: Disclaimer added

/104





PDGS

Mission Management or User / Service

Segment


Mission Planning



MMUS MMFI



Operations Segment

SentinelSatellites

Order Submission Order Handling &

Mission Planning



SensingUplink

Downlink



Replay Keys Distribution

B.4.1: Keys Management

Downlink Planning

Replay Keys Generation

Replay Keys (Sentinel-1) or Downlink Keys (Sentinel-2/3 – TBC) and Indexes

Encrypted using Receiving Station or Processing Facility Public KeyEncrypted using Receiving Station or Processing Facility Public Key

Replay Keys Decryption

Replay Keys Sanitisation

Decryption using Station Private KeyDecryption using Station Private Key

TBD time after key usageTBD time after key usage

Including:-Organisation of data takes in replays- Allocation of replays to downlink sessions

Including:-Organisation of data takes in replays- Allocation of replays to downlink sessions

IngestionDecryption


Figure 4.3-22: Scenario B.4.1 – Encryption and Keys Generation and Handling

At the time of Data Take schedule generation (Sentinel-1 case), the PDGS assigns data takes to replays and replays to downlink sessions. A downlink session may encompass one or several replays, e.g. it may be convenient for NRT to organise the downlink in such a manner that all NRT data takes are grouped into one “NRT replay” and are downlinked first.

In the case of Sentinel-2/3, since the satellite automatically determines which data takes are

downlinked during a given pass, there should be a one to one relationship between downlink sessions (covering an entire pass) and replay keys.

In the data take schedule, each replay/downlink is given a unique ID.

The FOS generates then the replay keys associated to each replay ID. These keys are uplinked encrypted to the spacecraft, and used on-board to encrypt the instrument data. The description mechanism used to encrypt replay keys on-ground and decrypt them on-board is outside the scope of the present document. The mechanism here is based on symmetric encryption, i.e. the same secret key is used for ciphering raw data (on-board) and deciphering them (on ground).

The replay/downlink keys are then passed by the FOS to the PDGS. They are themselves encrypted to circulate between the FOS and the PDGS and within the PDGS. In this case, an asymmetric encryption scheme is used, i.e. the keys are encrypted using the public key associated with the facility performing deciphering.

The mechanism for exchanging the public keys is not shown on the figure. In fact, the public key needs to be transmitted only once. This might for instance be via surface mail.

/104





The encrypted replay keys together with their associated replay indexes are sent by mission planning to the facility where decryption and processing take place. They are then decrypted locally using the relevant private key.

Once the data takes to decrypt are incoming, decryption takes place in a data driven manner. The replay index in the not encrypted part of the raw data is used to select the adequate replay or downlink key.

Once decryption of all raw data pertaining to a replay or downlink session is completed, the corresponding key becomes of no use. It can then be sanitised after a given time.

4.3.2.5.2 B.4.2: Precision Orbit Data Handling99

This scenario addresses the handing of Precise Orbit Data within the PDGS. Sentinel satellites of the Sentinel-1, Sentinel-2 and Sentinel-3 series will be equipped on-board with a GNSS

receiver. This will allow:

o On-board autonomous orbit determination: restituted orbit data will be downlinked with the instruments telemetry and used on ground as the most accurate orbit data for immediate processing

o Precise orbit determination: raw data from the GNSS receivers (GNSS pseudo range

data) will as well be downlinked with the instrument telemetry and passed to a Precise Orbit Determination service provider, which in return will provide a precise orbit vector, based on the knowledge of the GNSS satellites.

Hypotheses have been made that:

o -for Sentinel-1, the POD facility is external to the PDGS

o - for Sentinel-3, the POD facility is internal to the PDGS

The POD service to be provided may have different latencies according to the needs of the different missions. For instance, for Sentinel-3, the POD shall generate 3 levels of precision orbit data for:

o -the NRT service: fastest POD output available to allow NRT L2 processing in less than 3 hours.

o -the STC service: better POD output available to allow STC L2 processing in less than 2

days.

o -the NTC service: best POD output available to allow STC L2 processing without time constraint.

So, the scenario for POD Generation and handling is illustrated by Figure 4.3-23. Note that the scenario is not depending on how the POD service is implemented (external to the Ground Segment, internal to the Ground Segment e.g. provided by FOS, internal to the PDGS).

99 [RID D01-102]: New scenario added explaining the handling of POD

/104





PDGS


Mission Planning



MMUS MMFI


MMFI Station SPPASpace

SegmentPOD Service

ProvidersEnd User /

Service Segment

B.4.2: POD Management

IngestionDecryption


Downlink

Raw Data Reception

GNSS Raw Data Verification

Packets Analysis & Sorting

GNSS Raw Data Extraction

GNSS Raw Data

POD Generation

POD Circulation

POD Archiving (on-line)

POD Transmission

POD Verification

POD Retrieval Request

POD On-line Retrieval

Auxiliary Data dissemination (pull)

POD Dissemination (pull)

Figure 4.3-23: Scenario B.4.2 – POD Generation and Handling

GNSS pseudo range data (GNSS raw data) are received at the receiving station as part of the instrument raw data. Several hypotheses can be made:

o they are bundled in separate Instrument Source packets, possibly not encrypted

o they are downlinked once every orbit, and if possible received always at the same ground station (this may be Svalbard for Sentinel-1, Kiruna for Sentinel-2 and Sentinel-3, and again Svalbard for Sentinel-2 and Sentinel-3 blind orbits over Kiruna).

Once received at the station, the GNSS pseudo range data source packets are sorted out and extracted, and then sent to the (external or internal) POD service provider.

In parallel, they are subject to quality checks performed within the SPPA domain.

POD is then generated by the POD service provider, with different accuracies and different latencies. Once made available again at the PDGS, the POD is subject to quality control. The central Auxiliary Data Management function circulates them to the processing facilities where they are used to process / reprocess lower level data to final products (Level 1B, 1C or Level 2 according to the mission). They are also made available on the on-line archive wherefrom they can be accessed and retrieved by users for their own purpose. In order to be referenced

in the user catalogue, they are inventoried at the time of their ingestion in the archive.

4.3.2.5.3 B.4.3: Auxiliary Data Management100

100 [RID D01-108]: New scenario added explaining the handling of auxiliary data

/104





This scenario describes how Auxiliary Data are handled within the PDGS.

This scenario illustrated by Figure 4.3-24 assumes a centralized function within the PDGS to coordinate auxiliary data gathering, quality control and circulation (Auxiliary Data

Coordination element within the SPPA domain).

PDGS


Mission Planning



MMUS MMFI



Operations Segment

External Auxiliary

Data Providers

End User / Service

Segment

B.4.3: Auxiliary Data Management

IngestionDecryption


Auxiliary Data Generation

Auxiliary Data Circulation

Auxiliary Data Archiving (on-line)

e.g. Orbit Data

e.g. Precise Orbit Vector

Auxiliary Data Verification

Auxiliary Data Retrieval Request

Auxiliary Data On-line Retrieval

Auxiliary Data dissemination (pull)

Figure 4.3-24: Scenario B.4.3 – Auxiliary Data Management

Auxiliary data may have different sources:

o Generated inside the PDGS, like auxiliary data required for processing that are produced within the SPPA domain (e.g. instrument and products calibration data);

o Generated outside the PDGS, but inside the GMES Ground Segment: e.g. orbit data produced by the FOS

o Generated outside the GMES Ground Segment like Precise Orbit Data (if the service is

provided by a third party service provider), meteorological data or climatology data.

All this data whether produced internally or gathered from external sources is subject to quality control, this being part of the SPPA domain functions.

Once quality checks performed, auxiliary data are circulated towards:

o Where they are needed to support processing at different levels (i.e. the processing centres)

o Where they are archived: the hypothesis is that auxiliary data are made available on the on-line archive, so that they can easily be retrieved by users without requiring a heavy and time consuming ordering procedure.

In order to be easily identifiable, auxiliary data are referenced in the catalogue. Their retrieval is then performed in the same way as for on-line products retrieval.

/104





4.3.3 SPPA Scenarios

In this subsection, the following definitions are used:

Calibration / Validation products: Cal/Val products are all products required by the Sensor Performance, Products and Algorithms activities in order to ensure the quality of products delivered to end users, punctually and on the long-term. They are used to generate processing settings information – usually in the form of auxiliary file - , which are an input to the instrument processing facilities and are also used by the users101.

Calibration / Validation users: Cal / Val users are all individuals or organisations contributing to the activities of Sensors Performance, Products and Algorithms (SPPA). They include ESA SPPA

staff, Expert Support Laboratories (ESL’s), dedicated teams during Calibration / Validation campaigns102.

4.3.3.1 C.1: Subscription to Calibration / Validation Products

In the Sentinel-1 case, Cal/Val products include data takes over specific regions of interest (like rain forests) and over ground targets like dihedral reflectors.

In the case of Sentinel-2 and Sentinel-3, such products are TBD. For instance, Calibration/validation products would be a subset of systematically acquired products as long as the specific observation areas – e.g. white deserts – will be part of the systematic acquisition plans. Therefore no specific planning and processing would be required103.

It is assumed that the nominal way for Cal/Val users of receiving Cal/Val products will be via subscription, i.e. the ESA mission management will define subscriptions for Cal/Val products, to

which Cal/Val users will have the capability to register.

So, in this case, it is assumed that no specific orders for Cal/Val products will need being submitted, and that Cal/Val products will be the result of mission orders.

The corresponding scenario is described by Figure 4.3-25 below..

101 [RID D01-104]: Definition of Calibration / Validation products amended

102 [RID D01-106]: Definition of Cal / Val users added

103 [RID D01-103]: Clarification that in the Sentinel-2/3 cases, Cal/Val products would be a subset of the

systematically acquired products, thus not requiring dedicated scheduling or specific processing.

/104





PDGS


Mission Planning



MMUS MMFI



Operations Segment

SentinelSatellites

Cal/Val Product Archiving and Exploitation

Sensing

Downlink


Calibration / Validation Product


Metadata and Browse Product (Optional)

Dissemination to SPPA

C.1: Subscription to Cal /Val Products

Cal/ValSubscription Definition

Subscription List

IngestionDecryption


Figure 4.3-25: Scenario C.1 – Subscriptions to Cal/Val Products

The process for receiving Cal/Val products is similar to the process described for subscriptions, i.e. ESA will define subscriptions to Cal/Val products including the list of Cal/Val products subscribers.

In addition, Cal/Val products should be available from the online archive.

Following sensing by the spacecraft, the raw data are acquired, circulated and processed like standard products.

It is assumed that the capability shall be provided not to include Cal/Val products in the catalogue, or at least to make them visible only to some categories of users, including those contributing to SPPA activities.

Like any other product, Cal/Val products are stored in the Long Term Archive so that they can be retrieved at any time in order to perform SPPA tasks104.

4.3.3.2 C.2: Orders for Calibration / Validation Products

It is assumed that in addition to the subscription mechanism, there shall also be a capability given to Cal/Val operators to order specific Cal/Val products. This capability is assumed to be

restricted to the Sentinel-1 case (i.e. ordering of data takes over specific areas or ground transponders).

The corresponding scenario is illustrated by the Figure 4.3-26 which shows in red the main differences with respect to “single orders” submission scenarios (e.g. A.1.1 and B.1.1).

104 [RID D01-105]: Systematic archiving of all Cal/Val products

/104





PDGS


Mission Planning



MMUS MMFI



Operations Segment


Cal/Val Product Order

Order Handling & Mission Planning


Sensing Request

Cal/Val Product Archiving and Exploitation


SensingUplink

Downlink

Downlink Plan


Calibration / Validation Product


Decryption Keys


Metadata & Browse Product (Optional)

Dissemination to SPPA

C.2: Orders for Dedicated Cal /Val Products

IngestionDecryption


Figure 4.3-26: Scenario C.2 - Orders for Calibration/Validation Products

The submission of the order is made by a Cal/Val operator. This is why the interface is shown from the SPPA to the MMUS. However, it is anticipated that the Cal/Val operator will use a standard user interface for ordering (TBC).

From a mission planning standpoint, Cal/Val orders are handled in the same way as mission or users’ orders, the only exception being that such Cal/Val orders are given a high priority so that they can be superseded only by emergency orders (assuming a priority scheme whereby

emergency orders take precedence over any other order, Cal/Val orders coming with the second highest level of priority, and mission orders coming next and having precedence over users’ orders).

So, Cal/Val orders are incorporated in the data take schedule sent to the FOS and further on uplinked to the spacecraft.

The handling of data takes on ground follows the same process as any other order. After

processing, there shall be an option to record such Cal/Val products in the master catalogue or not. This is why the transmission of metadata and browse products to the master catalogue is shown as optional.

Dissemination then proceeds internally within the PDGS, towards the SPPA, which archives and then exploits the Cal/Val products.

/104





4.3.4 PDGS Monitoring Scenarios105

4.3.4.1 D.1: PDGS Operating and Monitoring

This scenario describes the activities required for monitoring and controlling the operations within the PDGS.

Two kinds of monitoring are performed:

o Technical monitoring: it consists in monitoring the technical status of the PDGS resources involved in the provision of the end-to-end service: electronic hardware, computer hardware, storage and archiving devices, networks. Such technical monitoring can be performed locally at each geographical site, through a local

operator interface, and centrally. Technical monitoring is based on the collection of the status of resources performed by a local monitoring agent that synthesises information and reports to a central monitoring agent.

o Operational monitoring: operational monitoring relates to the “Statistics and Reporting”, aiming at the generation of reports. Such reports include statistics about:

� the world-wide geographical coverage of acquisitions performed

� the number of products distributed for the various missions supported

� the number and ratio of requested vs. delivered products and of successful vs. failed systematic and on-demand production

� the number and success rates on:

- requested acquisitions

- planned acquisitions

- actually performed acquisitions (acquired vs. planned acquisitions)

- downlink (received vs. acquired data takes)106

- acquisitions with satisfactory quality

- processing (processed products vs. received raw data)

- archived products (archived vs. planned products)107

� the number, type and trend of user requests to the Help and Documentation Desk - in particular complaints

The scenario for technical and operational monitoring is illustrated by Figure 4.3-27.

105 [RID D01-123]: Title changed to “PDGS Monitoring Scenarios”

106 [RID D01-113]: added downlink success statistics

107 [RID D01-043]: added “acquired vs. planned”, “archived vs. planned”

/104





PDGS





MMUS MMFI


MMFI Station SPPAIngestion

DecryptionRequests Handling

Processing

D.1: PDGS Operating and Monitoring

OperationalMonitoring

TechnicalMonitoring

Reports Generation, Consolidation & Synthesis

Receiving Stations Technical Status and availability statistics

Processing Hardware status and availability reports

Archive occupancy reports

Reports Generation, Consolidation & Synthesis

Synthesis Report to Mission Management

HD Complaints Statistics

Products Quality Statistics

Dissemination status + Dissemination Statistics

Archiving Statistics

Production status + statistics

Downlink statistics

Orders completion statistics incl. Mission Orders

Satellite(s) & Sensor(s) Unavailability Statistics

Acquisition Reports

Figure 4.3-27: Scenario D.1 – PDGS Operating & Monitoring108109

For operational monitoring, the figure shows the gathering of status information from each of the components involved in the provision of the end-to-end service, i.e.:

o the receiving stations (acquisition reports and downlink statistics)

o the processing facilities (products generation statistics)

o the long term archive

o the dissemination facilities

o the SPPA for information gathering on products quality

o the Help and Documentation Desk for information related to Help and Documentation

Desk queries and handling of complaints

This information is then synthesized at central coordination and control level, in order to generate consolidated and configurable reports.

For technical monitoring, the technical status of assets involved in the provision of services is as well gathered from each remote facility and gathered centrally. It includes in particular the

technical status of receiving stations (to generate for instance statistics on the receiving stations availability rate), of the processing hardware and on the archive occupancy.

108 [RID D01-044] : Figure updated to include Unavailability Statistics of Satellite(s) and Sensor(s)

109 [RID D01-028] : Figure updated to include Acquisition Reports from Receiving Stations

/104





4.3.5 PDGS Maintenance Scenarios

4.3.5.1 E.1: PDGS Grow-up – Addition of new Mission

This scenario is not described as a time sequence of PDGS activities but by a sequence of actions to be performed in order to enable PDGS to run a new mission.

Whenever a new mission has to be supported, new components have to be added and the configuration of existing components has to be updated. The PDGS architecture shall support this scenario during runtime operations. The basic prerequisite is the product and processing

definition, containing all information required to configure the PDGS facilities.

Configuring the PDGS facilities include at least the following steps performed by PDGS administrators:

o Configuration of collections and product types with

� product metadata parameters and structures � logical product identifier (composed of product metadata parameters) � product components � product associations (e.g. predecessor/successor relationship in products of a

production chain) � archive locations

o Configuration and integration of processing systems with

� processing options � processors/processing algorithms

� cache partitions � processing request types and workflows (schemes/timers/triggers) � distributed processing systems in different version

o Configuration of production rules

� product dependencies (processing chains) � processing and post-processing responsibilities

o Configuration of user service system product upload rules with

� upload destinations

� product types and conditions � upload scheme (timer/trigger)

o Configuration of order management information including

� order sources

� order parameter dependent workflows � processing, formatting and delivery options � delivery medium label templates � prices and calculation rules � crisis areas

o Configuration of order options and interface to FOS for

/104





� acquisition � processing � post-processing � formatting and delivery

o Configuration of role-based access permissions and operating view

o Configuration of Mission Planning o Addition of information to Web site 110

110 [RID D01-077]: added “addition of information to Web site”

GMES Payload Data Ground Segment Architectural...

Documents

Transcript of GMES Payload Data Ground Segment Architectural...