Planning the Commissioning of a Multi Payload Mission

1
Planning the Commissioning of a Multi Payload
Mission
David FrewVega Group PLC RSOCESA/ESTECdavid.fre
w_at_esa.int
Background The Planning Concept Payload
Observations Identifying Constraints Consolidation
Process Planning Concept Validation Lessons
Learned
2
Background

• The Rosetta Mission
• Pointing scenario overview
• Summary of the Planning Tools

3
Rosetta Mission

• Rosetta is the 3rd cornerstone mission of the ESA
  long-term scientific program Horizon 2000.
• Target Churyumov-Gerasimenko.
• Launch 2nd March 2004.
• During the commissioning phase the Rosetta
  Science Operations Centre (RSOC) is responsible
  for two Mission Scenarios
• Interference scenario
• Pointing scenario

4
Pointing Scenario Overview

• Mission scenario a part of the mission
  fulfilling a set of science goals that typically
  requires a dedicated trajectory
• The pointing scenario consists of a set of
  observations (28 in total) defined by the
  principal investigator (PI) teams that require
  specific spacecraft attitudes in order to fulfil
  commissioning objectives, e.g.
• Bore-sight alignment
• Instrument co-alignment
• Payload calibration
• Geometric distortion measurements
• Scheduled for September 2004 with a duration of
  12 days.

5
Planning Tools

• Project Test Bed (PTB)
• Identifying geometric and environmental pointing
  constraints.
• Flag pointing restrictions and conflicts.
• Generating additional events used for constraint
  evaluation.
• Experiment Planning System (EPS)
• Payload operations verification on experiment
  mode level.
• Modelling the experiment resource allocation.
• Instrument timeline verification against known
  payload constraints.
• Synchronising the payload operations with the
  pointing requests.
• Generation of the Payload Operation Request
  (POR), submitted to the Rosetta Mission Operation
  Centre (RMOC) for uplink to the spacecraft.

6
The Planning Concept

• Overview of the Planning Approach
• Long-Term Planning
• Short-Term Planning

7
Planning Approach
POR
ITL
Instrument Timeline
SEVF
EFDE
PTR
PTB
EPS
Flight Dynamics
SPL
SOR
SOC
FCT
Pointing
Timeline
SPL
NOK OK
NOK OK
Slew request
OK NOK
Modify request
PI
The science operations preparation is a 2 stage
planning process 1st stage Pre-validation of PI
request by SOC ? equivalent to Long Term Plan
(LTP) 2nd stage Resolve operations with pointing
request to generate POR ? equivalent to Short
Term Plan (STP)
8
Stage 1 Pre-validation at SOC (LTP)

• Step 1. The experimenter teams and SOC formalise
  the pointing scenario request as an observation
  in the Scenario Parameter List (SPL).
• Step 2. SOC pre-validates the observation slew
  request via simulation on the PTB. If OK then an
  enhanced event file is created.
• Step 3. SOC checks the instrument timeline (ITL)
  against known constraints using EPS.
• Step 4. All of the verified observations are
  combined in the SPL and submitted to FD.

9
Stage 2 POR generation (STP)

• Step 5. FD confirms the feasibility of the
  pointing request. If OK then they provide SOC
  with a slew event file, if NOK then SOC must
  iterate the experimenter teams to modify the
  request.
• Step 6. Consolidate all payload requests and
  check against constraints. Event driven timelines
  are resolved to the slew events to produce a
  single POR containing absolute times.
• Step 7. The POR is submitted to the flight
  control team (FCT).
• This planning concept has been designed to be
  generic for all ESA planetary science missions.

10
Payload Observations

• Scenario Parameter List (SPL)
• Pre-validation of the request

11
Scenario Parameter List (SPL)

• Pointing requests from team summarised into scan
  design and duration estimation
• PTRS events used by PIs for event driven ITL
  development

12
Pre-validation of the PI request
Initial Conditions
Consistency
Operation Request
Pointing Request
Predicted Orbit
attitude
orbit
DB
ITL
EPS
PTB
Simulation
Simulation
Event definition Geometric constraints e.g. Sun
in FoV
Constraints e.g. Mode ON AND Sun_in_FoV
Pointing Constraints
Operation Constraints
Flight Dynamic Event File
Enhanced Flight Dynamic Event File
Writer
Reader
Writer
Reader
Conflicts

• For each SPL observation the instrument teams
  must provide an event driven ITL to be checked by
  EPS.
• Simulating the observation enables a
  pre-validation of the PI request before
  submission to flight dynamics.

13
Constraints

• Constraint Definition
• Conflict Evaluation

14
Constraint Definition
ITL pointing event delta time experiment
Mode sequence (parameters)
Enhanced events Sun_in_EXP_FoV straylight_angle
Sun_ndeg_panel_xyz orbit_height_above_n_km normal
FD events
EDF
Modes permitted transitions allowed
actions resources
Constraints events modes actions
EPS
Modelling mode update low-level actions resource
allocation
Database sequence command parameter
conflicts actions modes data power timeline

• EPS will flag constraint violations (conflicts).
• Constraint rules are defined in the Experiment
  Description File (EDF).
• Input conditions provided by enhanced event file
  (geometric information) plus experiment modes,
  actions and resources.

15
Conflict Evaluation

• Conflicts generated by
• Forbidden mode actions and transitions (EPS).
• Exceeding a resource allocation (EPS).
• Violating the operational constraints contained
  within the EDF (EPS).
• Violating environmental constraints (PTB).
• Exceeding slew-time constraints (PTB).
• Conflicts resolved by
• Modifying the pointing request the dwell times
  and slew durations may be modified after
  iteration with the PI to avoid constraint
  violations.
• Modify the operation request The timeline must
  be consistent with the EDF.
• Assign experiment priorities One payload usually
  drives each observation and has priority in the
  case of conflicts with the other experiments.

16
Consolidation Process

• SPL Observation
• Mission Scenario

17
Consolidation Process I
Obs 12 SEF
Top level ITL
Top level EDF
RPC EDF
OSIRIS EDF
RPC ITL
OSIRIS ITL
hhmmss PTRS(COUNT1) hhmmss PTRE(COUNT1) hhm
mss PTRS(COUNT2) hhmmss PTRE(COUNT2) hhmmss
PTRS(COUNT3) hhmmss PTRE(COUNT3)
GIADA EDF
MIDAS EDF
GIADA ITL
MIDAS ITL
Operations relative to Obs. 12 pointing events
EPS
conflicts actions modes data power timeline
Consolidate by observation As defined in the
SPL. Use pointing events to synchronise requests
of multiple payloads.
18
Consolidation Process II
Pointing Scenario SEF
Top level ITL
Top level EDF
RPC EDF
OSIRIS EDF
Obs. 1 ITL
hhmmss PTRS(COUNT001001) hhmmss PTRE(COUNT00
1001) up to hhmmss PTRS(COUNT028003) hhmmss
PTRE(COUNT028003)
GIADA EDF
MIDAS EDF
Obs. 28 ITL
EPS
POR

• Consolidation of the entire Mission Scenario
• All observations are included in top-level
  planning input files.
• EPS resolves all included files with the pointing
  event file to produce one Payload operational
  request (POR)

19
Planning Concept Validation

• Rosetta Commissioning
• Smart-1 Payload commissioning

20
Rosetta Commissioning
The planning mechanism has been used successfully
for a number of the individual payload
commissioning activities.

• MIRO spirals Scan enabled boresight alignment to
  Z to be established.

21
Shared Mission Experience

• SMART-1
• The Smart-1 lunar mission was the first ESA
  mission to use the planning software for
  in-flight operations.
• Planned commissioning and calibration phase in
  SPL format.
• Observation analysis done on PTB.
• All geometrical constraints defined in PTB as
  additional planning events.
• Constraint evaluation performed successfully
  using EPS.
• Payload operations run from POR for entire
  calibration phase.

22
Lessons Learned

• Lessons Learned
• Conclusions

23
Lessons Learned

• Interface with Flight Dynamics Must be well
  established with slew information formatted such
  that a fast iteration time is possible.
• Constraints Reviewed regularly, combinations
  should be possible
• Validation Campaign A representative POR has
  been run on Rosetta EQM, providing confidence in
  the planning setup. Further Pointing Scenario
  rehearsal planned for later this year.
• Configuration control Planning files must be
  strictly maintained under configuration control.

24
Conclusions

• Validation of Planning Process
• Rosetta individual commissioning
• Preparation of the Rosetta pointing scenario
• Successful completion of the Smart-1 payload
  commissioning campaign.
• Lessons learned
• Driven the development of the planning tools.
• Benefited all ESA planetary missions.
•  
• Apply generic (cross-mission) solutions
• All planning tool developments available to
  present and future missions.
• Knowledge and experience gained by the science
  operations centre.