HinzeSPP/FIELDS iCDR – TDS FSW Solar Probe Plus / FIELDS Instrument CDR TDS Flight Software Jason Hinze University of Minnesota 1

HinzeSPP/FIELDS iCDR – TDS FSW Flight Software Overview: High-Level Functional Description Boot Code: –Configure system to a known state. –Communicate with spacecraft (TC, engineering TM) –Select and execute operational code image –EBL: stay in boot; dump/load RAM/EEPROM Operational Code: –Communicate with spacecraft (Time and Status, Critical HK, TC, TM) –Communicate with DCB (CBS, TC, TM) –Generate and telemeter TDS events. –Manage MAGi (TC, TM, survey data, housekeeping) –Manage SWEAP –Manage AEB2 –Manage LNPS2 2

HinzeSPP/FIELDS iCDR – TDS FSW Flight Software Overview: Key Requirements System / Spacecraft -related –Configure to a known state at power on. –Support remote load-to/dump-from RAM and EEPROM. –Implement a commandable safe mode. –Communicate with spacecraft (per GI ICD ) FIELDS-related –Communicate with the DCB (per SPF_MEP_100_CDI_ICD) –Manage failover with the DCB. –Control and monitor MAGi, SWEAP, AEB2, LNPS2. –Send the Coordinated Burst Signal to DCB, SWEAP. Science Data Products -related –Time-tag science data accurately and precisely. –Collect, reduce, and send magnetometer science data (DC B-field). –Collect, evaluate, rank, and send TDS event data (AC E-field, AC B- field, SWEAP counts). 3

HinzeSPP/FIELDS iCDR – TDS FSW Flight Software Context: FIELDS Block Diagram 4

HinzeSPP/FIELDS iCDR – TDS FSW Flight Software Context: TDS Hardware 5

HinzeSPP/FIELDS iCDR – TDS FSW Changes Since iPDR There were no RFAs on the TDS FSW resulting from the iPDR. There were no major changes in software requirements. There were no major changes in relevant ICDs. There were no major changes in the top-level design of the FSW. TDS FSW pre-iCDR Peer Review (held 2014 Dec 5) resulted in 7 recommendations. –3 have been resolved. –4 will be implemented in the near term. Notable implementation changes: –Real-Time Clock Subsystem now uses multi-RTC hardware timestamping peripheral, obviating the need for timestamp-related RTC timebase conversion calculations. –TDS Event Quality / Classification algorithm increased in computational intensiveness. 6

HinzeSPP/FIELDS iCDR – TDS FSW Functional Description: Boot Code Configure system to a known state. –Initialize LEON3FT register file –Initialize RAM –Quiesce peripherals Communicate with spacecraft (Time and Status, Critical HK, TC, engineering TM) –Mostly in support of emergency boot load functionality. Select and execute operational code image –We have two slots for operational code images. –Select image to boot based on boot cause and “signature block” headers of operational code images. EBL: stay in boot; dump/load RAM/EEPROM –If we receive a command to stay in boot mode within a certain time period after boot, we will stay in boot mode waiting for further commands. –This is in support of emergency boot load functionality. 7

HinzeSPP/FIELDS iCDR – TDS FSW Functional Description: Operational Code Communicate with spacecraft (per GI ICD ) –ITF protocol processing –Spacecraft Time and Status –Instrument Critical Housekeeping –Telecommands, Telemetry Communicate with FIELDS1/DCB (CBS, TC, TM) –Coordinated Burst Signal –Telecommands, Telemetry Generate and telemeter TDS events. Manage MAGi (time sync, TC, survey data, housekeeping) Manage SWEAP (time sync, CBS, TC) Manage AEB2 (set DAC values, housekeeping) Manage LNPS2 (control mag power, housekeeping) 8

HinzeSPP/FIELDS iCDR – TDS FSW Design: Operational FSW Architecture Diagram 9

HinzeSPP/FIELDS iCDR – TDS FSW Design: Real-Time Clock Subsystem Maintains a number of Real-Time Clocks. –sMET, dMET: spacecraft-sourced and DCB-sourced MET: –FSCT: FIELDS Sample Clock Time (cycle/subcycle time) –TSCT: TDS Sample Clock Time (number of TDS samples acqed since reset) –SYST: System Time (number of bus clocks since reset) Handles MET sync from spacecraft and DCB interfaces. Makes available hardware timestamps of a variety of events: –Spacecraft start-of-cycle (“V1PPS”) –FIELDS start-of-cycle (“F0”) –TDS event captured –SWEAP sweep start. The current failover mode determines which MET source is used. –In slave mode, DCB-sourced MET (dMET) is used. –In master mode, spacecraft-sourced MET (sMET) is used. 10

HinzeSPP/FIELDS iCDR – TDS FSW Design: Failover Management On detection of DCB failure: –The Fields Sample Clock Time (FSCT) real-time clock is allowed to free-run. –The telemetry stream to the DCB is paused. –The MET from the spacecraft interface (sMET) is used for timestamping. –For long failures (or by command) increase telemetry bitrate to the spacecraft interface. On detection of DCB recovery: –The FIELDS Sample Clock Time (FSCT) is synced with the DCB. –The telemetry stream to the DCB is resumed. –The MET from the DCB interface (dMET) is used for timestamping. –Telemetry bitrates restored to defaults. 11

HinzeSPP/FIELDS iCDR – TDS FSW Design: TDS Instrument Handles parameter setting commands. Controls TDS analog input muxes. Maintains metadata for the TDS event buffers. –Quality –Datation timestamp –Current mux settings Calculates the quality of newly-acquired events. –Quality can be adjusted well after the acquisition as a result of further event processing. Feeds low-quality TDS event buffers back to the TDS acquisition hardware for recycling. When sufficient downlink allocation has been accumulated, telemeters highest-quality TDS event buffer. Telemetry rate commandable in bits per second. 12

HinzeSPP/FIELDS iCDR – TDS FSW Design: Interrupt and Task Management Actions requiring hard real time response are done in hardware and set up / post-processed in software, e.g.: –timestamping –sending time sync to MAGi, SWEAP Prefer to use interrupts as notifications of software work to be done, rather than replacements for hardware. –ISR’s preferred job is to post a task and possibly configure hardware for the next action. –ISR should be quick enough to not starve other ISRs or tasks unnecessarily: –Typical duration: 10µs-100µs. Most software work will be done in tasks. –Task means “a single task” not “thread of execution”. –Tasks are posted on and dispatched from a priority queue. –Tasks should be quick enough to not starve other tasks unnecessarily. –Typical duration: 100µs-1000µs. 13

HinzeSPP/FIELDS iCDR – TDS FSW Timing: Spacecraft Major Cycle (1 sec) 14

HinzeSPP/FIELDS iCDR – TDS FSW Timing: FIELDS Major Cycle (~0.874 sec), DCB-TDS 15

HinzeSPP/FIELDS iCDR – TDS FSW Timing: FIELDS Major Cycle (~0.874 sec), TDS-MAG 16

HinzeSPP/FIELDS iCDR – TDS FSW Resource Margins 17 ResourceAvailableCurrent Estimate Current % Margin Estimate at PDR % Margin at PDR Boot PROM 32kB19.9kB38%27.5kB14% EEPROM256kB (x2)84kB66%115kB55% RAM1024kB494kB52%527kB48% CPU100%37%63%10%90%

HinzeSPP/FIELDS iCDR – TDS FSW Software Verification and Testing Method: –Test environment will be determined based on test type. –Our GSE developer will implement scripted test suites. –Our Software QA lead will run test suites and document results. –Scripted test suites will test versus level 5 verification matrix requirements. Tests: –Unit Tests: (ongoing) Environment: GSEOS + FIG + FIELDS2 EM hardware Performed in-situ, with other modules quiesced as much as is feasible. –Integration Testing: (after major features complete) Environment: GSEOS + FIELDS1 EM + FIELDS2 EM Exercises as much of the system as possible, maximizing interaction effects. –Long-Duration Stress Testing: (after all requirements satisfied) Environment: GSEOS + FIELDS1 EM/FM + FIELDS2 EM/FM Day-in-the-life scenarios; double nominal TC/TM load –Acceptance Testing: (after Gold Master Candidate identified) Environment: GSEOS + FIELDS1 FM + FIELDS2 FM Comprehensive performance test of all requirements on the level 5 verification matrix. 18

HinzeSPP/FIELDS iCDR – TDS FSW Status of Engineering Model Software Substantially Completed: (currently running 24x7, stress-test load) –System Manager (interrupts, “tasks”, software timers, etc) –Spacecraft Interface –DCB Interface –Real-Time Clock Manager –Telemetry Manager –Command Manager –TDS Acquisition –MAGi Interface –SWEAP Interface –Housekeeping ADC Controller –Instrument Status Reporting Ongoing Development: –AEB driver (adapted from DCB’s FSW) –LNPS driver (adapted from DCB’s FSW) –MAG power cycle choreography (adapted from DCB’s FSW) –Coordinated Burst Signal –TDS Event quality calculation –TDS Event telemetry bit rate control –FIELDS2/TDS consolidated system-level housekeeping packet –Performance counters (fine-grained CPU utilization, ISR duration,...) 19

HinzeSPP/FIELDS iCDR – TDS FSW Development Environment Tools and Techniques –Highly-orthogonal C code modules –GCC cross-compiler suite –Heritage code from STEREO/WAVES FSW –Shared code with FIELDS DCB FSW –Mac OS X (unix) laptops & workstations GSE –PC laptop, running GSEOS –Spacecraft Emulator –DCB, MAG, SWEAP Emulator (FIG) Support for I&T and Flight Operations –We currently have the capability for rapid development, building FSW images on development laptops and uploading them to EM EEPROM in a couple of minutes. –We have plans for the deployment of frozen stable development environments at both UCB and UMN. This will ensure the long-term continuance of our capabilities to develop and test new flight software after launch, performing the bulk of development and testing UMN, while performing final acceptance testing at UCB. 20

HinzeSPP/FIELDS iCDR – TDS FSW Conclusion We have no outstanding issues. Design of TDS FSW meets all requirements. TDS FSW implementation hosted on ETU currently successfully performs most major functions 24x7. –TDS events captured from analog stimuli; TM delivered live via either Spacecraft or DCB interface (DCB by default) –MAGi survey data gathered from MAGi; TM delivered live via either Spacecraft or DCB interface (Spacecraft by default) –TMMGR concurrently routing TM to both Spacecraft and DCB interfaces –Commands received via either Spacecraft or DCB interface routed to appropriate destinations –Longest test run to date: 20 days. TDS FSW is ready to move into FM development. 21

HinzeSPP/FIELDS iCDR – TDS FSW Backup Slides 22

HinzeSPP/FIELDS iCDR – TDS FSW Peer Review Recommendations 23 ActionNameDescriptionResponseClosed? FSW-01Software Timing Errors Consider adding error flags to violations of timing constraints for interrupts and tasks (as well as metrics about typical/max values) We will add performance monitoring functionality to our system code after all major operational modules are fleshed out. y FSW-02Stay in boot Verify with APL the 'stay in boot' command sequence timing is consistent with what the spacecraft can do (can it send a command withing some time window)? We will resolve this boot-time operational protocol in the near term. y FSW-03PROM Size Margin Improve margin numbers for boot code. Either need 'actual' size or more margin per Gold Rules at CDR (20% for PROM). Boot code is currently 18kB and performs most functions. y FSW-04FIFO interrupts “Low-water” and “high-water” interrupts : priorities should be specified and command input queue priority should be fixed. This is already the case.y FSW-05AHB mastersDoes the AHB have a single or dual masters (if DMA controller is included) ? Current indications are that DMA is not required; as such, the only AHB bus master is the CPU. y FSW-06Cache Is cache enabled ? If so, which algorithm is selected (e.g. LRU) ? Are cache flushes allowed ? Both instruction and data caches are enabled, using the random replacement algorithm. Cache flushes are performed through the use of a privleged instruction. y FSW-07Register File Error Detection Error detection in register file for LEON3FT may be dependent on task switching. If so, what frequencies are tasks run ? Is scheduling of tasks programmable ? We will use hardened FPGA-fabric TMR registers for the CPU register file after migration from LEON3 to LEON3FT. Furthermore, as a result of normal operations, we will wrap through at least the full eight windows of the register file at least once per second. (Note that we do not use an FPU, so we have no FP registers.) y

HinzeSPP/FIELDS iCDR – TDS FSW FIELDS Flight Software Level 4 Requirements, Part 1 24

HinzeSPP/FIELDS iCDR – TDS FSW FIELDS Flight Software Level 4 Requirements, Part 2 25

HinzeSPP/FIELDS iCDR – TDS FSW TDS Flight Software Level 4 Requirements 26

HinzeSPP/FIELDS iCDR – TDS FSW System Manager Subsystem Level 5 Requirements 27

HinzeSPP/FIELDS iCDR – TDS FSW Spacecraft Interface Subsystem Level 5 Requirements 28

HinzeSPP/FIELDS iCDR – TDS FSW DCB Interface Subsystem Level 5 Requirements 29

HinzeSPP/FIELDS iCDR – TDS FSW MAGi Interface Subsystem Level 5 Requirements 30

HinzeSPP/FIELDS iCDR – TDS FSW SWEAP Interface Subsystem Level 5 Requirements 31

HinzeSPP/FIELDS iCDR – TDS FSW AEB2 Interface Subsystem Level 5 Requirements 32

HinzeSPP/FIELDS iCDR – TDS FSW LNPS2 Interface Subsystem Level 5 Requirements 33

HinzeSPP/FIELDS iCDR – TDS FSW TDS Acquisition Subsystem Level 5 Requirements 34

HinzeSPP/FIELDS iCDR – TDS FSW Housekeeping Subsystem Level 5 Requirements 35

HinzeSPP/FIELDS iCDR – TDS FSW Instrument Status Reporting Subsystem Level 5 Requirements 36

HinzeSPP/FIELDS iCDR – TDS FSW Telemetry Manager Subsystem Level 5 Requirements 37

HinzeSPP/FIELDS iCDR – TDS FSW Command Manager Subsystem Level 5 Requirements 38

HinzeSPP/FIELDS iCDR – TDS FSW Real-Time Clock Subsystem Level 5 Requirements 39