Greg Dunn
A properly working spacecraft needs properly programmed computer software to execute its mission. The July 2009 Monthly Highlights interviewee is Greg Dunn, IBEX Payload Software Developer.
Greg grew up on a farm in northeast Indiana, and has always been interested in computers and programming for as long as he can remember. Greg says, "We got our first computer when I was in 7th grade, and I broke it several times just poking around at things (what happens if I do this… oops!). I think I learned the most when trying to fix those things that were broken." Greg attended college at Purdue University, originally with a major in Computer Science. "The focus there was almost completely on software, though, and I wanted to know what really made a computer tick at both the hardware and software levels. So, during my second year, I switched to Computer Engineering, which is kind of a cross between Computer Science and Electrical Engineering." When he graduated, Greg admits that getting into the position (i.e. finding a job) was the hardest part. "I started college when the tech bubble was still intact, so everyone said we would be guaranteed great jobs when we finished. By the time I graduated, though, the bubble had burst and I was on the hunt for a job after graduation for several months before getting my first offer. I got through that just by being persistent - lots and lots of resumes, applications, and interviews."
He began working at Southwest Research Institute (SwRI) and has been there for over 6 years as a software engineer in the Space Sciences division. This division includes aspects of instrument development and everything from working with the scientists to defining software requirements; designing, writing and testing the software; supporting integration, environmental, and calibration testing; supporting post-launch commissioning; and diagnosing in-flight problems.
He explains, "For IBEX, my main contribution is that I wrote a large chunk of the software, along with Chad Loeffler, another SwRI software engineer, that controls the payload. The software essentially provides the user interface (commanding and telemetry generation), and controls the science data acquisition - sweeping the high voltage supplies through several values to gather data from different energy levels, then collecting and packaging the collected data. Some other functions include monitoring current, voltage, and temperature sensors for dangerous conditions and shutting everything down if needed; the capability to write to code memory in order to make software changes after launch; and maintaining the Solid State Recorder, similar to a hard drive, which stores both the payload and spacecraft data while the spacecraft is out of communications range.
Greg has a very interesting insight into the development of the IBEX spacecraft: "One of the biggest software challenges on IBEX was getting all of the software to fit. On a PC, you have gigabytes (billions of bytes) of storage space, and it is common for a program to require a few megabytes (millions of bytes) for code storage. But on IBEX, we had just 64 kilobytes (thousands of bytes), and a late requirements change left us with already-designed hardware that was not quite built for the processing required, requiring much more software processing than originally anticipated. At the end, a single line change in the source code would push it over the edge. I used some compiler features to help pare down the computer code so it would run properly using the mission hardware.
"One of the most helpful code-shrinking tricks the compiler offers is to search for duplicate chunks of computer code and consolidate them down to one chunk that is just referred to everywhere that it originally existed. An analogy would be if you were trying to reduce the word count in a book. If you had a 20 word sentence that was repeated several times throughout the book, you could write the sentence one time in an endnote, then replace every other occurrence in the book with 'see endnote 1'. It slows down execution (or reading) considerably, but if the primary concern is size (or word count), you save 17 words every time the substitution is made.
"After turning the compiler optimization up to 11 (yes, it really goes up to 11), and much finagling, we managed to get it to fit with a reasonable margin. It is good that NASA made us do that work before launch because during commissioning we had some issues that required software changes. Those changes would have been delayed while trying to get it all to fit if we had not done the additional work up front.
Prior to becoming a spacecraft software engineer, Greg did not realize how rigorous the spacecraft design and testing had to be. He says, "Once you fire off the rocket, there's no changing the spacecraft - you cannot send a tech out to replace a burned-out chip, after all - so we need to be extremely sure that the thing will survive launch and is going to work in the environment it will be in. To that end, there are loads of reviews and tests that the instrument must go through before it is given the 'ok" for launch.
Greg defines a typical day in terms of the phase of the project on which he is working. "Early on, it is a lot of document writing, including requirements, design, and test documents. Once the requirements and design are done, I spend most of my time writing code. That's the best part! When the Engineering Model hardware is ready and the software is fairly mature, I move into the lab and work on getting the software to run on the actual hardware (the early stuff is done in a simulator, and there are always surprises when you switch to the real thing). Working in the lab involves tracking down both hardware and software bugs until the two play nicely together."
"What is best about my job is that since the flight software provides the user interface to the instrument, I get to follow it through all phases of the mission, from early requirements gathering all the way through flight science operations. Many of the other disciplines tend to take care of their part, then move on to the next project and never really get to see the whole thing come together. Less enjoyable is documentation - it has got to be done, but I would rather be poking at hardware.
"My current job involves a lot of both hardware and software testing and debugging, so the Computer Engineering degree has helped a lot more than a straight Computer Science degree would have. I primarily do software development, but having the background in analog and digital hardware is essential when trying to integrate the software on a custom hardware platform; it is a lot different from writing software on a proven, mass produced PC-based platform such as a home computer.
When Greg is not writing software for high-flying spacecraft, he really enjoys spending time with his 4-year old daughter and two dogs. "Most weekends are spent at the playground, walking through nature parks, or just running around the neighborhood with my daughter and the pups. I also seem to spend quite a bit of time watching princess movies, Strawberry Shortcake, and Curious George, and jumping in Moon Bounces."
Greg has advice for those who may be thinking about a software-related job in the future, "With overseas outsourcing becoming more and more popular, many domestic engineering fields are becoming very competitive. Keeping grades up is obviously important, and getting some real work experience through internships or research projects while still in school will give you definite edge when looking for that first position after you graduate.
"I have always wanted to be a software developer (at least ever since I knew what that was), but originally I wanted to work on games. After talking to some people in the gaming industry, I am glad I didn't go that path - the industry is extremely competitive, so the work tends to be very stressful. I didn't have any particular interest in space sciences before I took this job, but now I really do enjoy it - and I really have enjoyed working on the IBEX team!"
