By Ashwin R. Vasavada
NASA’s robotic exploration of Mars represents, perhaps more than any other human endeavor, both a scientific and an engineering achievement. A Mars rover must survive a violent launch and entry into the Martian atmosphere, descend and land safely, navigate over rocky terrain, manage power and data across many subsystems, communicate with orbiters and ground stations on Earth, and operate for multiple years in a dusty environment of extreme thermal contrasts. Yet these profound technical challenges are only half the story. After four decades of Mars missions, the scientific goals are equally ambitious.
Each of the twin Mars Exploration Rovers (MER) that reached Mars in 2004 has found evidence that liquid water interacted with surface rocks and soils for a sustained period early in Martian history. Launching in 2011, the Mars Science Laboratory (MSL) rover mission will further assess Mars’s habitability by exploring a new landing site with a car-sized rover carrying more than 80 kg of scientific instruments. In addition to the imaging and “place and hold” sensors from MER, MSL is equipped with a system to drill into rocks and deliver sieved powder to chemical and mineralogical laboratories inside the rover body. It will make measurements that are difficult even by terrestrial standards: high-resolution imaging devices need stable platforms and precise articulation; chemical detectors require controls on contamination and sample handling; and calibration, cleaning, adjusting, and troubleshooting must all be accomplished through the looking glass of the spacecraft’s telemetry.
But what makes Mars exploration unique is not just the challenge it presents to the scientists and engineers involved, but how deeply these communities must be integrated in order to succeed. Mars exploration is a program driven by scientific goals but enabled by technical achievements. Technical design choices are motivated by the mission’s science objectives and each carries the potential to either limit or enhance science return. Furthermore, upon reaching Mars, the robotic vehicle becomes a virtual scientist: the investigations of scientists on Earth are accomplished via the spacecraft and the technical teams that operate it.
The need to bring scientists and engineers together is obvious, but that essential close collaboration is not easy to achieve in practice. For example, it’s tempting to view the two communities as playing distinct roles over the life cycle of a project. A mission might be defined by a team of external (for example, university) scientists, handing off their requirements to a NASA center comprising predominantly engineers who will design and develop the spacecraft, which will then return data to be analyzed by scientists scattered around the world. But having an integrated team during the critical middle stages is what ensures the mission will accomplish what was originally intended. Our strategy within the MSL project at the Jet Propulsion Laboratory (JPL) has been to integrate a small number of in-house project scientists into the engineering teams during design and development. Here are a few thoughts on how we’ve done that and what we’ve learned. While born out of a Mars mission, these strategies will be useful for any NASA mission with a scientific component, research or applied.
Who: Choose the Right People
Integrating a scientific and technical team starts by recruiting team members who are not only excellent in their disciplines but also have the skills and temperament conducive to working together. Project scientists are the liaisons between the engineers and the external science community. Strong research credentials will ensure that they are respected by their scientific peers and trusted to convey and defend the mission’s scientific objectives. Project scientists are likely to get a wide range of questions from project engineers, requiring broad knowledge and the ability to make timely judgment calls. JPL hires scientists with these criteria in mind and encourages them to stay current in their fields by dedicating a fraction of their project-supported time to related research. Sometimes it may be necessary to bring in additional expertise from the external community, perhaps by holding a teleconference or forming a working group. In such cases the project scientist can help find the experts, frame the questions, and translate the responses.
On the engineering side, JPL has found that project system engineers with research experience have a good framework for understanding how the scientific and technical aspects of a project interact. Also, the importance of temperament should never be underestimated. Scientists and engineers come from different cultures and bring their own presuppositions about each other’s motivations and capabilities. Rarely does a team regret integrating, but the path may initially be rocky.
How: Understand Each Other’s Work
The negative presuppositions held by each community sound something like this: “Scientists have unrealistic ideas about what can be done and always want more,” or “the engineers are killing the science.” It may take time and plenty of dialogue, but the goal is to go from a view of working at cross purposes (“look, if we don’t land successfully, we’re not going to get any science anyway!”), to one of thoughtful negotiation (“how much can we cut your energy before the science quality really suffers?”), to eventually one of working together toward a shared goal.
One of the most successful ways of moving along this path is to jointly discuss the larger scientific and technical context, not just the issues at the interface. For example, scientists need to develop an inherent appreciation for the cost, mass, schedule, and risk pressures that drive the engineers to certain choices.
Meanwhile, scientists can educate the engineers on the objectives of the mission, improving their judgment about where to push constraints and where to accept limitations. These approaches have worked especially well within our team that is designing and testing the MSL entry, descent, and landing (EDL) system. This team commissions external scientists to run state-of-the-art models of Martian weather, statistically analyzes the results against the capabilities of the EDL system, and simulates the spacecraft’s flight through the modeled atmosphere. Although there is enormous complexity on both sides of the science–engineering interface, we have a simple goal within the team: “No black boxes on either side.” Only by sharing our expertise with each other can we ensure accuracy and eventually a successful landing on Mars.
Where: Be in the Right Place
A large project like MSL, with more than one thousand JPL staff at the peak, is organized into systems, subsystems, and even smaller groupings. Where in this organizational structure should we integrate our dozen or so in-house scientists?
Our method is to attach an individual scientist (most of them part time) to each scientific instrument and the rover’s sampling system—in fact, to every project element that has a major scientific component. We also have two scientists attached part time to the team in charge of EDL: an expert on Mars’s surface and one on Mars’s atmosphere. The project scientist and his two full-time deputies interact primarily with the project core staff and address project-level requirements, design trades, and other management issues. Scientists pick up additional assignments as the need and our skills dictate, on topics including the expected environmental conditions on Mars, contamination issues, or mission operations strategies and tools.
By maintaining a presence across both dimensions of the project organizational chart, we can provide scientific guidance where needed and can stay current with engineering progress. JPL has taken steps to promote this integration by giving the project scientist shared authority with the project manager on decisions that affect science. The MSL project has helped by requiring scientific representation on all major internal reviews
But being there is what counts; a single missed meeting or review might be regretted.
When: Integrate Over All Phases of the Project
The sample acquisition and processing system on MSL has been a proving ground for our ability to integrate our scientists and engineers. A six-foot robotic arm must accurately place a jackhammer drill on a rock, then drill, collect, and sieve the rock powder and deliver measured amounts to instruments inside the rover body, all while minimizing fractionation (that is, separation by particle mass or size) and cross-contamination. Early in the project, we attempted to create a set of science requirements that would bound the capabilities of the subsystem but leave implementation choices to the engineers. This serial approach proved naïve in several ways.
For one thing, it was difficult to formulate a comprehensive set of requirements given the discovery-driven nature of the mission, with uncertainties about what might be encountered and what problems might occur. We just don’t know how many hard versus soft rocks we will encounter, even though such a prediction would provide a quantitative way of estimating the life of drill bits. Furthermore, implementation choices would affect the scientific quality and integrity of samples in different ways. At one point the design team worked hard to preserve our ability to study various depths within a rock by retrieving an intact core sample. Our science team grew increasingly concerned about the fractionation that would occur when crushing the core into powder and began to prefer a less complex powdering drill, but those relative judgments weren’t efficiently passed along to the engineers. We determined that it would be better if the end-user scientists were involved in the design process, weighing in on these decisions and sharing experiences from their own laboratories. Together the team could iteratively find a set of requirements and design choices.
We’ve now settled on a process that provides scientific input by both embedding a scientist full time into the team and by holding occasional science reviews of the subsystem with the external scientists who will eventually use the sampling capabilities. As the prototypes and flight-like models go through testing, our in-house scientist will provide samples of Mars’s analog rocks and soils and analyze performance. This is an important point for all the scientific equipment on the rover: the utility of the data returned from Mars depends on the characterization and calibration performed prior to launch, not just the verification against a set of functional requirements.
In the end, integration is successful only if internalized by individual team members. Our scientists are passionate about what they hope to achieve and know their success is tied to that of the engineering teams. One turning point occurred when our sampling system team revealed a new version of their design, much more clever and capable than anticipated by the scientists who will get to use it one day on Mars. In the other direction, the engineering teams have been greatly motivated by the enthusiastic and detailed discussions of landing sites and the potential for discovery. In the end it all comes down to two things: building trust and recognizing each other’s unique contributions.
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.