| News | Features | Interviews |
| Blog | Contact | Editorials |
| On Curiosity and its software |
| By Thom Holwerda on 2012-08-12 22:16:59 |
| "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." |
|
| This is a nice summary |
| By sukru on 2012-08-13 00:33:23 |
|
Having strict quality guidelines, and isolating systems as much as possible is great. However, my concern is the recent "brain transplant". Why are they doing a complete OTA software update right away? Isn't it too risky? |
 - Score: 2 |
| How |
| By Treza on 2012-08-13 00:38:43 |
|
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 !] |
| - Score: 9 |
| RE: This is a nice summary |
| By zima on 2012-08-13 00:59:02 |
|
I see it as somewhat less risky - for the landing (and post-landing checkout) they used a more specialised, more basic software. Now, the rover will start using the more complex main mission software - one that was uploaded to it fairly recently, when the probe was en route, so presumably also with more time for debugging (plus, I imagine that software update procedures are among the best tested; and that they're doing it one of two redundant computers at a time) In another update: more & also colour pictures! http://commons.wikimedia.org/wik... (and I guess this Commons page will have a decent selection, in the future - bookmarked) |
| - Score: 2 |
| codng at NASA |
| By l3v1 on 2012-08-13 06:18:25 |
|
"They Write the Right Stuff" http://www.fastcompany.com/28121... It's a bit old, but still a good read, giving some insight. On "Some of the traits of the Curiosity Rovers software closely resembles the architecture of Erlang. Are these traits basic for writing robust software?" - Well, I'd say it doesn't resemble Erlang, but it does resemble good thinking and good engineering, which might have been the case with Erlang designers too (which I don't know). On the other hand: Megalines? Really? That's not geeky, that's stupid. What comes next, hectolines? |
| - Score: 7 |
| RE: codng at NASA |
| By kwan_e on 2012-08-13 08:17:57 |
|
> On the other hand: Megalines? Really? That's not geeky, that's stupid. What comes next, hectolines? Should be mebisloc. Megalines is ambiguous as to whether it's a large number of lines, or just a number of huge lines. |
| - Score: 3 |
| RE: This is a nice summary |
| By kwan_e on 2012-08-13 08:24:31 |
|
> Why are they doing a complete OTA software update right away? Isn't it too risky? That's what you get when you release beta version as the point zero release and the stable version as the point one release... |
| - Score: 1 |
| RE: How |
| By gpsnoopy on 2012-08-13 10:03: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. |
| - Score: 2 |
| RE: codng at NASA |
| By Treza on 2012-08-13 13:02:33 |
|
This is indeed a good article. There is the old divide between "hackers" and "engineers". Critical software is done by engineers : There is no very clever hack, software must be readable and modified for more 20 years, and everything is aboundantly documented and based on requirements which are later verified. The software must do exactly what it is expected to do, nothing more. Of course, it is extremely expensive and it is certainly pointless to use this development method to all software, and it certainly stifles creativity. |
| - Score: 2 |
| RE[2]: How |
| By kwan_e on 2012-08-13 13:18:20 |
|
> it did look very unpractical It's even more impractical if a coding error requires tons more rocket fuel and metal to fix. |
| - Score: 3 |
| RE[2]: How |
| By viton on 2012-08-13 16:04:40 |
|
> 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. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |