Reply to post: Sounds like OPS5/CLIPS or something

The New Horizons mission is long. The primary science goal can only be achieved after a 9.5­year journey culminating in a complex set of observations requiring significant time to transmit the data to Earth. During spacecraft development, much thought and energy were devoted to fault protection. This effort continues as the operations team evaluates in­flight mission performance. The fault protection architecture uses the redundancy of the spacecraft system (shown in Figure 3) if off­nominal operation is detected. Basic elements of fault protection are resident in redundant elements of the PDU (power distribution unit). The PDU monitors C&DH (command and data handling) bus traffic and will automatically switch to the alternate C&DH system if it detects that nominal C&DH processor activity of the controlling system has stopped. The major elements of fault protection are implemented by software running on the controlling C&DH processor. This software is the principal component of the autonomy subsystem. The software evaluates telemetry data in real time and, based on the evaluation, takes one or more of the following actions:

1. Execute a set of commands to correct a detected fault.

2. Generate a “beacon tone” to alert operators that an event on the spacecraft requiring attention has occurred.

3. Execute one of two “go safe chain” command sets, which puts the spacecraft into either an Earth Safe or a Sun Safe state, as described in section 4 (in the event of a critical fault).

The evaluation of onboard data is performed by a set of rules that check for data that exceed defined limits for a period of time. The time period (or persistence) of the exceedance varies from rule to rule. The persistence length minimizes the chance of a rule “firing” on noisy data, or on transient data that occur during a commanded change in spacecraft pointing. Processors (other than the C&DH processor, whose activity is monitored by the PDU circuitry) are monitored via a set of “heartbeat” rules that use a telemetry point to determine if the processor is stuck at either a “one” or a “zero” state. The persistence of each of these heartbeat rules is adjusted as appropriate to match the nominal operation of the specific processor. The autonomy software can also compute dynamic limits. For example, the autonomy system monitors the propulsion system for potential propellant leaks. The system monitors the propellant as a function of both the pressure and the temperature of the fuel tank using the ideal gas law to compute a current volume and compares it to an initial value set at a previous time appropriate to the phase or mode of spacecraft operation. At the time of launch, the autonomy system used 126 rules to determine the state of health of the spacecraft.

The command sets are organized as user­defined macros and stored in memory space defined by the C&DH system. The macros can include any allowable C&DH command and can be used to power units on or off, change spacecraft modes, enable or disable autonomy rules, or execute other macros. These macros can be executed by either real­time commands or by the autonomy subsystem. The macros can also be executed by time­tagged commands, allowing the commands in the macros to execute at a specific time in the future. The autonomy subsystem used 132 macros at launch. This set has been modified as the spacecraft position along its trajectory has changed and will continue to be modified as different phases of the mission occur, system performance changes, and operational experience dictates.