Login Form

About the FLEX L2 E2ES project

The objective of this project is to provide the functionalities required for the performance assessment of the FLEX mission concept (including Sentinel-3) and to verify compliance of the E2E performance with the mission objectives.
These objectives will be met by FLEX L2 E2ES, which will be an updated version of the Phase A/B1 E2ES (FLEX_E), integrating the to-be-developed by industry L1 E2ES (FIPS/GPP) and the scientific L2 Retrievals Modules (L2RM) Later versions of the simulator will include L2PP (to be developed in a future project), instead of L2 RM.
Although the "operational" L1 E2ES (including instrument (FIPS) and L1 modules (GPP)) will be provided by an industrial external contract, a simplified version of the L2 E2ES (i.e. the updated phase A/B1 FLEX_E E2ES with Thales OSS modules) will be available to provide Test Data Sets as input for the L1 E2ES and to the scientific studies, and to maintain the possibility to analyse the impact of instrument developments on the mission objectives and product requirements defined at L2.
FLEX L2 E2ES will be used on a set of reference scenarios to assess the overall performance of the mission for the given baseline system implementation and L2 retrieval algorithms.
FLEX L2 E2ES will also be used to generate multiple orbits of synthetic products data for L2 ground processing and overall ground segment validation. It is to be noted that this activity will be performed exploiting the time-driven functionality of OpenSF, which was not used until now in FLEX_E, and therefore requires a number of functional and interface updates of the existing modules/interfaces.

This project will consist of 3 technical phases. At the end of each phase, requirements and planning will be reassessed and updated as required.

  • Phase I: from KO to delivery and acceptance of L2 E2ES V1
  • Phase II: from the end of Phase I up to delivery and acceptance of L2 E2ES V3 and completion of M-CDR analyses.
  • Phase III: from the end of Phase II up to delivery and acceptance of L2 E2ES V6 (integrating the L2PP) at IOCR version.

 

Scope of each L2 E2ES version

The L2 E2ES released will be the main component of the L2 E2ES software and it will be the responsible for the simulation of entire processing chain of FLEX mission from Level 0 data into the Level 2 data. L2 E2ES will be developed using different modules with different objectives in different versions.
The software will evolve, starting from the E2ES FLEX_E to the processing chain for the Ground Segment (GS) (Version 6).
In version 1, the integration of the OSS-T modules, and the implementation of the interfaces of the S3 L1 module into the actual image format (which implies the updating of interfaces of the L2 and PEM FLEX_E module) will be performed. Also, the updating of latest version of OpenSF will be implemented.
In versions 2 and 3, the OSS-T modules will be replaced by the FIPS and GPP modules, the implementation time-based orchestration will be developed (including the entire orbits of TOA stimuli generation), PAM will be divided in two parts: L2 PAM (developed in this contract) and L1 PAM (developed in an external contract), and L2 FLEX_E module will be replaced by L2RM which will include all the L2 FLEX Products.
In versions 4 and 5, L2RM will be replaced by L2PP and a cross validation campaign between L2PP and the corresponding Operational Processors (L2OP) will be executed.
In version 6, FIPS will be replaced by real L0 FLEX images and S3L1 will be replaced by real L1 S3 images and the commissioning phase will be developed.
All the data between the SGM module (Geometry and Instrument Modules) shall be exchanged via NetCDF files. The outputs of Instrument, L1 and L2 Modules must be in Payload Data Ground Segment (PDGS) and CCSDS format from version 4 onwards. The configuration files will be XML files. In this way it is easy to replace any of the modules for a new one without impacting any of the other modules code (as long as the format of the internal files is not changed). This will also allow for breakpoint data to be automatically available at the end of the processing execution for easier debugging.