Mars Exploration Rover Data Management for Mars Exploration

Mars Exploration Rover Data Management for Mars Exploration Rovers David E. Smyth Joseph F. Snyder Jet Propulsion Laboratory California Institute of Technology Pasadena, California Spacecraft Flight Software Workshop November 2009 DES/JFS - 1

Mars Exploration Rovers Mars Exploration Rover X-band Direct-to-Earth UHF Relay Link Backup/Demo UHF Link MGS Odyssey Mars Express Opportunity Spirit Landed 24 January 2004 Operating in excess of 2006 Sols Over 28 gigabits data returned Landed 3 January 2004 Operating in excess of 2027 Sols Over 30 gigabits data returned Spirit Opportunity Flight Software Workshop, November 2009 DES/JFS - 2

Introduction: Data Management Mars Exploration Rover • MER goal was to leverage as much as possible from Mars Pathfinder mission (MPF) – MER Surface Mission far more complicated and demanding than MPF – Data Management was a significant departure from MPF • MER Data Management defined as follows: – “Data” refers to Data Products generate by the Rovers for possible telemetry to Earth, as well as those actually received on Earth · Discrete set of data meant to be logically treated as a unit – a file · Images, spectra, sets of time-ordered measurements, related set of states, etc. – “Management” covers the handling of Data Products on-board, on Earth, and the interface between the two • MER Data Management treated as a System, during development and operations Flight Software Workshop, November 2009 DES/JFS - 3

A Day in the Life of MER Mars Exploration Rover • A Typical Sol on Mars: – Once per Sol Uplink: 100 KB – One DTE, one ODY downlink before command generation begins for next Sol. – Limited time to plan for next sol. – The rovers are on opposite sides of Mars… • MER-specific Flight System Constraints: – Frequent Shutdown/Wakeup Cycles – Data Generation and Storage Capacity Limitations – Asynchronous link bandwidth – Most data not down yet when we start to plan for next Sol – MGS data drop-outs additional latency Flight Software Workshop, November 2009 DES/JFS - 4

Summary Data Management Objective Mars Exploration Rover • Accommodate “human-in-the-loop” Tactical Operations – While simultaneously automating standard operations – While respecting the unique flight system constraints of MER – While respecting unique characteristics of each type of communications link – While supporting changes in downlink opportunities, changes in data collection, and changes in data criticality Flight Software Workshop, November 2009 DES/JFS - 5

Specific Objectives Mars Exploration Rover • Insight into On-board Data • Explicit Downlink Priority Control • Transmission Path Control • Retransmission Control • Deletion Control • • Data created each Sol is MUCH greater than can be transmitted Maintain compact Synopsis of on-board data: metadata – – • • Source Type Generating Event Sample Time Metadata must be predictable Create and telemeter a Data Product Summary Report containing a listing of metadata of all on-board data products Flight Software Workshop, November 2009 DES/JFS - 6

Specific Objectives Mars Exploration Rover • Insight into On-board Data • Explicit Downlink Priority Control • Transmission Path Control • Retransmission Control • Deletion Control • • • Some data is critical: needed for planning the next sol Individual Data Products have “Dynamic Usefulness” Implement fine priority control – Priority set at creation time per command parameters – Reprioritize individual DP – Reprioritize sets of DPs Flight Software Workshop, November 2009 DES/JFS - 7

Specific Objectives Mars Exploration Rover • • Insight into On-board Data • Explicit Downlink Priority Control • Transmission Path Control • Retransmission Control • Deletion Control Link characteristics vary considerably – Direct to Earth · Low bandwidth, least latency, high reliability – Relay · High bandwidth, fixed availability, variable latency and reliability • Implement transmission path control – Assign at discrete data product level – Assign to sets of data products – Allow specification of preferred path, multiple paths, or first available Flight Software Workshop, November 2009 DES/JFS - 8

Specific Objectives Mars Exploration Rover • Insight into On-board Data • Explicit Downlink Priority Control • Transmission Path Control • Retransmission Control • Deletion Control • Make partially received data useful – Self-identifying at part level – Delivered and “viewable” even with holes • Fine retransmission control – – – Rexmit parts of a DP Rexmit entire DP Rexmit sets of DPs Change priorities Change transmit path Flight Software Workshop, November 2009 DES/JFS - 9

Specific Objectives Mars Exploration Rover • Insight into On-board Data • Explicit Downlink Priority Control • Transmission Path Control • Retransmission Control • Deletion Control • Fine deletion control – Delete individual DP – Delete sets of DPs Flight Software Workshop, November 2009 DES/JFS - 10

Development History Mars Exploration Rover • MPF Data Architecture: Store and Transmit Packets – Event Reporting Service (EVR) – Channelized Telemetry Service (EHA) – Science and all other Engineering Data generated as raw packets – CCSDS Packet Telemetry Service (DWN) · · Packet priority based on APID Packet storage in RAM No other persistent storage Assumes no shutdowns (shutdowns result in loss of all data in RAM) Flight Software Workshop, November 2009 DES/JFS - 11

Development History Mars Exploration Rover • MER Data Architecture: Data Products = file+metadata Telemetry is Packets – Data Products stored in persistent memory (FLASH, not RAM) – MPF EVR and EHA services retained, but now produce Data Products – Science and all other Engineering Data generated as specific Data Products – CCSDS Packet Telemetry Service · Products turned to Packets “Just In Time” in product priority order Flight Software Workshop, November 2009 DES/JFS - 12

Key System Components Mars Exploration Rover • Flight Software – MRF : Massively multi-threaded Real-time File system · Client API, similar to POSIX fopen(), fwrite(), and fclose() calls – FME : File Metadata Engine · Supports operations on sets of data products, individual data products, and portions of individual data products · Provides prioritized list of data products to PDP for packetization – PDP : Packetized Data Products · Converts Data Products to Packets during communications sessions • Ground Software – MDP : MER Data Product Build · Reconstitutes Data Products from received packets · Accounts for missing packets – MDPV : MER Data Product View · Allows simple viewing of most Data Products Flight Software Workshop, November 2009 DES/JFS - 13

Data Management Surface Process Mars Exploration Rover • Current Surface Process performs the following tasks once each uplink cycle (1 per Rover per Sol) – Retransmit un-received, partially received, and corrupt data products · Typically results in tens of commands – Delete all other data products that have been sent · Typically results in hundreds of DPs deleted per command – Delete unsent data products no longer considered to be of value · Typical results in a half dozen commands deleting hundreds of DPs per sol – Reprioritize, retransmit, and/or delete data products per requests Flight Software Workshop, November 2009 DES/JFS - 14

Data Management Surface Process Details Mars Exploration Rover 1. Identify all partially and completely received Data Products since the last cycle completed – Includes all data products received from all relay assets and direct to earth links 2. Generate individual Retransmit Commands for each identified missing or partially received Data Product – Applies configurable heuristics: · · To not retransmit certain Data Products To change priority and/or transmission path of certain Data Products 3. Perform automatic corruption checking – Generate individual Retransmit Commands for corrupted parts – Update original corrupt data when the retransmitted data is received 4. Generate “Group” Delete Commands for each communications pass Flight Software Workshop, November 2009 DES/JFS - 15

Data Management Surface Process Details (contd) Mars Exploration Rover 5. Generate “Group” Delete Commands for unsent data products that meet configurable age and size parameters – Small PMA and HGA log files (no motion), old images, … 6. Generate single and “Group” Reprioritization Commands for classes of Data Products that meet configurable age and size parameters – Increase priority of biggest PMA and HGA log files (during movement) 7. Accommodate highly custom requests – Delete sets of data products no longer needed or wanted – Reprioritize data products from specific sequences, time ranges, or other criteria Flight Software Workshop, November 2009 DES/JFS - 16

Conclusions Mars Exploration Rover • Use of standard stdio-like API greatly simplified flight and ground software for science instruments and engineering subsystems • On-board metadata object base enabled operations on sets of data products – Effective use of downlink bandwidth across multiple types of links – Dramatically reduced uplink bandwidth needs • Designed for “mission-operations-in-the-loop” from the beginning – System is highly automated while still able to respond to unforeseen pitfalls and opportunities • Well suited for future autonomous spacecraft. • “Version 2” being applied to Mars Science Laboratory Flight Software Workshop, November 2009 DES/JFS - 17

Conclusion: Key Capabilities of MER DP Mars Exploration Rover • • MER DP is multi-route end-to-end MER DP has predictable and unique-over-life-of-mission DP IDs MER DP transaction state is persistent and auditable MER DP obeys FLP: – MER DP can use protocol level “immediate” data (packet headers) for non -destructive actions (recognizing when a DP arrives, detecting holes in DPs that need re-transmission) – MER DP uses an auditable “synchronous” artifact (DPSR) to make destructive actions (delete Flight Software Workshop, November 2009 DES/JFS - 18

What is FLP? Mars Exploration Rover • “Impossibility of distributed consensus with one faulty process” – – – Journal of the ACM, Volume 32, Issue 2 (April 1985) Pages: 374 - 382, ISSN: 0004 -5411 by Michael J Fisher, Yale, Nancy A. Lynch, MIT, and Michael S. Paterson, University of Coventry. In this paper, it is shown that every protocol for this problem has the possibility of non-termination, even with only one faulty process. By way of contrast, solutions are known for the synchronous case, the Byzantine Generals problem. • ACM Symposium on Principles of Distributed Computing Influential Paper Award: 2001 – The PODC Influential Paper Award was created to acknowledge an outstanding paper on the principles of distributed computing, whose significance and impact on theory and/or practice of distributed computing has been evident for at least a decade. Flight Software Workshop, November 2009 DES/JFS - 19