Generic Instrument Processing Facility Interface Specifications A Buongiorno

Generic Instrument Processing Facility Interface Specifications A. Buongiorno ESA EOP-GS Frascati 12 /10/2012 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 Space Segment The Payload Data Ground Segment is a component of the overall Ground Segment, in charge of the following key activities: PDGS Acquisition FOS • 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 Ingestion Mission Planning disseminatio n User Interfac e Archiving Processing QC GS USER

Processing Facility PDGS The PF architecture is based on the following subsystems : P 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. Processing PF Management Layer IP F I P F 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

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 Name Description Static/Dynamic Information Dynamic Job Order The 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 Logging Each Task must log major processing event Dynamic according to a specific logging syntax The Exit Code of the processors is used to Dynamic convey processing success/failure information to the Management Layer. The Task Table specifies the Processor structure Static (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. Exit Code Processor Task Table Generating Source Management Layer IPF IPF 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