SOC-Produced Auxiliary data CHRIS WATSON ESAC

Overview Auxiliary data as presented here covers two categories SPICE support (the software package, not the instrument) Time-correlation But there is some overlap because of SPICE time kernels We do not envisage implementing a “full” SPICE support (which can be very complicated and complete) from within the SOC Very limited use of SPICE inside the SOC Not clear that most instruments will use SPICE within their own planning or processing.

SPICE support We plan to support Conversion of the CCSDS OEM orbit file to SPICE format Across the whole mission, for long look-ahead planning – which people want, right? Updated occasionally, e.g. following GAMs Linked to a 1:1 “dummy clock” kernel Because we don’t want to circulate predictive clock-kernels based on the real SC clock, because they will end up being wrong, and there is a risk that people use them inappropriately

SPICE support A historic-only Spacecraft-clock kernel Based on the accurate known time correlation behaviour (see later) A historic-only Attitude kernel Giving the SC Frame (only) based on HK At some reasonable frequency We think the use-case should be more at the level of e.g. mean pointing through an integration, and less about RPE within the integration (?) Probably segmented (per downlink or per day) Besides the low-latency post-processing done at SOC, is there a need for this to be distributed in a timely way?

SPICE support We might add a historic orbit file, linked directly to historic clock kernel But I tend to think it is enough to use the time-correlation (see later) to establish the UTC corresponding to any OBT, and then use this this to access the full mission orbit file (?) I am reluctant to support multiple SPICE frames within the spacecraft We may face significant misalignments and thermo-elastics Often we wont know where in the mechanical chain a particular misalignment arises In many cases alignments may be determined only long after the fact, based on specific campaigns and full science (arriving with latency) Thus we can easily face a situation where any published set of frames are “always wrong” The boresight alignments used for pointing commanding are operations-orientated, and not intended to be science quality

Time Correlation We will provide a historic SPICE clock kernel, as described earlier We will also provide a TN describing how to make use of the correlation data (most likely in the form of the SPICE clock kernel) to perform (historic) OBT->UTC and UTC->OBT conversions Following a previous meeting instrument teams were canvassed to see if they wanted a SOC-implemented SW they could use to do the conversion Overwhelming response is “yes” We agree to do it as an over-all reduction in effort However it’s not work-reduction if you all ask for different languages… Therefore SOC propose to provide single language implementation (a “reference implementation”) Should be a widely-used platform-independent non-licensed language – could be java (?) but SOWG shall choose… Can be used directly, or source can be used as a guide for your own instrument-team implementation in any other language

ICDs We should ultimately produce an ICD for the SPICE data Should be quite simple Will just be a “tailoring” defining what parts of the existing SPICE formats we make use of, filenames, versioning etc.