One thing about developing satellites, spacecraft, rovers and kin is that they have a big overlap in terms of functionality. From communication, to handling sensors, propulsion, managing data storage, task scheduling and so on, the teams over at NASA have found over the years that with each project there was a lot of repetition.
Either they were either copy-pasting code from old projects, or multiple teams were essentially writing the same code.
To resolve this inefficiency NASA developed the Core Flight System (cFS), a common software framework for spacecraft, based on code and lessons from various space missions. The framework, which the space agency has released under the Apache license, consists of an operating system abstraction layer (OSAL), the underlying OS (VxWorks, FreeRTOS, RTEMS, POSIX, etc.), and the applications that run on top of the OSAL alongside the Core Flight Executive (cFE) component. Here cFS apps can be loaded and unloaded dynamically, along with cFS libraries, as cFS supports both static and dynamic linking.
There are a few sample applications to get started with, and documentation is available, should you wish to use cFS for your own projects. Admittedly, it’s a more complex framework than you’d need for a backyard rover. But who knows? As access to space gets cheaper and cheaper, you might actually get the chance to put together a DIY CubeSat someday — might as well start practicing now.
Interesting. I wonder how soon there will be a freeRTOS based distribution of this for RP2040, ESP32 or EFR32.
And then the real fun starts with hobbyist cubesat formfactor tabletop simulator models.
There has been several Cubesat projects funded on Kickstarter. I paid for one myself.
Amazing how this doesn’t fall under ITAR.
Even more amazing is how this is simply “one stop shopping” , heck more like “grab and go for free”, for America’s adversaries. Hey Russia, North Korea, Iran, feel free to take all this IP – courtesy US Taxpayers. No need to do any hard work of your own ! You can catch up to us – no thanks necessary.
Enjoy !
A big ” smh “.
It’s just a way we can check our privledge.
Well, use it because there is no back door :)
I’m not worried about it. It’s rover control software, not rocket guidance. And it has been re-hashed and re-hashed so much by NASA that they made a framework from it. Clearly not new ground
As someone who actually looked at what software they are providing, literally none of it controls avionics or does any trajectory calculations. It’s more like a template for building RTOS software that won’t suffer common software related failures.
I mean, it’s not exactly rocket science, is it.
Of course not. Every mission is unique in at least one way, but almost always many more than that. They do have some common applications, like memory integrity checks and CCSDS command/telemetry. I personally haven’t used cFS but have worked with other frameworks like this. There are even companies that license their frameworks which usually include drivers for common components (reaction wheels, star trackers, ADCS algorithms, etc.). I’m not aware of any launch vehicles using this, cFS targets spacecraft. From what I’ve seen, launch vehicle software is always “from scratch”, but GNC algos may be based on previous flight algos.
In terms of software, ITAR mostly covers guidance code, and that’s not included in the cFS distribution.
> the underlying OS (VxWorks, FreeRTOS, RTEMS, POSIX, etc.),
POSIX isn’t an OS – rather, it’s a set of standards for OSs to follow.
https://en.m.wikipedia.org/wiki/POSIX
And the OSAL only uses POSIX calls under Linux! On VxWorks and RTEMS, it uses other OS native calls.
RTEMS cFS deploymentsncan use either the native RTEMS or POSIX adapters. The one using RTEMS specific APIs is older.
Woohoo! Glad y’all picked up on this! cFS is a joy to work with and definitely was a really fun part of my career when I wrote applications for it. GSFC writes great code. Tight, modular, and light! Most frameworks could learn from cFS. Plus, the CCSDS standards used for telemetry are great for lots of embedded designs. I keep wanting to use them for something else too.
I wish it came with a better ground gui, most people seem to end up hacking grafana into something usable, but that’s not a great solution.
Happy to answer any questions people have.
I figure I’ll write out a few of my likes and dislikes after using cFS professionally.
The good:
1. It’s light and modular. A lot of software systems claim to be modular, but are in fact layered in ways that aren’t interchangeable. cFS is truly modular and each of the parts can be reasoned about it in isolation.
3. Multi-OS networked real time computing (This is also separately a feature of RTEMS)!! Using the SBN application to forward messages between computers, a system using cFS can have lots of different computers that run different applications on the same vehicle. Run it over any transport you want since cFS is so modular and easy to hack on!
2. It’s plain C. It compiles in under a minute on most systems. All the development tools ‘just work.’ Other frameworks take dozens of minutes to crunch C++ and still accomplish less.
3. It’s designed around really good telemetry standards, which are separate from cFS. This means it can be interoperable with lots of other systems!
4. Configuration can be defined separately from from your application and updated in flight. Not only is it easy to code for, it’s designed to be maintained in flight for years.
The meh:
1. It requires a filesystem. This isn’t a crazy requirement for most systems, but even modern safety critical systems may not include one of these.
2. It doesn’t support multiple instances of the same application! Most internal routing is based on integer message IDs, so multiple instances of an app will have the same logging and telemetry IDs. This can probably be worked around, but it’s not a normal use case.
3. CCSDS EDS (XML based telemetry definitions) never made it to mainline cFS. You define everything in C structs, with all the foot guns that that involves.
4. Application code depends on the message definitions for other apps. The are now macros like #if HAVE_$(APP NAME) that make conditional includes much easier but this is still a little tricky to work with and breaks some of the otherwise decoupled nature of the applications.
5. I haven’t seen as much software reuse as I would have hoped. Everyone seems to have to write their applications from scratch anyway. I think this relates to the point above how messages are defined, imported, and used.
6. Not enough people use RTEMS! Please, would someone at Hackaday please write an article on it? It’s another piece of wonderful, long running open source C code and more people should know about it.
I know that’s more gripes than positive features, but please don’t count it against cFS! Most other frameworks have more complaints than I can count. cFS stands out as a shining gem of software engineering in a sea of otherwise miserably complex and bespoke systems. Please, ask me questions! I will try and answer whatever I can about it.
Thanks for the RTEMS compliment. It has a 30+ year history as an open source project. There are a lot of features and we try to make it easy to port to RTEMS. But being library based, code size is based on what you use
I would be happy to answer questions if someone wants to do an article or just learned more.