Open-Source Software and Its Role in Space Exploration

A software developer from JPL explains the reasons that NASA has embraced free and open source software in its application development process. Because, in a Mars launch, the term "mission critical" has a literal meaning.

What did the rocket scientist say to the Free/Open Source Software developer? Let's do launch! It's only natural that they'd want to work together. Both communities are focused on the cutting edge: creating tools and capabilities that did not previously exist. Both dedicate their work to expanding humanity's pool of information and want that information to float freely through society.

I am a software developer currently working on the NASA/JPL MSL (Mars Science Laboratory) rover, which launches in 2009. These are personal observations of how I encounter Free/Open Source Software (FOSS), and what I think about it.

Common Goals

Free floating information feeds a cycle of knowledge. Where the FOSS community donates code, algorithms and products, NASA and other organizations reciprocate with knowledge about weather systems, climate and basic science. Everyone contributes what they're best at, and tightly chartered organizations can stay focused on deeper penetration of hard problems, confident that others are doing the same. Space exploration is necessarily a cooperative venture; it's much too hard for anything less than all of humanity.

Look at these statements side by side, and you'll see the philosophical similarities:

NASA codifies its dedication in Congress' Space Act Charter:

[NASA shall] ... provide for the widest practicable and appropriate dissemination of information concerning its activities and the results thereof...

The Open Source Initiative criteria for "Open Source" includes:

  • Allow free redistribution
  • Provide access to source code
  • Allow modifications and the creation of "derived works"

FOSS developers codify that dedication in copyrights, copy-lefts, and license agreements like the GPL (GNU Public License), which says in part:

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

Open Source in Space

Need a few examples?

FOSS explores our Solar System. We send robots to the moon, Mars and beyond to flyby, orbit or land. FOSS goes with them, pervasive in the real-time operating systems, math libraries and file systems. Consider the robotic decisions of where to rove, and realize the power given the human race by the Free Software Foundation's (FSF) compilers, libraries, build scripts and so on.

"Electra" is NASA/JPL's Software Defined Radio (SDR) product created to support the Mars Network, and the InterPlanetary Internet. Electra provides UHF radio links in compliance with Consultative Committee for Space Data Systems (CCSDS) protocols Proximity-1 (data link) and CFDP (file delivery).

The neat thing about SDRs is that we can still reconfigure the protocol and signal processing functions after launch. For example, on MRO some other hardware started "leaking" electro-magnetically, which interfered with the Electra radio. We sent up a software fix to Electra to reduce the impact. We already know MRO will act as a radio relay for future Mars probes not yet built, such as the Mars Science Laboratory (MSL), which will arrive in 2010. MSL and others will use protocols not yet invented, and MRO will have to be updated to learn them.

Please bear with me a moment; I'd like to make a point about how much FOSS enters into this. Each of the following are FOSS project technologies used in the program. The flight software is mostly C, with some assembly for trap handling. It lives on file servers running kerberized OpenAFS, in a CVS repository, and is cross-compiled on Linux for RTEMS on SPARCv7 target chip. The code is built with gcc, make and libtools, and linked with newlib. (There, that wasn't so bad. I'll mention it again later.)

Hubble "Pillars of Creation"

FOSS observes our Universe. All the striking Mars rover navigation images, all the roiling clouds of Jupiter, each new view of Saturn's spectacular rings, every azure picture of deep-blue Neptune; the distant stars, far-away galaxies and stupendous galaxy clusters; all of these come to us touched in some way by FOSS. Think about the JPEG image formats themselves, the X11 workstation software to process them, and the MySQL databases to hold them.

Deep Space Network antenna


FOSS moves and analyzes ground data. When we prepare, check and double-check command sequences for uplink, the inputs and outputs travel variously across multiple sendmail e-mail systems, Linux platforms, and of course Internet Protocol stacks. The downlinked data, after its tiring journey across the solar system, bounces those last miles in mostly the same way the rest of our Web-connected world works. In the 1960s, NASA engineers had to invent lots of ways to move data around, and it became expensive to maintain.

FOSS methodologies develop space software. Some FOSS project efforts are very widely distributed, driving development methodologies to leverage all those eyes while integrating all that expertise and smoothing together all those styles. That problem is much tougher than, but similar to, our allocation and integration of functions across organizations, teams and contractors. Those methodologies are very attractive to us. There are several NASA examples of using an "agile software lifecycle," and we look to open communities to show us that it can be done, and how to do it best.

The only way for the public to participate in seeing fresh images in near-real time is through an open architectures for public outreach.

FOSS develops the next-generation cutting-edge technology. Why can we put a man on the moon, but we still don't have robot cars? Some key challenges are:

  • Robots have different physical characteristics.
  • Robots have different hardware architectures.
  • Contributions made by multiple institutions.
  • Advanced research requires a flexible framework.
  • Software must support various platforms.
  • Lack of common low-cost robotic platforms.
  • Software must be unrestricted and accessible (ITAR and IP).
  • Software must integrate legacy code bases.

The Coupled Layer Architecture for Robotic Autonomy (CLARAty) project brings together folks from many institutions. They develop unified and reusable software that provides robotic functionality and simplifies the integration of new technologies on robotic platforms. (They also have some funky movies of robots doing funny things.)

Ubiquitous FOSS

Our dirty little secret is that space agencies are companies just like everybody else. We too (am I shocking you?) use e-mail, Web servers, and all the usual non-space-qualified suspects. Here are some examples:

  • Operating Systems, Systems Management: Rocks (cluster Linux), Ganglia, amanda
  • Software Management: Depot, Subversion, Trac, Bugzilla
  • Communications: OpenSSH, Apache, Jabber, Firefox/Mozilla, Sendmail, Mailman, Procmail, CUPS, OpenOffice, wikis (various)
  • Data Visualization: ImageMagick, GMT, MatPlotLib
  • Compilers, languages, code checkers: SunStudio, splint, Doxygen, valgrind, Java, Perl (some JPL history there), Python, Ruby
  • Databases: MySQL

The Open Advantage

OK, so given that our cultures are similar, how does that translate into our bottom line? Why does FOSS have such a large role in space exploration? Here's the top-10 list of what I see.

1. Schedule Margin

Planets move; launch windows don't. The Spirit and Opportunity Mars Rovers had to go in the summer of 2003 or never. They are simply too massive to throw that far, for that budget, unless the planets aligned just so. (Mars and Earth line up every 26 months or so, but in 2003 they were unusually close together.) Procurement cycles for spending lots of government money can be months long, and they can dominate critical paths.

Quickly obtainable FOSS relieves that pressure and gives us some elbow room. Bug fix turnaround times can be critical. If we can fix the source code ourselves, we can keep a whole team moving forward. If the fix is accepted by the open-source community, we avoid long-term maintenance costs and have it for the next project. Feature additions ("Gee, if it only did this, too...") have the same advantage but take longer to give back. Oddly, we can contract for new features but cannot easily give them away. The FOSS spirit hasn't yet pervaded government contracting rules.

2) Risk Mitigation

Full system visibility is key to risk identification, characterization and resolution. The Mars robots are sent to encounter unfamiliar situations. Think how much information system engineers need to mitigate those risks. This is no place for a closed system.

All flight software goes through rigorous review, including the software (compilers) that builds the software (command sequence generators) that builds the software (commands). We do code walk-throughs which perforce means having the source code. We design white-box test plans by analysis of software decision paths, which is easier to do with the source code in hand. Our review process requires "outside experts, not working on the project" to review the code; well, that's exactly what a FOSS community is all about, isn't it? In essence, the open-source community is the world's largest Review Board, only we don't have to buy the doughnuts.

3) Reliability

When you leave Earth's orbit, you also leave "push the reset button" and "reload from CD" far behind. We tend to find bugs that don't bother other customers. We live at or beyond the border cases, and we push frontiers in all senses of the word. So all the critical bugs have to be found and squashed before we go.

The best way to shake out software bugs is to have lots of testers independent of development try it out in unfamiliar environments and in ways unforeseen—which pretty much describes the FOSS user community. By the time something's on its 2.1 release, it's usually been beaten up pretty thoroughly. And the beauty is, you have full disclosure about what broke in the 1.0 release, under what conditions, how it was fixed and what tests prove it's gone.

4) Interoperability

Space exploration takes a lot of brain power—more brains than any one company or nation commands. Our industry, academic and international partners each have specialized expertise vital to the effort. And each partner, it seems, uses a different platform, language or protocol from the rest that's optimized for that particular piece. Each builds a sub-assembly, and the thing has to work when you bolt it all together.

This is interoperability by definition. Software must be designed from the start to "play well with others" beyond your organizational control. Attempts to dictate uniform development platforms are not infrequent, and always fail. At worst, they represent a willful desire to ignore strict interface control, and interfaces are precisely what call for the greatest care.

As we build the space shuttle replacement and new spacecraft for the moon, interoperability is a top-level requirement. Under the current "Vision for Space Exploration," the "Constellation Program's Communications, Command, Control and Information (C3I) Interoperability Specification" was drafted early. Not surprisingly, the specification calls on open standards.

5) Portability

The Pioneer and Voyager spacecraft are older than disco, though younger than the Beatles. They are further from Silicon Valley than anything made by human hands, and getting further. Data from them continues to puzzle us. So, software to analyze that data has been ported to myriad computers. There's never enough money to upgrade routinely, so we stick with a platform until it dies and/or its manufacturer goes out of business. This is only barely tenable through strict portability conventions.

Spacecraft parts are hideously expensive, what with radiation toleration, quality screening and so on. Software usually has to be developed on simulators and ported to a number of similar but not identical units. For every flight article, there may be a "qualification unit" (for testing to failure), two or three "form/fit" units for functional testing, and some "engineering units" for development. A simple radar algorithm has seen development on Mac OS X, Microsoft Windows and Linux (that I know of)—none of which is the final environment. It's been coded in python, perl and C. The work would take far longer had we been locked into one vendor.

The Electra platform and code described earlier have been ported/inherited/reused for:

  • a landing radar on MSL
  • a spectrometer interface on ISRO's (Indian Space Research Organisation) Chandrayaan-1 Moon Mineralogy Mapper
  • a lunar radio architecture prototype C3I (Command, Control, Communications, and Information) Communications Adaptor (CCA)
  • Radio Atmospheric Sounding and Scattering Instrument (RASSI)

—all in the space of a few years, each time by a different team.

6) Openness

I've seen technical information retrieved from hard copies of presentations, because people unable to open files that were only a few years old. The (closed) format had changed when a desktop computer was upgraded. That just won't fly.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies