Generic Instrument Processing Facility Interface Specifications

1. Generic Instrument Processing Facility Interface Specifications A. Buongiorno Frascati 12 /10/2012 ESA EOP-GS

2. What are they? ESA Interface Control Document • Interface • IPF • Generic Scope: • Establishing common practice across the various ESA missions for the development and the integration of new processing facilities • To this purpose the document specifies all interfaces, conventions and design constraints that must be satisfied by any processor that has to be integrated in the PDGS environment. • The specifications provide into this document are supposed to be customised on the basis of the Processing Facility specific ICDs to be issued in the frame of each mission development.

3. PDGS functions overview Space Segment The Payload Data Ground Segment is a component of the overall Ground Segment, in charge of the following key activities: • Implementing the mission observation scenario • Performing the processing activities in response to services needs and ensuring data archiving • Providing data to users • Monitoring instruments and mission performance • Ensuring products meet the expected quality, with necessary calibration and validation activities Acquisition Ingestion PDGS FOS Mission Planning dissemination Archiving User Interface QC Processing GS USER

4. Processing Facility PDGS P Processing PF Management Layer IPF IPF IPF IPF IPF The PF architecture is based on the following subsystems : Management Layer Manage and controls the Processors’ operations and implements the interface to the other PDGS elements. It interfaces the IPF on one side and the PDGS on the other one. Instrument Processing Facility encapsulates the algorithmic and computational part of the product generation process. Implemented as collection of executables. Each Executable is named: Task All the interfaces between the Management Layer and IPF are file-based.

5. ML <-> IPF interfaces The interfaces between the Managent Layer and the IPF are identified and classifiedas: • Compulsory • Non-compulsory • Recommended • Compulsory interfaces are the ML <-> IPF architecture cornerstones: the system cannot work without these interfaces implemented. • Non-compulsory interfaces includes interfaces that are widely used in existing PF, nevertheless simpler PF or new PF could not need all these interfaces. • The decision about which Non-compulsory interfaces has to be implemented is driven by the Management Layer architecture characteristics

6. Compulsory interfaces

7. PROCESSING LOGIC The PDGS generates a PROCESSING event (ORDER) and submits it into Management Layer (ML) processing queue To fulfil an ORDER the ML has to verify that all the inputs needed available in the PDGS Archive. The ML retrieve and puts in the working directory all input files needed (by the Processor. Generates the Job Order . Starts in sequence the IPF Processing Task according to the order specified in the Task Table. The ML passes the Job Order to each Task on the command line. The ML captures and logs the most significant events occurring during the execution of each Task. Upon execution accomplishment each Task returns an EXIT CODE to the ML. According to this value the ML makes the decision whether to start the next Task in the TASK TABLE list or not. When the last Task of the Processor finishes, the ML moves the files to be inventoried to the PDGS Archive and removes the working directory from disk.

8. Generic IPF Interface implementation EO Missions PDGS implementing the Generic IPF ICD…. Cryosat GOCE (~18 IPFs) SWARM ENVISAT (>30 IPFs ) Sentinel-1 Sentinel-3 (~ 30 IPFs )

9. Advantages in using a Generic IPF Interface Development • Decoupling of the IPF implementation from other PDGS elements • Easier the implementation of IPF simulators for PDGS testing • Easier the IPF integration activities • Improve PDGS elements re-use Operations • Scalability and configurability • Reliability • Easier the IPF maintenance activities • Improve the IPFs monitoring capability