F´ (F Prime): NASA's Component-Driven Flight Software Framework

What F´ Solves and Who It Is Built For

Flight software tends to grow into a knot of threads, queues, and hand-written serialization code. F´ attacks that by making the component the unit of design. The README describes it as "a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications," originally developed at the Jet Propulsion Laboratory and deployed on several space applications. It is, in the project's own words, tailored but not limited to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments. That scope matters. A team building a payload controller with a handful of sensors, a command interface, and a telemetry stream is the target user. A team writing a bare-metal interrupt handler for a motor driver is not. The framework is also a fit for anyone who wants the same architecture on a workstation and on a target board, because the repository ships separate directories for the OS abstraction layer (Os/), the framework core (Fw/), drivers (Drv/), and standard services (Svc/).

Components, FPP Models, and the Ground Data System

The mechanism is code generation from models. F´ provides "modeling tools for specifying components and connections and automatically generating code." Those models are written in FPP, and the repository carries an Fpp/ directory alongside the generated-code consumers. A component declares its ports, commands, events, telemetry channels, and parameters; the toolchain turns that declaration into C++ that plugs into the framework's message queues and threads. The README lists those queues and threads as core capabilities of the C++ framework itself, so the generated code is not a thin wrapper, it is wired into a runtime that already handles concurrency.

On the ground side, the requirements file pins fprime-gds, the ground data system, along with fprime-fpp for the modeling toolchain, fprime-tools for the CLI, fprime-visual, fprime-xtce, and fprime-yamcs. That is a lot of Python in one dependency list, and it tells you where the project's center of gravity sits: the C++ runs on the spacecraft, the Python tooling runs on your workstation and talks to it. The dependency list also pins specific versions, which means an F´ checkout expects a known set of libraries rather than whatever pip resolves today.

Installing F´ and Building a First Project

The README gives a two-step path. First install the bootstrapping tool, then use it to create a project. The tool is distributed on PyPI as fprime-bootstrap.

pip install fprime-bootstrap

With that installed, the bootstrap command creates a new project directory. The README shows it without arguments, and the tool prompts for the project name.

fprime-bootstrap project

What you should see is a generated project tree rather than a bare git clone: the bootstrap tool is what wires a new deployment to the framework, so it is the supported entry point rather than cloning the repository by hand. From there the project points new users at the HelloWorld Tutorial and the User Manual for the remaining steps. The README does not spell out the build commands in the top-level text; it delegates them to the tutorial, which is the honest boundary of what can be stated here.

Before any of this, the system requirements are worth checking. You need Linux, Windows with WSL, or macOS; git; Python 3.10+ with virtual environments and pip; and Clang or GNU C and C++ compilers. A Rust toolchain is optional and only needed for components that depend on Rust. The README is explicit about the fallback: components that require cargo are skipped when it is not found, and the rest of the framework builds normally.

Where F´ Gets in the Way

The optional Rust toolchain is a good illustration of a real constraint. If a component you want depends on Rust and you do not have cargo and rustc installed, that component is skipped rather than failing the build. Silent skipping is convenient until you wonder why a subsystem is missing from your deployment. The README documents the behavior but does not describe a warning mechanism for it, so verifying what actually got built is on you.

The Python dependency list is the second constraint. It pins cmake, ninja, clang-format, protobuf, pyzmq, Flask, and a long tail of other packages, plus platform-conditional entries such as fprime-jre that only install on specific OS and architecture combinations. Reproducing that environment on a locked-down build machine takes planning. And the framework itself is C++ with a CMake build: the repository has CMakeLists.txt, CMakePresets.json, and a cmake/ directory, so teams whose build system is not CMake-adjacent will feel the friction.

Finally, F´ is the wrong tool when the problem is small. If your embedded application is one control loop with no commanding, no telemetry framing, and no need for a ground station, the component model, the FPP compiler, and the GDS are overhead you will pay for and never use.

F´ Compared with cFS

The obvious comparison in this space is NASA's cFS, the Core Flight System, and it is a real search term for this project. The difference in approach is architectural. cFS is organized around applications and a software bus, with a runtime that routes messages between them and a separate set of labs tools for ground support. F´ organizes around components with declared interfaces and generates the C++ glue from FPP models, so the interface definition is the source of truth and the code is downstream of it. F´ also ships its ground data system as a Python package in the same requirements file as its modeling tools, which means one dependency install covers both the flight-side toolchain and the ground-side console. Which one fits depends on whether you want a message-bus runtime with separately developed apps or a model-driven component framework where the generator owns the wiring. Neither is a drop-in for the other.

Maintenance, Licensing, and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-20. Releases arrive on a regular cadence: v4.3.0 on 2026-08-20, v4.3.0b1 the same day, and v4.2.3 on 2026-09-09. The README's maintainer table shows a CCB with named members and per-product maintainers, including a separate maintainer line for v3.6.x maintenance, which indicates that older release lines are kept alive rather than dropped. That is reassuring for a flight project with a multi-year integration schedule, but it also means you have to decide which line you are on and track it deliberately.

Licensing is Apache-2.0, with LICENSE.txt and NOTICE.txt at the repository root. Apache-2.0 includes an explicit patent grant and requires that you preserve notices, which matters when flight software gets folded into a larger deliverable. This is a description of the license file, not legal advice; the obligations that apply to your product depend on how you redistribute it.

Editorial conclusion

Adopt F´ if you are building a smallsat, instrument, or embedded system where a component architecture, generated code, and an integrated ground data system save more time than they cost. Do not adopt it if your firmware is a single tightly coupled loop, or if you cannot take on Python, CMake, and FPP tooling in your build. Before committing, read the supported-platforms document, run the HelloWorld tutorial end to end, and confirm that a Rust toolchain is or is not needed for the components you plan to use.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nasa/fprime on GitHub
3. Project website
4. README
5. Releases