1. SOC-Produced Auxiliary data
CHRIS WATSON
ESAC

2. 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.

3. 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

4. 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?

5. 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

6. 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

7. 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.