71 Comments
- michaelzhao, on 07/16/2008, -0/+53the hardware on all of NASA's space systems are all very basic... the reasoning is that they must be radiation proof... all processors on space missions are thoroughly tested and hardened to withstand the radiation present in space...
http://en.wikipedia.org/wiki/Core_memory
the memory used is called magnetic core memory because it is extremely resistant to radiation and also non-volatile
Heres another great site with tons of information: http://www.dansdata.com/spacecomp.htm
As an example... the ISS uses these processors: http://www.pcguide.com/ref/cpu/fam/g3I386SX-c.html
The original US space shuttle used 5 of these processors: http://en.wikipedia.org/wiki/AP-101, the entire size of the shuttles control software was only 700 kilobytes... Ubertight code indeed... - megamod, on 07/16/2008, -0/+28All technical aspects aside I think this is the most interesting fact (at least I didn't know about it before):
"That's why this is called the Phoenix, because you used parts from other missions?
That's right."
But honestly? a 14 year old embedded board??? WOW. - m4csrgh3yk3v, on 07/16/2008, -7/+31"Hello World"
- vroom101, on 07/15/2008, -0/+20RAD6000 specifications:
http://www.baesystems.com/BAEProd/groups/public/do ... (www.baesystems.com/BAEProd/groups/public/documents/bae_publication/bae_pdf_eis_sfrwre.pdf) - rblancarte, on 07/16/2008, -0/+16I guess you never heard of radiation.
- kstar6, on 07/16/2008, -7/+23Apparently the webserver is running on a BAE Systems RAD6000 single board computer that's configured with one 33 MHz RISC CPU and 128 MB of RAM - FAiL...
- Raider007, on 07/16/2008, -0/+16Helicopters in space huh.... great thinking there Einstein
- Homerr, on 07/16/2008, -3/+16Microsoft needs to hire some of NASA's software engineers.
- teh_techie, on 07/16/2008, -2/+14and... you are buried for the use of above mentioned word.
Feel free to bury me for something too! - nakile, on 07/16/2008, -0/+11Or system reliability.
- drlha, on 07/16/2008, -0/+11Sure, its not like NASA doesn't have job ads for these types of positions, or you could try applying for a job at somewhere like SwRI that handles a lot of flight software coding for NASA missions. There's no magic to working at NASA, I speak as someone who has written spacecraft flight code for under a NASA contract myself.
- Lunarbunny, on 07/16/2008, -0/+11Probably hosted on a 286.
- neotrantor, on 07/16/2008, -2/+12i program the same hardware for a living to do nearly the same tasks here on earth... can i work for nasa?
- megamod, on 07/16/2008, -0/+8why would you want to do that? The aliens over there have far superior games to play on their own PC's.
- saleem, on 07/16/2008, -0/+8there is so much wrong with that post that my head just asp.... hurt a lot.
- Matt2k, on 07/16/2008, -1/+8I think NASA has heard of newegg.
I can't tell if you're being serious or not, but consumer hardware is generally inadequate for this. - dezertrat, on 07/16/2008, -0/+6Its crazy they can update the software while the thing is on mars, its scary enough doing a router connected to a hardline.
- Trigononamous, on 07/16/2008, -0/+6Dugg for the Umlaut
- morcheeba, on 07/16/2008, -0/+6I upgraded our ACS (attitude control system - the computer that keeps a satellite pointed in the right direction) in 1996. The fastest computer in the office was a Pentium 90... the satellite used a 4.77 MHz 8086 with an 8087 math coprocessor - the same as seen on the original PC. Finding chips that old was tough -- the last 8087's on the planet were in bare chip form. We bought them and then paid to have them put in ceramic DIP packages so that we could use them.
- SSUK, on 07/16/2008, -2/+7Oh, you own a HP computer then?
- netneutrality, on 07/16/2008, -0/+5NASA programmers know how to write real code! All in good honest C!
- LeRenard, on 07/16/2008, -0/+5One aspect of mission critical code that I never appreciated until I started writing it is that absolute need for small size and simplicity. I used to wonder why they would write the programs so tiny, surely they could afford more space (even with core memory). What I eventually came to understand is that the smaller the program is, the less testing you have to do, and these programs are so rigorously tested that the testing phase takes much more work than the programming phase. I've been told (and going from my fairly terrible memory) that its a factor of around 20 generally, but it depends on the permutations of possible operational states.
- Jenadae, on 07/16/2008, -0/+5Sounds like you're a little but hurt...
- LeRenard, on 07/16/2008, -0/+5A certain amount of that also has to do with the fact that once a piece of hardware has been validated, they don't have to do it again if they use the same part.. saving the project time and money.
- rblancarte, on 07/16/2008, -0/+5On Mars.
- rblancarte, on 07/16/2008, -0/+4Some of the old technology is really good. Motorola/Freescale made the 68HC11 how long ago? And it is still used in many applications.
Hell, I would look to go with any 14 year old tried and true technology in this case over a brand new solution in a case like this. You know it works. - Lunarbunny, on 07/16/2008, -0/+4That explains the 6 to 44 minute response time of some of these pages...
- lohphat, on 07/16/2008, -0/+4"I am charged!"
/sank you Doktor! - quarryman, on 07/16/2008, -0/+4Its mentioned in the article, its C.
- rblancarte, on 07/16/2008, -0/+4If I am reading the specs right, 3 MB.
- inactive, on 07/16/2008, -0/+310 watts at 33mhz?! its not going to win any power-efficiency awards...
- Schmich, on 07/16/2008, -0/+3Where you play aliens invading a blue planet and fighting humans in nanosuits?
- anarchyx34, on 07/16/2008, -1/+4Wow, already down?
- Gudeldar, on 07/16/2008, -0/+3Article says that all the code is in C.
- MtheoryX, on 07/16/2008, -0/+3@Jenadae:
"...but hurt..."
Ouch. - vroom101, on 07/16/2008, -0/+2How many megabytes/gigabytes of EEPROM / EPROM / ROM space is installed on the Mars Pheonix Lander's RAD6000 single board computer?
- peterfnet, on 07/16/2008, -1/+3I was hoping for some code!
- mtekk, on 07/16/2008, -1/+3It's probably assembly language. If not then C would be the higher level language of choice, unless they use ada (developed for the DoD).
- Zaxcomp, on 07/16/2008, -0/+2Mar's atmosphere is too thin for a helicopter to work. The parachutes they use to land already have to be massively oversized to make the most out of the weak air.
- kyleisgreat, on 07/16/2008, -0/+1Yeah, C. They also talk about (not) releasing the code to the public.
- Baryn, on 07/16/2008, -0/+1beaten
- morcheeba, on 07/16/2008, -0/+1I agree, but there's a different angle to consider, too. Technology brings lots of improvements that could be really helpful to spaceflight programs.
The 68HC11 is great, but it takes 135mW at 3 MHz. An SiLabs 8051F411 takes 19mW at 50 MHz.
Not only do you save power (=less batteries, less solar cells), the extra processing power means you might get away with fewer processors (=less size, fewer parts, more physical reliability). But, the heritage is big, and radiation testing important, and porting code is tricky, so it's often a wash. - DeathtoG4, on 07/16/2008, -0/+1power requirements...................
- FeargusMcDuff, on 07/16/2008, -0/+1Yeah I suppose it might be a little insulting to them.
- vroom101, on 07/16/2008, -0/+1According to "Mike Deliman: 'Did you watch it?'" at http://blogs.windriver.com/deliman/2008/05/did-you ... (blogs.windriver.com/deliman/2008/05/did-you-watch-i.html) the real-time operating system (RTOS) used on the Mars Phoenix Lander is Wind River Systems "VxWorks 5.2 for Rad6000".
More info about VxWorks: http://www.windriver.com/vxworks/ - bacchante, on 07/17/2008, -0/+1Microsoft has intelligent people. That's not what is causing them to produce utter *****.
- DougHenryII, on 07/16/2008, -1/+1Great article, went to read it again and it seems to be down, tried to pasterate but its far too long.
- jinkop38, on 07/18/2008, -1/+1More raves for VIsta...
- Yarin, on 07/16/2008, -1/+1Well, the University of Arizona is well-represented. The TEGA and the SSI and the RAC cameras were all developed at the University of Arizona. And so their teams are largely comprised of folks from U of A. In the case of the RAC, there's also some folks from Max Planck Aeronomy in Germany. There are other U of A folk that are on some of the other teams. But the scientists are coming from all over. There are Canadian scientists that are on the MET team there. There are scientists from JPL. In fact, I couldn't even tell you where all of the scientists are from. There's a large contingent of scientists there. Some of whom I've never been introduced to. [Laughs]
Scheduling all of those disparate interests might be a really contentious job.
Right. Which is why we have PSI. So PSI helps to do the modeling and provide the assessment necessary for the mission managers to adjudicate who's going to get to go and who isn't.
Say, "Don't blame me, it's just the software."
[Laughs]
I've said that before.
PETER: Well, it's a delicate balancing act between what's in the best interest of the mission and what each science team would really like to accomplish.
The only reason I brought that up is because one of my editors said, Oh look, they have Java on this thing.
Oh, Java. Well, we have Java in the ground system not onboard the spacecraft.
Right. That's what it's starting to sound like.
That's right. Yeah. The spacecraft software is entirely in C.
C? Really? That surprises me a little bit.
Yes. It's entirely in C.
I thought Lockheed Martin was a big Ada shop for this sort of thing.
Ada is used largely in military applications, but JPL at any rate has moved away from Ada. Cassini, I believe, would be the last JPL mission that used Ada. And that was largely due to the success of the Mars Pathfinder in the mid-nineties. And as I said, these missions are to a large extent all derived from Mars Pathfinder.
After that successful mission, you say, Hey, we could do it in C now. That's not as scary as everybody thought?
Yeah. Right. And we've been running VxWorks as our real-time operating system. I believe they all run VxWorks. I couldn't speak for some of — let's see. We've been branching out in contractors a little bit. I believe — you know what? I'm not sure what Ball Aerospace is using in their spacecraft. And I am not sure what Orbital Science is using in their spacecraft. But the Lockheed Martin line does use VxWorks as the operating system. In addition to the six Mars missions we mentioned, we've done another half a dozen Lockheed Martin missions over the last 12-15 years.
You have a high degree of confidence in the whole process there now?
Actually, yes, I do. I think that they have a very good set of processes there. They have a very good team of people. Our other contractors also have good people, and they're coming up to speed on what they need to do in order to have successful missions. Deep Impact was a very successful mission that Ball Aerospace produced for us. DAWN is up there thrusting away. That's an Orbital Sciences mission. So we work with our contractors to engage them and help them understand what it is that we need. I mean JPL has 50 years of experience in planetary space exploration.
Right.
And we don't expect someone who's relatively new to the field to understand everything we do. We have had a longer working relationship with Lockheed Martin, so it's more mature.
But this is still rocket science.
Oh, absolutely. There's nothing routine or commonplace about it. Every mission is unique and presents unique challenges and unique risks that we do our best to try and minimize. But EDL is by no means a sure thing.
Right.
I think we calculated our probability at somewhere in the nineties probability of success, but —
That's pretty good for putting something on a rock flying through space hundreds of millions of miles away.
Well, we think it is. And we really had a perfect EDL. I mean it just went straight down the pipe in terms of being right where we had hoped it would be. But we were robust to contingencies, and except in the very worst of circumstances, we still could've made it down safely and hopefully had a descent mission out of it. As it is, we landed on a huge sheet of ice. And not only was EDL perfect, but the landing location is absolutely perfect for this mission.
Icy, that's what we wanted.
That's what we wanted.
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.
Am I right in assuming that there's very little process separation in the older RAD 6000 boards?
There is no process separation. I mean basically what we —
One bad pointer in one module and —
Exactly.
— you wait for the next update window.
Exactly.
Wow. I could write software like that.
[Laughs] Well —
I won't give you a 90 percent certainty though.
We have strict coding guidelines that we use. We don't allow dynamic memory allocation, for example.
Transcript provided by Wendy Smith
Image credit: NASA/JPL-Calech/University of Arizona -
Show 51 - 72 of 72 discussions



What is Digg?
Check out the new & improved