During STS-34, the Galileo spacecraft atop the inertial upper stage is deployed from Atlantis's payload bay.
Photo Credit: NASA (Click image for fullsize.)
On October 18, 1989, the Galileo spacecraft lifted free from the shuttle cargo bay. This step was the culmination of a development effort spanning eleven years and six major mission redesigns, and the first step on a long, rocky road to Jupiter. Galileo’s ultimate success is a tribute to the creativity, hard work, and determination of the many individuals and groups who wrestled with problems that easily could have doomed the mission.
Galileo was originally conceived in the late 1960s and received its first development funding in 1978. Planned for launch in 1982, its fate was inextricably intertwined with that of the Space Shuttle, then under development. Galileo was to be one of the first deep-space missions to launch on the shuttle; early slips in the availability and capability of that vehicle directly affected Galileo. They also influenced the design.
Early on, the decision was made to use new technologies previously used only in Earth-orbiting spacecraft. Dual-spin spacecraft design was new to interplanetary craft and new to the Jet Propulsion Laboratory (JPL). The dual-spin design has one section of the spacecraft fixed while the other part spins. Remote-sensing instruments (which desire a stable platform for imaging) could be mounted on the fixed section, and the fields and particles instruments (which desire a complete view of space in all directions) could be mounted on the rotating section. This was an innovative way to meet science requirements, but it presented many design hurdles.
The extended journey required design modifications, including adding several sun shields to project the spacecraft when flying to Venus for its first gravity assist.
The second decision was to use a deployable high-gain antenna (HGA). Constraints on the size of an antenna that could fit within the shuttle cargo bay and a desire to reduce mass—a constant Galileo design issue—led to this choice. But both decisions created difficulties on the way to Jupiter. By far the most serious was the failure of the HGA to deploy.
Political pressures dogged the initially underfunded project as costs began to rise. Slips in capability and delivery of the planned shuttle necessitated several major redesigns, including options to move Galileo to an expendable launch vehicle, and dual launch options, with the spacecraft and the Jupiter probe (an integral part of the mission concept) launched on separate vehicles. Launch slipped from 1982 to 1983, then 1985, and finally to 1986 before the shuttle was successfully completed and flown, and the Galileo design stabilized. The spacecraft and the launch team were at the cape when the Challenger accident occurred on January 28, 1986.
Eight days after its final encounter with Earth, the Galileo spacecraft looked back and captured this remarkable view of Earth and the moon.
Photo Credit: NASA (Click image for fullsize.)
Galileo was shipped back to JPL for storage and continued testing. Ultimately, the spacecraft would make three transcontinental trips, which may have contributed to the antenna failure. While awaiting the shuttle’s fate, the Galileo team investigated alternatives. As the Challenger investigation drew to a close and recommended changes were made to shuttle operations, it became clear that Galileo was at a crisis point. To get the energy for a direct trajectory to Jupiter, Galileo planned to use the Centaur liquid-propellant upper stage to boost it on its way after exiting the shuttle. After the Challenger accident, the decision was made to prohibit liquid-propellant upper stages, forcing Galileo to use the much-less-capable inertial upper stage, which used solid propellant. This booster was not capable of sending the spacecraft on a direct course to Jupiter, but by the clever use of gravity assists from Venus and from Earth, a viable mission could be flown, with a much longer flight time to Jupiter.
The extended journey required design modifications, including adding several sun shields to protect the spacecraft when flying to Venus for its first gravity assist. Operational changes were needed also to ensure the systems would survive. One was to delay the deployment of the HGA until the spacecraft was past the first Earth flyby.
The science team had to work long and hard to prioritize science goals, develop new science plans, and, in some cases, plan updates to onboard software in the instruments to increase data efficiency.
The HGA was made of a metalized mesh attached to a set of ribs, and looked very much like an inverted umbrella. The ribs were held to a central tower by a series of pins and retaining rods. Shortly after launch, the retaining rods were released, but the antenna was held in a closed configuration, protected under the sun shield when the spacecraft was within 1.0 astronomical unit of the sun—the distance from Earth to the sun.
During the first two and a half years of the mission, the operations team communicated with the spacecraft via the first low-gain antenna (LGA), and a second LGA added specifically for communications during the Earth-to-Venus-to-Earth leg of the trajectory. On April 11, 1991, shortly after the first Earth flyby, the operations team at JPL commanded the HGA to open. After twenty minutes of anxiously waiting for the fully deployed signal, the project team realized that something terribly wrong had occurred, and the HGA mission was in jeopardy. An investigation team was quickly organized to determine the state of the antenna and find a way to rectify the problem.
Over the next two years, numerous attempts were made to further deploy the antenna. At the same time, the project commissioned a separate, multidisciplinary study team to investigate ways to continue the mission without the HGA. Radical alternatives such as launching a relay satellite were quickly discarded due to time and budget constraints, so the team concentrated on alternatives using the LGA to support Jovian orbital operations. The project’s worst fears were realized. All efforts to fully deploy the antenna were unsuccessful. The HGA was virtually useless.
To support operations using the LGA, we needed to radically redesign the telecommunications link architecture. Without any modifications, the LGA would only support 10 bits per second (bps) at Jupiter, less than one-ten-thousandth of the 134 kilobits per second (Kbps) planned. The task of the team was to recover as much functionality as possible, given the capabilities of the communications link. Major modifications to the spacecraft hardware to boost transmit power were not possible, so much of the effort was focused on increasing the receiving capability on Earth and developing a much more efficient data and telecommunications architecture.
The images used to create this color composite of Io were acquired by Galileo during its ninth orbit of Jupiter.
Photo Credit: NASA/JPL/University of Arizona (Click image for fullsize.)
Using advanced arraying at the Deep Space Network complexes, the receive aperture available (and thus the data rate) could be increased by a factor of 2.5, and additional changes to the receivers and the telecommunications link parameters increased capability significantly. These changes increased the data downlink rate from 10 bps to approximately 300 bps. More efficient downlink encoding and onboard data compression further increased the effective data rate. Together these efforts could increase the information downlink to approximately 4.5 Kbps, more than four hundred times the initial 10 bps.
But even this improvement was a huge decrease in the expected data-return rate. The science team had to work long and hard to prioritize science goals, develop new science plans, and, in some cases, plan updates to onboard software in the instruments to increase data efficiency. Clear, frank, and frequent communication between the science team and the development team was required to balance science desires with the capabilities of the system.
The most significant resource the Galileo team had was time: approximately four years between the time the HGA anomaly occurred and the spacecraft’s arrival at Jupiter. Having that span of time was critical to the redevelopment of the onboard software to do the required data processing and data compression. This was also a time when some other preflight decisions became crucial.
The most significant resource that the Galileo team had was time: approximately four years between the time the HGA anomaly occurred and the spacecraft's arrival at Jupiter.
As a backup to the real-time downlink, an onboard tape recorder (the Data Memory Subsystem, or DMS) had been designed to record data during certain high-activity periods. Since these periods were few, only a single DMS had been included in what was largely a dual, redundant avionics system. In addition, during the delay due to the Challenger accident, the project team investigated a potential solid-state memory failure and decided to double the onboard memory. Both of those resources became critical to the new orbital operations, to buffer high-rate data during the Jovian encounters, and trickle it to Earth over the remainder of the orbit.
Over the next four years, two updates to the onboard software were prepared and extensively tested. The first was a minor update to the software to support the critical probe relay and Jupiter orbit-insertion sequences. The project team wanted to make only those changes necessary to buffer the critical probe data to allow downlink over the LGA. The second update would completely replace the onboard software to implement the changes to the data system.
The fates were not through with Galileo. On October 11, 1995, as the spacecraft was approaching Jupiter, the mission controllers commanded the Solid-State Imager to record an image of the planet and store it on the DMS. At the conclusion of this activity, the tape recorder was to be rewound and the data played back onto the downlink. When commanded, the DMS began to rewind, but failed to stop at the end of the tape. All indications were that the DMS was broken and would not be available for orbital operations.
Pseudo-true-color mosaic of a belt zone boundary near Jupiter s equator. The images that make up the four quadrants of this mosaic were taken by Galileo within a few minutes of each other.
Photo Credit: NASA/JPL Caltech (Click image for fullsize.)
The project team immediately began an intensive effort to determine the actual state of the DMS, while initiating a concurrent activity to redesign the LGA orbital-operations software to work without this critical equipment. After two weeks of effort, the flight engineers were able to determine that the DMS was not broken, but that the tape itself had stuck to the erase head and did not rewind. The tape capstan was turning without tape movement, resulting in burnishing a spot on the tape. Subsequent efforts moved the tape forward, and the team decided it was prudent not to run the tape across the damaged area ever again. The burnished area was buried under several wraps of tape on the reel. The Phase 2 flight software was modified to use the tape recorder in a new way, using recorded markers to indicate the end of tape (rather than the tape markers), ensuring the damaged area would remain buried.
The support of the NASA management that made funding and resources available to the project to deal with the anomaly was critical, as were the enormous contributions of the technical community in understanding the system capabilities and design options.
After Jupiter orbit insertion, and successful reception of the critical probe data, the flight team carried out the first complete reload of flight software ever performed on a deep-space mission. Loading the Phase 2 flight software was a major operational undertaking, requiring several weeks. After all the software was loaded, the flight team waited breathlessly as the command was transmitted to turn on the new capabilities. After a brief blackout while the ground system synchronized with the new telemetry stream, data started flowing, and the new system became operational. The team was tremendously relieved, and as the science data flowed, they all celebrated the accomplishment.
While the volume of data returned was less than originally planned, the science value of the data is immense.
The ability of the Galileo project to face and overcome a debilitating failure in flight was a testament to the creativity and determination of the NASA community. The support of the NASA management that made funding and resources available to the project to deal with the anomaly was critical, as were the enormous contributions of the technical community in understanding the system capabilities and design options. The contributions of the Deep Space Network and the telecommunications community in advancing the state of the art in antenna arraying, low-noise receiver technology, and advanced modulation schemes provided hope that a solution could be found. And the dedication of the Galileo flight team and the software development and test crew proved that the loss of the HGA could be overcome. The HGA anomaly workarounds were truly a team effort involving a system approach that included science, flight, ground, hardware, and software.
In the end, the science return was the clearest testament to Galileo’s success. While the volume of data returned was less than originally planned, the science value of the data is immense. The textbooks on Jupiter and its moons have been rewritten, and intriguing new questions have surfaced. One is whether Europa could harbor an immense ocean under its icy surface. It will be up to future missions to build upon the legacy of Galileo and find out.
Note: This work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. © California Institute of Technology. Government sponsorship acknowledged.
Erik N. Nilsen joined the Galileo flight team shortly after launch and was integrally involved in the HGA anomaly investigation team and the LGA mission development team. He is currently the Mars Sample Return Advanced Concepts manager, working on the campaign to return surface samples from Mars to Earth for study. He is a registered professional engineer in the state of California and has more than twenty years of experience in space mission analysis and design.
P.A. “Trisha” Jansma is the lead for the deployment subgroup for the NASA Systems Engineering Working Group for the Office of the Chief Engineer. She also supports training and deployment for the Systems Engineering Advancement Project. With more than thirty years at the Jet Propulsion Laboratory in both line and project management positions, she has a broad background in systems and software engineering in both engineering and scientific environments. She received a NASA Exceptional Service Medal for her work as the implementation manager for the Planetary Data System Version 1.