######################### 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. 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 and Designer Observations - **Milestone 2**: Frozen Pointing Timeline Request (PTR) - **Milestone 3**: Frozen Instrument Timelines (ITL) The process will be divided in 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 and Designer Observations that will later 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 rather complicated diagram that schematizes the detailed scenario workflow. This diagram is present for reference. .. figure:: images/diagram_detailed_scenario.png :align: center :width: 100% :alt: JUICE Detailed Scenario Workflow JUICE Detailed Scenario Workflow 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. The segmentation plan also provides the data volume envelopes derived from the data volume assigned to each discipline. The blocks derived from the segmentation will mainly include two different blocks: - Science blocks, that will be split in a number of observations. - Operational Blocks, fixed and flexible operational blocks. 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. The operational blocks will be fixed at Long Term Planning (LTP) level during the nominal science phase. The operational blocks will be provided as part of the starting kit as the initial Observation Plan and will provide 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 Malargue. For each Malargue 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 (convention). - 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 contemplated for science downlink. The following flexibility is considered for the scheduling: - Theoretically, 8 hours out of the 9 hours should be scheduled during Malargue visibility. - In practice the detailed station scheduling will be known later in the mission. 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 but not a designer observation and it needs to be taken into account during the PTH process in order to ensure that the MGA operations are considered. 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 :ref:`30_modelling_and_constraints:Downlink limited observations`. .. Note:: The removal/shortening of a ``DL_`` block will result in an analysis of the DV reduction impact on the segmentation. 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. this is due to the suspension of HGA downlink between CA +/- 12hours, 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 fly-by, 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 Off-loading (``J_FD_WOL``) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wheel Off-loadings 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 fly-by, 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 as follows: the WOL is scheduled adjacent to a downlink segment: every 72 hours, we schedule a WOL slot ending right at the beginning of the Malargue visibility (no need to add the slew time of 30 min at the end of the WOL because it is already taken into account in the downlink segment). Total duration 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. Optical Navigation (``OPNAV_``) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Optical Navigation windows are meant to improve the knowledge of the S/C and the given Galilean moon relative position with NAVCAM observations. There are three different optical navigation slots, each dedicated to a Galilean moon: Callisto (``OPNAV_CAL``), Europa (``OPNAV_EUR``), abd Ganymede (``OPNAV_GAN``). All opportunities for NAVCAM observations covering the needs of Flight Dynamics Operations and Navigation are provided in the form of a file containing the (24 hour long) time windows and the moon targeted for each slot. The SGS should schedule one NAVCAM observation slot per window (2 hours in total, including one hour for imaging and 2x30 min for slews). The current set of opportunities for NAVCAM images (each window is 1 day long) is available from the `JUICE Segmentation Data git repository `_. Optical Navigation windows shall not be moved. Although there is flexibility in their scheduling, they are considered to be fixed at LTP level and therefore not moveable during the detailed scenario exercise. To schedule them, SOC selects a time window within this 24 hour opportunity being the least impacting (at first order) on the science planning. Also note that this selection has an impact on the navigation and therefore on the position knowledge accuracy. In particular, it could lead to slightly more pessimistic results in terms of pointing knowledge, dispersions and stochastic delta-V [TOURN]_. 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 :ref:`30_modelling_and_constraints: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 a flyby. These blocks are scheduled at segmentation level assuming maximum allowed battery depletion reached at the end of the flyby (60% DoD). Battery recovery segments impose the modes in which each instrument can operate. These are defined in :ref:`30_modelling_and_constraints: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) 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 this rule such as UVS stellar occultations the timing of which is not known at segmentation level (This rule led to all of our Io and Europa stellar occultations being removed from the ORB17 timeline, since WG2 is only prioritized for a small fraction of each orbit around flyby periods.) 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 a 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 the 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 observation will determine or design the pointing for the duration of the observation during the PTH process. OTH Process ----------- As mentioned before, 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 by the PI teams and the SOC are the Observation Plan Files (OPL) and the Observation Definition Files (ODF). More information on these files is available on :ref:`50_planning_files:Detailed Planning Files`. The starting point is the segmentation. As a first step, it can be refined during the detailed scenario kick-off meeting. Later, the instrument teams provide a set of initial science observations backed up by a science rationale. These observations can be labeled as PRIME, RIDER or plain 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 PI 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 :ref:`50_planning_files: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. - Decide on potential downlink skipping or reduction. - Decide on operational blocks re-scheduling (within MPAD [ROSP]_ rules). - 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 SHT 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. 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 :ref:`60_procedures_and_tools:Cesium Viewer`. The sub-sections below provide an overview of each step of the OTH process. Delivery (SOC->PI) Starting Kit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The starting point will be the latest applicable Segmentation Plan (SHT) available in the SOC entity database. I.e. for PJ12 the starting segmentation is ``CREMA_5_1_150LB_23_1_SEGMENTATION_v2_B``. As part of the Starting Kit, the SOC will generate a Segmentation Plan that only covers the period of the Detailed Scenario, this plan will be made available in the Timeline Tool (i.e. ``S007_PJ12_S00P00``). For more information on the rationale of this name please refer to :ref:`50_planning_files:File versioning and deliveries`. In addition, the SOC will generate an additional Segmentation Plan, where the initial/draft NAVCAM (OPNAV only, not including EAGLE images) and RADEM observations will have already been included: ``S007_PJ12_S01P00``. 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. .. figure:: images/S007_PJ12_S01P00.png :align: center :width: 100% :alt: First version of the Observation Plan in the Timeline Tool Segmentation Plan ``S007_PJ12_S01P00``, representing the skeleton segmentation for PJ12. 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 :ref:`50_planning_files:Observation Plan File (OPL)`. In addition, a baseline PTR will also be provided including the corresponding SPICE CK kernel. See :ref:`50_planning_files:Baseline PTR`. Kick-off Meeting (OTH#1) ~~~~~~~~~~~~~~~~~~~~~~~~ The kick-off meeting will consist of a presentation of the scenario overview, processes, applicable constraints, and a possible adjustment of the segmentation plan (``S007_PJ12_S10P00``). **Input:** - SOC: Rules of the Road for the Detailed Scenario. - SOC: Starting Kit presentation. - SOC: Baseline Segmentation Plan presentation. **Output:** - SOC: updated segmentation adjustment (if needed). - PI: Understanding of the process and tests of the tools. 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 email. It can also be uploaded in the corresponding page in Confluence, i.e.: `PJ12 Instruments Contribution `_. The original format is free: PowerPoint presentation, Word, Document, etc. The document name should follow this format: ``science_plan___.pdf``, e.g.: ``science_plan_janus_pj12_initial_v01.pdf``. Several Documents can be delivered if needed. Delivery (PI->SOC) Initial Observation Plan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Science Plan document must be complemented by another delivery from the PI teams, the initial Observation Plan ``P2 (PI->SOC) OPL S02PYY``. This OPL file will contain the initial observation plan or observation schedule 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, then the PI team needs to deliver the corresponding Observation Definition File. .. Important:: The initial Observation plan is expected 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. .. Important:: See the OPL section :ref:`60_procedures_and_tools:OPL Generation with the Timeline Tool` for indications on the generation and delivery of OPLs. The detailed delivery process is described in :ref:`60_procedures_and_tools:PI->SOC Deliveries`. Science Plan Meeting (OTH#2) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Science plan meeting will be preceded by a Science Plan document delivery by the PI teams and the initial Observation Plan (OPL). During this meeting each team, or working group if preferred, will present their science rationale and the observation plan that they have prepared, each team will have a maximum of 10 minutes to present. The goal is to present the intended observations and science within the applicable segmentation with the scientific priorities derived from the segmentation including a possible segmentation adjustment. During this meeting initial discussions on the PRIME observations will take place but will not be finalised as they will continue in the follow-up meetings. An example of a decision taken during the meeting is the removal of a DL segment: the impact has to be then assessed on the overall DL budget (e.g. how is the loss absorbed by the relevant WGs, if it is acceptable, etc.) 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 PI delivery and subsequent meeting. **Input:** - PI 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) 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 PI 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 :ref:`60_procedures_and_tools: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). 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 :ref:`50_planning_files:Observation Definition File (ODF)`. The detailed delivery process is described in :ref:`60_procedures_and_tools: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 :ref:`60_procedures_and_tools:OPL Generation with the Timeline Tool` for indications on the generation and delivery of OPLs. The detailed delivery process is described in :ref:`60_procedures_and_tools:PI->SOC Deliveries`. Observation Plan Meetings (OTH#3, OTH#4) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ During these meetings, PRIME observation requests conflicts in between teams 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. During these meetings, the SHT Timeline Tool can be used in an interactive manner in order to discuss and de-conflict the Designer and Prime Observations for each instrument team. This can be done by taking advantage of the observation/segment drag and drop, start and end times modifications, the connections of observations with the Pointing Tool, and the geometry series provided in the Timeline tool to quickly assess the feasibility of updates in the observation timeline. This will be an iterative process that will take a number of cycles of the following steps: - PI delivery, - SOC integration of deliveries, - delivery and integration de-conflicting during weekly meeting, - SOC harmonisation and SOC product delivery. The same steps will apply to all the phases of the detailed scenario. The output of this meeting will be a Harmonized 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 the power 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:** - PI teams: Observation Plan (OPL) - PI teams: Power and data Envelopes at Observation level (ODF) - SOC: Harmonised Observation Plan (OPL) **Output:** - SOC and PI teams: Frozen Harmonized Observation Plan with PRIME and RIDER observations and DESIGNER roles attributed. - PI teams: Agreements on slew absorption in consecutive observations. - SOC: Generation of ITL files by the SOC based on Harmonized Observation Plan including the rider information. Delivery (SOC->PI) Harmonised Observation Plans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The next deliveries from the SOC are the harmonised observation plans ``S3 (SOC->PI) OPL S03P00``. These deliveries will include both an updated Segmentation 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 these deliveries the SOC will generate a PRIME and DESIGNER OPL that will include any additional segment or observation observed by the SOC (S/C Flip, transit, etc.) along with an individual OPL file for each PI team and a SOC OPL containing all the 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 :ref:`60_procedures_and_tools:SOC->PI Deliveries`. Delivery (SOC->PI) Observation Timeline Files ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When an Observation Plan is Harmonised and the Observation Definitions that 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 ITLs that contain an observation timeline, as their name indicates. 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 :ref:`60_procedures_and_tools: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 :ref:`20_detailed_scenario_process: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 the observation compatibilities are respected. The coordination can be supported by the SOC and it will be determined during the different PTH iterations. Please note that certain PI teams might be able to skip this process: J-MAG, 3GM, and RPWI in most cases 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 cycle of this process, which ends up in a SOC delivery to the PIs, the SOC will regenerate the OPLs that are affected by the updates in the PTR. 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 :ref:`60_procedures_and_tools: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 assessing the energy status of the scenario. The available power generated by the solar arrays depends on the expected solar array angle derived from a given PTR. In order to assess the impact on the available power, the SOC has made available the power calculation with the Attitude Generation Module (AGM) through :ref:`60_procedures_and_tools:OSVE`, the :ref:`60_procedures_and_tools:Pointing Tool`, and the :ref:`60_procedures_and_tools: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, rather than in the ITH process, in order to ensure that no surprises arise on power availability during the ITH process. However, whenever this is already feasible during the OTH process it will be carried out. 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 (``S6 (SOC->PI) PTR S01P00``). 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. This PTR will follow the syntax and rules specified in :ref:`50_planning_files:Pointing Timeline Request File (PTR)`. Pointing Harmonisation Meetings (PTH#1, PTH#2, PTH#3) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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, if needed (and surely after the last meeting), 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 can be up to the point that the original observation (as well as the preceding and following one) can still be carried-out as agreed. The SOC will then regenerate the OPLs and OTLs based on the harmonised PTR before the Pointing Harmonisation Meeting. 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:** - PI teams (DESIGNER): Updated PTR blocks that are compliant with the PRIME observations. - SOC: Harmonized PTR based on the PI inputs. **Output:** - SOC: post-meeting Harmonized 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 instrument teams will perform deliveries based on the latest version of the harmonised PTR provided by the SOC (``P8 (PI->SOC) PTR S01PYY``, ``P9 (PI->SOC) PTR P02SYY``, ``P10 (PI->SOC) PTR S03PYY``). 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 :ref:`50_planning_files:Pointing Timeline Request File (PTR)`. Guidelines and rules for the instrument teams for PTR generation are provided in :ref:`60_procedures_and_tools:PTR Generation Guidelines and Rules`. .. Important:: During the PTR design preceding a PI->SOC delivery, the DESIGNER Instrument Teams need to be coordinated and in agreement with the PRIME observation instrument teams. They are also encouraged to organise working meetings in order to consolidate the PTR blocks for the relevant observations. This can be done in coordination and with the support of the SOC. 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 power and data volume envelopes. During this process, the level of modelling detail will depend on each instrument; the bare minimum being the power and data rate or data volume envelopes for an observation. A level of modelling that allows for accurate power and data rates profiles along with other constraint checks such as inter-instrument interference or the information on how to model activation of the instrument field-of-view (FOV) for some teams could help perform preliminary coverage analysis. 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 (``S10 (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 :ref:`50_planning_files:Instrument Timeline File (ITL)`. Deliveries (PI->SOC) ITL updates -------------------------------- During the ITH process the instrument teams will perform ITL deliveries (``P11 (PI->SOC) ITL S01PYY``, ``P12 (PI->SOC) ITL S02PYY``, ``P13 (PI->SOC) ITL S03PYY``). These deliveries will contain the adequate level of instrument commanding modeling 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 :ref:`50_planning_files: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 :ref:`50_planning_files:ITLs with Observations`. Instrument Harmonisation Meetings (ITH#1, ITH#2, ITH#3) ------------------------------------------------------- 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 an harmonised timeline. **Input:** - PI teams (ALL): Updated ITL. - SOC: Harmonized ITLs based on the Instrument Teams inputs. **Output:** - SOC: post-meeting Harmonized ITL generation including generation of the corresponding data volume and power status reports. **Attendance:** SOC, PI teams. Wrap-up Meeting --------------- The Detailed Scenario process reaches its conclusion in the final Wrap-up meeting (last ITH meeting). During this meeting: - Detailed Scenario is summarized. - Scientific assessment Reports are provided by the Instrument Teams - Process, Tools, results, feedback are provided by the Instrument Teams and recorded in the corresponding Confluence Page.