ESOC | Chris Watson | ESA/ESOC | Page 1 SOC-Instrument Team interfaces CHRIS WATSON ESAC

ESOC | Chris Watson | ESA/ESOC | Page 2 Overview Present the status and planned schedule for the interfaces needed Low-latency outputs Mission planning Science Archive Inputs Present concepts for “tricky” mission-planning things that are coming Anything else…

ESOC | Chris Watson | ESA/ESOC | Page 3 SOC-Instrument Team interfaces ICDStatusDraft expectedAgreement expected Low-latency outputs CDFMetadata draft discussed in MADWG Around SWT-16 Feb 2015 SOWG-7 July 2015 FITS“““ Mission- planning IOR Instrument commanding Draft issued (without VSTP part) Done End Sept 2014 No SOWG comments received. Some comments from SOC-review April 2014 (without VSTP part) E-FECS planning skeleton -Feb 2015“ TM corridors TM allocation -Feb 2015“ ArchiveData Producer to Archive ICD Pre-draft in MADAWG Initial draft available Comments expected on -Data sets -Data exchange End Feb

ESOC | Chris Watson | ESA/ESOC | Page 4 Planning interfaces

ESOC | Chris Watson | ESA/ESOC | Page 5 E-FECS = planning skeleton Planning skeleton Goes to instrument teams prior to MTP In principal contains everything the instrument teams need to know to do their own planning Contains Everything that is in the MOC FECS. Windows for GAMs Trajectory manoeuvres Rolls HGA/MGA/SA movements Wheel offloadings Conjunctions RSWs Plus scientific windows Precursor times Explicit attitude disturbance windows EMC windows

ESOC | Chris Watson | ESA/ESOC | Page 6 E-FECS EMC-quiet handling EID-A requirement is 70% EMC quiet over an orbit Quiet period has to be at least one hour long to count We don’t believe it’s sensible to apriori *schedule/plan* the quiet periods fully up to the level of 70% (especially not 70% through RSWs) Potentially imposes severe restrictions on instruments E.g. EUI filter wheel? E.g. STIX attenuator …probably more, some that we may find only in flight…. Of course, the better the instruments can control their EMC “noisiness” via design, the easier this will be for everyone. Instead we have mixed approach Enforce planned restrictions in certain periods (but not 70%) Rely on some statistical achievement of quiet also outside of the pre- planned windows Make the scheme flexible, so it can be tuned Track how it works. If 70% not achieved on first orbit, SWT potentially has to extend the periods over which the planning restrictions apply (maybe with impact on the noisy instruments)

ESOC | Chris Watson | ESA/ESOC | Page 7 E-FECS EMC-quiet handling Black = Planning feature Blue = Plausible way the feature could be used in practise (but details up to the SWT) List of noisy operations will need to be established Likely that the list is a “living document” Mandatory quiet windows Pre-determined times (chosen to be outside of SC planned noisy events) where instruments are not allowed to execute an operation known to be noisy ~1 hour per day in RSWs to ensure scheduled bursts can be done inside a quiet period. Longer outside of RSWs. Preferred noisy windows Pre-determined times where instruments shall put noisy operations that are “easily movable”, e.g. noisy ops that are not tightly integrated into an observing plan (these will be a subset of the “noisy list”) Example: door/opening closing? Often placed on top of SC operations that are known to be noisy

ESOC | Chris Watson | ESA/ESOC | Page 8 Planning interfaces

ESOC | Chris Watson | ESA/ESOC | Page 9 Data allocations Super-optimistic interpretation of allocation - “I can generate my data allocation whenever I like in the orbit” Super-optimistic interpretation is not true. Simply cannot work with this level of flexibility 100% IS RS Smooth generation – what is modelled Extreme “early” generation Extreme “late” generation Cumulative TM generation over an orbit

ESOC | Chris Watson | ESA/ESOC | Page 10 Data allocations We know some instruments want to have a level of flexibility on when they generate their TM E.g. EPD, reactivity to solar activity E.g. SOLO-HI, Stereo experience We know that RSWs may not all be equal E.g. Planning simulation yesterday where we were assuming a particular perihelion got more than 33% of the allocation We think that instruments will not want manage their store at low-level, including Knowledge of how the backlog accumulates during poor comms periods Operational margins e.g. station outage …would limit SOC’s ability to centrally resolve problems Our proposed solution => “TM generation corridors”

ESOC | Chris Watson | ESA/ESOC | Page 11 Data allocations We know some instruments want to have a level of flexibility on when they generate their TM E.g. EPD, reactivity to solar activity E.g. SOLO-HI, Stereo experience We know that RSWs may not all be equal E.g. Planning simulation yesterday where we were assuming a particular perihelion got more than 33% of the allocation We think that instruments will not want manage their store at low-level, including Knowledge of how the backlog accumulates during poor comms periods Operational margins e.g. station outage …would limit SOC’s ability to centrally resolve problems Our proposed solution => “TM generation corridors”

ESOC | Chris Watson | ESA/ESOC | Page 12 TM generation corridors Two curves representing cumulative TM generation (i.e. when written to SpW) One is a maximum, one is a minimum Will be over the calendar six-month planning period (i.e. not the orbit). This so we are certain what the station provision is. Principally relates to each instrument’s bulk-science. We will have to control HK, LLD as well, but will not be included in the bulk corridor. Could be done by other means. Two stage process to create We (SOC) run our modelling based on some assumed generation profile Currently EID-A Could be in the SAP This establishes how the baseline of how the downlink is allocated over time to the instruments Using this SOC generates the corridors that are sent to the instrument teams.

ESOC | Chris Watson | ESA/ESOC | Page 13 TM generation corridors Planning stages Prior to MTP: corridors sent to instrument teams During execution: regularly updated corridors are distributed with the actual cumulative generation superimposed. Reaction If an instrument is heading to towards the edge of a corridor, we expect them to take steps to steer back into the allowed region Reduce/increase cadence, compression, burst modes, response to flags Done via STP Once the corridor is left, data return is not guaranteed and data can be lost Data loss affects only the misbehaving instrument, but can affect any data period still onboard (not limited to the period outside the corridor)

ESOC | Chris Watson | ESA/ESOC | Page 14 TM generation corridors Practically-speaking the RS corridors will be more towards planning than reaction, because of the limited opportunity to correct via STP We think we will have to close the flexibility to zero sometimes At the end of each planning period. We don’t want to When we the baseline TM profile predicts that the store will become empty Instruments that over-produce wrt the end of period target, will have this carried over into the starting “actual” of the next period No automatic “forgiveness” for TM overproduction RS IS

ESOC | Chris Watson | ESA/ESOC | Page 15 AOI (Any Other Interfaces) Orbit Either CCSDS OEM or SPICE I don’t expect any problems here Power allocation TBC If operationally everybody stays within their EID-A av. allocation, we should not need this If we have to control power consumption via mission-planning it will make RSWs (especially) complicated. …to be continued…. Anything we have forgotten?.....