29.11.2014 Views

GSC Sentinel-2 PDGS OCD - Emits - ESA

GSC Sentinel-2 PDGS OCD - Emits - ESA

GSC Sentinel-2 PDGS OCD - Emits - ESA

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>GSC</strong> <strong>Sentinel</strong>-2 <strong>PDGS</strong> <strong>OCD</strong><br />

Issue 1 Revision 2 (draft) - 25.07.2010<br />

GMES-GSEG-EOPG-TN-09-0008<br />

page 253 of 350<br />

○ The timeliness requirements also possibly impose the relative prioritisation of the<br />

processing jobs to ensure the different <strong>PDGS</strong> processing priorities as RT, NRT and<br />

reprocessing products imposing the access to a larger pool of processing resources<br />

than the ones required for the “nominal” processing;<br />

○ The DPC will be operable via HMI from an operator to carry out rehearsals, processing<br />

error recovery (i.e. trigger again a given processing), reprocessing activities, etc;<br />

○ The DPC will cope with the hosted-processing requests submitted by the <strong>PDGS</strong> frontend<br />

services;<br />

○ The DPC will be operable independently following several possibly conflicting<br />

triggering mechanisms (data-driven, operator-driven, support of hosted-processing<br />

requests). This constrains the DPC operations by an appropriate assignment and<br />

relative apportioning of the various processing resources available to each source<br />

trigger is well statically balanced or performed dynamically following the demand;<br />

○ Finally, the high volumes to be processed impose a constraint on the I/O performance,<br />

in particular versus the collocated AI function such that I/O does not become a<br />

bottleneck in the overall performance budget.<br />

6.2.3 OPERATION SCENARIOS<br />

6.2.3.1 Data Processing Control Configuration<br />

This scenario stands for the operator-driven configuration activities of the processing activities<br />

prior to its activation and normal operations. This scenario also accounts for the operatordriven<br />

definition and configuration of the DPC and the IDP (cf. section 6.3) functions.<br />

The DPC function is supported by the RP function in the process of the definition of the<br />

configuration according to the available processing resources, the expected processing load,<br />

timeliness definitions, etc by the usage of the mission configuration validation capabilities (cf.<br />

section 6.18.3.4) to test and rehearsal the processing activities devoted to the fine tuning<br />

configuration.<br />

Amongst others, the DPC and IDP functions configuration includes:<br />

○ Processing rules definition;<br />

○ Data fragmentation rules;<br />

○ Parallelisation rules;<br />

○ Processing resources definition.<br />

The use case of this scenario is the generation of the <strong>PDGS</strong> processing configuration (i.e.<br />

DPC/IDP functions). Such configuration is modelled to take into account the different data<br />

product load assigned to the different processing centres and can be managed by the MCC<br />

function (cf. section 6.14 - Mission Configuration Control (MCC) Operations) as Mission<br />

Reference Files for their release across the federated centres.<br />

<strong>ESA</strong> UNCLASSIFIED – For Official Use<br />

© <strong>ESA</strong><br />

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

communicated to any third party without written permission from <strong>ESA</strong>.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!