Sometimes, despite all ground testing, a new build of software can break a satellite. How does one put in protections to keep this failure from being a permanent failure?

For example, what do you do if for some reason the new software isn't 100% updated? Or if there was an unintended consequence of the new build? How can you ensure you can always fix a problem caused by a software bug?


A typical approach as used on Mars rovers is to keep the previous build on the spacecraft as the default to boot to on a reset. You load the new build and command a boot to the new one. Then you test it. If something goes south, it will reboot to the old build. Or you can command a reboot to the old one. Once you're confident in the new build, you make it the default. Even then you can keep the old build on-board just in case. It can be booted to by setting a bit to use that one and commanding a reset (using "hardware" commands decoded by the radio).

  • $\begingroup$ Some sources and examples would be great. :) $\endgroup$ – Vedant Chandra Feb 7 '14 at 17:22
  • 21
    $\begingroup$ I am the source. $\endgroup$ – Mark Adler Feb 7 '14 at 17:25
  • 3
    $\begingroup$ @VedantChandra Google "Mark Adler", be enlightened. $\endgroup$ – called2voyage Feb 7 '14 at 18:11
  • 3
    $\begingroup$ The operating systems I've seen on spacecraft are not capable of that. If you mean on the ground, then certainly lots of testing is done before it goes up. $\endgroup$ – Mark Adler Feb 7 '14 at 20:54
  • 2
    $\begingroup$ @called2voyage Hahaha I know who Mark is, I wasn't doubting the answer in any way! I just found it interesting and would like a source to read up about this further. $\endgroup$ – Vedant Chandra Feb 8 '14 at 14:04

There are 2 main methods I'm aware of that spacecraft employ. One is what Mark mentioned, that two images are kept on the spacecraft. Usually one of these images is called the "Gold" image, and is never actually updated during flight. This image is thoroughly tested to ensure proper functionality on the ground prior to launch.

The second way is to have 3 layers of software build on top of each other. The Mon 1 image is just a bootloader, which loads Mon 2. Mon 1 and Mon 2 never change during flight, and are thoroughly tested prior to launch. They contain the minimum code required to talk to the satellite, so it can be fixed. The Mon 3 code contains the useful code, and is updated in flight.

  • $\begingroup$ This sounds the same, except for how it's used. The only difference is that you never change the first image that you launched with. You keep replacing the second image. $\endgroup$ – Mark Adler Feb 8 '14 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.