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!

Gross Monotony

It is amazing to me how much wasted time is blindly accepted in a workplace. And it's not just wasted time, but obviously duplicated efforts. It's like the time and effort you put into any work you do is really not considered important - to a certain extent, you're not important.

I have spent one month learning a software tool, adjusting to its idiosyncrasies, picking up the fine art of interpreting the results and identification of clouds versus smoke vers fog, etc. I have been bored out of my mind at the tedious nature of it all - staring at the computer screen, feeling as though my right arm might fall off from excessive mouse usage. And for what? To be told today that there is yet another update to the software. And despite the developer's prior assurance, post-processing of the data is not possible. So the original estimate of having to redo about half of the work I'd already completed is inaccurate. What is more accurate? A complete revision of all of the work that I have done up until this morning's software update. Anything that I'd finished prior to this? Completely useless.

And all of this so scientists at Harvard can write their PhDs and publications, possibly never understanding what went into getting them this data. And we're still waiting for the 7 years of raw data for the remainder of the country.

My summer is stretching out in front of me like the vast Sahara desert with no oasis in sight.