Linked by Thom Holwerda on Sun 12th Aug 2012 22:16 UTC
General Development "I cannot help but speculate on how the software on the Curiosity rover has been constructed. We know that most of the code is written in C and that it comprises 2.5 Megalines of code, roughly. One may wonder why it is possible to write such a complex system and have it work. This is the Erlang programmers view."
Thread beginning with comment 530884
To read all comments associated with this story, please click here.
How
by Treza on Mon 13th Aug 2012 00:38 UTC
Treza
Member since:
2006-01-11

I don't know how things are done in Curiosity but I know a bit about critical software in aircrafts.

- The operating systems are deliberately crippled and very static. Task scheduling is fixed with pre-defined deadlines. For hardcore stuff (flight controls for example), equipments are single-purpose and there is often no "real" operating system, just a scheduler.
The Arinc653 standard for operating systems is now more and more used for "modular avionics" : Multi-purpose onboard computers.

- Safety is usually obtained by using both redundancy and dissemblance. Redundancy by using several identical equipments for fault tolerance, dissemblance by selecting different components and software (including eventually different programming languages) to avoid systematic issues.
For example, Boeing "triple" B777 : Three primary computers based each on three dissimilar CPUs : intel 486, AMD 29k and Motorola 68040.

- The 2.5M LOC can be misleading as often C is not the original programming language (except for some special parts for system control, drivers) but instead an intermediate format generated by higher level tools (for example "SCADE, Matlab"). C compilers are often the most mature, and proven reliable compilers exists for subsets of the C langage. Optimisers are used with a lot of caution.
The auto-generated C code is (deliberately) very dumb and basic (no pointers, global variables at fixed memory addresses...)

I suppose also that for Curiosity there are plenty of backup mechanisms. The software is certainly very very complex but in most of the software, eventual bugs don't compromise the mission and can be patched remotely.

[As an afterthought, I realise that this post is not that much related to the subject. Sorry !]

Reply Score: 9

RE: How
by gpsnoopy on Mon 13th Aug 2012 10:03 in reply to "How"
gpsnoopy Member since:
2007-04-17

I was reading the JPL C coding guidelines the other week. While I can understand the rationales behind most of them, it did look very unpractical. Like for example the no recursion rule, as some very powerful data structures require recursion to be implemented efficiently (trees anyone?).

Luckily, I got to talk to someone who used to work on static code analysis on NASA code. Two things struck me:

- They don't always follow their own guidelines. As they can lead to worse and buggier code (see the recursion example above).

- These guidelines are written by researchers and paper pusher. The actual coding is done by an entire different group of people. IMHO it shows in the guidelines, as they sound nice in theory but I can see so many problems with them in practice.

While NASA (and similar agencies) are always proud of their strict rules and rugged procedures to produce perfect code and spacecrafts, one has to remember that these are also part PR stunt and that reality is always a lot greyer.

Reply Parent Score: 2

RE[2]: How
by kwan_e on Mon 13th Aug 2012 13:18 in reply to "RE: How"
kwan_e Member since:
2007-02-18

it did look very unpractical


It's even more impractical if a coding error requires tons more rocket fuel and metal to fix.

Reply Parent Score: 3

RE[2]: How
by viton on Mon 13th Aug 2012 16:04 in reply to "RE: How"
viton Member since:
2005-08-09

as some very powerful data structures require recursion to be implemented efficiently (trees anyone?)

Recursion cannot be checked statically.
You can emulate recursion iteratively with custom controlled stack. It will also be faster on RISC architectures. Recursion is dangerous (it could break through the limits of allocated stack for example)

As they can lead to worse and buggier code (see the recursion example above).
Bad example. Recursion (via recursive calls to itself) doesn't work nice with modern hardware anyway.

Reply Parent Score: 2

RE[2]: How
by ilovebeer on Mon 13th Aug 2012 17:28 in reply to "RE: How"
ilovebeer Member since:
2011-08-08

While NASA (and similar agencies) are always proud of their strict rules and rugged procedures to produce perfect code and spacecrafts, one has to remember that these are also part PR stunt and that reality is always a lot greyer.

Wound you mind elaborating on why you think NASA having struct rules & procedures is "part PR stunt"?

Reply Parent Score: 2