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

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

Embed Size (px)

Citation preview

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

IESFlight Software

J. Hanley / P. Mokashi

May 29, 2013

Page 2: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

2

Outline

Overview of the Flight Software (FSW) Existing Features

Data Acquisition Autorecovery

Special Features for Commissioning Proposed Modifications Anomalies

Page 3: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 4: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 5: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

Physical Location of FSW and Tables (1/2)

5

Page 6: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

Physical Location of FSW and Tables (2/2)

6

Page 7: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 8: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 9: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 10: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 11: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

Acquisition Timing Overview

11

Page 12: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

Acquisition Timing Detail

12

Page 13: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 14: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 15: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 16: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 17: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 18: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 19: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 20: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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

Page 21: IES Flight Software J. Hanley / P. Mokashi May 29, 2013

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