Forgot your password?
Mars Software Science Technology

Stress-Testing Software For Deep Space 87

Posted by samzenpus
from the phone-the-help-desk dept.
kenekaplan writes "NASA has used VxWorks for several deep space missions, including Sojourner, Spirit, Opportunity and the Mars Reconnaissance Orbiter. When the space agency's Jet Propulsion Laboratory (JPL) needs to run stress tests or simulations for upgrades and fixes to the OS, Wind River's Mike Deliman gets the call. In a recent interview, Deliman, a senior member of the technical staff at Wind River, which is owned by Intel, gave a peek at the legacy technology under Curiosity's hood and recalled the emergency call he got when an earlier Mars mission hit a software snag after liftoff."
This discussion has been archived. No new comments can be posted.

Stress-Testing Software For Deep Space

Comments Filter:
  • by gadzook33 (740455) on Wednesday October 10, 2012 @10:36PM (#41615239)
    While I buy that the landing systems need an RTOS, I doubt Curiosity does. Image processing that happens with "precision"? Do x86 processors not process images precisely enough? I get the idea of being hardened to radiation but it was my understanding we have newer processors that fit the bill on this. The rest of this seems like a rationalization for using old hardware. However, as an engineer for the government it's possible I'm just old and embittered.
  • by Anonymous Coward on Wednesday October 10, 2012 @10:38PM (#41615249)

    ''recalled the emergency call he got when an earlier Mars mission hit a software snag after liftoff."
    From TFA:

    Back when Spirit Rover landed on Mars in 2004, it experienced file systems problems. I got a call on landing day while I was in Southern California. I fired up my laptop and worked with three groups who were dealing with a variety of time zones: California, Japan and Mars. Since I had a RAD 6000 systems on my desk running simulations, by the end of first week we figured it out and were able to fix it.

  • by Anonymous Coward on Wednesday October 10, 2012 @10:56PM (#41615357)
    At least one instrument [] running VxWorks has been flying on the ISS since 2001. I'd be surprised if it were the only one.
  • by Anonymous Coward on Wednesday October 10, 2012 @11:16PM (#41615489)

    Reminds me of about 10 years ago when I was working at Motorola on cell phone base stations. We switched from VxWorks to Linux and got... nothing. No performance gains, no reliability gains. Just a free OS instead of something we had to spend money licensing.

    Of course, all the extra time spent switching and testing certainly cost a lot of money in man hours.

  • by Anonymous Coward on Thursday October 11, 2012 @12:34AM (#41615869)

    FORTH is great. From about 2 dozen core instructions an entire operating environment can be built. Unfortunately, FORTH takes in-depth knowledge of not only the hardware, but also a firm grasp of scope of the tasks that need to be performed. Most programmers today cannot handle FORTH -- imagine building your own TCPIP stack, filesystem, and RTOS operating environment from scratch. That talent is found only in a dying breed of programmers, literally.

    For a robust 100% reliable radiation-hardened space environment, even the processor, data paths, and memory need to be self-correcting for each data bit. Sapphire-On-Silicon processors are only the beginning of solving the reliability issues. Commercial Off The Shelf solutions are an invitation to disaster, but nobody wants to invest the time and money for proper solutions any more.

    You can thank Just In Time supply chains, quarterly corporate focus on maximizing profits, and Globalization for the current sad state of space exploration. Without a paradigm shift in attitude, there will be no more Voyagers. I know. I used to work for rocket scientists.

  • by Jeremi (14640) on Thursday October 11, 2012 @03:01AM (#41616501) Homepage

    Up through version 5.3 the malloc() implementation was absolutely horrid and suffered from severe fragmentation and performance problems.

    I talked to one of Curiosity's software engineers the day it landed... he mentioned that one of their coding rules was: no malloc() allowed.

Uncompensated overtime? Just Say No.