Chapter 11: Onboard Systems
Page One | Page Two | Page Three | Page Four
Upon completion of this chapter you will be able to describe the role of typical spacecraft subsystems: structural, thermal, mechanical devices, data handling, attitude and articulation control, telecommunications, electrical power and distribution, and propulsion. You will be able to list advanced technologies being considered for use on future spacecraft.
One might expect a system to comprise subsystems, and subsystems to contain assemblies as in the ideal hierarchy shown in the system hierarchy illustration. For example, a spacecraft, also called a flight system (to differentiate it from the ground system), might contain a dozen subsystems including an attitude control subsystem, which itself might contain dozens of assemblies including for example three or four reaction wheel assemblies, celestial reference assemblies, and inertial reference assemblies, etc.
But all too often system and subsystem are used arbitrarily. In some usage a single system may comprise subsystems both aboard a spacecraft and on the ground, for example a telecommunications system with transmitter and receiver subsystems on both spacecraft and Earth.
In other usage, as if to ensure permanent confusion of terms, frequently an instrument is named a subsystem, but it may contain lens systems, and so on.
Individual spacecraft can be very different from one another, and they can display different approaches to solving similar problems. Newer spacecraft are smaller and less massive than their predecessors, yet there are common functions carried out by spacecraft regardless how massive or miniature.
Not all classifications of spacecraft have the same subsystems, though. An atmospheric probe spacecraft, for example, may lack propulsion and attitude control subsystems entirely. The discussions in this chapter mainly address subsystems that satisfy the requirements typical of complex flyby- or orbiter-class spacecraft, and in this way cover most simpler classes of spacecraft as well.
The Structure subsystem provides overall mechanical integrity of the spacecraft. It must ensure that all spacecraft components are supported, and that they can withstand handling and launch loads as well as flight in freefall and during operation of propulsive components.
The spacecraft bus is a major part of a spacecraft's structure subsystem. It provides a place to attach components internally and externally, and to house delicate modules requiring the protection of an environment with a measure of thermal and mechanical stability. It can provide an integral card chassis for supporting circuit boards of radio equipment, data recorders, and computers. It supports gyroscopes, reaction wheels, cables, plumbing, and many other components.
The bus also influences the basic geometry of the spacecraft, and it provides the attachment points for other parts of the structure subsystem such as booms, antennas, and scan platforms. It also provides points that allow holding and moving the spacecraft during construction, testing, transportation, and launch.
A magnetometer boom appendage is typically the longest component of the structure subsystem on a spacecraft, although since it is deployable, it may fall under the aegis of the mechanical devices subsystem discussed below. Since magnetometers (discussed in Chapter 12) are sensitive to electric currents near the spacecraft bus, they are placed at the greatest practical distance from them on a boom.
The Voyager magnetometers are mounted 6 and 13 meters out the boom from the spacecraft bus. At launch, the mag boom, constructed of thin, non-metallic rods, is typically collapsed very compactly into a protective canister. Once deployed in flight, it cannot be retracted.
Some of today's science instruments, or other subsystems, may easily have more embedded computing power than an entire Voyager spacecraft has. But there is usually one computer identified as the "spacecraft central" computer responsible for overall management of a spacecraft's activity. It is typically the same one which maintains timing, interprets commands from Earth, collects, processes, and formats the telemetry data to be returned to Earth, and manages high-level fault protection and safing routines. On some spacecraft, this computer is referred to as the command and data subsystem (CDS). For convenience, that term will be used here, recognizing that other names may apply to similar subsystems or sets of subsystems which accomplish some or all of the same tasks.
A portion of the CDS memory is managed as storage space for command sequences and programs uplinked from Earth that control the spacecraft's activities over a period of time. After use, these sequences and programs can be repeatedly overwritten with new ones to maintain optimum control of the spacecraft. These sequence loads are typically created by the project's planning and sequencing teams by negotiating and incorporating inputs from the spacecraft team, the science teams, and others.
As mentioned in Chapter 2, the spacecraft clock (SCLK, pronounced "sklock") is typically a counter maintained by CDS. It meters the passing of time during the life of the spacecraft. Nearly all activity within the spacecraft systems is regulated by the SCLK (an exception is real-time commands). The spacecraft clock may be very simple, incrementing every second and bumping its value up by one, or it may be more complex, with several main and subordinate fields that can track and control activity at multiple granularities. The SCLK on the Ulysses spacecraft, for instance, was designed to increment its single field by one count every two seconds. The Galileo and Magellan clocks, on the other hand, were designed as four fields of increasing resolution. Many types of commands uplinked to the spacecraft are set to begin execution at specific SCLK counts. In telemetry, SCLK counts that indicate data creation time mark engineering and science data whether it goes to the onboard storage device, or directly onto the downlink. The presence of SCLK in telemetry facilitates processing, storage, retrieval, distribution, and analysis.
EVENT DESCRIPTION | SCET | S/C CLOCK |
EXECUTE BOTH CAMERAS COMMAND ID: 450 | 335 13:28:45 | 1354282800:204 |
EXECUTE UV IMAGING SPECTROMETER OBSERVATION | 335 13:28:45 | 1354282800:207 |
Excerpt from Cassini Sequence of Events during Jupiter phase December 2000. SCLK values for two commands appears next to their equivalent SCET times. | ||
Telemetry data from science instruments and engineering subsystems is picked up by the CDS, where it is assembled into packages appropriate to the telemetry frame or packet scheme in use (for example CCSDS). If the spacecraft is downlinking data in real time, the packet or frame may be sent to the spacecraft's transmitter. Otherwise, telemetry may be written to a mass storage device until transmission is feasible.
Spacecraft engineering or health data is composed of a wide range of measurements, from switch positions and subsystem states to voltages, temperatures, and pressures. Thousands of measurements are collected and inserted into the telemetry stream.
CDS's capability to alter the telemetry format and content accommodates various mission phases or downlink rates, as well as to enable diagnosis of anomalies. In the case of an anomaly, it may be necessary to temporarily terminate the collection of science data and to return only an enriched or specialized stream of engineering and housekeeping data.
Some data processing may take place within the CDS before science and engineering data are stored or transmitted. CDS may apply data compression methods to reduce the number of bits to be transmitted, and apply one or more encoding schemes to reduce data loss as described in Chapter 10.
It is rare for a mission to be provided the constant support of real-time tracking. Also, a spacecraft may spend time with its antenna off Earth-point while gathering data. For these reasons, spacecraft data handling subsystems are usually provided with one or more data storage devices such as tape recorders, or the solid-state equivalent of tape recorders which maintain large quantities of data in banks of memory, for example RAM or FLASH. The storage devices can be commanded to play out their stored data for downlink when DSN resources are available, and then to overwrite the old data with new.
A robotic space flight system must have the intelligence and autonomy to monitor and control itself to some degree throughout its useful life at a great distance from Earth. Though ground teams also monitor and control the spacecraft, light time physically prohibits the ability to respond immediately to anomalies on the spacecraft. Tightly constrained tracking schedules also limit the ability to detect problems and respond. Fault protection (FP) algorithms, which normally run in one or more of the spacecraft's subsystems, therefore must ensure the ability to mitigate the impact of a mishap, and to re-establish the spacecraft's ability to contact Earth if an anomaly has caused an interruption in communications. A spacecraft may have many different FP algorithms running simultaneously with the ability to request CDS to take action.
Safing is one response that FP routines can request. Safing involves shutting down or reconfiguring components to prevent damage either from within or from the external environment. Another internal response may be an automated, methodical search to re-establish Earth-pointing and regain communications. This routine may or may not be a normal part of safing. While entrance into safing may temporarily disrupt ongoing science observations and require the flight team to perform additional work, safing provides strong and reliable protection for the spacecraft and its mission.
Usually a minimal set of safing-like instructions is also installed in ROM (it was contained in 1 kbyte on Magellan) where it can hide from even the worst imaginable scenarios of runaway program execution or power outage. More intricate safing routines (also called "contingency modes") and FP routines typically reside in CDS RAM, as well as parameters for use by the ROM code, where they can be updated as necessary during the life of the mission.
One example of a fault-protection routine is the Command-Loss Timer, CLT. This is a software timer running in CDS that is reset to a predetermined value, for example a week, every time the spacecraft receives a command from Earth. If the timer decrements all the way to zero, the assumption is that the spacecraft has experienced a failure in its receiver or other components in the command string. The CLT fault protection response issues commands for actions such as swapping to redundant hardware in an attempt to re-establish the ability to receive commands.
