1. IES Flight Software J. Hanley / P. Mokashi May 29, 2013

2. 2 Outline Overview of the Flight Software (FSW) Existing Features  Data Acquisition  Autorecovery Special Features for Commissioning Proposed Modifications Anomalies

3. Overview of the FSW Runs on the Harris RTX-2010; a 16-bit microprocessor Written primarily in the C programming language, with some RTX-2010 assembly language (Forth-like)  Forth is a stack-based programming language: think Hewlett-Packard Reverse Polish Notation (RPN) calculator 3

4. Two code images reside within IES Boot Code  Resides in Programmable Read-Only Memory (PROM)  PROMs are 8 kB x 8-bit parts; two physical parts to get 16-bit wide data  Cannot be modified in flight Science Code (current version is 1.5)  Resides in Electrically Eraseable PROM (EEPROM)  EEPROMs are 128 kB x 8-bit parts; two physical parts to get 16-bit wide data  Note that tables are also stored in EEPROM  Can be modified in flight (code and tables) 4

5. Physical Location of FSW and Tables (1/2) 5

6. Physical Location of FSW and Tables (2/2) 6

7. Boot (PROM) Code Manages IES right after power up Two modes (shown) Provides basic functions such as:  Receipt of telecommands and transmission of engineering telemetry such as monitors  Memory checks, memory load and dump Automatically transitions to Science code after approx 70 seconds 7

8. Science (EEPROM) code The real workhorse for IES science acquisition, processing and telemetering Three modes (shown) Boot code transitions to science code after approx 70 seconds Actual science data acquired during HVSCI mode 8

9. Existing Features in the Science Code Receive telecommands and messages as input; engineering and science telemetry along with event messages as output  These are defined in the Rosetta Database (RSDB) Controls all HVPS, including sweeping ESAs and DEFs Has internal command sequences for making operations simpler Has science tables to define ESA/DEF sweeps, science acquisition, processing and telemetering Has means for recovering from faults as signaled by other instruments (ROSINA, GIADA), high flux rates 9

10. Science Data Acquisition Data acquisition controlled by a series of tables  ESA sweep – table that defines the 128-step energy sweep  DEF sweep – table that defines the 2048-step (128 energies x 16 deflection angle)  Acquisition tables Acquisition tables determine the cadence of the overall sweep and how data are processed 10

11. Acquisition Timing Overview 11

12. Acquisition Timing Detail 12

13. Autorecovery (1/2) Added to FSW in anticipation of high count rates, high pressure and high dust counts in the comet environment (Service19) The goal is to keep IES on as much as possible with minimal ground intervention If potential danger is detected, IES safes itself, but will autonomously recover.  Pressure from ROSINA  Pressure Gradient from ROSINA  Dust Count from GIADA  High ION or ELC counts The behavior is based on reconfigurable autorecovery table parameters such as trip points and recovery times (state machine at right) This has been tested in the FSW lab and on the EQM 13

14. Autorecovery (2/2) Current settings (examples)  Thresholds for number of counts per 2.5 ms = 1000 (equivalent to 400 kHz)  Number of consecutive 2.5ms windows that threshold was tripped prior to safing = 5  Rosina safe and recover threshold = 1e-6; 5e-7 (units defined in EIDA, section 2.8.3.9)  Giada dust particle density = 150  Different wait and recovery times in seconds shown as “Countdown” values in the table at right 14

15. Special Feature for Commissioning During (re-)commissioning, it is required that we get quick feedback of the MCP’s behavior when they are first turned back on, primarily using ion and electron counts. In IES, ion and electron counts are normally telemetered via science packets but these have a lower priority than engineering packets so are delayed in receipt relative to engineering packets A temporary, special feature patch will be uploaded to IES for quickly telemetering total ion and electron counts every 32 seconds via event messages This feature was used during the initial commissioning activities of 2004. 15

16. Proposed Modifications Science code: Only one modification is proposed for the FSW: to sample the ESA and DEF A/D monitors at a different cadence so that the entire sweep can be seen in housekeeping telemetry Tables Macros 16

17. Link Reset Anomaly On September 28, 2009, during PC10, new tables were uploaded to EEPROM Load was successful, however, the last (3rd out of 3) memory dump command after the load generated a burst of 64 “IES PIU Link Error” event messages from IES This caused PIU to go into a “loop”  Repeated transmission of IES memory dump instead of IES science by PIU  IES rebooted twice in that period but no change in PIU behavior Resolved upon a PIU reboot 17

18. Event Message Burst and Concerns Event Message Burst  IES couldn’t deliver data to PIU due to communications link problem  IES tried to reset the link and queued up error event messages  When the link was reestablished, the event messages were transmitted in a burst to PIU and then from PIU to the spacecraft Operational and safety concerns  RPC Science PIU stopped transmitting science from IES to the spacecraft and repeatedly transmitted the previous memory dump, even when IES was turned off  Spacecraft safety Concern expressed by RMOC about the ability of the spacecraft CDH to handle the burst ALICE event messages have safed the EQM VEX which has the same fundamental spacecraft CDH system has safed in flight due to a burst of event messages 18

19. Risk Mitigation Strategy Limit the number of event messages in a queue to 10 EEPROM mode  One time change in the EEPROM code  Successfully tested on the EQM by inducing link resets  Software change implemented in PC12 PROM mode  30 seconds after each boot up into PROM mode entry, poke the SRAM memory to change two variables  Successfully tested on the EQM by inducing link resets  Used in flight during PC12 & PC13 Table top review on Oct 5, 2010 with JPL agreed with the assessment 19

20. Link Reset Incidents 2 to 4 PC12 EQM Testing PC12 Flight Execution PC13 Flight Execution (twice) For all of the above  Number of event messages successfully limited to 10  PIU did not go into a loop and no reboot required  No impact on science or remaining memory dumps  PROM Risk mitigation strategy was successful 20

21. Link Reset Anomaly Conclusion Link resets occurring on a fairly consistent basis during memory dumps Unable to recreate the problem on the EQM Risk mitigation strategy to limit them to 10 has been working well Root cause unknown Should we consider eliminating memory dumps and rely on the page checksums generated after boot up. 21