The Core Flight System can save your team many (many) months of work. And it's a flexible framework that lets you use it on many types of projects. However, it has its weaknesses.

It was Built for Single-Core Computers

For decades, space vehicles ran on a single, radiation-hard processor. These processors (and the custom boards that held them) were so expensive and time consuming to build that teams built everything around optimizing that single "Core". (This use of Core is related to a CPU/Processor and is not the same as the Core in Core Flight System). That doesn't mean you couldn't have mutliple threads, though: The benefit of running on an operating system is that it can take a single CPU and "split it" into many threads that each get a slice of time. The cFS uses threads by running a main thread that can spawn new threads that it calls a "Task". For instance, many Apps will run in their own threads and even have child threads of their own.

One of the main challenges with threads is you can get into race conditions. You can search the Internet for "thread race conditions" to find more details, but the basic idea is that splitting work up among multiple threads and CPUs can lead to a mess when you combine the results. 

A simple example is shuffling a deck of cards. Each hand is one "Core". What you want is for each hand to bend its cards back and release them in coordination with the other hand. But if you get the timing wrong, you get a bad shuffle, no shuffle, and/or a big mess. This can happen in computers if a parent thread is looking for information from multiple child threads. If one child thread finishes much faster than the other thread, the parent thread may combine new data with old data and get a bad result. Running multiple threads on a single CPU is not too bad. However, coordinating mutliple CPUs with shared memory and other resources introduces a much trickier set of problems. And this is where cFS can stumble.

NASA is working on a more robust solution for all the new flight computers that come with multiple cores. For instance, they were able to get something working with the PACE mission. And they're working on a more robust solution for the Lunar Gateway mission. But, as of this writing, the general consensus is that more could be done in this area. 

Bottom Line: If your flight computer has a single processor then this isn't a problem for you. And if it has multiple processors then you'll need to talk with the board provider to see what kind of Board and Package Support they offer for cFS since those layers have a lot to do with how well things work in this area.

Side Note: Some programs will not use all the processors for a single cFS instance. They'll avoid all those problems by, perhaps surprisingly, running one independent instance of cFS on each processor! One processor might run an instance of cFS that has the main functions and another processor runs an instance of cFS that handles reading sensors or managing payloads. These are more advanced topics than we'll cover here but it's something to consider if you've got the option.

Versions are Not Backwards Compatible

NASA is doing what's best for NASA and is not concerned with making sure all the code you write will work in the future. If they decide they need to break something to make their framework better, they absolutely will. In fact, as of this writing, NASA is working on version 7 (Draco) and none of the versions are compatible with each other. This means Apps, Tools, compiling directions, and everything else you do has a very good probability of not working if you change versions.

This is a "hot topic" outside NASA since they want to keep their investment worthwhile. Inside NASA, there are sympathetic people but they're trying to fix problems, keep up with hardware changes, and create more robust software. Supporting all the free users with compatibility is not in their best interest (and they don't have the time/money to do it anyway).

Bottom Line: Many teams choose a version of cFS and stick with it for years. A popular choice had been version 6.5. However, enough good things are happening now in version 7 that the recommendation is to start there if you're new.

NASA Doesn't Share its Latest Apps

If you got to the Github repository for cFS, you'll see they're updating the Executive and other layers frequently. In fact, as of this writing, this is how NASA makes sure all the different locations across the country have access to the latest stuff. So you can trust that it's as up to date as anything anyone else has.

But this is not true for the Apps. Apps like command ingestion, memory checkers, and more that you can find on their Github pages are not up to date. They could even be two versions behind (or more). And, since cFS versions are almost never backwards compatible, you can't use the old stuff with with the new stuff. This is a big source of frustration inside and outside of NASA. Many developers in NASA wish they could share the latest version of the apps with you but NASA bureaucracy, lawyers, and funding priorities choke progress.

This means you're on your own for Apps. You can check out the old stuff to see how it works and try to write it to the new version standards. Or you can start from scratch using their App template.

The good news is you've got a great foundation to build on. Even with the work of creating Apps, you're still ahead of the curve in terms of all the framework and infrastructure that you'd otherwise have to write and certify.

Bottom Line: You'll likely have to write your own Apps and/or find Apps in places other than NASA for the version of cFS you're using.

Class A Human-Rated Version May Not be Released

If you're developing a mission meant to host humans on NASA missions, you'll have to certify your software to "Class A". (Most of the rules are described in a document known as 7150.2.) The good news is that NASA is working on certifying cFS to Class-A and much of the foundational code will be released. The bad news is that "Class A" rating also requires lots of paperwork proving testing, certification to standards, and more. Writing all the unit testing code can be just as much work as writing the flight software! Unfortunately, NASA is unlikely to release all the supplemental work so you're on your own.

You also don't get NASA's willingness to write waivers against requirements it set for itself. For instance, Class A requires that the organizations developing the software be certified to something called "CMMI Level 3". But NASA is only certified to Level 2! So NASA has to write a waiver saying that it's okay for them to not meet their own standard. It is uncertain if they'll grant you the same leeway.

Bottom Line: There's a foundation of code but getting NASA agree that you're Class A because they're Class A is not going to happen.

Final Thoughts

cFS does a lot for you but there's still much for you to do. Most of the problems have to do with version control: They break compatibility frequently and they don't release updated Apps. If they fixed either one of these problems, it would boost the community tremendously. As it is, you'll have to get into the code base, learn it well, and create what you need.

Still, if you're starting from scratch, we really believe that you're better off grabbing the latest version of cFS and digging in. You'll save yourselves thousands of hours of labor vs. writing everything from scratch yourself.