PDS4 Data From The Rover RSP Archive Concept Review 28 September 2017 Tanya Lim Archive Scientist

Now we dive into some details Please stop me for questions along the way

PSA Standards PDS4 is a very flexible standard To impose continuity with an archive common across several planetary missions we (ESAC AS + ESDC) have agreed to impose additional PSA standards to all missions These have also been agreed with IKI for the Surface Platform PSA Standards cover two areas: Data structure Next slides as elements become mission specific PSA specific classes (not discussed further here) Metadata attributes not in PDS but useful to use cross-mission e.g. sub_instrument name and type The PSA Schema (Local Data Dictionary) is publicly available

A PDS4/PSA Bundle Bundle = Everything relating to the mission or an instrument For the PSA each mission always has N_inst + 1 (mission) bundles PSA Collection = Everything relating to a type of data

Raw – Re-packed telemetry Partially Processed – Partly calibrated PDS Data Levels Raw – Re-packed telemetry Partially Processed – Partly calibrated Calibrated – All instrument artifacts removed Derived – Scientific Results Minimum acceptable level for the final archive is Calibrated

Instrument Bundles In the PSA

Instrument Bundle Definition Status The structures are definitively described in the ROCC to PPL (PI) ICDs (Governing Documents) They are also on Confluence pages – which will be the working area for now and will be ahead: All parties expect evolution up to and beyond launch ROCC and ESAC systems can support this But changes are disruptive and the more we can pin down at an early stage the better The level of definition ranges from none to a list of products. This is not yet a concern for ESAC To move forward we (ESAC) now need a face to face discussion with each PI team

Typical Example: ISEM Partially Processed data_partially_processed: collection_calibration.xml collection_calibration.csv pre-launch / cruise version products post_landing_to_egress / surface sol housekeeping ISE-PP-03 ISEM Housekeeping Data, AOTF, Detector_Temperature science ISE-PP-02 Spectrum_f Dependence of Intensity from the AOM frequency It is a start, more work is needed but this is normal work

PanCam Calibration Collection

The Mission Bundle

Daily Reports

Example Daily Assessment Report for CLUPI

Rover Housekeeping ROCC will collect, in PDS4 products, the Rover HK data required by at least one PPL team The Rover data list will be shared with the PPL teams The PPL teams will select from this list the data relevant for a complete assessment of their instruments’ telemetry ROCC will setup a pipeline to generate auxiliary data products in PDS4 format ROCC foresees to group the HK Data by RV S/S ROCC will generate the PDS4 data products containing the converted (physical) parameters values and the raw data. The converted rover housekeeping parameters are used as input to generate calibrated science products, hence are classified as partially_processed data products.

Rover Geometry Rover Geometry will only be delivered to ESAC via SPICE files Over time absolute position drifts and position determination only takes place at certain points These files will not be post-processed -> zig zags .. at best ESAC has no resources to take care of this ROCC are proposing not to have any motion counter ESAC have no resources to sort through the data to figure out events Some Rover geometry may be inserted into instrument labels in post- processing by ROCC TBA PDS4 geometry products may be produced by PI teams specific to their instruments So far we are only aware that PanCam will provide this

Rover Geometry and Local Targets The PDS target for all data at Mars will be “Mars” Local targets will be identified and named by the mission Sample numbers, named rocks, others? Each local target will have a context generated by ROCC and these context files will be stored in the mission bundle Processed data will be associated with a local target if relevant manually by the PI team Some instruments such as CLUPI and Micro-Omega may wish to label features within a target This is possible using either the instrument LDD and/or Target Context Products within the instrument bundles

Rover “Mission” Bundle

Rover “Mission” Bundle Outline of the Rover bundle is well defined Each product detailed so far has its own Confluence page A lot of work still to do on details and defining lower levels Changes at this level in areas e.g. addition of mission phase, are still possible Reference will be the ROCC-ESAC ICD

ROCC – ESAC Open Issues Many …. but at the detailed level, these include: Agree some details of bundle deliveries e.g. complete or partial index file How the modification history will be handled in detail Whether to have two mission bundles or two host bundles Where to put, and how to structure, the operational reports Local target context files Schema versioning scheme How to handle common/specific Rover Geometry How SPICE will be delivered to PSA Archival of primary=secondary products Static vs Dynamic Calibration Classes… A lot of this now needs to be discussed in a DAWG

Questions?