1. ESAC | Chris Watson | ESA/ESAC | Page 1 TM corridors Concept and ICD CHRIS WATSON ESAC

2. ESAC | Chris Watson | ESA/ESAC | Page 2 What is a TM corridor Familiar diagram The Telemetry corridor (TMC) *is* the data resource profile for the instrument team planning at MTP/STP It is a constraint on the cumulative bulk-science write-to-SpW over the planning period, represented by a max cumulative curve and a minimum cumulative curve

3. ESAC | Chris Watson | ESA/ESAC | Page 3 Details about TM-corridors Constraint is at the point of *writing onto SpW* Decoupled from complicated factors like Downlink etc. SpW-write is under the direct control of the instrument Managing the elements downstream of this is SOC responsibility Ignores instrument-internal TM storage (where present) Instrument-internals are for the instrument-teams to manage The TM-corridor only cares when data is written to SpW Corridor is applied to bulk science production only Because different stores are used, we can’t easily make a corridor that provides flexibility across all TM production We assume that HK,LLD rates (and active periods) will be clear Principle that an instrument can plan its downlink without dependencies on what the other instruments may be doing at the same time Avoids apriori that data-return conflicts arise as a result of instrument teams planning TM generation profiles that end up incompatible with each other Makes clear who shall be penalised if over-production leads to a data-return problem

4. ESAC | Chris Watson | ESA/ESAC | Page 4 InSitu Picture Max constraint Min constraint Actual performance Curve shown quite gentle relative to corridor width Real behaviour can sometime be more severe. Consequence of the strong changes in downlink capability

5. ESAC | Chris Watson | ESA/ESAC | Page 5 Remote-Sensing Picture Cumulative curves flat outside the active periods

6. ESAC | Chris Watson | ESA/ESAC | Page 6 What the corridor is *not* supposed to represent NOT exactly the true SSMM fill-state of the store (e.g. by looking at the distance between min, and max) We will know this on ground, but we don’t use it as a planning constraint Implicit margins in the corridor to allow for downlink misbehaviour Corridor shall be a stable planning product. We don’t want that the planning constraints have to be reissued daily according to whatever weird thing the downlink has done today. NOT delineating the moments within the pass when the bulk science downlink is done The SSMM fill-behaviour on Solar Orbiter is not driven by pass-to-pass storage, but rather the very long “tides” created by comms performance variation. There is no good reason to have instruments tying their SpW write times directly to passes or dump-slots within passes, when plenty of other things will be occurring in parallel Therefore one-point-per-day and not one-point-per-hour/minute

7. ESAC | Chris Watson | ESA/ESAC | Page 7 Some design considerations The corridor approach is not hugely different to telling the instruments: How much (bulk-)downlink they are supposed to get pass-by-pass And how big their store is And then letting the instruments manage according to this So why did we do it this way? Because we believe SOC should be responsible for planning the margins against downlink misbehaviour, rather than requiring this planning of downlink margins to be done by the instrument teams We believe the cumulative representation is better at showing the longer-term needs in broad terms of “when shall the store be fulller? When shall it be more empty?” This is highly important for Solar Orbiter, where the “tidal flow” between good and bad comms largely drives the fill state of the stores. Similarly it can be used to give an easily interpretable data-return status indication, by super-imposing historic data of when SpW writing actually occurred.

8. ESAC | Chris Watson | ESA/ESAC | Page 8 ICD XML schema diagram

9. ESAC | Chris Watson | ESA/ESAC | Page 9 Documentation ICD v0_3 available on the SOC-Public. And a XML schema Please review. Idea is to take comments on the draft before going to issue 1.0 for signature. Describes two “products” TMC TMC-M“M”= “Measured”. Regular update that includes “you are here” (and historical “you were here”) actual But within one XML format (optional structure for extra part of TMC- M) Supporting documentation New SOC TN on downlink explains some of the context

10. ESAC | Chris Watson | ESA/ESAC | Page 10 Backup slides Context of TM-corridors within overall data-return planning CHRIS WATSON ESAC

11. ESAC | Chris Watson | ESA/ESAC | Page 11 Basically SOC take the TM-generation of the EID-A (or the SAP) and tries to make it work Yellow TM-gen profile is to symbolise that this is coarsely-defined single profile that is modelled. We talk about assumption of “smooth generation” Clearly SSMM stores and Downlink share are about how we divide up a fixed total. We (SOC) expect to do this empirically based on simulation. Similarly, number of passes is a constrained resource over the mission In the ideal case we would find a single store-sizing and downlink-share that works over the entire mission (principle of keep-it-simple). But we retain the possibility to modify these where possible. Trajectory also fixed in all these diagrams Background: Mission-level data-return planning Pass requests TM-generation profileSSMM store sizing Downlink share Fixed assumptionsPoints of flexibility

12. ESAC | Chris Watson | ESA/ESAC | Page 12 At LTP we have to “tune” the plan over ~six months. A large part of this tuning is adapting for the actual pass schedule The TM-generation is still yellow, meaning that we are still using a single profile. Granularity still quite coarse, although perhaps better than at mission-level The SSMM store sizing has already been set based on the mission-level. (Sometime there may be an opportunity to resize stores in the middle of the planning period – doesn’t help the early part of period) Downlink share can only move capability from one instrument to another. Any overall shortfall in the station schedule (beyond any margin assumed) can only be compensated by reducing the TM generation profile Background: LTP-level data-return planning Actual Pass schedule TM-generation profile SSMM store sizing Downlink share Fixed assumptionsPoints of flexibility

13. ESAC | Chris Watson | ESA/ESAC | Page 13 Background: MTP/STP-level By the end of the LTP process we have a firm plan for the downlink share over the upcoming period (as well as the other two already decided parameters) We use these three parameters to derive the range of TM-generation that is still acceptable. This is the first time in the process that the coarsely-grained “smooth generation” is abandoned, and a range of allowed values given instead. Actual pass schedule Acceptable range of TM-generation profiles represented as TM-corridor SSMM sizing Downlink share Fixed assumptionsPoints of flexibility

14. ESAC | Chris Watson | ESA/ESAC | Page 14 Background: In a single diagram Legible version available in new SOC downlink TN