8
$\begingroup$

Computer software is arguably the only component of an unmanned spacecraft that can be changed once the mission is already underway. Many spacecraft are now designed to accept new programs through radio communication. There are numerous examples of software updates once the mission has started.

Although the earliest computer software in space was written in assembly language, developers quickly changed to higher-level languages such as Fortran, FORTH, and C. This means it is possible that software is developed in one programming language prior to launch, but redone in a different language once the mission is underway.

Has such a programming language change happened?

  • Refers to the language the developers used, not the machine code running on the spacecraft.
  • Mission may be manned or unmanned.
  • Any type of software (e.g. flight control, data collection, signal encoding, etc.).
  • Inspired by a comment I made in this question.
Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Many experienced software developers would try to avoid that. Even changing the version of the used compiler. $\endgroup$
    – Uwe
    Oct 6, 2018 at 9:34
  • $\begingroup$ I completely agree with Uwe and Darkdust that it is not a good practice. Nonetheless, this would be the question to document any examples. $\endgroup$
    – DrSheldon
    Oct 6, 2018 at 19:03

3 Answers 3

Reset to default
6
$\begingroup$

Flight software for JPL's Deep Space 1 mission (1998-2001) was written in C. A two-day experiment (Remote Agent Experiment -- RAX) was implemented in Lisp. A Lisp interpreter and the RAX code were uplinked to the spacecraft, ran for two days on top of the C flight software, and discarded after the experiment finished. See https://www.cliki.net/DeepSpace1 and https://ti.arc.nasa.gov/m/pub-archive/176h/0176%20(Havelund).pdf

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ Which proves Greenspun's tenth rule: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." $\endgroup$
    – Martin Schröder
    Oct 8, 2018 at 22:08
  • $\begingroup$ @MartinSchröder I don't think the rule was meant to apply to Lisp interpreters. $\endgroup$
    – user253751
    Sep 21, 2020 at 19:08
7
$\begingroup$

I have to agree with everyone here. However, in some instances this is not possible. For example our ISEE-3 spacecraft did not have a processor. We had no idea regarding what the original development environment was and none of the old ground software for development and commanding the spacecraft existed anymore.

All we had was the command strings along with some fairly well documented processes. We did not even know if we had the right command codes as was flown on the spacecraft as that information had disappeared and after 30-35 years none of the original guys remembered it.

You would have to ask some of our guys but we looked at two approaches. The first was using labview's bit manipulation system and we did use advanced programming languages to directly implement and upload bit codes to the spacecraft. So in our instance we had to rebuild everything from scratch and so there was absolutely no way that we were going to try and redevelop the original programming environment.

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ While not strictly meeting the definition of the OP, this information is invaluable. If I understand you correctly, there was no software on the craft -- hardware level logic only. Ground control software was completely redesigned because original had been lost. The ISEE 3 reboot effort clearly deserves more questions and answers on the site. $\endgroup$
    – Bit Chaser
    Oct 6, 2018 at 22:57
  • 2
    $\begingroup$ Bitchaser, you are absolutely correct there. We completely recreated the command system from nothing more than having a sheet with the command codes from scratch in 42 days. We had the telemetry processing system up and running less than 30 days after that. We were able to do a global ground system with the transmitter in Puerto Rico, the receiver in Germany, and ground software processing in California, all in real time. It was a damn fine effort by our team. $\endgroup$
    – Dennis Ray Wingo
    Oct 7, 2018 at 0:57
  • $\begingroup$ Excellent answer! fyi if you're also the unregistered Dennis Wingo here you can merge the IDs. See answers to How can one link / merge / combine / associate two accounts / users? (Anonymous / unregistered / cookie, or OpenID / registered) or just go directly to the Merging Accounts blurb. $\endgroup$
    – uhoh
    Oct 7, 2018 at 1:55
  • 1
    $\begingroup$ One of the things that I learned from the ISEE-3 experience is that very capable spacecraft do not have to be complicated. Say I wanted a constellation of spacecraft in the inner solar system. With a good thermal balance they could last 50 years. Why would I want to have those birds with a software system and development environment that is obsolete in 10 years and dang near impossible to recreate in 30-40 years. Thus long lived spacecraft need to be very simple systems. JPL had a lot of problems finding people to program Voyager since it was so old. $\endgroup$
    – Dennis Ray Wingo
    Oct 7, 2018 at 15:43
6
$\begingroup$

This is more of a comment than an answer since I don't know whether this has been done, but I really doubt mission critical software has switched to a different programming language after the mission started (lift-off).

A change in programming language is a large risk. Every language has its own benefits, disadvantages and quirks that need to be managed.

For example, the C programming languages allows for several constructs that make it easy for the developer to shoot into their foot (e.g. overwrite/corrupt memory) so NASA has a guide on how to use C in its projects and so does ESA (alternative link to the actual ESA C/C++ coding standard since the one from ESAs site didn't load). Depending on the project, even stricter rules may be applied (e.g. no use of dynamic memory allocation).

These rules are often enforced by static analyzers and other tools, so the language is actually part of an ecosystem. Last but not least there should be unit and integration tests. If you change the language you need to change a whole ecosystem and not just the source files of your program.

(There's also actual project management, of course, but I guess this stays roughly the same if you "just" switch a language.)

The development of correct software can be a very tedious and time-consuming task. If you spent months or years developing a mission critical project and then decide to switch the language you need to essentially start from scratch (even if you can port/reuse parts of the original implementation). When you switch a programming language you usually want to do so because the new language allows you to employ coding patterns that solve a problem (e.g. make it easier to implement certain parts or make it safer to do so). But this in turn means that you probably want to at least partly change the design of the original project to make use of these features which introduces even more risks.

Since correctness (or maybe "being able to accurately predict the behaviour") is so important and it's better to work with known issues than introduce new, unknown ones, even changing the compiler (or just the version of a compiler used) is a change that needs to be carefully evaluated. Compilers do have bugs or change the way code is behaving: to use C as an example again, it has so-called undefined behaviour for certain constructs like the famous i = i++ + i++; where the outcome of the expression is explicitly not defined by the standard and every compiler is allowed to do what it wants (the famous joke being it's allowed to make daemons fly out of your nose in this case). If you change the version of the compiler such code may alter its previous behaviour.

The bottomline is: the change in programming language is a very costly (time and money) task that introduces a lot of risks. The benefit of such a switch must therefor outweigh the costs and risks involved. I can imaging this being the case for software used on the ground (stupid example: switch from an old X11 UNIX software written in C to Java) but I have a hard time imagining this happening for software used in flight hardware.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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