Operating System Basics

Key Points

  1. Operating systems help you reuse code, provide tasking and scheduling, provide a file system, provide network communications, and are more flexible than hard-coded, hardware-specific solutions.

  2. Not all spacecraft use operating systems, but the ones who do opt for a real-time version.

  3. The primary options are RTEMS, Linux, and VxWorks. FreeRTOS may become more popular over the next few years.


Spacecraft that use operating systems use real-time (or close enough to real-time) operating systems. Traditionally, this has been because every clock cycle and bit of memory matters. Consider the ISS, which is traveling at about 7,700 kilometers per second. If it takes you a second or two to call a location-critical function, you can miss your target by a big margin.

When you choose to go with an operating system, you do so because you can:

  1. Schedule events: Having a way to start things at precise times matters when microseconds matter. Also important is a way for high-priority tasks to interrupt low-priority tasks. You wouldn’t want a routine health check to block you from listening to an important command, for instance.

  2. More easily switch hardware: Operating systems can run on different boards and processors so that your algorithms work without changing anything. Space organizations have had to write custom code for every new set of electronic hardware at great expense, so this is a big deal.

  3. Use a built-in file system: Being able to store and retrieve data in files without having to write your own approach is another time-saver. It’s also an area where customers will double and triple-check you get right, so going with a certified solution here can save time and money.


There are many operating system options, although only a few see significant use. The list below covers the popular options.


No Operating System

For simple algorithms on simple hardware, the best operating system may be no operating system. If it’s okay for your timing to be off by a second and/or you don’t have a dozen (or even hundreds of) tasks competing for processor time and/or it’s okay if you reboot periodically to clear errors then a “Super Loop” approach may work just fine. 

Arduino-based CubeSats are an example of this type of approach. If you’ve programmed an Arduino or even a Matlab or Python script, then you’re familiar with “Super Loop” approaches where you start at the top of the script then work line-by-line until you reach the end and start back at the top. Nothing can interrupt the loop unless you program in a periodic break to check if something more important is going on. This wouldn’t work for commercial systems that have to handle lots of data and tasks, but a CubeSat measuring magnetic fields and streaming data down once a day would work out just fine with this approach.

In this same category would be a system running off an FPGA. Modern FPGAs can be designed with processors inside them. They also have plenty of memory, table tools, network protocols, and more. In this scenario, you’re likely building a state machine highly customized for your mission.




RTEMS is the “Real-Time Executive for Multiprocessors Systems”, an open-source, real-time operating system. The European Space Agency (ESA) and NASA have both used RTEMS on flagship missions. And major aerospace companies like Thales have modified the software for their commercial operations. Perhaps the biggest endorsement is that key software architectures like Core Flight Software and F’ (F prime) have both been designed to run on RTEMS.

One reason it’s so popular for space applications is that it was originally designed for missiles, which need tight real-time capabilities so they can maneuver in fractions of a second. And, because the US military used it, it was designed from the beginning to be robust to failure. Another reason is that it’s designed for multiple processors, unlike some operating systems that do better with one or two options. 

If you go this route, the current recommendation is to go with their 5.1 version. This is the one that NASA and ESA are investing resources in to stabilize and build around for the next few years. It’s also been chosen for the Core Flight and F’ architectures.

Finally, if you’re looking for support, the Online Applications Research (OAR) corporation runs the overall maintenance of RTEMS and can consult with you on your needs.




The vanilla version of Linux is not real-time, but you can configure it with flags to get closer to what you need. You can also find pre-configured, specialized options such as RTLinux. And, if you know what you’re doing, you can of course go deep into the operating system and customize anything you’d like. 

The benefits of using larger operating systems like Linux (compared to something like RTEMS) include more networking capabilities for larger systems, better graphics options if you need a human interface, and an easier time of finding drivers for off-the-shelf hardware. You will pay a price, though, in performance since all of these things require computational power and additional memory.

SpaceX famously uses a variation of Linux to run its systems and NASA signed off on it as safe for humans. And some would argue that, while it’s true that Linux demands more computing power, modern systems have that power to spare. It would not be surprising to see more Linux systems flying in space over the next decade.




VxWorks is a commercial operating system owned by Wind River. A significant fraction (maybe a majority) of large spacecraft run this operating system. 

The argument for and against paying for the operating system vs. an open-source solution parallels the arguments for any software package. You’re going to pay (a lot) for VxWorks, but that money goes to ensuring the operating system is robust, well documented, certified, and that it will exist for years to come. Running software in space is fraught with challenges including communication latency, radiation effects, and an inability to fix some things after you launch it. Going with a commercial company that has solutions for all of these things is a good way to improve the odds of mission success.

A tangential benefit is you’re more likely to find VxWorks developers than RTEMS developers, for instance. Because VxWorks is used in many industries, for a wide variety of applications, you can hire from a larger pool of people.



This is the most popular real-time operating system in the world. It’s owned by Amazon now and has been receiving consistent attention and excellent documentation. It has also flown on a few CubeSats so has space heritage for simple missions. To date, none of the major space software architectures have supported it, though, so you’ll likely have to write custom code or connect with a university group that may have a starting point for you. Amazon has been making a larger push into the space industry so this is something to watch over the next few years.



Kubos is a company that created the KubOS satellite software architecture that runs on a modified version of Linux they call Kubos Linux. All of the software is open source. Notable is that they support popular CubeSat computing platforms including Pumpkin, ISIS, and BeagleBone. They also have built-in support for components such as radios.

Around the 2020 timeframe, the company pivoted towards cloud-based mission operations software. The Github for their software is still up, but it has not seen updates for a couple of years now. There may still be value there for you, though, especially if you’re using the supported hardware.


Wrapping Up

If you’re a small mission, you may not need an operating system. Starting an event a second or two late may not be that big a deal and may not be worth the extra overhead. However, if timing, scheduling, robustness, and code reusability all matter to you then we recommend one of the solutions above.


Curated Videos

  1. https://www.youtube.com/watch?v=F321087yYy4
    Digi-key (one of the biggest electronic component providers) put together an outstanding series on real-time operating systems and how to use them. This first video introduces concepts and is worth watching even if you don’t choose the FreeRTOS path they walk down.

  2. https://www.youtube.com/c/FlightSoftwareWorkshop/videos
    Johns Hopkins hosts a flight software workshop every year. A number of sessions discuss operating systems, including RTEMS.


Curated Links

  1. https://hackaday.com/2021/02/24/real-time-os-basics-picking-the-right-rtos-when-you-need-one/
    Has a great write-up on why you choose a real-time operating system.

  2. https://arstechnica.com/features/2020/10/the-space-operating-systems-booting-up-where-no-one-has-gone-before/
    Ars Technica put together an article comparing VxWorks, RTEMS, and a startup effort called Space Chain. The Space Chain OS seems defunct since around 2020, but the article still has good historical insights and discusses the ESA’s motivations for using RTEMS.

  3. https://www.rtems.org/
    The main page for the RTEMS operating system. They have a link to the 5.1 version right at the top of their home page.

  4. https://wiki.linuxfoundation.org/realtime/start
    There is a separate initiative within the Linux Foundation to create the real-time version. They’ve been migrating to this new page where they discuss what they’re doing differently and their roadmap for changes.

  5. https://www.windriver.com/products/vxworks
    The main page for the VxWorks system.