Detailed Scenario Process
Note
The Detailed Scenario process described in this section gathers the feedback from the ORB17, PJ12, and 7E1 scenarios, and therefore does not reflect the process when these detailed scenarios were being addressed. If you need to access a previous version of the process, please refer to the corresponding version of this document available on Eclipse.
Process Overview
The Detailed Scenario process includes three milestones that will be tackled in three different phases. The milestones are:
Milestone 1: Consolidated Observation Plan (OPL) for PRIME observations and skeleton pointing timeline (PTR) with DESIGNER blocks.
Milestone 2: Frozen Pointing Timeline Request (PTR)
Milestone 3: Frozen Instrument Timelines (ITL)
The process will be divided into 3 phases:
Observation Timeline Harmonisation (OTH)
Pointing Timeline Harmonisation (PTH)
Instrument Timeline Harmonisation (ITH)
OTH: Starting from the Segmentation, the goal is to consolidate an Observation Plan (OPL) and obtain a timeline for the PRIME Observations as well as a skeleton pointing timeline (PTR) and associated DESIGNER instruments. This will later be refined to define the Spacecraft Pointing.
- PTH: Starting from a baseline PTR generated from the consolidated Observation Plan, the goal is to obtain a frozen
PTR built by the DESIGNER instruments in collaboration with the PRIME and RIDER instruments already taking into account the impact on the Energy budget.
ITH: Starting from ITLs generated from the Observation Plan updated after the PTH process, the goal is to obtain instrument timelines within the Power and Data resources and applicable constraints.
Detailed Scenario Workflow
The following figure provides a simplified process overview.
JUICE Detailed Scenario Workflow
Starting Point: Segmentation Plan
The starting point of the Detailed Scenario Process is the Segmentation Plan covering the time period of the detailed scenario. This Segmentation Plan will be provided by the SOC as part of the starting kit for the detailed scenario exercise. This also provides the data volume envelopes derived from the data volume assigned to each discipline. Note that as we get closer to nominal operations, the Segmentation Plan will be more detailed and the data volume envelopes more accurate. The iterations over the Segmentation are not part of the detailed scenario but part of the strategic planning led by the Working Groups. The strategic planning is described in the Science Activity Plan [SAP].
The blocks derived from the Segmentation will mainly include two different blocks:
Science blocks (associated with WGs), that will be split in a number of individual observations along the process.
Operational Blocks, defined by the SOC based on the MPAD [MPAD].
Operational Blocks
The operational blocks specify periods that are reserved for a number of spacecraft operations that impose restrictions on the observations that can be included. The operational blocks have been scheduled by the SOC during the Segmentation process based on rules defined in [MPAD]. Some of them have limited flexibility that can be used to reschedule them during the Observation Timeline Harmonisation process.
During the nominal science phase, the operational blocks will be fixed at Long Term Planning (LTP) level.
The operational blocks will be provided as part of the starting kit as the initial Observation Plan and with
the description of these blocks and their scheduling rules, it will be included in the TIMELINE
directory of the JUICE_PREOPS repository of the given scenario and can be used by the teams as a starting point
to generate their OPLs.
The flexibility of each block is described in the following sub-sections which are extracted from the MPAD [MPAD].
Downlink (DL_)
The baseline station considered for the detailed scenario analysis is Malargüe.
For each Malargüe visibility, a downlink window is identified as follows:
Baseline duration of each downlink window in segmentation is 9 hours.
Start of downlink window when topographic elevation reaches 10 deg.
First and last 30 min of this window are assumed to be used to point the HGA to/from Earth (1 hour total).
1 hour used for HK downlink and a maximum of 7 hours is considered for science downlink.
The following flexibility is considered for the scheduling:
Theoretically, 8 hours out of the 9 hours should be scheduled during Malargüe visibility.
In practice the detailed station scheduling will be known later in the mission (at LTP). For strategic science planning, communication windows can be shortened but cannot be shorter than 3 hours (i.e. 4 hours including slews) for the HGA and 4 hours for the MGA.
2 successive HGA communication windows cannot be removed from the plan.
If an HGA pass is skipped then the block becomes a PRIME observation without DESIGNER status. This means other observations can be scheduled and request DESIGNER status but will need to take into account to allow MGA operations.
In addition, please note that Downlink blocks impose a restriction on the instruments that can operate and therefore the observations that can be contemporarily scheduled. These are defined in Downlink limited observations.
Note
The removal/shortening of a DL_ block will result in an analysis of the DV reduction impact
on the Segmentation. MGA passes cannot be used for science data (introduced in [MPAD] v. XX).
Finally it is important to mention that there is a number of Downlink modification already implemented at skeleton Segmentation level:
Reduced HGA downlink windows during flyby inbound leg
HGA Downlink skipped during flyby
This results in about 9.25 hours of lost downlink capacity for each flyby (~ 1.5 Gb). This is due to the suspension of HGA downlink between CA +/- 12 hours, and depending on the geometry this can result in reducing or removing 1 full pass or 2 partial passes.
Trajectory Correction Manoeuvres (J_FD_TCM)
Trajectory Correction Manoeuvres are operational blocks that involve thruster or main engine firing and that have an unknown attitude profile which is assumed as default Jupiter track during the Tour phase. They are scheduled as follows: In the days around a Jovian moon flyby, 3-hour Navigation TCM slots (including 30 min slew time on both ends) shall be reserved at CA-7 days, CA-3 days and CA+3 days.
TCM blocks cannot be moved and the profile of reserved TCM slots is based on the assumptions taken for the Jupiter Tour Navigation Analysis [MPAD].
Wheel Offloading (J_FD_WOL)
Wheel Offloadings (WOLs) are operational blocks that involve thruster firing and that have an unknown attitude profile which is assumed as default Jupiter track during the Tour phase.
Their definition is as follows:
2-hour long WOL slots (including 30 min slews on both ends) shall be reserved every 72 hours (or shorter).
In the last week before the flyby, a WOL slot shall be combined with the TCM slot at CA-3 days (i.e. a single 3 hour slot).
Another 2-hour WOL slot shall be reserved at CA+12 hours.
The current implementation is to schedule the WOL adjacent to a downlink segment: every 72 hours, we schedule a WOL slot ending right at the beginning of the Malargüe visibility thus optimizing the slew time needed for both operation blocks. Total duration of the WOL block in this case is 1.5 hours.
Effectively, for the detailed scenarios the blocks cannot be moved. However, WOL slots can be moved by maximum 1 hour to gain some flexibility in the planning exercises. In any case, one should keep the need for such shifts to a strict minimum and gain experience on what planning cases really require flexibility at all.
During the science phase, WOLs will be baseline at LTP level but depending on the requested pointing timeline, their number might increase and they might change.
S/C +Z Axis flip (FLIP_ZAXIS)
Flip blocks indicate that the S/C needs to be flipped around the +Z axis to avoid the +X face being illuminated based on the Jupiter Tour default attitude (see Detailed Scenario Constraints). Observations can be planned in parallel but this flip block needs to be considered as a PRIME observation for the pointing design.
Battery Recovery (BATTERY_RECOVERY_STANDARD)
Battery Recovery blocks indicate that the S/C has to recover its battery after a period with dense operations such as a flyby.
These blocks are scheduled at Segmentation level assuming maximum allowed battery depletion reached at the end of the flyby (see [MPAD] for applicable value).
Battery recovery segments impose the modes in which each instrument can operate. These are defined in Battery Recovery Segments.
Science Blocks
The science blocks (or science segments) assigned to the different disciplines (or Working Groups) based on the mission phases coming from the Segmentation can be used by the instrument teams to schedule their desired observations. Example of science blocks present in ORB17:
C_GPH_16C9: Callisto Flyby Geophysics (WG1)C_RS_16C9: Callisto Flyby Remote Sensing (WG2)JM_GM: Jupiter Magnetosphere Monitoring (WG3)JA_PE17: Jupiter Atmosphere Perijove (WG4)
Observation Timeline Harmonisation
The first step of the detailed scenario is to obtain an Observation Plan from the Segmentation.
Following the identification of the scenario time period, the adequate Segmentation Plan is extracted. From there, the segments within the plan will be used as a basis for the instrument teams to define and request observations supported by a science plan that will be presented, shared, and documented with all the other teams.
The Observation plan proposed by the teams needs to be aligned with the working groups or disciplines specified by the corresponding Segmentation Plan.
Each team needs to first provide a science justification or rationale for their starting observation plan. This is addressed during the Science Plan Meeting. The requests will be considered and prioritized based on the the original blocks’ science objective; i.e. in case of a conflict, the observation associated to the corresponding WG science objective will be prioritized.
Note
Some exceptions might apply to the prioritization rule such as UVS stellar occultations the timing of which is not known at Segmentation level. Any request for deviation should be thoroughly justified in the science plan.
This observation plan will contain a number of observation time requests for each of the relevant instruments. Each instrument will have their observation plan (OPL). In addition, there will be a PRIME observation timeline that will reflect the PRIME observations as a function of time. Finally, a DESIGNER timeline will reflect which instrument team will be in charge of designing the pointing of a specific time window during the PTH process.
A detailed definition of the observation types is provided hereunder:
PRIME observations are observations that require a specific spacecraft pointing. Although several PRIME observations can be scheduled in parallel, only one can have DESIGNER status at a time. E.g. instrument X wants to look nadir with a specific phase angle. PRIME observations need to be taken into account by the DESIGNER instrument in order to ensure that the observation is compatible with the pointing.
RIDER observations are observations that do not have a specific pointing requirement but are attached to a specific pointing block and will live with the pointing designer for that block without the possibility to infer in the design. They can therefore be modified during the PTH process following any modification of that DESIGNER block. E.g. instrument X wants to look at the limb but will adapt to whatever pointing instrument Y is using, so it can be scheduled as a RIDER observation to instrument Y’s DESIGNER block pointing at the limb.
OBSERVATION (Non-Designer-Prime-Rider) are completely agnostic to the pointing. E.g. instrument X wants to observe at a set time and does not care about the pointing, so it can be scheduled as a regular observation without any specific pointing requirement.
In addition to the observation type, if an observation is of PRIME type it can have a DESIGNER attribute. As specified before, this means that the associated instrument will design the pointing for the duration of the observation during the PTH process.
OTH Process
The goal of the OTH process is to turn the Segmentation Plan of the detailed scenario period into an observation plan that includes all the observations requested by the Instrument Teams that address the science goals of the scenario and that are compliant with the Power and Data Volume resources.
During this process, the files exchanged between the Instrument Teams and the SOC are the Observation Plan Files (OPL) and the Observation Definition Files (ODF). More information on these files is available on Detailed Planning Files.
The starting point is the Segmentation. As a first step, it can be refined at the first OTH meeting. Requests need to be thoroughly justified. Later, the Instrument Teams provide a set of initial science observations aligned with the priorities of this refined Segmentation and accompanied by a science plan document (template provided by SOC). These observations can be labeled as PRIME, RIDER or simple OBSERVATION. At the end of the OTH process, DESIGNER status will be attributed to one PRIME instrument by time block for pointing design - no overlap is possible.
The observations indicated by the Instrument Teams must have an observation definition either by being present a priori in the SOC observation database or by providing an Observation Definition File (see Observation Definition File (ODF)). These observation definitions will have a Power (mandatory) and Data Rate envelope (optional) or an instrument mode in such a way that from the early stages of the planning process potential limitations of resources can be identified. In addition, each observation in the timeline must have a unique identifier (or unique name) which is derived from the observation definition.
Some of the steps that will be carried out during the process are:
Refine the Segmentation (e.g. move science segments, or decide on potential downlink skipping or reduction)
Provide a name and a science rationale to each observation.
Provide Power and Data Volume envelopes for the resulting observations whenever possible.
Determine the PRIME observation and DESIGNER timelines based on pointing needs and science justification.
The main supporting tool used during this process will be the Timeline Tool which will allow all participants to visualise the different timelines at each iteration.
At each step of the OTH process, SOC will provide draft OTL files generated from the OPL files in order to perform an initial assessment of the Power and Data envelopes whenever available. This will be supported by Python Notebooks made available to the teams. Note that these assessments will be preliminary and can only be as good as the information provided in the observation definitions (ODF). Instrument Teams are therefore encouraged to provide as much detail as possible in the ODFs to avoid unrealistic power or data envelopes that could lead to important modifications of the observation plan later in the process.
Additionally Cesium Coverage GeoJSON files might be generated for an initial coverage assessment if deemed necessary during the exercise (note that this did not happen for ORB17). These ITL and GeoJSON files could be generated for each contributing instrument. More information is available at Cesium Viewer.
The sub-sections below provide an overview of each step of the OTH process.
Delivery (SOC->PI) Starting Kit
As part of the Starting Kit, the SOC will generate a Segmentation Plan that only covers the period of the Detailed Scenario. For this delivery, the SOC will generate a segmentation OPL that will include the PRIME timeline and any additional segment or observation observed by the SOC (S/C Flip, transit, etc.) along with an individual OPL file for the NAVCAM and for RADEM.
This plan will be used as a starting point for the Observation Timeline Harmonisation (OTH) process discussed during the kick-off meeting.
These files will be made available in the TIMELINE folder of the JUICE_PREOPS repository (e.g. OPL_SEG_S007_PJ12_S00P00.json).
For more information on the rationale of this name please refer to File versioning and deliveries.
First version of the Observation Plan in the Timeline Tool Segmentation Plan S007_PJ12_S01P00
Important
More details on OPLs, including how to generate them are available in Observation Plan File (OPL). In addition, a baseline PTR will also be provided including the corresponding SPICE CK kernel. See Baseline PTR.
Kick-off Meeting (KO)
The kick-off meeting will consist of a presentation of the scenario overview, processes, applicable constraints, etc.
- Input:
SOC: Rules of the Road for the Detailed Scenario.
SOC: Starting Kit presentation.
SOC: Baseline Segmentation Plan presentation.
- Output:
SOC: Adjustments to the process (if needed).
Instrument Teams: Understanding of the process and tests of the tools.
Segmentation Review (OTH#1)
This subsequent meeting could be skipped if no changes to the Segmentation are needed after the kick-off meeting. The goal is to review and finalise the Segmentation Plan for the detailed scenario period. This can include requests for moving or shortening a DL_ block (within the allowed flexibility), calibration windows or any other modification to the Segmentation that could help improve the science return of the scenario.
- Input:
Instrument Teams: Proposed Segmentation adjustments (if any) with justification.
- Output:
SOC: updated Segmentation adjustment (if needed).
Delivery (PI->SOC) Science Plan
The Science Plan is the document that describes the science that will be performed by each instrument relating them to the observation plan. This document will be presented during the Science Plan Meeting.
The Document needs to be delivered in PDF format and must have a reasonable size. The delivery
mechanism will be via git merge request to the JUICE_PREOPS repository in the
PLANNING/SCENARIOS/<scenario>/SCIENCE_PLAN folder.
The document name should follow this format: <scenario>_<instrument_name>_science_plan_<version>.pdf,
e.g.: pj12_janus_science_plan_v01.pdf.
Delivery (PI->SOC) Initial Observation Plan
The Science Plan document must be complemented by another delivery from the Instrument Teams,
the initial Observation Plan P1 (PI->SOC) OPL S01PYY.
This OPL file will contain the initial observation plan for the instrument team based on observations available on the JUICE SOC Observation Database. If the observations are not present in the database or the data and power envelopes from the database need to be updated, the Instrument Team needs to deliver the corresponding Observation Definition files.
Important
The initial Observation plan is expected to contain observation instantiation proposals mainly inside the applicable segments (WG and/or discipline). Although this is not a strict rule, it will be taken into account for prioritization. Any request for deviation should be thoroughly justified in the science plan.
Important
See the OPL section OPL Generation with the Timeline Tool for indications on the generation and delivery of OPLs. The detailed delivery process is described in PI->SOC Deliveries.
Science Plan Meeting (OTH#2)
The Science Plan meeting will be preceded by a Science Plan document delivery by the Instrument Teams and the initial Observation Plan (OPL).
During this meeting each team will present their science rationale and the observation plan that they have prepared. Although the delivered science plan can (and should!) be comprehensive, each team will have a maximum of 10 minutes to present the highlights and points for discussion to the group. This is the opportunity to discuss potential conflicts between teams and to refine the observation plan based on the feedback from the other teams.
The SOC will generate a new draft harmonised version of the Observation Plan (OPL) that will be used as a starting point for the next Instrument Team delivery and subsequent meeting.
- Input:
Instrument Teams: description of the science to be performed by each instrument and eventually ideal observation schedule (or at least the observation strategy). In particular, when the instrument requests to be PRIME.
- Output:
SOC: updated Segmentation adjustment (if needed).
SOC: Segmentation Plan with the observations delivered by the instrument teams.
Delivery (SOC->PI) First Harmonised Observation Plan
The next delivery from the SOC is the first harmonised observation plan S3 (SOC->PI) OPL S03P00.
This delivery will include both an updated Plan available in the Timeline Tool, that will already
include the timelines of all the instruments and the corresponding Observation Plan File (OPL) in
the JUICE_PREOPS repository.
For this delivery the SOC will generate a PRIME OPL and a DESIGNER OPL that will include the PRIME timeline
and any additional segment or observation observed by the SOC (S/C Flip, transit, etc.) along with an individual
OPL file for each Instrument Team with observations of all types.
Following the delivery from the SOC, the Instrument Teams must follow the procedure to incorporate the delivery in their repository branches. The detailed delivery process is described in SOC->PI Deliveries.
Deliveries (PI->SOC) Observation Definition Updates
After the extraction of observation definitions from the Observation Database further updates to the
Observation Definition for the instantiation of the observations specific to the scenario are performed
by updating the Observation Definition Files (ODF) directly in the JUICE_PREOPS repository (PLANNING/SCENARIOS/<scenario>/OBSERVATIONS).
The Observation Definition File (ODF) updates will include the possibility to add or update:
a PTR snippet in the observation to build up the Baseline Pointing Timeline Request (PTR). This could be helpful for performing a more realistic early assessment of the available Power.
an ITL snippet in the observation. This could help to perform an early assessment of Power and Data volume envelopes.
The level of detail that is available at this point of the process will be agreed with each team.
Important
details on ODFs, including how to generate them are available in Observation Definition File (ODF). The detailed delivery process is described in PI->SOC Deliveries.
Deliveries (PI->SOC) Observation Plan Iterations
Following the different Observation Plan Meetings, successive OPL deliveries will be performed by the instrument teams.
These iterative OPL files will include the feedback discussed in the meetings on the previous observation plan or observation schedule for the instrument team based on the available observation definitions.
Important
See the OPL section OPL Generation with the Timeline Tool for indications on the generation and delivery of OPLs. The detailed delivery process is described in PI->SOC Deliveries.
Observation Plan Meetings (OTH#3, OTH#4, OTH#5)
During these meetings, PRIME observation requests conflicts are sorted out based on the Observation Plan inputs provided by the instrument teams with the aim to converge on a consolidated PRIME observation timeline, pointing DESIGNER timeline, and an overall observation timeline free of obvious pointing conflicts within the estimated resources envelopes.
This will be an iterative process that will take a number of cycles of the following steps:
Instrument Team delivery,
SOC integration of deliveries,
deconflicting through iterations and discussion at weekly meetings,
SOC harmonisation and updated OPL delivery.
The output of this meeting will be a Harmonised Observation Plan from which the high-level Instrument Timeline Files (OTL) can be generated, using the power envelopes provided in the ODFs in order to be able to perform resource analysis as soon as possible
In addition, the baseline Pointing Timeline Request (PTR) file will be generated by the SOC based on the consolidated PRIME and DESIGNER OPLs.
- Input:
Instrument Teams: Observation Plan (OPL)
Instrument Teams: Power and Data Envelopes at Observation level (ODF)
SOC: Harmonised Observation Plan (OPL)
- Output:
SOC and Instrument Teams: Frozen Harmonised Observation Plan with PRIME and RIDER observations and DESIGNER roles attributed.
Instrument Teams: Agreements on slew absorption in consecutive observations and phasing where applicable.
SOC: Generation of OTL files by the SOC based on Harmonised Observation Plan including the rider information.
Delivery (SOC->PI) Harmonised Observation Plans
The next deliveries from the SOC are the harmonised observation plans SX (SOC->PI) OPL S0XP00.
These deliveries will include several updated OPL files corresponding to the PRIME and RIDER timelines,
the DESIGNER timeline, each individual instrument timeline for that iteration and a merged SOC OPL including all observations.
Following the delivery from the SOC, the Instrument Teams must follow the procedure to incorporate the delivery in their repository branches. The detailed delivery process is described in SOC->PI Deliveries.
Delivery (SOC->PI) Observation Timeline Files
When an Observation Plan is Harmonised and the Observation Definitions it contains are well defined, a set of Observation Timeline files can be generated. This is mandatory when the final Observation Plan is obtained.
The Observation Timeline files are essentially ITLs that contain an observation timeline.
Following the delivery from the SOC, the Instrument Teams must follow the procedure to incorporate the delivery in their repository branches. The detailed delivery process is described in SOC->PI Deliveries.
Pointing Timeline Harmonisation
Following the consolidation of the Observation Plan, the next step is to obtain a harmonized Pointing Timeline. In order to do so, a baseline Pointing Timeline Request (PTR) will be delivered by the SOC as described in Delivery (SOC->PI) Baseline PTR.
During this process the main contributions will be from the Instrument Teams that are DESIGNER of pointing blocks given that they are ultimately responsible to deliver PTR updates to the SOC.
The Instrument Teams with PRIME observations need to be in coordination with the respective DESIGNER instrument teams in order to ensure that their observations are feasible with the implemented pointing requests and that all their needs are clearly communicated. The coordination can be supported by the SOC as needed but the ultimate responsibility lies with the Instrument Teams.
Please note that certain Instrument Teams might be able to skip this process: in most cases, J-MAG and RPWI, 3GM in the absence of Earth occultations, and RIME and GALA if there are no geophysics segments. Nevertheless these teams should be available whenever requested especially if an observation compatibility issue appears.
During each iteration of this process, which ends in a SOC delivery to the Instrument Teams, the SOC will regenerate an OPL for each new updated PTR in order to ensure that the observation and pointing timelines are aligned at all times.
During the PTH process the SOC might generate Cesium Scene files directly in Cesium Viewer for each pointing iteration if deemed necessary. More information is available at Cesium Viewer. In addition Cesium Coverage GeoJSON files could be generated for an initial coverage assessment.
PTR impact on Available Power
During the PTH process, the impact of the PTR requests on the available power will be assessed by running a simplified simulation. The SOC has made available the power calculation with the Attitude Generation Module (AGM) through OSVE, the Pointing Tool, and the Pointing Tool Wrapper.
If a PTR request has a major impact on the power, the issue will be flagged and discussed in the PTH process meetings to avoid consequences on the overall scenario power budget that could lead to important modifications of the observation plan later in the process.
PTH Process
Delivery (SOC->PI) Baseline PTR
This PTR will contain the agreed default attitude of the trajectory as defined in the corresponding Segmentation Plan, together with a
potential number of PTR blocks that correspond to DESIGNER observations whenever the associated PTR blocks are provided by their
Observation Definition Files (S5 (SOC->PI) PTR S05P00).
In addition, the default attitude for certain blocks can be updated from the default coming from the Segmentation based on collective agreements made during the OTH process, i.e.: for a certain period the default attitude could be to track the North Pole of Jupiter. High-level agreements on phasing where applicable will also be considered to make the pointing design easier for the DESIGNER instruments.
This PTR will follow the syntax and rules specified in Pointing Timeline Request File (PTR).
Pointing Harmonisation Meetings (PTH#1, PTH#2, PTH#3, PTH#4)
A number of meetings will be held in order to achieve a harmonised Pointing Timeline. These meetings will be held after the SOC integrates the deliveries by the DESIGNER Instrument Teams and identifies potential conflicts that will be discussed during the meeting (available power issues, torque violations, slew timings, etc.).
Additionally, with each iteration the SOC will generate updated OPLs for the DESIGNER, PRIME, and RIDER observations that have been impacted by modifications in the delivered PTRs; although the PTRs need to follow the observation start and end times agreed during the OTH as reflected in the OPLs it is understood that PTR iterations may modify these times for different reasons (slews, pointing design itself, DESIGNER-PRIME agreements). These modifications could result in significant changes in the observation plan that will need to be discussed during the meetings.
The outcome of the meetings will be the instructions and/or indications for the DESIGNER and PRIME instruments on another delivery of the PTR in order to converge towards a harmonised timeline.
- Input:
Instrument Teams (DESIGNER): Updated PTR blocks that are compliant with the PRIME observations.
SOC: Proposed conflict resolution, harmonised PTR based on the Instrument Team inputs.
- Output:
SOC: post-meeting Harmonised PTR generation including generation of the updated OPLs, OTLs, and available power impact analysis.
Deliveries (PI->SOC) PTR updates
During the PTH process the DESIGNER Instruments will perform deliveries based on the latest version of the
harmonised PTR provided by the SOC (PNN (PI->SOC) PTR SNNPYY).
These deliveries will contain the PTR for the full period of the scenario but with updates only for the pointing blocks assigned
to the DESIGNER instrument team performing the delivery.
These PTRs will follow the syntax and rules specified in Pointing Timeline Request File (PTR).
Guidelines and rules for the instrument teams for PTR generation are provided in PTR Generation Guidelines and Rules.
Important
During the PTR design preceding a PI->SOC delivery, the DESIGNER teams need to be coordinated and in agreement with the PRIME observation teams. They are also encouraged to organise working meetings in order to consolidate the PTR blocks for the relevant observations. This can be done with support from the SOC as needed.
Instrument Timeline Harmonisation
The Instrument Timeline Harmonisation (ITH) process goal is to agree and consolidate the Power and Data Volume generated by the instruments and to ensure that they are compliant with the available resources for the scenario.
During this process, the level of modelling detail will depend on each instrument; the minimum being the Power and Data Rate or Data Volume envelopes for each observation. As of TR03, SSMM modelling will be considered with the direction of the Data resources to specific Data Flows mapped to the different SSMM directories. This will allow a more refined analysis of Data Volume generation, storage usage and latency during the scenario.
Delivery (SOC->PI) Draft ITLs
Following the PTR Freezing Milestone, a set of draft/initial ITL files will be generated based on the latest version
of the Observation Plans delivered by the instrument teams, including the potential updates that might have occurred
during the PTH process (S9 (SOC->PI) ITL S01P00). These ITL files will be used as a starting point for the Instrument
Timeline Harmonisation.
These ITLs will follow the syntax and rules specified in Instrument Timeline File (ITL).
Deliveries (PI->SOC) ITL updates
During the ITH process the Instrument Teams will perform ITL deliveries (PNN (PI->SOC) ITL S0XPYY).
These deliveries will contain the adequate level of instrument commanding modeling to run full OSVE/MAPPS simulations and
will comply with the resources envelopes agreed for each instrument during the ITH process.
These ITLs will follow the syntax and rules specified in Instrument Timeline File (ITL).
The generation of ITL files highly depends on the internal processes of each team but it is important to understand that ITL updates can be performed in two different ways: either by providing the “commanding” directly in the ITL files or by updating the ITL blocks in the observation definition files (ODF) for the different observation instantiations. More information is provided in 50_planning_files:ITLs with Observations.
Instrument Harmonisation Meetings (ITH#1, ITH#2)
A number of meetings will be held in order to achieve a harmonised Instrument Timeline. These meetings will be held after the SOC integrates the deliveries by the Instrument Teams and identifies potential data volume and power usage exceeding the allocated envelope for the scenario.
The outcome of the meetings will be the instructions and/or indications for the instruments on another delivery of the ITLs in order to converge towards a harmonised timeline.
- Input:
Instrument Teams: Updated ITL.
SOC: Harmonised ITLs based on the Instrument Teams inputs.
- Output:
SOC: post-meeting Harmonised ITL generation including generation of the corresponding Data Volume and Power status reports.
Retrospective Meeting
The Detailed Scenario process reaches its conclusion in the final Retrospective meeting. The goal of this meeting is to summarise the overall process, present the scientific assessment reports by the Instrument Teams, and collect feedback on the process, tools, and results.
- Input:
Instrument Teams: Detailed Scenario Report, including scientific assessment of the scenario and feedback on the process and tools.
SOC: Detailed Scenario results overview and preliminary lessons learned on the process, tools, and results.
- Output:
SOC: Exercise Implementation Report and proposed list of delta development for future exercises.