The flight control software for the Space Shuttle was developed to the most rigorous standards that exist today. They went to enormous lengths to prevent bugs from ever threatening the mission and/or the crew. The towering cost of the software makes it seem unlikely to me that this process is used routinely for scientific space missions.

For scientific satellites and deep space probes, you have a similar problem (although without the lives-at-stake element): you have one chance at making your observations (e.g. planet flyby missions), there are billions of dollars in hardware at stake (flagship missions) and no chance to repair or recover.

Yet the impression I get is that scientific spacecraft are developed mostly by the science team, i.e. scientists, not e.g. specialists in the development of high-availability software.
Is that impression correct?
And what methods are used to reduce the risk of software failure on science missions?

The reason I'm asking specifically about scientific space missions: commercial missions often take advantage of series production so the cost can be spread, and the amount of new functionality on the average commercial mission is small. These missions can also be insured. Scientific space missions tend to be uninsured one-offs.


No, scientific spacecraft are not developed by scientists on the science team. They may develop their instruments, but not the spacecraft. The spacecraft are developed by professional spacecraft engineers in the government or industry.

The software engineers are trained in software engineering, and in particular in high-reliability, real-time software. There are a set of rules and verification approaches used to develop high-reliability software, and there is extensive software testing both in software testbeds and on the spacecraft hardware.

You can read the JPL C coding standard for an example of such a set of rules. These rules were produced by JPL's Laboratory for Reliable Software, established specifically to improve the reliability of the critical software on one-off scientific missions. It was run by Gerard Holzmann, an expert on the automatic verification of software correctness.

  • 1
    $\begingroup$ The link to JPL C coding standard is inoperational at 2020. I have found another link, probably to this standard. $\endgroup$ – Peter Nazarenko Aug 7 '20 at 12:42
  • 1
    $\begingroup$ @PeterNazarenko Thanks. Fixed the link. Removed another one. Gerard is no longer at JPL. $\endgroup$ – Mark Adler Aug 9 '20 at 1:15
  • $\begingroup$ The JPL C coding standard was written by someone or someones who are very good at that type of document: It states not only the rule, but the why, in plain language. It's kind of fun to read, actually. $\endgroup$ – Wayne Conrad Aug 9 '20 at 1:57

I do want to add that while the spacecraft software is not developed by scientists, it's not uncommon for the scientists to develop (At least in part) post-processing software for the spacecraft that runs on the ground. This software, while important, doesn't require the same level of coding standards as ground software. Still, software engineers will write the more difficult parts of the code, essentially leaving scientists to piece together existing tools to post process the images exactly as is desired.


About software testing :

The ESA software (particularly developed by France) used on Ariane was (is?) written in ADA; This language relies a lot on ranges of values. For example, you don't just declare an integer, you must say if they are positive integers, and how high they can go. And an exception is raised when the values reach the lower or higher limit.

It sounds silly, but it allows you to develop an entire mathematical model of software testing and proving.

In other words : You can start heavily testing your software in an automated way, and for what you cannot automatically test, mathematics come to the rescue.

That didn't prevent the bug on Ariane 5, though, which went off-course specifically because of a mistake in allowed values range.

About software corruption:

I don't know what methods they use for dealing with code redundancy errors (caused by strong magnetic fields/radiations/etc.) but I know that's another huge field of research.

  • 1
    $\begingroup$ ESA is no French organisation, it is European. See Wikipedia. $\endgroup$ – Uwe Jun 5 '18 at 13:57
  • $\begingroup$ I know. The "slash" applied to the software. The software is or used to be French/European, as in : mostly developed by French people as part of a European organization. $\endgroup$ – jeancallisti Jun 5 '18 at 15:42
  • 1
    $\begingroup$ Yet, an Ariane V launch vehicle veered off course and blew up due to a software bug in code written in Ada. Neither Ada nor any language is a panacea for software bugs. By the way, as far as I know, no one other than US Department of Defense projects uses Ada anymore. $\endgroup$ – Mark Adler Jun 5 '18 at 16:18
  • $\begingroup$ I was simply answering the question asked : "How is the software for space developed?" --> By using more restrictive programming languages and some extended tools (maths and such). $\endgroup$ – jeancallisti Jun 6 '18 at 10:33

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.