By Kerry Ellis
Many project managers tout communication and collaboration as important elements for building a successful team. But what happens when an ocean separates team members? Tougher still, what if you throw in a few different languages? Is it still possible to succeed? Cassini-Huygens’ launch on October 15, 1997, and its successful science data return imply the answer is “yes,” but language and time zone differences were the least of its challenges.
Cassini captures the rough terrain of Rhea, another of Saturn’s satellites, during a flyby.
Photo Credit: NASA/JPL/Space Science Institute
When Robert Mitchell joined the Cassini team as project manager in June 1998, he knew he was walking into a complex environment. The project was an international collaboration among seventeen nations that were building the spacecraft and more than 250 scientists worldwide who would study the data streaming back from Saturn. NASA’s Jet Propulsion Laboratory (JPL) built the Cassini orbiter while the European Space Agency (ESA) built the Huygens probe and the Italian Space Agency provided communications equipment and major parts for three instruments on the orbiter.
Of the scientists supporting the combined Cassini and Huygens missions, slightly more than half are Europeans. Nearly 180 engineers also support the effort. The scientists and engineers on the team find it challenging to coordinate communication. Because of its distributed nature, the Cassini team holds many of its planning meetings through teleconferences, which time differences make difficult to schedule — 8:00 a.m. in California is 5:00 p.m. in Italy, France, and Germany. The scheduling problem means scientists participate in observation planning to varying degrees, but they all receive the data equally. The team also has three Project Science Group meetings each year. The formal agreement between NASA, ESA, and Agenzia Spaziole Italiana (Italy) is that two of those meetings will be in the United States and one will be in Europe each year, “but occasionally we reverse that to help maintain a sense of equal partnership,” Mitchell says. This kind of balance and cooperation characterized the project as a whole and, more than once, a cooperative search to solve a technical problem both served the mission and resolved apparent conflicts between groups.
An earlier decision not to perform cruise science during Cassini-Huygens’ seven-year trip to Saturn was one of the first technical challenges. This decision, made for budgetary reasons, caused significant conflicts within the project, especially between the science community, which wanted to take advantage of the opportunity to do new science, and members of the project management team, who needed to keep limited engineering staff focused on preparing for the spacecraft’s arrival at Saturn. Mitchell asked the two communities to develop a solution together that would allow cruise science at no additional cost.
“It just seemed that we were missing out on an opportunity to do new, unique science,” Mitchell explains. “Perhaps more importantly, we were missing the opportunity to find out how this machine worked.” The team was already developing nearly all the ground software and much of the flight software during Cassini-Huygens’ cruise to Saturn, which had always been the plan given the long flight time to the planet. It became apparent that they could be more effective if they exercised the system as they went. Pursuing cruise science improved the working environment and attitudes around the project, and it also helped increase the capabilities of the systems operating at Saturn and on the ground today. The cruise science decision made it possible to improve the technology, gather more data, and bring people together.
That wasn’t the last time testing the system would be an issue. A previously proposed in-flight test of the probe-to-orbiter relay link had been denied. It was a relatively simple and risk-free test to perform, so Mitchell agreed to do it. The team asked the Goldstone Deep Space Network (DSN) station located near Barstow, California, to transmit a signal to Cassini that would simulate the signal coming from Huygens during the relay. The team would then record the signal on board and play it back to Earth in the same manner that would be used during the probe’s descent to the surface of Titan. They originally proposed using only a carrier signal, but one of the ESA engineers, Boris Smeds, pushed to make it a full simulation with telemetry. He even offered to develop everything on his laptop and go to the DSN station to implement it. “Most people thought this was overkill, but we agreed to let him do it,” Mitchell says. As it turned out, the carrier signal was received just fine, but the telemetry was not. If they had done no test, or just the carrier test, the team would have lost a significant amount of Huygens’ data and would not have known about the problem until after the mission was completed.
The problem was a flaw in the design of the receiver, which was part of the Huygens system but carried on the Cassini spacecraft. As Huygens descended into Titan’s murky atmosphere, it would transmit data to Cassini through the receiver. On many deep space missions, engineers would send new software and parameters to the system to fix the problem, but the software and parameters were permanently burned into firmware in Cassini’s receiver and could not be changed. Solving the telemetry problem in a sense pitted the Huygens scientists against the Cassini scientists because the most viable solution threatened Cassini’s science activities. Prior to discovering the anomaly, the orbiter was supposed to complete its data relay with the probe prior to its closest approach to Titan. From the perspective of the probe, which entered Titan’s atmosphere about four hours before the orbiter would reach its closest approach, the orbiter seemed to be coming straight down from overhead and then zipping by at the last minute. Since the probe slowed dramatically once it was captured by the moon’s atmosphere, the orbiter was closing in on it at about 6 km/sec, which was exactly the problem. The Doppler effect caused by this closing speed changed the frequency received by the orbiter. The solution was to change the orbiter’s flyby altitude at Titan from 1,200 kilometers to about 60,000 kilometers so it was flying off to the side of the probe during the relay instead of coming straight in. This reduced the maximum closing speed by about half at the start of the relay and to nearly zero at its closest approach, which substantially reduced the change in frequency seen in the original design.
But changing Cassini’s trajectory presented a new problem. It would require using a significant portion of the propellant reserves otherwise available for tour anomalies and extended mission opportunities. It would also affect the sequence planning work that had already been done for orbiter science observations and could change the four-year orbital tour, which had been very carefully crafted to rely on Titan’s gravity on each flyby. The key to solving this problem lay in shortening Cassini’s orbital period when it was inserted into orbit around Saturn. Some remarkable brainstorming between the ESA and NASA teams came up with changing Cassini’s trajectory so it also used Titan’s movement across the sky to compensate for the course change. The shorter initial orbit allowed the team to insert an additional orbit into their original sequence, which accommodated the 60,000-kilometer flyby needed for the probe data relay. The next Titan flyby was unaffected by this redesign, and from that point on the previously designed tour and science observation designs were preserved.
There was surprisingly little finger-pointing about where the fault lay in the relay mishap. The team focused instead on making the program work. “One thing that was a big help with this,” says Mitchell, “was after we had spent a fair amount of NASA-funded time and resources (like propellant) on fixing the problem, the ESA Director of Engineering offered to send three ESA engineers to JPL at his expense to help offset what we had spent on the problem, since he was prohibited from sending any money over here.” Two of the engineers remained for at least three years. The third position rotated among a series of engineers who cycled in and out. “It worked out very well having them right here on the same time we were on and feeling very much a part of the overall effort,” Mitchell recalls.
Figuring out which of the twelve instruments on Cassini would get observing priority at which times was another difficult challenge. For budgetary reasons, a scan platform to orient Cassini’s instruments was eliminated from the design, which means all instruments are bolted solid to the spacecraft chassis. In order to point an instrument at a target, the entire spacecraft has to turn, which isn’t quick or easy to do. It also means that at any given time, only one instrument can control where the spacecraft points since they are generally located on different parts of the chassis.
Because the process of allocating observing opportunities to the different teams was such an involved one, they started planning shortly after the Jupiter flyby in December 2000. First, each team identified every observation they wanted to make; then, based on scientific priorities, they determined who could do what. The result was a conflict-free observation timeline. “We had a couple of review boards tell us that we were doing too much too early and our efforts would be wasted, but we ignored this and kept going,” Mitchell recalls. The team felt they hadn’t conveyed well enough to the review board the enormity of effort scheduling would take. “It wasn’t for lack of trying,” he says, “but it’s hard for somebody not involved on a day-to-day basis to get a fire hose treatment for two days and really understand the picture.” Today the sequencing process is working very well, and the process allows for some updates to the early plans based on what they learn from Cassini-Huygens in the meantime and how the instruments are functioning. With hindsight for how the process has worked, Mitchell says he’s glad they started the observation design process when they did, and if they could change anything, it might be to start the process even earlier.
Being able to maintain those observations with other countries by communicating and sharing software tools is becoming more of an issue due to International Traffic in Arms Regulations (ITAR) restrictions. These U.S. policies and rules govern what kinds of information and hardware can be shared with foreign nationals. The ITAR definition of sensitive “defense articles” includes spacecraft and hardware or software that monitors a spacecraft. “it’s hard to know what you can or cannot do,” Mitchell explains, “but it generally means you can’t share anything concerning spacecraft design and operation.” Most of the Europeans understand that ITAR is something beyond NASA’s control, but it makes communication difficult. NASA works with the U.S. State Department to ameliorate the situation, but it isn’t going away. Currently at risk is NASA’s ability to share new software tools the Europeans will need to continue the sequence design process for Cassini-Huygens. Mitchell says, “Our European partners get quite concerned about the prospect of us not being able to release the new tools because it would effectively put them out of business.” Fortunately, the good working relationship between the two teams helps alleviate some of the tension ITAR is causing, but they haven’t found a final solution to this dilemma.
Despite these complexities, Cassini-Huygens continues to explore Saturn, improving upon previous successful missions to examine the ringed planet: Pioneer 11, Voyager 1, and Voyager 2. The Cassini and Huygens teams also continue to work together as the sophisticated instruments on both spacecraft provide them with vital data and the best views ever of this region. Cassini-Huygens became a collaborative unit that no ocean — or seven years of space travel — could separate.
