NASA cFS Bundle: Framework Setup and Mission Boundaries

What the nasa/cFS Bundle Is Intended to Solve

NASA's Core Flight System, or cFS, is a generic flight software architecture framework. The README says it is used on flagship spacecraft, human spacecraft, cubesats, and Raspberry Pi. That range matters because cFS is not a complete spacecraft product. It supplies a framework and a collection of common components that can be selected, configured, and adapted for different mission environments.

The repository is explicitly a bundle containing submodules. The open-source distribution includes cFE, OSAL, PSP, demo applications, libraries, and tools such as Data Storage, File Manager, HouseKeeping, Health and Safety, Memory Dwell, CFDP File Transfer, CheckSum, Limit Checker, Stored Command, cFS Ground System, elf2cfetbl, and tblCRCTool. These components provide a starting point for command handling, telemetry, scheduling, health checks, storage, file operations, and related flight software functions.

The intended users are therefore spacecraft software teams, mission integrators, and developers who understand the relationship between an architecture framework and a mission-ready distribution. The README also distinguishes this open bundle from a flight distribution, which is normally assembled around cFE, OSAL, PSP, and a selection of mission-specific flight applications. The open bundle is a development starting point, not a substitute for that selection and validation work.

How the cFS Bundle Is Organized

The repository layout shows a modular structure rather than a single application directory. The `cfe/` entry represents the cFE portion, while `osal/` and `psp/` represent the operating system abstraction and platform support portions. The `apps/` directory contains application components, `libs/` contains libraries, and `tools/` contains supporting tools. Top-level files such as `.gitmodules`, `Makefile`, `goal-configs.mk`, `target-configs.mk`, and `target-rules.mk` indicate that the bundle coordinates multiple submodules and build configurations.

The architecture is driven by configuration. The repository contains files such as `sample_defs/`, `simple_defs`, `native_std-test.mk`, `native_eds-test.mk`, and `qemu_yocto_linux-test.mk`. These names show that builds are associated with configurations and targets rather than with one universal binary. The Makefile describes paired goals in the form `<config>.<goal>`, with examples including `native.prep` and `flight.test`. This is a concrete sign that mission teams select components and target settings before building.

The bundle also includes a ground-system component and demo apps for command ingest and telemetry output. The README describes those lab apps as examples that enable the bundle to build, execute, receive commands, and send telemetry. That behavior is useful for development, but it does not establish mission readiness. The README says extensive analysis is not performed and places verification and validation responsibility on the mission.

Installing the Bundle and Preparing a Build

The README gives one direct setup step for cloning the bundle. It says to install Make, CMake, GCC, and Git first. Clone the repository from the URL shown in the README. The command below is the only setup command documented in the README.

git clone https://github.com/nasa/cFS.

After cloning, the repository's Makefile documents the available build goals. `prep` runs CMake to create or reconfigure a build tree, `all` builds targets, `install` copies files into the installation tree and runs packaging scripts, `test` runs unit tests defined in the build, and `docs` builds Doxygen source documentation. The same file defines configuration-specific forms such as `native.prep`, `native.compile`, `native.test`, and `flight.test`.

One documented example target is `native.prep`.

The Makefile says that `native.prep` runs `prep` for the `native` configuration. The README does not provide a complete first-run sequence showing the required subsequent target, the generated executable name, or the exact procedure for sending setup commands and receiving telemetry. For that reason, the verified first use is preparation of a configuration, followed by selecting and running the build goals documented for that configuration.

Commands, Telemetry, and Demo Applications

The README says the demo applications make the bundle capable of receiving commands and sending telemetry. It specifically lists Command Ingest Lab, Telemetry Output Lab, Scheduler Lab, Sample App, and Sample Lib as demo elements. These are not presented as an integrated mission command database or a complete operational ground system. They are examples included to help the bundle build and execute.

The repository's build system also includes application, library, tool, and target configuration files. That arrangement suggests that a mission would define its own application set, table data, and platform settings. However, the README does not document the command syntax for the demo command-ingest app, the telemetry packet format, or the procedure for validating received telemetry. It would be incorrect to invent a command sequence based on common cFS conventions.

This distinction affects adoption. A developer can use the bundle to establish a build and exercise command and telemetry paths. A flight team still needs to determine which applications belong on the target, how commands are authorized, which telemetry is required, and how the system behaves under mission-specific faults. The repository's own warning that it has not been fully verified as an operational system is a direct limit on what the demo setup proves.

Mission Readiness, Licensing, and Upgrade Cost

The repository is not archived. The README says cFS follows semantic versioning, with release candidates identified by an `rc[#]` suffix. It also says bug and vulnerability fixes are addressed in the next sequential release and are not backported to prior open-source cFS releases. Users are encouraged to upgrade to the latest version, while users who cannot upgrade are referred to the mission-ready government version discussion.

The open-source release is under Apache 2.0. The README also says that other related capabilities are released under a variety of licenses in their respective repositories. A mission adopting the bundle must therefore review the license of each submodule or related tool rather than assuming that one top-level license covers every dependency. This is a licensing review, not legal advice.

Maintenance and upgrade work include tracking submodule compatibility, selecting the correct cFE, OSAL, PSP, app, library, and tool versions, and reviewing release changes. The README also reports that Memory Manager is being deprecated from the open-source version in the `v7.0.2rc1` release candidate and will continue in cFS Gov with additional security measures. For a mission already using Memory Manager, that is a concrete migration issue rather than a routine version bump.

When cFS Is the Wrong Choice

cFS is the wrong choice when you need a certified, mission-ready flight distribution that can be flown without further integration. The README explicitly says the bundle should not be flown as is. It also says the bundle has not been fully verified as an operational system. The gap is not limited to missing documentation. A mission must perform its own verification and validation against mission requirements.

It is also a poor fit for teams seeking a small standalone command-processing library, a simple telemetry utility, or a complete ground-system product. The bundle is a broad framework with multiple submodules and configuration targets. Its value comes from integrating the right components for a spacecraft architecture, which adds engineering work compared with adopting a narrowly scoped application.

A separate mission-ready option is the Government-use Distro C version described in the README. It is available through a Software User Agreement and is described as including features, certifiability, and security measures for a full flight mission. The difference is therefore distribution and support scope, not simply a different build command. Teams should compare the open demo bundle with their certification, security, support, and licensing requirements before choosing.

Editorial conclusion

Adopt nasa/cFS when you need an extensible spacecraft software framework and can perform mission-specific integration and verification. Do not fly the bundle as shipped. Before adoption, verify the selected cFE, OSAL, PSP, applications, licensing, test evidence, and mission validation requirements.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nasa/cFS on GitHub
4. README
5. Releases