The Software Behind the Mars Phoenix Lander 152
chromatic writes "Imagine managing a million lines of code to send over seven hundred pounds of equipment millions of miles through space to land safely on Mars and perform dozens of experiments. You have C, 128 MB of RAM, and very few opportunities to retry if you get it wrong. O'Reilly News interviewed Peter Gluck, project software engineer for NASA's Mars Phoenix Lander, about the process of writing software and managing these constraints — and why you're unlikely to see the source code to the project any time soon."
Great software! (Score:2, Interesting)
wow, long article, here's the answer to the teaser (Score:5, Interesting)
basically, its because the code is part of a space vehicle regulated by international arms and trafficking laws. That means Joe Blow doesnt get it.
Sorry dude, you're Joe Blow. Unless you're reading this from a JPL/NASA'ish sort of place. Then you're just smirking.
===================
FTA:
Sort of on a different topic, I have a quote here. One of our editors talked to Frank Hecker from the Mozilla Foundation the other day.
Okay.
In that talk, he suggested that all software developed by the Federal Government should be released to the public domain or a very, very liberal open-source license. That's not even a copyleft license. Does the American public have any access to the source code currently on the Phoenix? Are there plans to make some of the source code available?
Well, no. There are no plans to make that available. And one of the issues that we have is that our spacecraft are designated as subject to international trafficking and arms regulations. So even --
Crypto regulations in exporting and such?
Yeah. Yeah. I mean even though these are not military spacecraft, the technology used in them is space technology. And so the State Department does not allow us to release anything that we've done in terms of technical details to foreign scrutiny. Now, in fact as I said, we have a team of Canadians. The Canadians delivered our meteorology instruments, and we had to be very careful about our relationship with them and how much we could disclose to them.
Really?
Yeah. Yeah.
I can see that in applying control software, but how about the payload software?
Even the payload software -- in this particular case, remember that the payload software operates within the confines of the RAD 6000 that contains the spacecraft software. And although the newer versions of real-time operating systems allow you to compartmentalize better, the older ones are just global name space. So there really wasn't any way to allow them to provide software for the MET instruments. So we had to define an interface and build the software at JPL, and then do our integration testing. And we worked closely with the Canadians in terms of the integration testing and making sure that the software was going to do what they needed it to do.
Right.
But we could not actually release the source code to them.
Re:Millions of lines? (Score:5, Interesting)
Well, of course, the proper response to your query is "it doesn't work like that" or "neither are a good metric" or something, but that's a big boring, so let's consider an empirical result.
liblink-grammar.so.4.3.5 is 616129 bytes. It is built from 23289 lines of code. So that's about 26.4 bytes of code per line.So 128 MB of RAM can hold about 5,084,005 lines of code :)
Not like the olden days (Score:5, Interesting)
I'm curious how many old kinds of code we're still communicating with. FTA, Cassini is ADA-based. I know the Voyager craft are in FORTH (my first programming love).
Re:wow, long article, here's the answer to the tea (Score:5, Interesting)
Neither the basic science, nor the applied science (aka engineering) is open.
The only reason any of us know the rocket equation is because it was invented before these laws were.
I wouldn't waste my time... (Score:1, Interesting)
...using something as error prone as C. And neither did JPL, originally. You might find this an entertaining read.
http://www.flownet.com/gat/jpl-lisp.html
Misleading summary (Score:3, Interesting)
Re:Millions of lines? (Score:3, Interesting)
How many lines of code can 128 MB of RAM hold and what is the average 'line' for C?
I don't know, but 15 years ago, I would have killed for 128 MB of RAM or even a 128 MB HDD. My first "PC" had 4 MB RAM and a 102 MB HDD. It ran DOS 6.2, Windows 3.1 and a host of crappy DOS games. (Actually, I don't think the DOS games used more than the first MB)
Strip the GUI and even the CLI, and you'll find that 128MB is quite a bit if your main concern is code. Data could take quite a chunk of that, but if you're just talking about text files with data and configuration, a few MB could handle it with not problem.
Now, once you're on the ground and you want to start storing some hires pics to send back to Houston... you better have a flash card stashed away on that thing somewhere!
Re:Your statement is flawed. (Score:3, Interesting)
Well, the shuttle software has zero bugs - or seemingly as close to it as to be indistinguishable from zero. The software for the [nuclear tipped missile] fire control system I used to work on in the Navy, as well as the firmware in the missile had absolutely zero bugs... Its not impossible to get zero bugs, its merely very damn expensive.
Re:Nah, space technology is just as junky as us. (Score:1, Interesting)
This actually didn't crash the computer. It just caused some routines to get missed because the data was taking to long to process, and an alarm to activate so that ground control had to determine quickly whether this warranted an abort. I'm unclear whether this was the cause of the descent running long, but Armstrong didn't actually take manual control until he perceived they were heading towards a large crater that would make a dangerous landing target.