Introduction and Timeline

Nominal Phase Segment 1 refers here to the first two orbits of the NMP, so roughly calendar year 2022, encompassing LTPs 06, 07, 08 and 09. It is the shortest period that can be planned independently of the rest of the mission, i.e. it contains a period during which the SSMM will not empty, so planning decisions made for LTP 06 will have an effect on the scope for operations in LTP 09.

The orbit during these periods is as follows (note these still assume geometrically placed Remote Sensing Windows):

Here we analyse the scope for science operations and data generation during this segment, with the goal of informing the SWT so they can decide the following:

• Exact RSW times during LTP 06 (and by extension LTP 07). Approximate (though the more precise the better) RSW times for LTP08/09 Deadline end July for pre-LTP TN. Or if significant divergence from PS/SOC assumptions, end May for ground station negotiation.
• Requests for offpoints / rolls campaigns for out of RSW calibrations during LTP 06. Deadline end July for pre-LTP TN.
• Requests for high priority science opportunities outside of RSWs, so we can flag them to flight dynamics. Deadline end July for pre-LTP TN.
• Science goals for at least the LTP06 RSWs. Better if it's for all of 2022 to inform... Deadline early September for SOWG prep.
• Telemetry allocation / generation focus for all of 2022 (see below for details). Deadline early September for SOWG prep.

Of course, the earlier the information comes, the more time we can spend planning and the better-optimised the end result will be.

The Link Between Remote Sensing Window Timing and the Scope for Data Generation

The data that can be generated during a particular period of scientific interest (e.g. a remote sensing window) is the sum of the data that can be downlinked during that window and the data that can be stored in the SSMM for later downlink. The latter is itself a function of how much data is already in the SSMM at the start of the period and crucially, how much data is expected to be stored in the SSMM during the next period of scientific interest, and how much data can be downlinked in between the two periods. Thus, the ideal case would be two intervals that are well-separated in time and take place during periods of good downlink. The worst case would be two concatenated intervals that take place during a period of bad downlink. Assuming the SSMM is not emptied at any point, any data that are generated in between the intervals (e.g. from a synoptic programme) are data that cannot be generated during the intervals of scientific interest.

Because the downlink rate is highly variable, the first step in assessing the scope an LTP period has for data generation, and the split between RSW and synoptic generation (equally applicable for high rate vs normal rate intervals for in situ instruments) is thus fixing the location of the remote sensing windows.

Proposed Remote Sensing Window Locations

During these early, low-inclination, orbits of the nominal mission phase, the default geometric placement of remote sensing windows doesn't make scientific sense. Instead we believe a reasonable trade-off between Sun-spacecraft distance and downlink performance, taking into account solar conjunctions, is to concatenate the three remote sensing windows from each orbit, so we have assumed two sets of 30 days covering these intervals:

• 07 March 2022 (0.5 AU) - 06 April 2022 (0.39 AU); perihelion 26 March (0.32 AU); average distance 0.375 AU. In this case we would set the start of LTP07 to be immediately after RSW3, so all RSWs fall in the same LTP.
• 08 October 2022 (0.31 AU) - 07 November 2022 (0.57 AU); perihelion 12 October 0.29 AU; average distance 0.39 AU ← This is limited by the conjunction, so it's likely unfeasible to move any earlier. TBC with MOC

In terms of downlink, this means that the first ~20 days of the first set of RSWs have excellent downlink and it drops off during the last ~10 days, and for the second set of RSWs the downlink inreases to a maximum during the first ~20 days and is excellent for the last ~10:

By delaying the first set of remote sensing windows, it is possible to position their start so that they lie symmetrically relative to perihelion, but this comes with a downlink cost (see available trade-offs, below). In this proposal, the second set of remote sensing windows already start ~5 days after the end of the conjunction, this might be too close for comfort (MOC will need time with the spacecraft to check everything out post-conjunction, deal with any FDIR incidents etc., instruments might want to see their housekeeping data before doing anything complex) so we don't think it's possible to improve the geometry any further, indeed we may have to delay, but this has benefits for downlink, both during the windows and for data taken in the inter-window period.

Data Generation Scenario

https://solarorbiter.esac.esa.int/soopkitchen/#/planning/plan/Nominal%20Segment%201%20Initial%20Assessment

No assumptions have been made about the science content of the plan, nor of the exact downlink share between instruments. In situ data generation is modelled based on default ~EID-A and "high rate" observation definitions as used during the cruise phase. Remote sensing data generation is based on generic observation definitions without making any assumptions about e.g. whether data comes from EUI HRI or FSI. No changes to SSMM store sizes have been made. Daily passes on either MLG or CEB are assumed throughout (this likely overestimates downlink - some fraction of the time we will get NNO, which is less performant).

The plan was built following these steps:

1. Include MAG, RPW, SWA observations at ~EIDA rates during periods of "bad" downlink, high rates during periods of "good" downlink. EPD in close mode throughout.
2. Include remote sensing synoptic programme outside of RSWs that generates data at 0.5 EID-A rates (e.g. 10kbps for EUI)
3. Start with 2xEID-A remote sensing generation in each RSW and see what happens, fill them up as much as possible.

EPD close mode is effectively their EID-A rate. High rate is taken to be 100% BURST64 mode for MAG (4x EID-A) HIGH1 configuration for RPW (~4.75x EIDA) and for SWA a combination of sensor settings that gives ~5x EID-A, although of course this can be changed during subsequent planning.

For EUI, PHI and STIX the following behaviour was assumed:

• EUI: Flushes of synoptic data every 2 weeks. Daily flushes of all data during RSWs (i.e. EUI doesn't keep data internally for an extended period)
• PHI: Flushes of synoptic data every 2 weeks. Daily flushes of the equivalent volume to synoptic data during RSWs. The rest of the data taken during RSWs is flushed evenly, every 2 weeks, throughout the inter-window period. This has consequences.
• STIX: Equal flushes every 28 days, regardless of RSWs

The frequency of flushes is somewhat arbitrary. More frequent, smaller flushes would be better, but including these would have made building the plan more time consuming. Less frequent, larger flushes may not work when the SSMM is close to full.

Results

In summary, with the assumed station coverage, we should be able to support:

• 0.5 x EID-A RS synoptics throughout
• IS high rate >50% of the time, although a lot of this is at high SC-Sun distances (see Data Accounting, below). EID-A the rest of the time.
  • High rate: 2021-12-27 - 2022-04-18, 2022-10-03 - 2022-12-26
• Selective downlink throughout for RPW & EPD
• 4 - 5 x EID-A in RSW1 for EUI, Metis, SoloHI & SPICE. 3x for PHI (see Special Considerations for PHI, below)
• 3 x EID-A for EUI, Metis, PHI, SoloHI & SPICE in RSW2 and RSW3
• 2 x EID-A for EUI, Metis, SoloHI & SPICE in RSW 4 and RSW 5
• 3 x EID-A for EUI, Metis, SoloHI & SPICE in RSW 6
• PHI is essentially unconstrained for RSWs 4-6, but assumed the same as the others for accounting purposes (see Special Considerations for PHI, below)

This results in the following SSMM fill profile:

Note we still need to tweak STIX generation / downlink share but this won't make a significant difference to the overall picture. This gives us a peak SSMM fill state of around 75%. We don't want to go further at this point given the uncertainty in pass coverage.

This implies the following data latencies (note for PHI it's time between flush & downlink, not generation & downlink):

In situ latencies are higher because of the high rate observations extending a couple of weeks after the end of the RSWs into the bad downlink period.

Special Considerations for PHI

To take into account the required processing time for PHI we have assumed the following:

• Data with equivalent volume to synoptics (0.5xEID-A) are flushed to the SSMM during the remote sensing windows.
• All other data are processed and flushed smoothly during the period between the end of RSW 3 and the start of RSW 4

This means that while other RS instruments can take advantage of the good downlink during the RSWs themselves, PHI cannot and their RSW data must be downlinked slowly throughout the inter-window period. If all data taken during RSWs 1-3 must be flushed to the SSMM before the start of RSW4, this places a limit on what PHI can generate during RSWs 1-3. If that constraint can be relaxed, of course they will be able to generate more and hold it internally until after RSW 6.

Under the assumption that all RSW 1-3 data are flushed before the start of RSW 4, this limits PHI's generation to 3x EID-A during RSWs 1-3 (less than the other RS instruments), but even so this means they require 40% of the downlink share during the inter-window period in order not to overfill their SSMM store, and we are not able to assign them more downlink without negatively affecting the data generation of other instruments. Conversely, during RSWs 4-6, PHI are not limited by the lower telemetry rates and instead can take advantage of maximum downlink after RSW 6 while the spacecraft is close to the Earth, and are effectively unconstrained by telemetry.

This pattern will hold, to a greater or lesser extent, throughout the mission. Unless PHI wish to hold data internally for ~1 year, they will be more constrained than the other remote sensing instruments just before and during orbit legs where the spacecraft is outbound from Earth, but less constrained just before and during orbit legs where the spacecraft is inbound.

Data Accounting

With the strawman plan assumed above, all instruments are able to generate more data than the baseline. In total, the in situ payload can generate 215.5 GiBytes over the two orbits. The EID-A volume per orbit for in situ is 42 GiBytes. The remote sensing payload are generating 298 GiBytes over the two orbits compared to an EID-A per orbit volume of of 27 GiBytes.

However, these numbers don't consider when the data are generated. Because of the assumptions made while building the plan, a significant proportion of the in situ data generation takes place while the spacecraft is close to Earth (and thus far from the Sun) where downlink is essentially unconstrained and the data have less scientific value. If the RS generation was increased while downlink was good (through a larger synoptic programme, for example), data generation would further be skewed towards the RS payload. The data generation as a function of heliocentric distance is in the table below.

Scope for More Data Generation

The above plan essentially fills the downlink, apart from during the very good periods when the spacecraft is close to the Earth:

So the only scope for additional activities is during these periods. Of course, PHI could generate more in the first set of remote sensing windows if they were willing to keep those data internally until after the second set of remote sensing windows.

Available Trade-offs

• Move first three RSWs by 5 days so they're centred on the perihelion.
  • Pro: Better range of Sun/sc distance
  • Con: Lose Sun-Earth line coverage
  • Con: Less scope for data generation - 11 GiBytes less downlink during the RSWs and we can't really carry that extra load in the SSMM, so it would mean downgrading the synoptics by the same amount of data (synoptics between windows are about 80 GiBytes).
• More data for in situ so they can be in high rates whenever we're within 0.5 AU (not true currently). This would require about 8 GiBytes, so 10% of the existing inter-window synoptic programme, maybe a bit less.
• Trade-off data between inter-window synoptics and RSWs. In practice this would mean trading off between RSW 3, the synoptics and RSW 4. Currently:
  • Inter window synoptics: 80 GiBytes
  • RSWs 1-3: 94 GiBytes
  • RSWs 4-6: 69 GiBytes
• Move RSWs 4-6 later (note we're already close to the limit after the conjunction so this might have to happen anyway):
  • Pro: More data
  • Con: Already at 0.6 AU at the end of the current windows
  • Con: Perihelion is already on day 4/5 of the current 30

Possible Changes to the Pass Requests for 2022 H1 and/or 2022 H2:

• We could request reduced hours per day in January/February when we are not filling the downlink and ask for more in April/May. We could also do the same in H2, i.e. fewer hours in November/December and more in the days before the conjunction. Either would relieve pressure on the SSMM and allow us to do more in RSWs 4-6 or during the inter-window period.