MOC-SOC ICD - Solar Orbiter PLID Annex B - 1

Prepared by Sylvain Lodiot Reference SO-ESC-IF-05012 Issue 2 Revision 0 Date of Issue 16/05/2020 Status Issued Document Type

ESA UNCLASSIFIED - For Official Use

esoc European Space Operations Centre

Robert-Bosch-Strasse 5 D-64293 Darmstadt

Germany T +49 (0)6151 900

F +49 (0)6151 90495 www.esa.int

MOC-SOC ICD - Solar Orbiter PLID Annex B

/38 MOC-SOC ICD - Solar Orbiter PLID Annex B Date 16/05/2020 Issue 2 Rev 0


Prepared by: Solar Orbiter Flight Control Team Approved by: ____________________ S.Lodiot (OPS-OPS)

Solar Orbiter Spacecraft Operations Manager Approved by: ____________________ A. Accomazzo (OPS-OP) Solar Orbiter Ground Segment Manager Approved by: ____________________ L. Sanchez (SRE-OD) Solar Orbiter Science Ground Segment Development Manager Approved by: ____________________ D.Werner (OPS-GDS)

Operations Data Systems Manager



Reason for change Issue Revision Date First Draft for GSDR 0 1 07-10-2013 First Issue (incorporates actions from GSDR) and addresses a number of issues discussed since then:

• Refinement of the FECS events • Defines the contents for all other

interfaces including SAP, POR and Pass Change Requests

• Defines the usage of Z records

1 0 02-12-2013

Review following MOC-SOC coordination meeting of 30 Sept 2015, MoM SOL-ESC-MN-05012.

1 1 09-10-2015

Review following MOC-SOC coordination meeting of Dec 2015 and Feb 2016, MoM SOL-ESC-MN-05013, SOL-ESC-MN-05014.

1 1 26-02-2016

Review following MOC-SOC coordination meetings with MoM SOL-ESC-MN-05016, SOL-ESC-MN-05017, SOL-ESC-MN-05018.

1 1 11-07-2016

Update the consolidated POR Metadata interface

1 1 16-09-2016

Update the FECS definition for VSTP_UPDATE

1 2 05-10-2016

Inserted new FECS events (STP_BOUND and MTP_BOUND), included the POR file naming convention (previously in the PLID). Modified FECS example and schema.

1 2 31-03-2017

Added the PDOR file definition and updated the naming convention

1 3 07-04-2017

Brought in line with latest MPC (1.6) 1 3 07-06-2017 Correction of inconsistencies with PLID 1 3 04-09-2017 Corrections and clarifications implemented as requested by Email from CW

1 4 18-12-2017

Closure of GSIR action [PLID B (2)]: Inconsistent use of SGS and SOC

1 4 19-12-2017

Change to FECS dump events 1 4 25-01-2018



Clarifications as result from Email CW 03/04/2018 19:56

1 5 04-04-2018

Updates to file names and latest clarifications

1 6 20-12-2019

Updates following final agreements 2 0 16-05-2020



Issue 2 Revision 0 Reason for change Date Pages Paragraph(s) POR file naming convention update 05/06/2020 30 9.3 PORG vvvvv usage clarified 05/06/2020 31 10.2 Added note on VSTP file name which may be revised based on MPC discussions

05/06/2020 34 13.3

Added example for CRR 05/06/2020 18 3.3 Distribution list simplified 05/06/2020 STP cycle number does not wrap around

16/06/2020 30 9.3

Update to PORG naming convention, swap of “D” and “E” and where doors are commanded from

16/06/2020 31 10.2

Updated VDOR naming convention as per agreements

16/06/2020 13.3 34

Updated window for S-13 entries 16/06/2020 15.1.1 37 Updated section with door queuing 16/06/2020 15.1.3 38 Removed one “_” for CRR 16/06/2020 2.1 17 Issue 1 Revision 1 Reason for change Date Pages

Paragraph(s) GSDR RID #22 02-12-2013 7 2.2 Expanded document to cover all MOC-SOC interfaces. See Change Log above.

05-06-2014 All

Updated Distribution List and Table of Contents

05-06-2014 4 - 5

Added comments from C.Watson/L.Sanchez (email LS 02-06-2014)

05-06-2014 8 - 9 3.2

Added Comments from Internal Review I.Tanco/D.Lakey (emails 02-06-2014)

05-06-2014 Several 3.2, 4.2, 4.2.1, 4.2.2, 4.2.3



Split ROLL into COM_ROLL, REF_ROLL and CAL_ROLL and split ANT_PT in HGA_PT and MGA_PT as per ACTION MSM-05 of SOL-ESC-MN-05012

09-10-2015 8 3.2

Changed the Hibernation period in two instant events of start and end

02-11-2015 9 3.2

Updated the FECS example, following the changes made to the present document.

5-11-2015 16 6

Update to consistently use TX_ON 12-01-2016 8 3.2 Update the format of the FECS file and the attributes of the events

07-03-2016 8 3.1

Removed parameter of CAL_ROLL event - ACTION #5 of SOL-ESC-MN-05013, clarified that CAL_ROLL are a multiple of 360 deg rotation - ACTION #06-06 of SOL-ESC-MN-05016,

07-03-2016 8 3.2

Added explanatory notes to the FECS Events - ACTION#06-05 of SOL-ESC-MN-05016

07-03-2016 11 3.2

Modified the use of the Z-record. Added the information about the iVSTP window - ACTION#06-02 of SOL-ESC-MN-05016

07-03-2016 14 4.2.3

Added ENG_WIN event as per ACTION #3 of SOL-ESC-MN-05013

07-03-2016 10 3.2

Added XML Schema - ACTION #6 of SOL-ESC-MN-05013

07-03-2016 17 Appendix-B

Clarified the timing of RSW, relative to the End of Pass - ACTION #3 of SOL-ESC-MN-05014

07-03-2016 11 3.2

Specified a naming convention for the FECS file- ACTION#06-05 of SOL-ESC-MN-05016

07-03-2016 11 3.4

Added MAINT window – ACTION#07-02

23/03/2016 11 3.2

Clarified that WOL FECS event includes slews.

11-07-2016 11 3.2

Clarified that MAG_CAL_ROLL FECS event includes slews to sun disk centre.

11-07-2016 10 3.2

Added POR iVSTP metadata section 11-07-2016 17 4.2.4 Revised the FECS attribute names as lowercase

11-07-2016 9-10-11 3.2



Renamed CAL_ROLL in MAG_CAL_ROLL

11-07-2016 9-10-11 3.2

Added a note about HK_DUMP calculation done between actual time of dumps

11-07-2016 11 3.2

Updated XML schema 11-07-2016 23-26 Appendix B Clarified that FECS changes during MTP cycle happen only in case of changes requested by SOC

11-07-2016 12 3.4

Added FECS event STP_BOUND, such that MOC has control over the STP boundary definition, to be respected by the Instrument teams.

11-07-2016 11 3.2

Clarified that SA_ROT and MGA_PT do not include tranquilisation period.

11-07-2016 10 3.2

Updated the POR Metadata interface, including the information implemented on Mission Planning System SPR [EGOSMPS] BepiMPS#619

16-09-2016 17-18 4.2.4

Update the FECS definition for VSTP_UPDATE to be a period of time and not anymore a instant event. Closes ACTION#11-01 of SOL-ESC-MN-05022. The event takes into account the worst-case limb-to-limb slew time.

05-10-2016 10-11 3.2

Added MTP_BOUND event and modified STP_BOUND, adding parameters. 020216_16_MOC

31-03-2017 11 3.2

Modified the Z record to include only power and data. Deleted HK_data and kept Science_data. Action 130217_01_SL of SOL-ESC-MN-05025

31-03-2017 16-17 4.3.2

Added POR file naming convention 31-03-2017 14-15 4.1 Modified FECS example and schema. 31-03-2017 24-29 Appendix A, B

Issue 1 Revision 3 Reason for change Date Pages

Paragraph(s) Added new reference documents 07-04-2017 11 1.1 Updated POR naming convention 07-04-2017 25 4.4 Added new section for the PDOR 07-04-2017 26 5



Updated POR contents for iVSTP metadata

07-04-2017 24 4.2.4

Added Product Plan Boundary Skeleton 07-06-2017 12 3 Removed elements which will come in PTSL from FECS

07-06-2017 14 4.2

Removed reference to periodicity as this is covered by the MPC

07-06-2017 Whole document Whole document

Complete restructuring. Files sorted alphabetically.

18-08-2017 Whole document Whole document

Added MPOR 18-08-2017 5 Added MIB 18-08-2017 6 Added CRR 18-08-2017 3 Add both types of PDOR provision to Figure 2

04-09-2017 13 2

Add extra underscore to filenames with three letter acronym

04-09-2017 14,19,27 2.1 9.3

Z-Record description changed to DR and PW and corrected/augmented example

04-09-2017 25 9.2.1


Paragraph(s) Clarify calculation and meaning of SCI_DUMP and HK_DUMP for FECS

18-12-2017 17 4.2

Clarify that bit-rates refer to frame-level rates

18-12-2017 17 4.2

Update RSW start and endtimes from “always” to “default”

18-12-2017 18 4.2

Clarified that whitelist and its implementation are to be defined

18-12-2017 23 8.2

Changed “return to default state” to “return to state consistent with default state”

18-12-2017 25 9.2

Changed “Science Data” to “Aggregated Instrument Data”

18-12-2017 26 9.2.1

Included reference to MTP 18-12-2017 27 9.2.2 Added explicitly that zip file extension is “.SOL”

18-12-2017 30 10.2

Removed reference to calibration curve 18-12-2017 38 15 Added section for heat shield door operations covered by POR

18-12-2017 39 15.1.3

Closure of GSIR action [PLID B (2)]: Inconsistent use of SGS and SOC

19-12-2017 14,15 2




Paragraph(s) Added note stating that VSTP/Contingency PORGs are not used in current MPC

30 10.2

Added statement for DEU Operations clarifying they should come in a separate POR using the OMM file naming convention for DEU

37 15.1.3

Introduced distinction between PDOR and VDOR

30.05.2018 23,32 8; 13

Changed type in attribute power for FECS and removed attribute id for pass

19.11.2018 18 4.2

Changed attribute Power in FECS to better reflect the actual power budget available for payloads

07.12.2018 18 4.2

Updates to POR filename convention to reflect version number of input IOR and change of file number from hex to decimal.

04.03.2019 30 9.3

Update of FECS filename example and stated explicitly the format of GenTime

01.07.2019 20 4.3

Updated PORG naming convention to be compatible with GFTS (5 digits version counter and ending with .zip)

15.08.2019 30 10

Added explicit statement for grouped PDOR/MDORs in CRFGs

15.08.2019 21, 24 5, 8

Updated FECS Example 15.08.2019 34 Appendix A Removed outdated Appendix B ( FECS Template )

15.08.2019 Appendix B

Changed MIB naming convention and clarified that it is a zip file

16.08.2019 22 6


Paragraph(s) Corrected POR,PORG,VDOR,MDOR,PDOR naming convention to be in-line with the PLID

16.12.2019 21,24,29,30,33 5.3, 8.3, 9.3, 10.2, 13.3



Updated figure 2 to replace PDOR by VDOR in the case of VST planning, to be in line with section 13

17.12.2019 15 Figure 2

Updated Figure 3 and example for POR metadata in case of i-VSTP planning

20.12.2019 20,21 9.2.2, Figure 3



DISTRIBUTION LIST

Recipient Organisation L. Sanchez SCI-SDS C. Watson SCI-SDS SolO FCT

@ [email protected] OPS-OPS SolO DSMs [email protected] [email protected]



Table of contents:

1 INTRODUCTION ...................................................................................... 14 1.1 Reference Documents ..................................................................................................... 15 2 OVERVIEW .............................................................................................. 16 2.1 Summary of files ............................................................................................................. 17 3 CRR - COMMAND REQUEST RESPONSE FILE ......................................... 18 3.1 Format ............................................................................................................................. 18 3.2 Content ............................................................................................................................ 18 3.3 Naming Convention ........................................................................................................ 18 4 FECS - FLIGHT EVENT AND COMMUNICATIONS SKELETON ................. 19 4.1 Format ............................................................................................................................. 19 4.2 Contents .......................................................................................................................... 19 4.3 Naming Convention ........................................................................................................ 21 5 MDOR - MEMORY DIRECT OPERATIONS REQUEST ............................... 22 5.1 Format ............................................................................................................................ 22 5.2 Content ........................................................................................................................... 22 5.3 Naming Convention ....................................................................................................... 22 6 MIB – MISSION INFORMATION BASE .................................................... 23 6.1 Format .............................................................................................................................23 6.2 Contents ..........................................................................................................................23 6.3 Naming Convention ........................................................................................................23 7 PCR - PASS CHANGE REQUESTS ............................................................. 24 7.1 Format ............................................................................................................................ 24 7.2 Contents ......................................................................................................................... 24 7.3 Naming Convention ....................................................................................................... 24 8 PDOR - PAYLOAD DIRECT OPERATIONS REQUEST ............................... 25 8.1 Format ............................................................................................................................. 25 8.2 Contents .......................................................................................................................... 25 8.3 Naming Convention ........................................................................................................ 25 9 POR - PAYLOAD OPERATIONS REQUESTS ............................................. 26 9.1 Format ............................................................................................................................ 26 9.2 Contents ......................................................................................................................... 26 9.2.1 Z records ........................................................................................................................ 27 9.2.2 POR iVSTP metadata ................................................................................................... 28 9.3 Naming Convention ....................................................................................................... 30 10 PORG - PAYLOAD OPERATIONS REQUESTS GROUP .............................. 31 10.1 Format ............................................................................................................................. 31 10.2 Naming Convention ........................................................................................................ 31 11 PRE LTP TN – PRE LONG TERM PLANNING CYCLE TECHNICAL NOTE . 32 11.1 Format .............................................................................................................................32 11.2 Contents ..........................................................................................................................32 11.3 Naming Convention ........................................................................................................32 12 UEVT - USER EVENT FILE ....................................................................... 33 12.1 Format ............................................................................................................................. 33 12.2 Contents .......................................................................................................................... 33



12.3 Naming Convention ........................................................................................................ 33 13 VDOR – I-VSTP DIRECT OPERATIONS REQUEST ................................... 34 13.1 Format ............................................................................................................................ 34 13.2 Contents ......................................................................................................................... 34 13.3 Naming Convention ....................................................................................................... 34 14 APPENDIX A– FECS EXAMPLE ............................................................... 35 15 APPENDIX D– SPECIAL POR CASES ....................................................... 37 15.1.1SSMM POR .................................................................................................................... 37 15.1.2 SOLOHi POR ............................................................................................................. 37 15.1.3 Heat Shield Door Operations ................................................................................... 38



1 INTRODUCTION

This document constitutes the Annex B to the PLID [RD1] and describes the products generated by the Mission Planning System and delivered to the Science Operations Center (SOC) and vice-versa. It also describes the products sent by the PIs to MOC and the response files back to the PIs, since these files are routed via SOC. In particular, this document defines the configuration and contents of these interfaces. The formats and other technical properties of the interface are defined in the PF ICD [RD3]. Please refer to the Mission Planning Concept [RD4] for information about periodicity and purpose of the file.

Figure 1 - Interfaces between MOC and SOC, this document covers the content of the interface defined in the PLID between SOC and MOC



1.1 Reference Documents [RD1] SOL-ESC-IF-05010, PLID, [RD2] SOL-ESC-IA-05002, SOIA, [RD3] MDS-MCS-SW-ICD-1001-HSO-GD, PF ICD, [RD4] SOL-ESC-TN-12000, , SOL Mission Planning Concept [RD5] Solar Orbiter Flight Operations Plan, SOL-ESC-PL-00001, TBW. [RD6] SOL-ESC-IF-50002 (FD Events file ICD) [RD7] SOL-ESC-TN-10013 SOL OMM File Naming Convention [RD8] EGOS-MCS-S2K-ICD SCOS 2000 Database Import ICD Latest versions of documents apply.



2 OVERVIEW

Please find below a graph showing the Interfaces between Mission Operations Center (MOC) and Science Ground Segment (SGS). The Science Ground Segment (SGS) comprises the SOLO Principal Investigators (PIs) and the Science Operations Center (SOC). MOC includes Mission Planning System (MPS), Flight Control Team (FCT) and Mission Control Center (MCS). This document does not describe the interface to Fdyn and SOC [RD6] nor the one between PIs and SOC. SOC and MOC send all products via the Generic File Transfer System (GFTS) which automatically takes care of the routing to the individual subsystem.

Figure 2 - Context of product interfaces between SGS(SOC/PIs) and MOC.

SGS MOC

POR(G)

CRR(G)

POF

SOC

SOL PIs

PDOR_[E/C] (eng or con via SOC)

CRR

MPS

MCS

MDOR

ESTRACK

FCT

FECS

pre_LTP TN

PCR

OSSUPD

PLNVIEW

UEVT

MIB

VDOR_ (iVSTP)

IOR



2.1 Summary of files

File Name Type Source Destination CRR_* Command Request File MOC SGS FECS_* Event File MOC SGS MDOR_* Command Request File PI MOC (via SGS) MIB__* SCOS 2000 Database MOC SOC PCR__* Email SOC MOC PDOR_* Command Request File PI (via SOC) MOC (via SOC) POR__* Command Request File SOC MOC PORG_* Zip File SOC MOC Pre_LTP TN* Technical Note SGS MOC UEVT_* Event File MOC SGS



3 CRR - COMMAND REQUEST RESPONSE FILE

The CRR is the file sent from MOC to SGS as response to all files being sent by SGS to MOC.

3.1 Format The format follows the Planning files ICD [RD3] with the SOLO specific tailoring for the generation time element in the header as specified in the PLID [RD1]

3.2 Content The file contains a reference to the checked file and the list of errors as specified in the Planning files ICD [RD3].

3.3 Naming Convention The naming convention for the CRR follows the generic CRR Naming convention as specified in the PLID [RD1] Ex: CRR_<original_filename>.ZIP



4 FECS - FLIGHT EVENT AND COMMUNICATIONS SKELETON

The Mission Planning System produces the Flight Event and Communication Skeleton as defined in the SOIA [RD2]and MPC[RD4]. The FECS is the event file passing information from the FCT to the SOC for what concerns data downlink windows, TM bit rates, and generically information about spacecraft operations required for science planning.

4.1 Format The format of the file is as defined for event files in the PF ICD [RD3], with the exception of the following attributes:

- The format of the attribute “duration” is expressed in seconds, and shall be set to 0 for instantaneous events.

- The attribute “comment” is a plain text field that shall not be longer than 140 characters. This will be used only exceptionally.

4.2 Contents The file will contain instances of the following events whenever the MPS determines that they occur (start time and duration):

EVENT NAME Description Parameters Inst./Period

Comment

SSMM_DUMP_1WAY

SCIENCE DATA DUMP 1WAY

Minimal period during which the SSMM dumps are active before the sweep. So called Blind Dumps.

tm_rate (Frame-Level Spacecraft downlink TM bit rate minus the VC0 HK rate and its frame overhead - bps). Note, the actual bandwidth used by VC0 frames depends on the fill state of each frame, Thus it is not possible to give an exact dump period

Period

SSMM_DUMP_2WAY

SCIENCE DATA DUMP 2WAY

Minimal period during which the SSMM dumps are active after the sweep.

tm_rate (Frame-Level Spacecraft downlink TM bit rate minus the VC0 HK rate and its frame overhead - bps). Note, the actual bandwidth used by VC0 frames depends on the fill state of each frame, Thus it is

Period



not possible to give an exact dump period

OMM_DUMP HK DATA DUMP

Estimated period during which the OMM dumps are active

tm_rate (Frame-Level Spacecraft downlink TM bit rate minus the VC0 HK rate and its frame overhead - bps). Note, the actual bandwidth used by VC0 frames depends on the fill state of each frame, Thus it is not possible to give an exact dump period

Period

PASS Ground Station pass (in SC Time)

PASS corresponds to the booked pass on Ground minus OWLT.

station (MLG/CEB/NNO) tm_rate (Frame-Level Spacecraft TM bit rate - bps) dbcode (mapped to rates, encoding scheme, modulation scheme)

Period

RSW_START Start of Remote Sensing Window

Indicates the start of a Remote Sensing Window (by default starts at End of Pass)

Instant

RSW_END End of Remote Sensing Window

Indicates the end of a Remote Sensing Window (by default ends at End of Pass)

Instant

POWER Available Power for Payload

Gives the available Power for Payloads calculated by subtracting the Power consumed by the Platform from the generated power of the Solar Arrays. Note that a POWER fact will be generated every time either the consumption changes or the generation. Since the data points for the generated power of the SA are ingested from a table

max (float) 2

Period (at most 12 hours)

2 The data points are connected with a step profile with time. That means that for decreasing power generation the power is slightly overestimated towards the end of a step. A margin has been therefore introduced to account for the worst case discrepancy within a step.



with discrete timestamps of 12 hours, there is at least a new datapoint every 12 hours. 1

LTP_BOUND LTP boundaries

Indicates the boundary time between the end of an MTP period and the start of the following one l_count = LTP counter first_stp = first stp counter of this LTP last_stp = last stp counter of this LTP

l_count first_stp last_stp (all integer)

Notes:

- The “time” of the FECS event is always referred to S/C on-board time. - The FECS events will only contain events within its validity times

4.3 Naming Convention The file naming convention is as follows: FECS_<StartValidity>_<EndValidity>_<GenDate>_v<Version>.SOL where Validity date is Year and DoY and GenDate is YYYYDOYHHMMSS Version is 2 digits Examples of Valid Filenames FECS_2020202_2020365 _2018341152207_v02.SOL

1 The Power Consumption is driven by the State Models as described in the ORCD and at for LTP the events changing the state are coming from the PTEL and the PLNVIEW file. Wheel and TWTA state changes are the main drivers with approximately 5-10 points per day.



5 MDOR - MEMORY DIRECT OPERATIONS REQUEST

These contain sequences for the purpose of patching or dumping instrument on-board memories, as well as for requesting checksums. They are also processed directly by the MCS TC system and are to be used by PI teams to specify memory maintenance operations.

5.1 Format The format is specified in the PLID [RD1] and similar to the PDOR format but utilizing octet string parameter type to allow a memory patch to be specified as a string of hexadecimal values.

5.2 Content The contents are sequences to perform direct operation request such as performing a checksum, dumping and patching a part of a memory device. It shall be noted that a MDOR is a general purpose file to do all of this operations within one file, which is an evolution to the three different files used for example for Rosetta.

5.3 Naming Convention The naming convention follows the generic CRF Naming Convention as described in the PLID [RD1]. <Type>_<Source>_<TypeOfOperation><filenumber>_<date>_<freetext>_<version>.SOL To give a practical example: MDOR_<Source>_P001_2020365_PATCHEEPROM_00002.SOL Placeholder Value Meaning <Type> MDOR Memory Direct Operation Request <Source> SPHI Source should be PHI <TypeOfOperation> P (or D or T) Patching Activity (or D for Dumping or T for

Test) <filenumber> 001 First file for that activity (on that date) <date> (Optional) 2020365 execution start date in year + Day of year <freetext> (Optional) PATCHEEPROM description of activity (up to 20 characters) <version> 00002 2nd version of this MDOR file

If multiple files are to be transmitted they should be grouped together as a CRFG including a Manifest file with the naming convention as defined in [RD1].



6 MIB – MISSION INFORMATION BASE

The MIB is the set of files containing the TM/TC definitions for the mission. This file is sent to the SGS for commanding purposes and the interface between SGS and MOC is at command sequence level. Nevertheless the full MIB is transmitted to SGS.

6.1 Format The Format of the MIB is defined in the SCOS 2000 Database Importer ICD [RD8]

6.2 Contents The MIB is a set of ASCII files which are zipped up in a single file and the resulting zip file is delivered.

6.3 Naming Convention The naming convention for the MIB is the following: MIB__yyyymmddMvdfSyyy_SOL.zip where: yyyy Year of issue mm Month of issue dd Day of issue vdf Version of the Master database from VDF_NAME with whitespaces and points removed yyy Version of the Sequences database



7 PCR - PASS CHANGE REQUESTS

The SOC produces Pass Change Requests as defined in the MPC [RD4]. The Pass Change Requests (PCR) contains requests to delete or modify current passes or add new ones on top of the baseline pass allocation. Passes are known to SGS via the FECS (see Sect. 4.2) in Spacecraft time. SGS may request modifications to these events when they interfere significantly with payload activities as long as the modifications respect the visibility windows. MOC will convert the modified PASS events to the corresponding pass times in ground time reference and generate the respective Operational Service Session Updates for ESTRACK.

7.1 Format The format of the file is an Email specifying Station, old and new pass times in spacecraft time.

7.2 Contents The expected content of this Email is a list of passes identified by Groundstation ID, BoT and EoT (in Spacecraft Time). Every Pass should be followed by a text line describing the change and a line with the new expected times (if applicable). As a practical Example ID GS ID BoT EoT Old NNO 2019-100T12:30 2019-100T18:30 desc 3 hours earlier EOT to allow for new slew New NNO 2019-100T12:30 2019-100T15:30 Old CEB 2019-101T19:30 2019-102T05:00 desc Remove pass because it interferes with science observation New Old desc Add a new pass to dump science data from observation New MLG 2019-102T08:00 2019-102T12:00

7.3 Naming Convention The file naming convention is not relevant



8 PDOR - PAYLOAD DIRECT OPERATIONS REQUEST

The Payload Direct Operation Request (PDOR) as defined in SOLO Planning Interface Document [RD1] contains inputs from PIs which shall be injected directly to the MCS TC system without the need of the MPS for engineering purposes that cannot be pre-planned.

8.1 Format The format of the file is as defined for event files in the PLID [RD1].

8.2 Contents Similar to PORs, PDORs shall contain TC sequences as defined in the Payload FOP but because they are used in the case of contingency or engineering activities and therefore can contain also single commands. PDOR contents will be checked against a whitelist to prohibit the use of critical platform commands and sequences.

8.3 Naming Convention The naming convention for PDORs in the engineering or contingency case should follow a similar convention but they should refer to dates instead of planning cycles. <Type>_<Source>_<TypeOfOperation><filenumber>_<date>_<freetext>_<version>.SOL To give a practical example: PDOR_SSHI_E004_2020365_UPDATETABLES02_00002.SOL Placeholder Value Meaning <Type> PDOR Payload Direct Operation Request <Source> SSHI Source Payload <TypeOfOperation> E (or C) Engineering Activity (or C for Contingency) <filenumber> 004 File counter for this Engineering activity <date> (optional) 2020365 execution start date in year + Day of year <freetext> (optional) UpdateTables02 description of activity (up to 20 characters) <version> 00002 2nd version of this PDOR file

If multiple files are to be transmitted they should be grouped together as a CRFG including a Manifest file with the naming convention as defined in [RD1].



9 POR - PAYLOAD OPERATIONS REQUESTS

The SOC shall produce Payload Operations Requests as defined in the MPC [RD4] and PLID [RD1]. The Payload Operations Requests contain all the payload command sequence calls required for a given planning cycle and that are to be checked and converted to TC stacks by the MOC.

9.1 Format The format of the file is as defined for event files in the PF ICD [RD3].

9.2 Contents The Payload Operations Requests shall contain TC sequence calls according to their definitions in the Payload FOP volumes (see [RD5]), or TC sequence calls for data downlink according to their definitions in the Data Handling FOP (see [RD5]), including valid values for any required formal parameters. When the value is not yet known (e.g. at MTP), a valid default shall be given, such that the file can be processed. The TC sequence calls shall respect any constraints defined in the corresponding FOP (e.g. timing or separation of sequences, exclusivity of sequence usage, etc.) The TC sequence calls shall be time-tagged with an absolute UTC time. The POR shall be self-contained, that is they shall contain all the commanding required to initialise the payload from a state being consistent with its default3 state, perform all the observations for a given time span and then finish with restoring the payload back to a state consistent with its default state – this ensures that in case a POR, for some reason, does not make it to the spacecraft, the subsequent plan of operations for that payload is not invalidated. The time span for observations shall be as needed for a particular payload (minutes, hourly, daily or weekly), but it shall not expand beyond the length of an STP cycle – this ensures that 3 Default state: thus is assumed to be the unique end-state of the instrument-provided CRPs achieving a post-contingency recovery back to science. In general for RS-instruments it is assumed that the default-state is not actively observing (it needs subsequent MTL commanding to perform observations), for some (e.g. IS) instruments it may be that the "default-state" creates science. Instruments are required to identify in their CRPs whether they require re-entry into a pre-planned MTL only at defined points in order to preserve command integrity (in which case the MTL will be restarted only at the beginning of the next POR) or whether the MTL can be reactivated at any time.



no operations within an STP are missed because they expand into another STP. The shorter the time span of a POR the more flexibility it will allow in cases that require re-planning and re-synching with a new starting point. As a guideline, one POR per day is an adequate rate. The contents for the “special” cases for the SSMM downlink programming and SOLOHI please refer to Appendix D.

9.2.1 Z records The POR format foresees the optional usage of Z records to pass resource usage information associated to the operations scenario presented by the sequence requests. In addition the Z-records of a POR are used to make iVSTP windows visible to MOC (TBC). The following Z record types are foreseen:

- DR – indicates the rate [in bps] at which aggregated instrument data is being generated as off the associated time marker

- PW – (optional given that MOC will run its own state-based models) Indicates the total power consumption [in Watts] of the payload as off the associated time marker

Time markers are offsets to the execution time of the sequence to which they are associated in the POR. For each Sequence there can be 0, 1 or more Z records of any given type associated, as long as they are chronologically listed (in growing order of the time offset). Both positive and negative offsets are acceptable. Be aware that negative or positive offsets that fall outside the validity period of the POR (or outside the span of the current STP) will cause the markers to be rejected when the POR is processed. Given the recurrent problem that often sequences tend to have record markers with fixed offsets, it may occur that when the sequences execution time comes close enough the associated Z record offsets will interleave causing the system to fail to build a coherent profile. It is advisable to build the complete record profile associated only to the very first sequence of the POR to prevent unwanted interleaving. Below is an example of the usage of Z records associated to a particular sequence in a POR: <profileList count="5">

<profile type="DR"> <timeOffset>-00:22:33</timeOffset> <value>8950</value>

</profile> <profile type="DR">

<timeOffset>-012.11:22:30</timeOffset> <value>9950</value>

</profile> <profile type="PW">

<timeOffset>00:00:00</timeOffset>



<value>10</value> </profile> <profile type="PW">

<timeOffset>128.01:01:01</timeOffset> <value>15</value>

</profile> <profile type="PW">

<timeOffset>03:02:01</timeOffset> <value>0</value>

</profile> </profileList>

9.2.2 POR iVSTP metadata During the STP/MTP cycle, SGS shall define a number of iVSTP windows where later (during the VSTP cycle) they will insert instrument commands via a dedicated iVSTP PDOR. (Note, PORs and PDORs are called IORs for PIs). The PDOR will be uplinked directly into the MTL by ground and forced to a dedicated SSID which is specific to iVSTP and per instrument. SGS need to pass to MOC a set of information about the iVSTP within the STP/MTP POR (see below the definition of the iVSTP element and its attributes). This information will be linked to the "enable SSID for iVSTP PDOR" sequence, contained in the POR.

Figure 3: Example of POR and PDOR schedule during RSW

For this purpose, an additional (optional) custom field will be used, within a sequence in the POR, effectively adding metadata to a sequence.



The POR will contain a new element called <iVSTP> with the following attributes:

- start_time – indicates the start time of the iVSTP, specifying the starting time with the “timeOffset” parameter, with offset of 1 second before the start of the PDOR. The iVSTP validity time shall be repeated in the “value” field of the “profile type” for readability and checking purposes, in the format CCSDS ASCII timecode B, “yyyy-DOYThh:mm:ssZ".

- end_time – indicates the end time of the iVSTP, specifying the ending time with the “timeOffset”parameter, as offset of 1 second to the end of the the last command of the PDOR. The iVSTP validity time shall be repeated in the “value” field of the “profile type” for readability and checking purposes, in the format CCSDS ASCII timecode B, “yyyy-DOYThh:mm:ssZ".

- max_num_TC – indicates the maximum number of telecommands that can be sent within the specific iVSTP window.

- VDOR_ground_filename – indicates the ground filename of the sequence TC file included in the POR.

An example of usage of iVSTP custom element is shown below:

<sequence name="ASYT010A"> <passID> </passID> <uniqueID> SSGS0000000000000001</uniqueID> <insertOrDeleteFlag>Insert</insertOrDeleteFlag> <source> SSGS</source> <destination>R</destination> <executionTime> <actionTime>2019-005T13:00:00Z</actionTime> </executionTime> <iVSTP start_time="2022-175T23:53:51Z" end_time="2022-175T23:58:51Z"

max_num_TCs="10" POR_ground_filename="VDOR_SSHI_S029X13P2_IH_I02V1.SOL" /> </sequence>

Due to the definition within the extended schema, the MPS would now interpret the above 'iVSTP' custom element and ingest, into the data-model, all attributes of this 'iVSTP' element as custom parameters of the 'SSGS0000000000000001' occurrence in which this element was added. This would result in the MPS ingesting: - start_time - end_time - max_TCs - POR_ground_filename as new custom parameters into the MPS data model with a link to the sequence they correspond to (using occurrID="SSGS0000000000000001" in this case). This is the same mechanism as for standard parameters. Their value fields would be respectively: - 2022-175T23:53:51Z



- 2022-175T23:58:51Z - 10 - VDOR_SSHI_S029X13P2_IH_I02V1.SOL These custom parameters would then also be accessible: - via rules in order to perform specific checks. - within the MPS MMI through a new 'Custom Parameters' tabulation in the sequence fact properties.

9.3 Naming Convention The file naming convention for PORs is only applicable for MTP and STP and should follow the convention below: <Type>_<Source>_<PlanType>_<STPcycle><file#>_<subsystem>_<version>_<P><SS><v><ccc><f>.SOL This is an exception to the default PLID naming convention. To give a practical example: POR__SSHI_S_S029F13_IH_I06V1_2161029D.SOL Placeholder Value Meaning <Type> POR_ Payload Operation Request <Source> SSHI Source Payload (SSGS for the ones coming from SGS) <PlanType> S STP – Applicable for short term planning cycle <STPcycle> S029 29th STP cycle of the Mission <file#> F13 13th POR file of this instrument within this STP <subsystem> IH SoloHI <IORversion> I06 6th IOR input version <PORversion> V1 1st version of this POR file

On-board part of filename <P> 2 On-board Conversion of Plan type (1 = MTP, 2 = STP) <SS> 16 Sub System / Payload ID, as (Table 2 in [RD7]) <version> 1 File version (POR version) <ccc> 029 Mission STP cycle number (decimal), does not wrap around <f> D File number (hexadecimal)

To allow tracing of operations from planning file to on-board, the resultant on-board file name shall take the form as defined in SOL OMM File Naming Convention [RD7]):



10 PORG - PAYLOAD OPERATIONS REQUESTS GROUP

10.1 Format When multiple PORs are delivered, they shall be zipped in a single file to be called Payload Operation Requests Group (PORG).

10.2 Naming Convention PORGs shall follow the naming convention hereafter defined: PORG_SSGS_cxxx_D_vvvvv.ZIP (for Payloads and the heatshield doors) PORG_SSGS_cxxx_E_vvvvv.ZIP (for PORs generated by SOC for whitelisted platform commands allowing operation of SSMM downlink queue) where

c planning cycle type, M for MTP, S for STP, V for VSTP, C for Contingency Note, within the current planning concept no use case for VSTP/Contingency has been identified yet.

xxx planning cycle counter on 3 digits uniquely identifying the Plan number. For STP/VSTP the number is as identified through the PTEL defined in [RD6]. For MTP delivery the number follows the LTP_Bound event as defined in the FECS. FOR contingency operations products required for recovery operations the number shall follow the STP in which they are scheduled.

vvvvv version of the file, starting from 01 strictly monotonically increasing per delivery but only containing the deltas to the previous version Note: SOC will use this as 000vv which is transparent to MOC Note2: complete (re)deliveries shall be provided to MOC. In a redelivery, all file versions are to be incremented by one even for unchanged files.

Note, that the PORs contained in the zip file in some cases might not have the same version of all PORs i.e. for multiple congruent updates of different Instrument PORs. For each submitted PORG MOC will generate a corresponding zip file containing all the CRRs of the transferred PORs with a name that is the same as the one of the concerned PORG but with POR replaced by CRRG.



11 PRE LTP TN – PRE LONG TERM PLANNING CYCLE TECHNICAL NOTE

The pre-LTP TN is a document that contains information that is relevant for the long term planning. The SOC compiles a report containing the overall estimation of data generation over the planning period (an orbit in the future) and any special Ground Station needs required

11.1 Format The format of this report is a Technical Note in PDF.

11.2 Contents It should contain:

• A table with the official dates of the RSW start and end within the planning orbit (during nominal phase).

• A table reporting special needs in terms of Ground Station usage, including constraints on pass times at given periods, passes to be skipped (to prevent interference with relevant observations) and additional station coverage

• A table with the periods of payload check-outs (during Cruise). • A brief summary of the type of science activities performed in the planning period

and their implication in data generation (optional)

11.3 Naming Convention The file naming convention is not relevant



12 UEVT - USER EVENT FILE

The UEVT is the event file used by the FCT to provide planning information. This event file is intended to be used by the MPS and by the SGS to make sure the two systems are synchronized.

12.1 Format The format of the UEVT and the definition of the event format is consistent with the rules for event files as provided in the PLID [RD1]

12.2 Contents The table below provides the list of elements and element IDs with the attributes in addition to the ones which are mandatory by the PLID [RD1] (i.e. time, count and duration) Element Name Event ID Attribute(s) Attribute Values uvt MGTM DB_BR BitRate DB value (0..146)

Text_BR BitRate as string uvt CBTM DB_BR BitRate DB value (0..146)

Text_BR BitRate as string uvt NNTM DB_BR BitRate DB value (0..146)

Text_BR BitRate as string uvt LTP_Start uvt LTP_End uvt RSW_Start uvt RSW_End

Note that the calibration curve to convert between textual description of the bitrates and their decimal value is available in the MIB.

12.3 Naming Convention The UEVT shall follow the naming convention hereafter defined: UEVT_<Validity Start>_<Validity End>_<Generation Date>_<version>.SOL



13 VDOR – I-VSTP DIRECT OPERATIONS REQUEST

The I-VSTP Direct Operation Request (VDOR) is a special sub-case of the PDOR as defined in SOLO Planning Interface Document [RD1]. It contains inputs from SGS which shall be injected directly to the MCS TC system. VDORS are used during the iVSTPs phase to load a set of commands into the MTL to fine-tune instrument settings during Remote Science windows in a very short turnaround. The difference between PDORs and VDORs is only in the list of allowed sequences and commands.

13.1 Format The format of the file is as defined for event files in the PLID [RD1].

13.2 Contents Similar to PDORs, VDORs shall contain TC sequences as defined in the Payload FOP and explicitly allowed in the whitelist of sequences I-VSTP. If used for the iVSTP the contained sequences will be set to a SSID such that these commands are only enabled during the dedicated slot by the “mother” STP POR file containing that VSTP slot. For iVSTPs the PDORs contents will be checked against a whitelist of allowed sequences and against the time slot assigned by the “mother” POR (see 9.2.2 POR iVSTP metadata).

13.3 Naming Convention Note: VDOR naming convention may be revised once VSTP is discussed at mission planning level and a final VSTP concept is in place. The following file naming convention for PDORs is only applicable for iVSTPs (Instrument Very Short Term Plan) and should follow the following convention: <Type>_<Source>_<STPcycle><file>_<subsystem>_<input><version>.SOL To give a practical example: VDOR_ SSHI_ S029X13_IH_ I02V1.SOL Placeholder Value Meaning <Type> VDOR_ Payload Direct Operation Request <Source> SSHI Source i.e Payload or SSGS <STPcycle> S029 29th STP cycle of the Mission <file> X13 13th POR file of this instrument within this STP <subsystem> IH SoloHI <fnumber> I02 2nd IOR input version <version> V1 1st version of this PDOR file



14 APPENDIX A– FECS EXAMPLE

The following is an excerpt from an example of a FECS file: <?xml version="1.0" encoding="UTF-8"?> <eventfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://esa.esoc.events solo_event_definitions.xsd" xmlns="http://esa.esoc.events" xmlns:ems="http://esa.esoc.ems"> <header format_version="1" gen_time="2019-008T11:37:37Z" icd_version="PLID-1.0" spacecraft="SOL" validity_start="2025-182T00:00:00Z" validity_end="2026-001T00:00:00Z"/> <events> <POWER time="2025-182T00:00:00Z" max="637" duration="299"/> <LTP_BOUND time="2025-182T00:00:00Z" l_count="1" first_stp="1" last_stp="27" duration="15897600"/> <POWER time="2025-182T00:05:00Z" max="684" duration="10799"/> <POWER time="2025-182T03:05:00Z" max="732" duration="2582"/> <POWER time="2025-182T03:48:02Z" max="725" duration="119"/> <POWER time="2025-182T03:50:02Z" max="681" duration="2099"/> <POWER time="2025-182T04:25:02Z" max="631" duration="119"/> <POWER time="2025-182T04:27:02Z" max="638" duration="2879"/> <POWER time="2025-182T05:15:02Z" max="732" duration="49"/> <POWER time="2025-182T05:15:52Z" max="597" duration="2647"/> <PASS time="2025-182T05:20:52Z" station="CEB" tm_rate="9.959812158000000E+05" dbcode="146" duration="32400"/> <SSMM_DUMP_1WAY time="2025-182T05:21:52Z" tm_rate="9.689707974074074E+05" duration="1140"/> <OMM_DUMP time="2025-182T05:44:52Z" tm_rate="9.689707974074074E+05" duration="187"/> <SSMM_DUMP_2WAY time="2025-182T05:47:59Z" tm_rate="9.689707974074074E+05" duration="30652"/> <POWER time="2025-182T06:00:00Z" max="598" duration="14402"/> <POWER time="2025-182T10:00:02Z" max="591" duration="119"/>



15 APPENDIX D– SPECIAL POR CASES

15.1.1 SSMM POR The SOC will submit POR to manage the SSMM. This includes:

• Program the content of the S13 downlink management queue for each communication pass.

• Routinely change the priority of S-15 unbound downlink requests It is acceptable to have either one POR that covers all the passes within one STP cycle or one POR per pass. The MOC will create TC sequences that allow calling for each of the above activities. The sequence calls will contain the necessary formal parameters to configure these actions. For the S-13 queue entries, for each pass the SOC will time-tag these sequences to be executed in the period of time between the flushing of the S13 queue and at least 5 minutes before the start of the corresponding pass. These PORs are to be submitted exclusively at STP cycle covering all the passes of that cycle – hence they are not needed at MTP.

15.1.2 SOLOHi POR SoloHI operates using an on-board File System (see [RD6]). Inputs for nominal operations are communicated to the instrument as files. This is in addition to commands with pre-defined discrete or numerical parameters. Default files (both parameter and schedule files) are stored in non-volatile memory. To support this interface the MOC will make available to the SOC template sequences that call each of the TC required to manage the file upload (typically one sequence per TC, with formal parameters mapping to each of the TC formal parameters). It is up to SOC/PI to parse the files into instantiations of sequence calls and populate POR files with these calls (e.g. one POR per day). The sequences must have associated execution times. The conversion to TC is done by the MOC (MPS) and will be uploaded to for delayed execution. In order to avoid missing uplink parts due to planning errors, it is recommend to not split parts of the same file across multiple POR files. The only activities that impact significantly the power consumption are annealing operations. Ideally (TBD) these would be commanded by isolated sequences (that is, not from within these schedule files) such that they can be trapped and modeled by the MPS



15.1.3 Heat Shield Door Operations Heatshield Doors must be operated in sync with the rest of the instruments and therefore are part of the delivery from SGS. The operations requests shall come in POR files separate from the instrument PORs, as they might contain compound commanding i.e. commands affecting multiple doors. The subsystem identifier for DEU is defined in Table 2 [RD7]. There are several constraints which must be respected by SGS:

• Number of operations per door per RSW is not allowed to exceed 4 (tbc) • Door operations can only be performed consecutively (never at the same time) with

one operation (opening or closing) taking up to 10 min. However it is nominal to allow door operations to queue (i.e. not to respect 10 mins separation in the commanding) in order reduce the number of DEU cycles in the mission.

• Door operations shall only be performed during the pre-curser of the RSW or during the RSW itself or shortly after the RSW (tbc)

MOC-SOC ICD - Solar Orbiter PLID Annex B - 1

Documents

Transcript of MOC-SOC ICD - Solar Orbiter PLID Annex B - 1