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

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. 2

PDGS functions overview USER FOS PDGS Mission Planning Archiving Processing disseminati on User Interfa ce QCQC 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 Space Segment GS

Processing Facility 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. 4 PDGS IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF IPFIPF Management Layer PF Processing P P

ML IPF interfaces The interfaces between the Managent Layer and the IPF are identified and classified as: – 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 5

Compulsory interfaces Interface NameDescriptionStatic/Dynamic Information Generating Source Job OrderThe Job Order contains the set of input files to the Processor, a specification of the output product types and other processing parameters. The same Job Order file is supplied to every Task of the same Processor DynamicManagement Layer LoggingEach Task must log major processing event according to a specific logging syntax DynamicIPF Exit CodeThe Exit Code of the processors is used to convey processing success/failure information to the Management Layer. DynamicIPF Processor Task TableThe Task Table specifies the Processor structure (list of Tasks), the list of input/output to each Task as well as the calling sequence of the Tasks and the input files selection rules. There is one Processor Task Table for each IPF. StaticIPF 6

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. 7

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 ) 8

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 9