I read somewhere that it’s mostly based on linux now. Is that right? I assume some of it is custom. One advantage for linux is they can get the source code and tweak it if needed.
Of course it could be Windows 95 
Depends what you mean by “software”. I’m sure both NASA and SpaceX have many many people using Word, Excel, and Powerpoint on Windows boxes.
If you really mean the software at the pointy end, inside spacecraft, that is a different matter. NASA doesn’t do much in the way of spacecraft construction. JPL, and a whole host of contractors, on the other hand do a great deal.
If you mean the operating system on spacecraft, that varies. VxWorks is a very popular commercial embedded real time operating system and was famously used for the Sojourner Mars Pathfinder Rover. Before that, the OS tended to be bespoke. The limited capacity of processors rated to survive in space, precluded a lot of what could be achieved with an off the shelf software system.
James Webb Space Telescope (astoundingly) uses a version of Javascript for managing a great deal of on board operations.
Linux is a very varied thing, and can be built to provide an embedded system. But I doubt it would be considered up to the task of a mission critical hard real time system. There are other open Unix systems as well, for instance BSD comes in a few useful flavours. The world outside of Windows is not just Linux.
A large fraction of what people think of as the operating system isn’t really part of it, and even then, a spacecraft has such different needs in actual operation, that a lot of what is in a common operating system, still isn’t needed.
If you mean the software running systems on the screens in the various mission control rooms, the answer could be any popular OS. What matters more is the platform used to construct the interfaces. That will vary by the time when the system was built. Many modern systems are moving towards HTML-5. But there is nothing intrinsically wrong with systems like Qt, or just banging away with the basic window manager and graphics libraries. Don’t imagine that there are not systems based on Windows 95 still in use. Fancy graphics don’t add nearly as much as one might hope for.
SpaceX uses Linux for all of their flight hardware. That includes the Falcon 9/Heavy, the Dragon capsule, and all of their Starlink satellites. It’s a customized version that does continuous cross-checks between at least three different systems. SpaceX uses fairly ordinary components–no expensive space-rated CPUs or anything. They achieve reliability via redundancy.
For non-flight use, I think it’s a mismash, but it includes Windows.
BTW, a few people on the SpaceX software team did a Reddit AMA here:
https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_spacex_software_team_ask_us_anything/
And a summary:
https://www.reddit.com/r/spacex/comments/nd9ipw/summary_of_spacex_software_ama/
A relevant Q/A:
Q: How does SpaceX get away with using Linux instead of a true real-time operating system on its vehicles? I know the PREEMPT_RT patch makes Linux more real-time, but still doesn’t make it fully real-time. It seems like flying crewed rockets and spacecraft is a place where hard real-time guarantees would be necessary all of the time.
A: While I can’t go into specifics here, we design our software to work without a fully real time OS. We also use a custom build of Linux and fully understand the environment in which our software and OS operates in. Operating in a much more constrained environment (as compared to say the open internet) combined with extensive instrumentation and hardware in the loop testing means we can know that the OS is going to behave as we expect it to when on orbit. -Jarrett
Back in day (early 90s) I worked on the team that provided software for a major upgrade to NASA Mission Control in Houston. It was Digital Ultrix and several other off the shelf products. Previously, the systems were all special built and hard wired; switching to open systems gave them amazing flexibility and control.
The version of the OS they used was at least one version old, but hardened and battle tested. We continued to do security and bug fixes on it longer than our normal support cycle, but it was a basic version of our OS.
It is true that NASA in general doesn’t really built or integrate spacecraft (even at JPL most hands on-work is limited to landers, rovers, and the highly specialized instrumentation design versus actual spacecraft systems) but NASA has historically been on the bleeding edge of flight software development, largely because they were also on the bleeding edge of computing. Although they do farm out a lot of actual flight and instrument software development these days, they are still very heavily involved in software systems integration, software testing, and of course software requirements and interfaces. While software isn’t as visible or ‘sexy’ as propulsion, aerofluids, or structural dynamics, it is absolutely crucial to flight successes as any error in timing or inadvertent reset can cause a complete mission failure, and software is a part of virtually every single mechanism and instrument on a modern spacecraft or space launch vehicle. NASA Goddard Flight Center actually has an initiative (the core Flight System ) to develop a next generation modular and reusable software framework and applications to be used across all NASA spacecraft to reduce both development/testing costs and errors.
As for SpaceX, I can’t speak to the details of their software development save that what they are doing is pretty common among the commercial space launch industry. Having a true real time operating system (RTOS) embedded system in your hardware is less important now than it was in previous decades because of just how fast and reliable processors and memory are now such that any latencies are far more likely to be due to errors in the code than inherent limitations of the hardware. There are still crucial systems that require true real time operation by requirement such as autonomous flight termination systems but most of the systems on a launch vehicle or spacecraft have timing requirements that are so much larger than the clock speed of a modern processor that it is easy to run them on top of a near RTOS like VxWorks and have no fundamental timing issues, and doing so makes development and reuse a lot easier.
A lot of modern GUIs in testing and flight console are HTML based, often using a JavaScript front end and even more are going to Python for both front end and back end use because of how easy it is to use and extensible compared to writing the back end in C++ or C# or whatever people use for that.
Stranger
I am not sure what different flavors of Windows might be available to high end engineering applications. But Linux comes in a myriad of flavors and levels. From extremely bare bones to full desktop installations that are at the same operating plushness of Windows.
It is also open source, so the high end tech users can optimize their installation even further.
Linux is of course the OS. The code to be executed can be written to the most base level.
The immediate benefit of Linux is you can get the most stripped down basic OS to run your code on. It is more predictable. Less bloat. Fewer chances for unexpected things to happen that are buried deep in a more complex OS.
Some systems operate on even more bare bones methods than the simplest Linux install.
Well, I’m biased, but software has always been sexy to me. I’ve found NASA’s approach to software to be top-notch since I read Feynman’s Appendix F on the report for the Challenger disaster. Software is the one area where Feynman found no cause to complain:
The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.
To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each.
I bolded what I find to be a key insight, not just for software but for any type of engineering. A failure in verification should be treated with as much seriousness as an actual failure. Earlier testing can fail; that is expected. But verification should be considered to be the same as an actual flight, but in non-catastrophic fashion.
Of course, almost no one wants to pay for this level of reliability. But NASA managed it, at least for a time, with the Shuttle software stack.
quoting Dr.Strangelove’s quote of Richard Feynman
Feynman was pretty far from being a perfect human being, but damn if his brain, and his ability to clearly and directly express the thoughts it generated, weren’t impressive as hell.
An important distinction: A great deal of software, in any technical enterprise, will be run in Linux or some other flavor of Unix. But the vast majority of it will not be based on Linux. Most likely, the vast majority of folks involved in making and using the software will never even look at the Linux source code at all (though they could if they wanted to), and just depend upon it working correctly. And most of the software could in principle be run in any operating system at all, though some might have a few extra hoops you’d need to jump through.
It’s also not clear precisely which software you’re referring to. Do you mean the software on the computers on the spacecraft themselves, or the software on the computer the engineers use to design the spacecraft, or the the software that they use to analyze data that comes back from the spacecraft, or the software that they use to deliver the webpage to tell people all about the spacecraft?
There are all kinds of solutions. For example, something like Xenomai gives you a hard or semi-hard real-time core with a genuine Linux development and/or runtime environment running on top of it. The point of Linux is that it is free software, unlike some alternatives. And of course you are right that some of the higher-level “apps” do not depend on understanding the kernel source code and may not have hard real-time requirements at all.
I mean on the capsule and rockets .