Linked by Thom Holwerda on Mon 6th Aug 2012 14:42 UTC
OSNews, Generic OSes 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.
Order by: Score:
Not new
by zima on Mon 6th Aug 2012 14:56 UTC
zima
Member since:
2005-07-06

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

Reply Score: 4

RE: Not new
by Treza on Mon 6th Aug 2012 18:34 UTC in reply to "Not new"
Treza Member since:
2006-01-11

is there some internal movement to make x86 the "premier" architecture, towards some radiation-hardened x86 chips?

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.

Reply Score: 8

RE[2]: Not new
by zima on Mon 6th Aug 2012 19:26 UTC in reply to "RE: Not new"
zima Member since:
2005-07-06

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?

Reply Score: 2

Historically they *haven't* been bug free
by tggzzz on Mon 6th Aug 2012 14:59 UTC
tggzzz
Member since:
2005-09-06

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."

Reply Score: 2

VxWorks at JPL
by mkowalik on Mon 6th Aug 2012 15:15 UTC
mkowalik
Member since:
2012-08-06

Hi,

related topic, although from a bit different angle. vxWorks mentioned couple of times:

http://www.flownet.com/gat/jpl-lisp.html

Reply Score: 2

IBM product saved the day last mission
by jefro on Mon 6th Aug 2012 15:36 UTC
jefro
Member since:
2007-04-13

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.

Reply Score: 2

Micro-kernel and security conscious.
by moondevil on Mon 6th Aug 2012 15:42 UTC
moondevil
Member since:
2005-07-08

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

Reply Score: 8

kjmph Member since:
2009-07-17

Whoa, awesome read. I like the explicit cast to (void) for return code checking.

Reply Score: 1

ingraham Member since:
2006-05-20

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.

Reply Score: 2

TomR Member since:
2012-08-07

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.

Reply Score: 3

ingraham Member since:
2006-05-20

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.)

Reply Score: 1

moondevil Member since:
2005-07-08

I am fairly certain that VxWorks is not a micro-kernel based system.


Oh, I lack VxWorks experience, so I just inferred that from the documentation, maybe due to my bias in favour of micro-kernel architectures.

Reply Score: 2

Cisco CSS/Arrowpoint
by tony on Mon 6th Aug 2012 16:38 UTC
tony
Member since:
2005-07-06

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.

Reply Score: 2

Bugs in space
by ShadesFox on Mon 6th Aug 2012 20:30 UTC
ShadesFox
Member since:
2006-10-01

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.

Reply Score: 2

Comment by MOS6510
by MOS6510 on Tue 7th Aug 2012 06:09 UTC
MOS6510
Member since:
2011-05-12

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.

Reply Score: 4

RE: Comment by MOS6510
by anda_skoa on Tue 7th Aug 2012 07:05 UTC in reply to "Comment by MOS6510"
anda_skoa Member since:
2005-07-07

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 ;)

Reply Score: 2

RE[2]: Comment by MOS6510
by MOS6510 on Tue 7th Aug 2012 07:24 UTC in reply to "RE: Comment by MOS6510"
MOS6510 Member since:
2011-05-12

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

Reply Score: 2

moondevil
Member since:
2005-07-08

According to the discussions on Stackexchange

The code is based on that of MER (Spirit and Opportunity), which were based off of their first lander, MPF (Sojourner). It's 3.5 million lines of C (much of it autogenerated), running on a RA50 processor manufactured by BAE and the VxWorks Operating system. Over a million lines were hand coded.

The code is implemented as 150 separate modules, each performing a different function. Highly coupled modules are organized into Components that abstract the modules they contain, and "specify either a specific function, activity, or behavior." These components are futher organized into layers, and there are "no more than 10 top-level components."



You can read all about it here,
http://programmers.stackexchange.com/questions/159637/what-is-the-m...

Reply Score: 3

zima Member since:
2005-07-06

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 )

Reply Score: 2

Hardware redundancy
by MenDig0 on Wed 8th Aug 2012 11:29 UTC
MenDig0
Member since:
2012-08-08

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).

Reply Score: 1

RE: Hardware redundancy
by zima on Mon 13th Aug 2012 23:59 UTC in reply to "Hardware redundancy"
zima Member since:
2005-07-06

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

Reply Score: 2