As the first images of the Mars Curiosity lander start pouring in, let’s talk about what operating system it runs. As I found out via Hacker News, the project runs on VxWorks, a very popular embedded operating system used for truly mission critical tasks. I’d love to know just how much work has gone into making it bug-free – this isn’t the kind of environment where you want code to fail.
Previous Mars rovers also used it, and quite a few other space missions in general: http://en.wikipedia.org/wiki/VxWorks#Spacecraft
(since Intel owns them now – is there some internal movement to make x86 the “premier” architecture, towards some radiation-hardened x86 chips? I imagine Intel could see this as worthy even just for PR)
Other space-used OS that I stumbled on once: http://en.wikipedia.org/wiki/RTEMS – and this one’s OSS.
I would be curious to know what other OS are up there (apart from… well, just look what’s on the screen ;p http://en.wikipedia.org/wiki/File:Iss017e015059.jpg )
About the first images – FINALLY, the promise fulfilled!!111 (I was watching live NASA TV coverage) See, as a kid, I was kinda promised a “live pictures” from the coverage of Pathfinder landing – the announcements of the upcoming coverage, on my national TV network, presented it like that …so the actual coverage felt a bit underwhelming back then.
But not any more – first picture in the first few minutes after touchdown!
Edited 2012-08-06 15:03 UTC
Intel does not manufacture anymore simple CPUs (Pentium class) nor it sells IPs to third parties (unlike ARM).
All current Intel designs are extremely unsuited for really critical applications, as they are far too complex and non deterministic (impossible to prove the temporal behaviour).
In addition, space applications often use special semiconductor processes (>100nm for radiation hard) and modifications of the sources, like, for example, using triple redundancy for registers.
Curiosity is based on a IBM-derived PowerPC RAD750 (G3) running at 200 MHz.
Oh I realize what MSL uses (and others http://en.wikipedia.org/wiki/Category:Radiation-hardened_microproce… ), the constraints and goals, and that Intel doesn’t pursuit them with present designs – thing is, they probably could fairly easily considering their resources, and be quite successful at it (even if only in a decade or two, considering the typical inertia of avionics systems)
Intel does maintain simpler, in-order, sort of Pentium-derived cores – with Atom and Larrabee/MIC architecture.
Anyway, glancing more thoroughly at VxWorks Wiki article in the meantime, I noticed “Native 64-bit operating system[7] (only one 64-bit architecture supported: X86-64)” – so maybe, over time, Intel does plan to make its chips the premium choice for users of that OS (and Intel would probably like the publicity from usage in space missions). Why would Intel buy them out otherwise, anyway?
A famous example is the Mars Pathfinder had a priority inversion bug that caused the computer to repeatedly reset itself.
From http://research.microsoft.com/en-us/um/people/mbj/Mars_Pathfinder/A…
“No, we did not use the vxWorks shell to change the software (although the shell is usable on the spacecraft). The process of “patching” the software on the spacecraft is a specialized process. It involves sending the differences between what you have onboard and what you want (and have on Earth) to the spacecraft. Custom software on the spacecraft (with a whole bunch of validation) modifies the onboard copy.”
Hi,
related topic, although from a bit different angle. vxWorks mentioned couple of times:
http://www.flownet.com/gat/jpl-lisp.html
VXworks and an ibm system was on one of the last missions. When the system failed NASA thought the deal was lost. The system finally lost enough power and automatically rebooted and worked.
I have to say. We use VXworks for some automation. I can’t ever remember an issue with it. We pxe load it from a windows so it goes down well before the vxworks dies.
From what I can see from the VxWorks documentation, it also belongs to the successful micro-kernel family of operating systems like QNX.
It is also one of the embedded operating systems that has Ada as part of the standard set of native supported languages.
As for the Pathfinder, even if it was written in C, most likely JPL guys were following their security guidelines to write safe C code.
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Whoa, awesome read. I like the explicit cast to (void) for return code checking.
I am fairly certain that VxWorks is not a micro-kernel based system. It’s one of the things that QNX brags about as being superior to VxWorks; whether that’s true or not is open to debate, and VxWorks has considerably higher market share in the embedded space. One thing that always disturbed me about VxWorks is that it uses global variables as REALLY global variables. As in every program you run on the system has access to all the global variables of all the others. Naming conflicts can be a disaster. I much prefer message passing, as is native to QNX and OSE.
It used to be true several years ago in VxWorks that all global variables were global, but that was when you could only have kernel applications. Now with Real-Time Processes (RTPs) added, each address space can have its own global variables. They can be of the same name as in other RTPs (or in the kernel) if desired (good for spawning multiple copies of an RTP from one copy in flash to differently named tasks). In multi-core VxWorks SMP, the Memory Management Unit protects all of the data and code in RTPs not intentionally shared. Data can be shared in Shared Data Regions and code in Shared Libraries.
That is good. Globals are bad enough as is; making them REALLY global, with no method for finding namespace conflicts or thinking you’re writing to MyVar1 when you’ve typo’ed it to MyVarl is a big problem (In submission box’s font, you can’t even tell that’s a “one” and an “el”! It’s a little better after it’s “published” to the site.)
Oh, I lack VxWorks experience, so I just inferred that from the documentation, maybe due to my bias in favour of micro-kernel architectures.
The only device I’ve come across that ran VxWorks was the load balancer from Cisco, the Cisco’s CSS (previously Arrowpoint). It was a great load balancer at the time, but Cisco let it atrophy and F5 and other vendors surpassed the CSS. Not VxWorks fault, though.
I know that the Spirit rover had a software bug. Specifically a reboot doom loop. I think it was caused by an excessive number of open files at boot. Though those two rovers also had a setup where the radio had a separate minimal OS that could control the rover OS and was used to supply fixes.
I once saw a documentary where they upgraded one of the Voyager’s systems, but it didn’t work out that well as instead of exploring space it returned back to Earth trying to talk to whales.
Saw that documentary as well, but you are mixing up two different space probes.
The upgraded Voyager returned to meet its creator.
The one looking for whales is a totally different beast, most likely deployed by some future version of Sea Shepherd
Sea Shepherd is cool. They are the non-gay version of Green Peace.
If someone would make a game based on Sea Shepherd it would be an aquatic themed FPS.
SEA SHEPHERD (Xbox 360, PS3)
Fail Whale Strikes Back
According to the discussions on Stackexchange
You can read all about it here,
http://programmers.stackexchange.com/questions/159637/what-is-the-m…
MER reminded me – one can download and run a basic version of the desktop software which is used to control those (well, at this point one of them). Considering their relation, perhaps it’s also fairly close to MSL control software…
http://marsrovers.nasa.gov/relatedsites/
http://mars.telascience.org/home/ (homepage of the initiative, open it through archive.org – OSNews breaks archive.org links; and at least some mirrors with updates, which include actual Mars images, are still up ftp://ftp.net.usf.edu/pub/maestro/ …BTW, an image codec used by MER: http://en.wikipedia.org/wiki/ICER )
Most of the code on current spacecraft/rovers/whatever is somehow buggy. When bugs are quite serious, there is always a piece of software that is amazingly validated to patch the rest of the software.
On the other hand, most of these things have redundancy on most hardware components, so if for example the software runs wild at some point, the hardware detects this and switches over to other processor. Then the ground team can investigate the failure while keeping the spacecraft healthy. Some systems even have several processors running in parallel with priority voting. At least that how we do it here at ESA, I guess at NASA they do pretty much the same (actually it is done in joint projects).
And then there’s safe mode so the spacecraft itself can keep itself healthy/alive (I guess also quite extensively validated)
BTW, it’s easy to stumble (say, a listing in Wiki category that I linked in my comment near the top) that ESA ~makes its own rad-hardened SPARC cores …but what operating systems do you use? Not much luck finding info about it on esa.int
(still, some curious bits… http://www.esa.int/SPECIALS/Operations/SEMYVF3XQEF_0.html – still depending on “old UNIX” workstations?
And the on-board systems themselves http://www.esa.int/TEC/OBCDH/ & http://www.esa.int/TEC/OBDP/SEMYHDFKZ6G_0.html & http://www.esa.int/TEC/Microelectronics/ or my kind of tidiness
http://www.esa.int/SPECIALS/Space_Engineering/SEM4U3KVUZF_0.html …and some pages bragging about the skills with software, but a) not much details b) mostly about grand control softtware)
PS. you won’t come back before the closure of this discussion, but there’s a new one http://www.osnews.com/comments/26271 about “space software” – maybe you can chime in there?
Edited 2012-08-14 00:17 UTC