generic instrument processing facility interface specifications a. buongiornofrascati 12 /10/2012...
TRANSCRIPT
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