IORs CHRIS WATSON ESAC Chris Watson ESAESAC Page

IORs CHRIS WATSON ESAC | Chris Watson | ESA/ESAC | Page 1

Routine commanding basics n All routine instrument commanding is from the spacecraft MTL • “execution. Time” in the IOR is the time that the sequence starts from • Upload into the MTL is transparent to the instrument teams n MTL commanding is “blind” to the result of sent commands • Command failures do not stop subsequent commands (*) • MTL does not check TM(1, 1), TM(1, 7) nor command end-effects • Ground will notice TC failures at the next pass and begin an investigation • Unless there already super-clear instructions in the UM what to do • (*) exception is if a defined onboard-FDIR response is triggered that includes stopping the MTL (or instrument part thereof). ESAC | Chris Watson | ESA/ESAC | Page 2

Routine procedure restrictions n Because routine commanding has to run like a “batch job” from the MTL • No branching • No loops • Other constraints of SOL-ESC-TN-10034 ESAC | Chris Watson | ESA/ESAC | Page 3

Link between Procedures and Sequences Procedure name Sequence name n Reference is the FOP (Flight Operations Plan) issued by MOC FPs declared n Example shown (from a different mission) n Precise presentation format may vary between missions FPs linked to command parameters ESAC | Chris Watson | ESA/ESAC | Page 4

Timings The sequence call in the IOR allows to place this structure in the MTL starting at some specific UTC execution. Time of sequence call in IOR The sequence is a predefined structure of commanding (based on a procedure – essentially it is only the commanding parts of a proc) Ends up in MTL Delta time of first TC (normally zero) Contained in IOR First TC of sequence Delta time of second TC Time Second TC of sequence Remember delta times are in whole seconds – IOR ICD Only the first delta time is allowed to be zero Delta time of third TC Third TC of sequence ESAC | Chris Watson | ESA/ESAC | Page 5

Parameters Formal parameters of the sequence are the tunable elements which “fill in” the few command fields fixed neither at command- nor sequence-level sequence call in IOR Formal parameter 1 Formal parameter 2 Command fields Not fixed Fixed in Fixed by Exposed sequence command definition as FP First TC of sequence Contained in IOR Second TC of sequence Third TC of sequence ESAC | Chris Watson | ESA/ESAC | Page 6

Building your IORs needs n Awareness of your science • Meet the goals of SAP/LTP planning • Understand the geometry n Understanding of your instrument • File-handling • Sub-fielding • Calibration needs • etc. n Respect the restrictions imposed by the E-FECS and TMC. E. g. • Respect safety constraints • Avoid integrating images during disturbances • Instrument-specific sensitivities to roll, solar array angle etc. • Control your data production staying within the TM corridor, and looking ahead within the ~six month period to the future “bends in the road” ESAC | Chris Watson | ESA/ESAC | Page 7

IOR checking at SOC n n n Known safety constraints. E. g. • Allowed mode transitions • Thrusters / HV / doors etc. • METIS and POINT_ events • MTL loading, number of commands Compliance with • EMC windows • Power resource (TBC) • No RS commanding outside of RSWs or additional windows agreed at LTP Additional checks (tricky / instrument-specific) • Science intent • • Data Resource • • If it is obvious that the IOR is not doing the science that was agreed at LTP For those instruments that have (largely) deterministic TM production, if we can see that an IOR is going to go outside the TMC we will reject it. No image acquisitions during disturbances • Certain instruments might occasionally deliberately acquire here IORs that do not pass these checks will be rejected ESAC | Chris Watson | ESA/ESAC | Page 8

Checks at MOC n Similar checks at MOC on SOC produced PORs • n Rejection comes to SOC initially • n Focused on safety and resources But if the underlying problem arises from the IOR Rejections at STP are bad • Not much time to fix • Unacceptable to ask other instruments to change at this point • This is the reason to: • Fix major decisions in advance • Establish E-FECS, TMC etc. • Do the MTP cycle ESAC | Chris Watson | ESA/ESAC | Page 9

Differences between IORs and PORs IORs -> SOC subsequently PORs->MOC n PORs delivered as a checked, complete and mutually compatible set across all instruments n Very limited XML format changes in the POR n MTL load levelling as in IOR ICD section 7 ESAC | Chris Watson | ESA/ESAC | Page 10

POLL of Instrument Teams n How will you develop your planning software? • Adapted from legacy code/systems from previous missions • New development, but path clear • …don’t know ESAC | Chris Watson | ESA/ESAC | Page 11

IOR test n IS E 2 E test is the first “big system test” actively using IORs • However this is a complex scenario test which relies on the underlying interfaces already working • Therefore we have to start working towards implementing IORs already n We propose first IOR example files from each instrument team in early 2017 • Should cover a subset of the 2022 period which was already LTP planned (in a planning exercise) and for which E-FECS and TMCs exist • It is understood that sequence names/formal parameters may not match FOP exactly. n Further IOR testing leading up to E 2 E tests to be detailed later. ESAC | Chris Watson | ESA/ESAC | Page 12