Integrating Payload Data Interfaces with LADEE Flight and

Integrating Payload Data Interfaces with LADEE Flight and Ground Software Douglas Forman Millennium Engineering and Integration Company (MEI) LADEE FSW Payload I/F Developer NASA-Ames Research Center Moffett Field, CA Craig Pires – LADEE C&DH Lead (NASA) Matthew Dortenzio – LADEE Mission Ops Manager (NASA) Michael Logan – LADEE FSW Dev / Ops Gnd Ctl (LMSI) Mark Shirley – LADEE SE / Ops (NASA) 1

Overview • LADEE Payloads – Data Interfaces/Protocols • LADEE Flight Software – Payload Interface Architecture • FSW Payload Integration Strategy – Decisions and Rationale • Lessons Learned (good and bad) – Lessons Being Applied 2

Model-Based “Common-Bus” LADEE • c. FE/c. FS Software Bus – “Common Bus” H/W – Loosely Coupled Apps • Model Based Evolution – Simulink/Autocode • Closed Loop Simulation • Auto-coded to various fixed -fidelity Targets • CCSDS Cmd/Tlm – ITOS Ground S/W 3

LADEE Payloads • UVS (Ultra-violet Spectrometer) – Draper Labs • NMS (Neutral mass Spectrometer) – Goddard Spaceflight Center • LDEX (Lunar Dust Environment Experiment) – LASP (University of Colorado at Boulder) • LLST (Lunar Laser Space Terminal) Control Electronics and High Speed FSW Tlm – MIT Lincoln Labs • Star Tracker Camera s Bonu 4

General Payload Data Interface Requirements • Protocol (H/W and S/W) – Clocking of bits / Data Rate – Flow Control – Message Framing / Synchronization – Checksum – RS 422 Termination • Payload Commanding/Telemetry – Live from Ground and/or Stored • Large Data Upload/Download – Firmware Update, Image Download • Periodic Messages to Payloads from S/C FSW – Time Tag (PPS) – Attitude, Ephemeris • S/C FSW Payload Data Interface SOH and Fault Detection Tlm • S/C FSW Collects Unexpected “Out-of-Band” (OOB) Data 5

UVS Data Interface H/W Architecture RS 422 230. 4 K bits/sec Cmd Data c. PCI LADEE CPU Rad 750 Tlm Data LADEE Avionics Interface Board (FPGA Programmable) UVS (Ultra-Violet Spectrometer) 6

UVS Data Interface • • • Custom Protocol based on interactive modem commands – COTS Product with Flight Heritage (from Draper Labs) – Default ascii mode (two letter commands: “AA”, “BB”) • Ack/Nack for all commands Integration Advantages – Easy to debug interactively in ascii mode – After initial set-up, spectral data produced periodically – Standard RS-422 UART Integration Challenges – Early integration with ITOS (TLYF) complex • Variable length tlm/cmd layered over fixed size packet definition • Accomplished due to proximity of payload team • ITOS STOL used for full regression tests before CDR – S/C FSW Design slightly more complex • Knowing how many bytes to expect from UVS and wrap in APPID 7

NMS Data Interface H/W Architecture RS 422 2 M bits/sec c. PCI LADEE CPU Rad 750 Cmd Data Cmd Clock Cmd Frame Valid Ready for Cmd Tlm Data Tlm Clock Tlm Frame Valid Ready for Tlm LADEE Avionics Interface Board (FPGA Programmable) NMS (Neutral Mass Spectrometer) COTS from Goddard 8

NMS Data Interface • Instrument Transfer Frame H/W S/W Protocol – Legacy (COTS) Instrument from Goddard • Integration Advantages: – Large data transfers supported (32 bit size field) – Frame synchronization in hardware – Flow control supported by hardware • Integration Challenges: – No early integration with ITOS • ITOS complexity: Checksum and variable length • Variable length tlm/cmd layered over fixed size packet definition • Payload Team used existing GSE ; not funded/motivated for early ITOS – Integration with FSW more complex • Add/strip CCSDS Wrappers to/from telemetry/commands • Checksum Computations for Time Sync Message – Required custom H/W FPGA (lag between issues and fixes) 9

LDEX Payload I/F H/W Architecture RS 422 57. 6 K bits/sec PPS c. PCI Cmd Data Tlm Data LADEE CPU Rad 750 LADEE Avionics Interface Board (FPGA Programmable) LDEX (Lunar Dust Environment Experiment) New Development from University of Colorado at Boulder LASP 10

LDEX Data Interface • CCSDS Packet cmd/tlm I/F (same as S/C FSW) – New development from LASP UC Boulder – FPGA only ; no software on instrument • Integration Advantages – Allows Cmd/Tlm “bent-pipe” pass-through in S/C FSW – Easy integration with FSW and ITOS – Standard RS-422 UART H/W • Integration Challenges – No synchronization pattern in packet • Used fixed fields in CCDS Primary Header – Required custom H/W for PPS Signal • Synchronized with periodic Time Msg 11

LLST Data Interface H/W Architecture LVDH High Speed FSW Tlm 40 M bits/ sec Optical Module Tlm Data LADEE CPU Rad 750 Tlm Clk Tlm Frame Valid Ready for Tlm Internal Data Comm c. P CI Optical Link Cmd Data Tlm Data RS 422 115. 2 K bits/ sec LADEE Avionics Interface Board (FPGA Programmable) Lasercom Control Electronics (CE) 12

LLST CE Data Interface • CCSDS Packet cmd/tlm I/F (same as S/C FSW) – New Development from Lincoln Labs MIT • Integration Advantages – Allows Cmd/Tlm “bent-pipe” pass-through in S/C FSW – Early integration with ITOS and FSW • No other GSE used – ITOS used before FSW EDU in place • Easy Integration of FSW generated mesages – Standard RS 422 UART H/W • Integration Challenges – Packet size limited to 64 K bytes (16 bit size field) • CFDP implemented in payload FSW for large data upload – No synchronization pattern in packet • Used fixed fields in CCDS Primary Header – Small buffer in UART ; S/W Flow Control Required 13

LLST High Speed Lasercom Data Interface • Downlink of FSW tlm through Lasercom – Multiplexed in with Lasercom test data • 40 MB/sec difficult to fill using FSW • Implemented on FPGA – Direct access to 1 GB Flash (File System) • Dumped File System Partitions (5) – Re-assembled and mounted on ground • Pros: – All payload and S/C SOH data available – Minimal impact to S/C processing 14

LLST High Speed Lasercom Implementation • FPGA transmits Memory Dump chunks – Takes Flash Mass Storage Start, Stop Addresses as input • Dumps all memory between Start and Stop Addresses – CPU interrupted when full Transmission completes • Lasercom Device Driver (on CPU) – Only c. PCI access is writing Start/Stop addresses – Restarts transmission if looping flag set • Ground Commands – Set Start, Stop Addresses – Set/Unset looping flags • Workstation (linux) Post Processing – – FPGA (H/W) headers processed and stripped Binary data written to file File mounted on workstation as a dos partition All files and directories accessible 15

ST Camera Data Interface H/W Architecture RS 422 115. . 2 K bits/sec Cmd Data c. PCI LADEE CPU Rad 750 Tlm Data LADEE Avionics Interface Board (FPGA Programmable) Star Tracker Camera us e n Bo atur fe 16

Star Tracker Data Interface • CCSDS Packet cmd/tlm I/F (defined in Vendor ICD) – COTS implementation of Packet Utilization Standard (PUS) • Integration Advantages – Allows Cmd/Tlm “bent-pipe” pass-through in S/C FSW • Facilitated un-documented features – (For example: Image Download) – Image File Chunking built in to COTS cmd/tlm I/F – Could have facilitated early integration with ITOS and FSW • No ST ETU available for FSW testing (coded to ICD) – Standard RS-422 UART H/W • Integration Challenges – ITOS Integration with PUS is tricky • One APPID ; msg type in PUS header ; variable len pkts – No synchronization pattern in packet • Used fixed fields in Primary and PUS Headers 17

High Level “Loosely-Coupled” FSW Architecture OFSW Command & Mode Processor Actuator Manager State Estimator Safe Mode Controller Attitude Control System Thermal Control System Power Control System Battery Charge System Memory Scrub Hardware I/O Software Bus Scheduler Stored Commands Health & Safety Memory Manager File Manager Memory Dwell CCSDS File Delivery Checksum Housekeeping Data Storage Telemetry Output Command Ingest System Support, O/S Services and Device Drivers Telemetry Gnd Cmds KEY Sensor Data FSW Internal FSW External Limit Checker Simulink Task c. FS Task Hand Written Task 18

Context of Payload I/O Apps Command & Mode Processor Attitude Control System State Estimator Power Control System Software Bus Stored Commands Data Storage EPSIO HWIO: Payload I/O APPS LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, Star Tracker IO (STIO) Telemetry Output Command Ingest Device Drivers NOTE: Data Flow is shown between c. FE Apps using shaded dotted lines for clarity. The messages actually go through the Software Bus. Power Switch 19

Payload Initialization Message Flow Command & Mode Processor 1 a State Estimator Attitude Control System Power Control System Software Bus 1 Stored Commands Data Storage EPSIO HWIO: Payload I/O APPS LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, STIO Telemetry Output Command Ingest Device Drivers Initialization Sequence 1 – Achieve Attitude Mode to satisfy Payload Pointing Requirements 2 – Power on Payload Device 3 – Send Initialization Commands to Payload Power Switch 20

Payload Initialization Message Flow Command & Mode Processor State Estimator Attitude Control System Power Control System 2 a Software Bus 2 Stored Commands Data Storage EPSIO HWIO: Payload I/O APPS LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, STIO Telemetry Output Command Ingest Device Drivers Initialization Sequence 1 – Achieve Attitude Mode to satisfy Payload Pointing Requirements 2 – Power on Payload Device 3 – Send Initialization Commands to Payload Power Switch 21

Payload Initialization Message Flow Command & Mode Processor State Estimator Attitude Control System Power Control System Software Bus Stored Commands Data Storage EPSIO HWIO: Payload I/O APPS LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, STIO Telemetry Output Command Ingest 3 b Device Drivers Initialization Sequence 1 – Achieve Attitude Mode to satisfy Payload Pointing Requirements 2 – Power on Payload Device 3 – Send Initialization Commands to Payload Power Switch 22

Live Payload Cmd/Tlm Message Flow Command & Mode Processor Attitude Control System State Estimator Power Control System Software Bus 1 Stored Commands Data Storage Other Hardware I/O HWIO: Payload I/O APPS LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, STIO 1 a 2 3 a Telemetry Output Command Ingest 2 a Device Drivers Live Cmd/Tlm Message Flow 1 – Build and Transmit Periodic (time/att) msg to payload 2 – Receive Ground Commands and pass to Payload 3 – Receive Payload Data and pass to Ground 3 23

Stored Payload Cmd/Tlm Message Flow OFSW Command & Mode Processor Attitude Control System State Estimator Power Control System 1 Software Bus Stored Commands Data Storage 2 Other Hardware I/O HWIO: Payload I/O APPS 3 a LDEXIO, UVSIO, NMSIO, LLCDIO, HLLCDIO, STIO 1 a Telemetry Output Command Ingest 2 a Device Drivers Stored Cmd/Tlm Message Flow 1 – Build and Transmit Periodic (time/att) msg to payload 2 – Receive Stored Commands and pass to Payload 3 – Receive Payload Data and pass to Data Storage 3 24

Downlink of Stored Payload Data CCSDS FILE DELIVERY PROTOCOL (CFDP) http: //public. ccsds. org/publications/archive/727 x 0 b 4. pdf CCSDS File Delivery (CFDP) Software Bus Re-transmit Chunk Requests File Chunks LADEE Science Team Telemetry Output Command Ingest System Support, O/S Services and Device Drivers Telemetry Gnd Cmds Push Pull SVN Server Payload Data Files 25

LADEE Payload Integration Strategy • Program Decisions – No Payload (or ST) ETU/EDUs for FSW Testing • Cost/Schedule Savings – Travelling Road Show (Suitcase Simulator) • FSW EDU travels to Payload Sites • ST ETU available to FSW for only 3 days – Payload Simulator (with H/W I/F) for FSW Testing • Delivery/Fidelity inadequate for FSW development • S/C FSW Decisions – Minimal S/C FSW Processing of Payload Data • “Bent-Pipe” pass through as much as possible – Iterative FSW Development Coupled with TRS testing • Payload Decisions – H/W, S/W Interface Protocols – Early Integration with ITOS Gnd S/W (or not) 26

LADEE Travelling Road Show (TRS) • Ensure H/W I/F compatibility before I&T • Early EDU Integration at Payload Sites – Draft ICDs ; Working Prototypes – Iterative Maturation – Logged Data Analyzed • Left EDU/SDU at MIT – Remote S/W Updates No I&T or flight issues 27

Lessons Learned • Bent-pipe pass-through of payload cmd/tlm advantageous – Early “Test Like You Fly” Ground System Integration – Simplifies S/C FSW logic – Gives power (rope) to Payload Teams – COTS/Legacy may not preclude modification • Travelling Road Show was Effective – No Payload H/W interface issues found in I&T • Iterative Payload FSW ICD/Integration was Effective – Minimal Payload-related FSW defects during I&T • TRS Test Acceptance Criteria needed more scrutiny – FSW device driver issue identified during S/C I&T – Issue present, but not detected in TRS EDU testing • More time (>3 days) with the Star Tracker ETU needed – FSW Risks realized during S/C I&T and Flight 28

Lessons Being Applied • Biosentinel – Deep Space Cubesat – Re-using LADEE architecture (c. FE/c. FS, ITOS) – 3 payloads: 2 new developments, one legacy provided by JSC • Ames responsible for all payload integration and testing • Early-ish acquisition GNC H/W Engineering Units planned – Includes Star Tracker • Requiring CCSDS packets on new developments • Existing JSC Linear Energy Transfer Payload – Will add/strip CCSDS headers to/from tlm/cmd • Planning to use ITOS interface before FSW/EDU ready – Similar to LLCD CE strategy – Test Like you Fly ASAP 29