To the Moon! (Part I)

NASA's Constellation Program aims to return a human to the moon by 2020. As part of my summer internship, I (along with 10 other summer interns) have been asked to conceptualize one of the first missions for this program: a sample return mission to the South Pole Aiken-Basin. Being the eldest on the team (quite a new experience for me!), I was nominated to be the study lead.

What's interesting about this process is that it is truly systems engineering and requires a lot of "outside of the box" thinking. Stuff they didn't teach me in school (perhaps more so because I didn't study astronautics than because it is not taught). Knowing how to start the project was probably the most difficult thing: what questions do you ask the experts so you can develop a mission architecture that is feasible, cost effective, and innovative?

As an engineer, I'm always surprised at how these space missions always come back to the science. For a nation so steeped in technological growth and development, we do a lot more to advance pure science than most people realize. If there is no scientific objective to the mission, no goal that will advance the knowledge base of the world's scientists, then you can forget it. NASA (or any other agency I imagine) is not going to fund a mission simply to test the newest communication error correcting code or information theory advancement.

So where do you start? With the science. What do scientists want to know about where you're going? What do they already think is happening in that area, and can you prove or disprove it with your mission? From these science objectives, requirements are developed. Requirements are the bread and butter of systems engineers. The mission shall...An engineer working in the science area of a mission quickly becomes a scientist, sometimes shooting for the moon (no pun intended!) with ideas about what the mission could accomplish. And we've hit the key word: could. What the mission could achieve is a far cry from what the mission can achieve when the budget and engineering constraints are taken into account. The goal is to accomplish the most relevant and important science while staying within the other mission boundaries. It seems almost an art, knowing what the best science is, and certainly that is something that is never taught in school.

Next comes the instrument choice. Fueled by research into heritage missions and instruments that have done similar work for scientists in the past, engineers tread a fine line between incorporating new technology and increasing the risk of the mission. Yes, that instrument may have worked on MSL, but isn't it overkill for the Moon? Remembering the different environmental constraints and considering the communication delays for the instruments also presents an interesting challenge for the systems engineer. This is where technological innovation begins to come into play -- instruments are nearly always re-invented to a certain degree as they are used from one mission to the next. And it's not just true for the instrumentation: spacecraft, subsystems, rovers, landers, etc - nearly everything is retooled to take advantage of advances in research for every mission that is sent out.

I'll continue with this topic tomorrow - it's been a several week process learning it, so I imagine it'll be a several hour process writing about it!