Thousands of spacecraft have flown in space and almost all of them have used unique software stacks. Incredible amounts of resources have been spent reinventing the wheel time and time (and time) again. And, worse, every company decides to create their own "special" flight software that is poorly documented, held together with duct tape, and struggles to meet certification. And then, after all the miracles are worked, key staff leave the company and take lessons with them that don't translate to the new company's software. You could visit with any flight software team and they'd tell you horror stories.

It's madness.

NASA faced the same challenges and eventually said, "We have got to do better". So they invented their "core Flight System" (which they call cFS) and they fly all sorts of missions with it. (The 'c' is lowercase because it's a "little" and "lightweight" core.) And, incredibly, they decided to make it open-source software that anybody in the world can use.

To hammer on how awesome it is, NASA is using it for their next space station. They're investing years and millions of dollars to human certify it. That is a BIG deal.

And it's free. To put this in perspective, companies would charge you hundreds of thousands of dollars for this if they developed it.

Finally, it's worth pointing out that it's not just space missions using cFS. Drones and underwater vehicles are using it. And people are looking at it for robots. When you spend the time to understand cFS, you're developing a career skill that will make you valuable to all sorts of programs.

What it does

cFS provides both the foundation and the structure for you to hang your mission logic. You've got to paint the walls and frame the windows but a lot of the heavy work is already done for you.

More technically, it talks to the operating system, moves data around, handles timing, tracks events, runs the boot-up process, and manages resources. Importantly, it also hosts free "apps" that you can select from, similar to a cell phone's apps. These apps include file management, scheduling, and telemetry requests.

A key benefit of cFS is that it runs on an operating system like RTEMS, freeRTOS, Raspbian, VxWorks, and Linux. This means the software you develop for one satellite works just as well on another satellite with different computer hardware. In fact, teams often develop their code on a low-cost Linux machine knowing it will run the same way on whatever operating system they end up using on their flight system.

Think of it as a Taco Bar: all the ingredients are laid out for you and you build what you want. If you don't want tomatoes on your taco, don't grab them. Similarly, if you don't need a way to store files, then don't use that app. But it and others are available if you want them.

cFS can be put together to make what you need

What it doesn't do

You'll still need to write your specific mission algorithms. For instance, if you're using a camera to dock with the space station, you'll need to get the camera's data from cFS, run your algorithm, and send your results back to cFS as instructions. Or, if you know you need to point at Svalbard four times a day to downlink data, then you'll need to create that table of events and upload it to the satellite.

It also doesn't hold your hand. The code is C/C++ and the documentation is good if you invest the time to study. People are working to improve things in this area, including us, but be prepared to think through things to take the best advantage of the potential power.

More details

The "S" in cFS stands for "system" and points to cFS being three layers of software that stack to create the full product. The three layers are:

1. Operating System Layer: Documentation calls this "OSAL". This layer talks to the operating system. The other cFS layers do not do this, they only talk to the OSAL. This is what makes your code reusable. Your algorithms run in cFS and have no idea what hardware or operating system you're using.

2. Core Flight Executive: Documentation calls this "CFE". This is the brain of the operation. And the traffic signal. It's what apps talk to, what your sensors talk to, what the ground talks to, and so on. It also handles timing (experts will tell you is much harder than many people appreciate). And it handles startup and tables, two critical functions that can be hard to get right.

3. App Layer: This is where your mission logic, special algorithms, and higher-level programs run. NASA provides several common apps for free and templates to help you create your own.

The image below shows this in casual terms.

cFS layers

Free tools are also provided by NASA (and us). NASA's tools include unit testing, a performance analyzer, a simple Python-based ground system, the cMake files, and a simple App generator.

A Little History

NASA's Goddard Space Flight Center (GSFC) developed the cFS over many years on many successful missions. The initial effort started with a team of senior engineers that performed a structured heritage analysis of missions covering more than a decade. The diversity of the heritage missions (single vs. redundant components, varying orbits, different operational communication scenarios, etc.) provided valuable insights into what drove commonality and variability across the missions. The team considered the entire flight software lifecycle including in-orbit sustaining engineering, as they performed their analysis. They identified system and application-level variations to address the range and scope of the flight systems domain. A primary goal was to enable portability across embedded computing platforms and to implement different end-user functional needs without the need to modify the source code.

The resulting core Flight Executive (cFE), including the platform abstraction layer, was first used on the Lunar Reconnaissance Orbiter (LRO) launched in 2009. The initial suite of cFS applications was first used on the Global Precipitation Measurement (GPM) spacecraft launched in 2014. In January 2015, NASA released the entire cFS software suite as open-source software under the NASA Open Source Agreement (NOSA). With each iteration, components were incrementally developed and publically released. In 2020, everything was converted to the more permissive Apache 2.0 license.

This image shows that many of the seeds of cFS were planted as far back as 1992 with the SAMPEX mission. Many of these may be missions you've never heard of. A lot of times that's good news because that means they worked well! Over generations of spacecraft, more important and expensive missions began adopting the code including the James Webb Space Telescope, a system famous for scrutinizing every detail.

cfs_history

Final Thoughts

NASA took a bold step forward in creating and distributing a great software framework you can use on just about any vehicle mission including in space, in the air, or underwater. They've been working on it now for close to two decades and still going strong, too, so you can trust that it's going to be around for a long time.

There are challenges: documentation is good (sometimes great) but tends to rely on you being comfortable with writing code in C. And, like anything that's powerful, there's a bit of complexity that requires you to study if you want to be proficient.

We believe, though, that the investment is worth your time. It would take you years to duplicate what they've done and, by then, they'll have moved on to an even better release. We warmly recommend cFS to you.