SATFAULT at 40

In the late seventies and early eighties NASA was busy with the STS program envisioned in February 1969, by a Space Task Group, appointed by President Richard Nixon and headed by Vice President Spiro Agnew to recommend human space projects beyond Apollo. NASA appropriated the name for its Space Shuttle Program, the only component of the proposal to survive Congressional funding approval.

The purpose of the system was two-fold:

• to reduce the cost of spaceflight by replacing the existing method of launching capsules on expendable rockets with reusable spacecraft; and
• to support ambitious follow-on programs including permanent orbiting space stations around Earth and the Moon, and a human landing mission to Mars.

As a result of funding constraints, Shuttle was significantly scaled back from its planned degree of reusability. The overall program scheduled was also delayed. The Shuttle first flew in 1981, and was retired in 2011.

In the early eighties, NASA was actively involved in seeking industrial and financial support for the budget-constrained Shuttle program. As reviewed at the Space Construction Conference, December 1986 by G.M. Levin:

In October 1983 the Office of Space Flight at NASA Headquarters established a new program office to: undertake a series of developments which would support program objectives of the Office of Space Flight; give younger NASA engineers "hands on" experience with the development of flight hardware; lead to new business for the Space Transportation System (STS); and stimulate present customers of the STS towards more efficient use of the unique capabilities of the space shuttle. The Flight Demonstration Program was initiated by undertaking the development of six demonstrations. The first of these demonstrations, the Orbital Refueling System was successfully flown on STS 41-C on August 29, 1984. The second and third Flight Demonstrations, EASE and ACCESS, were performed successfully on STS 61-B on November 29 and December l, 1985.

As detailed in this prospective report, other planned demonstrations were a voice control system for the shuttle's closed circuit television system, an infrared intercommunications system, a plasma motor/generator proof of function demonstration, the implementation of a force feedback device on the shuttle's remote manipulator system, the transfer of super fluid helium on orbit, a laser docking sensor and a small expendable deployment system.

Typical areas of emphasis for Flight Demonstrations were:

• Space Construction/Large Space Structure
• Expendable Resupply
• System Improvement
• Satellite Servicing
• Tether Applications

Note that some, if not all, of these broad objectives are still valid and of interest today even though undergoing a changing field and different business model. The Orbital Refueling System (ORS) is particularly significant here.

The Orbital Refueling System was the first Flight Demonstrations Program sponsored by the Office of Space Flight. develop and demonstrate the equipment and procedures for a hydrazine fuel transfer system; to develop and demonstrate the tools needed to interface with existing satellites to accomplish fuel transfer; and to developand evaluate specific procedures to refuel present satellites of the Landsat type.

The ORS consisted of five major categories: the structural subsystem; the fluid subsystem; the avionics subsystem; the thermal control subsystem; and the EVA tools. The ORS tankage unit (with its fuel tanks, piping, valving, heaters, and avionics) was mounted on a Mission Peculiar Experiment Support Structure (MPESS) in the cargo bay of the orbiter. In the demonstration configuration the ORS was capable of multiple transfers of approximately 200 pounds of hydrazine fuel. The ORS could be modified to deliver approximately 500pounds of fuel to an orbiting satellite by a fuel line connected with a hydrazine servicing interface toolset.The ORS was interfaced to the Orbiter general purpose computer,and analog channels were available for data monitoring. Control of the ORS fuel transfer was from the Aft Flight Deck. During the ORS demonstration fuel was transferred througha fixed propellant bypass as well as through a fuel line connection established by an EVA crew member.

The EVA tools were the unique hardware items required to: permit access to the manual fill valve; provide redundant seals for crew safety; and control fluid flow to the satellite.The toolset consisted of seven items designed for satellite engagement,valve opening,and valve closing. The fuel transfer unit and valve,once engaged,became permanently attached to the satellite, thus providing a standard interface for refueling.

The Orbital Refueling System (ORS), managed by NASA’s Johnson Space Center in Houston, while not directly an Earth observation payload the primary one in the STS-41G flight, assessed the feasibility of on-orbit refueling of the Landsat-4 remote sensing satellite, then under consideration as a mission in 1987, as well as Department of Defense satellites not designed for on-orbit refueling. In the demonstration, the astronauts remotely controlled the transfer of hydrazine, a highly toxic fuel, between two tanks mounted in the payload bay. During a spacewalk, two crew members simulated connecting the refueling system to a satellite and later tested the connection with another remotely controlled fuel transfer.

During the mission components of Orbital Refueling System were connected in an EVA by Kathryn Sullivan and David Leestma on October 11, 1984 (3h 29m), demonstrating that it is possible to refuel satellites in orbit. The Orbital Refueling System experiment was a demonstration of Shuttle-human-tended capabilities to refuel already orbiting satellites once their self-contained thruster systems have depleted fuel reserves. This demonstration was a precursor to actual Shuttle refueling missions for satellites.

For the final fuel transfer stage, mission specialists David Leestma and Kathryn Sullivan donned their spacesuits and proceed to the aft end of the payload bay where the ORS equipment was mounted on an MPESS (Mission Peculiar Experiment Support Structure) along with the Large Format Camera. There the crewmembers opened the tool kit and removed the hydrazine servicing tool - which was already be hooked up to the fuel supply tank. The crewmembers connected it to the ground fill panel of a simulated satellite panel, thus completing the fuel supply link. After pressure checking the hookup, the crewmembers returned to the cabin.

The actual transfer of the hydrazine, which is a very toxic and corrosive material, was controlled from the aft flight deck experiment control panels. The ORS was equipped with sensors which provide pressure and temperature values and switch and valve positions.

One of the important findings of ORS was the heating of pressurant gas behind the bladder. It turned out the transfer rate was limited by a desire to keep temperatures from reaching the decomposition temperature of hydrazine (200 F). The transfer process was controlled to limit ullage gas temperatures to 150 F. Kauffam 37 gives a detailed analysis and post flight reconciliation to the test data. Unfortunately the ORS instrumentation was limited to one temperature sensor for each tank mounted on the sidewall external to the tank so actual ullage gas temperatures are unknown. (See review of the later state of the art in Technologies for Refueling Spacecraft On-Orbit, by David J. Chato published in 2000.)

As for the Landsat-4, which orbital refueling was envisioned by the OSF, it was an experimental earth resources monitoring system with the new powerful remote-sensing capabilities of the thematic mapper (TM), and it provided a transition for both foreign and domestic users from the multispectral scanner (MSS) data to the higher resolution and data rate of the TM. It had a complete end-to-end highly automated data system, which was designed to be a new generation system, and was a major step forward in global remote-sensing applications. The Landsat-4 mission consisted of an orbiting satellite (flight segment) with the necessary wideband data links and support systems, and a ground segment. The Landsat 4 flight segment consisted of two major systems:

• the instrument module, containing the instruments together with the mission unique subsystems, such as the solar array and drive, the TDRS antenna, the wide-band module (WBM), and the global positioning system (GPS);
• and the multimission modular spacecraft (MMS) that contained the modularized and standardized power, propulsion, attitude control, and communications and data handling subsystems.

The flight segment was designed with 3 years nominal lifetime in orbit and could be extended through in-orbit replacement capability when the Space Shuttle became operational. The spacecraft was placed into an orbit having a descending node equatorial crossing between 9:30 and 10:00 a.m. local time. The spacecraft and attendant sensors were operated through the GSTDN stations before the Tracking And Data Relay Satellite System (TDRSS) was available. Landsat 4 was decommissioned on 15 June 2001.

As recently as April 2024, USGS reviewed the status of the current Landsat-7 to Landsat-9 missions and gave indication that Landsat-7 (1999-2024), recently lowered into lower storage, orbit was awaiting OSAM-1 satellite rendezvous and refueling (est. 2026).

And as this is written China’s satellites may have pulled off world’s first in-orbit fuel refill, beating US turning ORS up to a power fight for geopolitical dominance.

The original knowledge-base development was inspired by Boy's work at NASA Ames on Fault Diagnosis In Orbital Refueling Operations, a paper presented at the Space Station Human Factors Research Review, NASA Ames Research Center, December 1985. Thus clearly positioned within the field of Human-Computer Interaction (HCI) research, the expert system approach pionneered here was a stepping stone to later intelligent assistant systems research:

Usually, operation manuals are provided for helping astronauts during space operations. These manuals include normal and malfunction procedures. Transferring operation manual knowledge into a computerized form is not a trivial task. This knowledge is generally written by designers or operation engineers, and is often quite different from the user logic. The latter is usually a "compiled" version of the former. Experiments are in progress to assess the user logic. HORSES (Human - Orbital Refueling System - Expert System) is an attempt to include both of these logics in the same tool. It is designed to assist astronauts during monitoring and diagnosis tasks. Basically, HORSES includes a situation recognition level coupled to an analytical diagnoser, and a meta-level working on both of the previous levels. HORSES is a good tool for modeling task models and is also more broadly useful for knowledge design.

So the topic is the study of Human-Computer-System tri-partite interactions in "normal" and "abnormal" situations. The "system" being in this case the ORS.

The so-called User's Guide Expert System drew heavily on modelling approaches and human factors studies to address its objectives of providing an optimal level of automation and levelled explanations all within an easy-to-use interface. It heralded the "seminal HCI" phase proposed by Joelle Coutaz in ¹.

On the Macintosh, the transposition of a simplified version of the HORSES expert system, used abundant graphics and images to serve the above objectives.

NASA procedure manuals were transposed into expert system's rules used both for diagnosis/situation assessment plus remedies and for explanations.

Keeping in line with the methodology of the original HORSES expert system, the much simplified SATFAULT usual session ran through three distinct phases:

• (Simulated) data capture and alarm levels checks: signs are data points like pressure or temperature in hydrazine tanks, hypothesis are categories of alarms to keep track of triggering events in later phases.
• Immediate remedies, so called "actions", to bring back data indicators to nominal values. Signs are the alarm types–hypotheses in the previous phase–and hypothesis are the action reference, as defined in the NASA manual. The RHS of these rules change the data signs back to nominal values when triggered.
• Diagnosis rules proper, which based on the result of the immediate remedy actions and the alarm type from the first phase offer explanation and assessment of the event/situation.

Such a structure, while simplistic compared to the original, nonetheless played well to the competitive features of the engine. Starting a session by volunteering some data points outside their safe zone for some tanks, for instance, would trigger forward chaining, processing and checking the data, possibly with additional interactive questions or graphics/image instructions, through the 3 phases above to produce a complete, explainable trace of reasoning from data to diagnosis. Suggesting a diagnostic hypothesis, on the other hand (usually 'EXC_PRISEV10' or 'EXC_PRISEV16'), would start backward chaining instead and drive the optimal collection of data points, questioning the user or retrieving data from outside sources like spreadsheet files (or executable third-party programs), to produce a comprehensive situation assessment within the initial diagnosis to explore.

RULE tank_pressure_check_1
IF
pressure_P1 nxp@ 370 >
THEN ALARM_TANK_WAS_HIGH

RULE tank_pressure_check_2
IF
pressure_P2 nxp@ 370 >
THEN ALARM_TANK_WAS_HIGH

RULE tank_pressure_check_3
IF
pressure_P3 nxp@ 370 >
THEN ALARM_TANK_WAS_HIGH

RULE tank_pressure_check_4
IF
pressure_P4 nxp@ 370 >
THEN ALARM_TANK_WAS_HIGH

RULE tank_pressure_check_5
IF
pressure_P1 nxp@ pressure_P3 nxp@ =
THEN TANKS_EQUAL

RULE tank_pressure_check_6
IF
pressure_P2 nxp@ pressure_P4 nxp@ =
THEN TANKS_EQUAL

RULE tank_pressure_check_5
IF
pressure_P1 nxp@ 370 >
THEN ALERT

RULE tank_pressure_check_6
IF
pressure_P2 nxp@ 370 >
THEN ALERT

RULE tank_pressure_check_7
IF
pressure_P1 nxp@ 20 <
THEN ALERT

RULE tank_pressure_check_8
IF
pressure_P2 nxp@ 20 <
THEN ALERT

RULE tank_pressure_check_9
IF
pressure_out_P3 nxp@ 370 >
THEN ALERT

RULE tank_pressure_check_10
IF
pressure_out_P3 nxp@ 370 >
THEN ALERT

RULE tank_pressure_check_11
IF
pressure_out_P3 nxp@ 20 <
THEN ALERT

RULE tank_pressure_check_12
IF
pressure_out_P4 nxp@ 20 <
THEN ALERT

RULE tank_pressure_check_13
IF
pressure_P1 nxp@ 370 >
THEN ALARM_TANK_WAS_P1_OR_P2

RULE tank_pressure_check_14
IF
pressure_P2 nxp@ 370 >
THEN ALARM_TANK_WAS_P1_OR_P2

RULE tank_pressure_check_15
IF
pressure_P1 nxp@ 20 <
THEN ALARM_TANK_WAS_P1_OR_P2

RULE tank_pressure_check_16
IF
pressure_P2 nxp@ 20 <
THEN ALARM_TANK_WAS_P1_OR_P2

RULE tank_pressure_check_17
IF
pressure_P1 nxp@ 370 >
THEN TANK_P1_OR_P2_WAS_HIGH

RULE tank_pressure_check_18
IF
pressure_P2 nxp@ 370 >
THEN TANK_P1_OR_P2_WAS_HIGH

RULE nil
IF
pressure_out_P3 nxp@ 20 <
THEN TANKS_OUT_PRESSURE_LOW

RULE data_capture_2
IF
pressure_out_P4 nxp@ 20 <
THEN TANKS_OUT_PRESSURE_LOW

RULE nil
IF
NO TANKS_OUT_PRESSURE_LOW
pressure_out_P3 nxp@ pressure_out_P4 nxp@ =
THEN THERMAL_TRANSIENT_CONDITION

RULE action_remedy_1
IF
$CRT_and_KDU nxp@ =s( AGREE)
$task nxp@ =s( FLUID_TRANSFER) invert
YES ALARM_TANK_WAS_P1_OR_P2
YES TANK_P1_OR_P2_WAS_HIGH
THEN ACTION_12
200 pressure_P1 nxp!
205 pressure_P2 nxp!
300 pressure_P3 nxp!
200 pressure_P4 nxp!
200 pressure_out_P3 nxp!
205 pressure_out_P4 nxp!
200 pressure_P5 nxp!

RULE action_remedy_2
IF
$CRT_and_KDU nxp@ =s( AGREE)
$task nxp@ =s( FLUID_TRANSFER) invert
YES ALARM_TANK_WAS_P1_OR_P2
NO TANK_P1_OR_P2_WAS_HIGH
THEN ACTION_14
200 pressure_P1 nxp!
205 pressure_P2 nxp!
300 pressure_P3 nxp!
200 pressure_P4 nxp!
200 pressure_out_P3 nxp!
205 pressure_out_P4 nxp!

RULE action_remedy_3
IF
$CRT_and_KDU nxp@ =s( AGREE)
$task nxp@ =s( FLUID_TRANSFER) invert
YES ALARM_TANK_WAS_P1_OR_P2
pressure_out_P3 nxp@ pressure_out_P4 nxp@ <>
THEN ACTION_19
200 pressure_out_P3 nxp!
200 pressure_out_P4 nxp!

RULE action_remedy_4
IF
$CRT_and_KDU nxp@ =s( AGREE)
$task nxp@ =s( FLUID_TRANSFER)
YES ALERT
THEN ACTION_4
200 pressure_P1 nxp!
205 pressure_P2 nxp!
300 pressure_P3 nxp!
200 pressure_P4 nxp!
200 pressure_out_P3 nxp!
205 pressure_out_P4 nxp!

RULE diagnostic_1
IF
$CRT_and_KDU nxp@ =s( AGREE)
$task nxp@ =s( FLUID_TRANSFER) invert
NO ALARM_TANK_WAS_P1_OR_P2
pressure_out_P3 nxp@ pressure_out_P4 nxp@ =
THEN DECREASE_DUE_TO_THERMAL_CONDITIONS

RULE diagnostic_2
IF
YES ACTION_12
pressure_P2 nxp@ pressure_P5 nxp@ =
THEN EXC_P_RISE_V10
s( img/DIAGNOS.PNG) nxp_show

RULE diagnostic_3
IF
YES ACTION_12
pressure_P1 nxp@ pressure_P5 nxp@ =
THEN EXC_P_RISE_V3

RULE diagnostic_4
IF
YES ACTION_4
YES TANKS_EQUAL
YES ALARM_TANK_WAS_HIGH
THEN EXC_P_RISE_V16

RULE diagnostic_5
IF
YES ACTION_19
NO TANKS_OUT_PRESSURE_LOW
pressure_out_P3 nxp@ pressure_out_P4 nxp@ =
THEN THERMAL_TRANSIENT_CONDITION

RULE diagnostic_6
IF
YES ACTION_19
YES TANKS_OUT_PRESSURE_LOW
pressure_out_P3 nxp@ pressure_out_P4 nxp@ =
THEN POSSIBLE_LEAK
s( img/POSSIBLE.PNG) nxp_show

RULE diagnostic_7
IF
YES ACTION_14
YES TANKS_EQUAL
THEN POSSIBLE_LEAK
s( img/CONTACT_.PNG) nxp_show

RULE diagnostic_8
IF
YES ACTION_4
YES TANKS_EQUAL
NO ALARM_TANK_WAS_HIGH
THEN POSSIBLE_LEAK
s( img/POSSIBLE.PNG) nxp_show

RULE diagnostic_9
IF
$CRT_and_KDU nxp@ =s( DISAGREE)
YES ALERT
THEN MDM_ANALOG_INPUT_PARAMETER_LOSS

RULE diagnostic_10
IF
Yes ACTION_14
NO TANKS_EQUAL
THEN XDRC_FAILURE_OR_BIAS

RULE diagnostic_10
IF
YES ACTION_4
NO TANKS_EQUAL
THEN XDRC_FAILURE_OR_BIAS

RULE diagnostic_11
IF
YES ACTION_19
pressure_out_P3 nxp@ pressure_out_P4 nxp@ <>
THEN XDRC_FAILURE_OR_BIAS

RULE diagnostic_12
IF
YES ACTION_12
pressure_P1 nxp@ pressure_P5 nxp@ <>
pressure_P2 nxp@ pressure_P5 nxp@ <>
THEN XDRC_FAILURE_OR_BIAS