Generic Instrument Processing Facility Interface Specifications

A. Buongiorno Frascati 12 /10/2012ESA EOP-GS

1

What are they?

ESA Interface Control Document

– Interface– IPF– GenericScope:

•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 USER

FOSFOSFOSFOSPDGSPDGS

Mission Mission PlanningPlanning

ArchivingArchiving

ProcessingProcessing

dissemination

dissemination

User User InterfacInterfac

ee

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 SegmentSpace Segment

GSGS

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

PDGSPDGS

IPF

IPF

IPF

IPF

IPF

Management Layer

Management Layer

PF

Processing

PP

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

Generating Source

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

Dynamic Management Layer

Logging Each Task must log major processing event according to a specific logging syntax

Dynamic IPF

Exit Code The Exit Code of the processors is used to convey processing success/failure information to the Management Layer.

Dynamic IPF

Processor Task Table The 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.

Static 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