GOCE Instrument Processing Facility Infrastructure. From Telemetry to Level 1b: Architecture,Products and Processing Strategy

1
GOCE Instrument Processing Facility
Infrastructure. From Telemetry to Level 1b
Architecture,Products and Processing Strategy

• P.L. Mantovani, D. De Candia, T. Geminale, C.
  Zelli
• Advanced Computer Systems (ACS)

2
Summary of the Presentation

• The paper presents the IPF Systems Architecture
  as well as Processing Strategy and resulting
  Products.
• The presentation will focus on Products and
  Processing Strategy rather than on Architecture
• The learning path

• Conclusions

3
Summary of the Requirements for L0 Generation

• Data driven generation -gt no acquisition plan
• Input
• VC2 (Science TM) and VC3 (HK TM) OBT/UTC
  conversion table.
• Output
• Each L0 contains
• Consecutive ISPs relevant to one Instrument and
  one Operative mode (VC2)
• Consecutive ISPs of the same HK telemetry type
  (VC3).
• Time coverage
• For every L0 but the calibration products the
  time coverage is the same as the TM coverage
• Calibration products time coverage calibration
  activity duration.
• Gaps
• Every L0 is gap-free Gaps in ISPs stream causes
  two L0 of the same type to be generated

4
Summary of the Requirements for L1b Generation

• Data driven generation
• Input
• L0 auxiliary data
• Output
• Each L1b contains either Scientific or Monitoring
  or Calibration payload data processed up to Level
  1b
• Time coverage
• Every Scientific L1b product covers one orbit
  from ANX to ANX
• Monitoring L1b products can cover either one
  orbit or one day.
• Calibration L1b products time coverage
  calibration activity duration
• Gaps
• Gaps are allowed in L1b products. They are of two
  types
• Recoverable gaps (data on-board but not yet
  received on ground) removed by consolidation
  processing
• Unrecoverable gaps (data are not on-board)
  forever missed

5
System Requirements

• Cross-coupling of instrument data for product
  generation
• SSTI GPS datation in input to every product
  generator.
• DFAC and EGG measurements have to be coupled.
• Specific contingency strategy.
• Usage of data history (previous data)
• Kalman filter warm-up (at least 5 orbits).
• Monitoring of Gravity Gradient Tensor Trace
• Usage of data with different availability in time
• Consolidation strategy.
• Very flexible local features for System
  Calibration and Monitoring purposes
• Intermediate Product Generation.
• No real-time performances
• Product formats
• Usage of EE formats

6
Data Flow

• IPF product generation flow requires
• Products with different time coverage have to be
  cross-coupled in input.
• Products from different instruments have to be
  cross-coupled in input.
• Processing history does matter in the generation
  of one product
• The simplest example the L0 Data flow

7
The Level 0 Data Flow
8
The Processing Strategy Divide and Conquer

• Complexity of requirements has been managed by
  decomposing the data flow implementation into
  many tasks so that the level of abstraction in
  each is reduced.
• Dependencies between the decomposed tasks is
  reduced thus reducing the complexity.
• As a result of this strategy to manage
  complexity, the number of tasks is pretty high.
  The IPF consists of
• 5 Level 0 Processors -gt 15 Level 0 products
• 11 Level 1b Processors -gt 14 intermediate
  products (for monitoring purposes) 3 Level 1b
  products (to be distributed to the End-Users)

9
Level 0 Processing Strategy Divide First and

• DIVIDE VC2 and VC3 are first processed
  separately

10
Level 0 Processing Strategy then Conquer

• CONQUER combine the divided results into the
  final products

SST_ICB_0_
SST_L0_PP
SST_NOM_0_
DFC_F10_0
DFC10_L0_PP
DFC_Anw_0_
(Science Telemetry)
EGG_NOM_0_
EGG_L0_PP
EGG_ICM_0_
(HK Telemetry)
11
Processing Strategy the Complete Picture

• In the next slide

12

SST_NOM_1b
SST_RIN_1b
EGG_NOM_1B
VC2
VC3
13
Conclusions

• The GOCE requirements and data flow have been
  proven to be not straightforward
• Products with different time coverage have to be
  cross-coupled in input.
• Products from different instruments have to be
  cross-coupled in input.
• Processing history does matter in the generation
  of one product
• The complexity of this product generation flow
  required a specific strategy to be studied to
  manage the complexity.
• The IPF design has been found to be suitable to
  manage this kind of complexity by translating
  complex tasks into many, elementary processing
  tasks. The IPF consists of
• 5 Level 0 Processors -gt 15 Level 0 products
• 11 Level 1b Processors -gt 14 intermediate
  products, 3 Level 1b products to be distributed
• The IPF system has been implemented and proven to
  be
• Flexible e.g. different product time coverage
  requirements have been implemented
• Scalable upgrade of hardware configuration is
  effort-free
• Configurable e.g. several Processors version can
  be installed at the same time in the IPF
• Reliable a failure on one node doesnt affect
  the overall system behaviour (but performance
  figures)
• Easy to use