Core Flight System

The core Flight System is a flight software product line developed by the Flight Software Systems Branch at NASA GSFC. It replaces per-mission software with a layered framework plus a set of pluggable applications, and it has flown on spacecraft from a 6U CubeSat to Class A observatories [1][2]. Where the Mars Exploration Rover software is one team’s 93 modules and 300,000 source lines built for one vehicle [6], cFS is built so that a component can be reused with no source change at all, using compile-time configuration parameters for every point of variation [7].

Why a framework, and what the alternatives were

Flight software has to run a fixed set of housekeeping functions (commanding, telemetry, time, events, tables, fault response) on radiation-tolerant processors with small memories, for years, with no physical access. A NASA multi-center study found flight software size growing steadily with launch year and attributed much of the growth to complexity in requirements, architecture and verification, not to the number of functions [18]. An analysis of 199 critical post-launch anomaly reports from seven flown JPL spacecraft found 41 percent triggered by data access or delivery problems, and about a third involving rare events that then needed new fault protection [19]. Those two results are the argument for a controlled, reused core: the same low level services are rewritten and re-verified on every project, and the defects sit at their interfaces.

The flown alternatives fall into four families, and cFS is one of them.

• Per-mission monolithic flight software with an in-house core. The Mars Exploration Rover software was one team’s 93 modules, 97 VxWorks tasks and roughly 300,000 source lines, built over 35 months for one vehicle, with point to point queues and no broadcast [6]. Mars Science Laboratory grew to 139 modules and about 1.15 million source lines, 68.6 percent auto-generated [17]. Reuse is by heritage and adaptation, and the counting rule behind the source line figures is not stated [17]. An MSL flight software engineer describes an avionics layer exporting atomic functions beneath an application layer exporting activities, with redundancy management hiding dual-string swaps from application components [29].
• A published product line with a controlled core. cFS is the NASA Goddard product line [1][7]. F Prime from JPL is the other NASA family, described below [11].
• Goal and state based autonomy architectures. The JPL Mission Data System was specified as a state and goal based architecture in contrast to timed sequences, and at the time of the paper only goal elaboration, scheduling and failure detection were claimed demonstrated, on a simplified one-dimensional entry prototype [24]. The Remote Agent on Deep Space 1 shaped the flight software architecture of its day, by comparison with a time-tagged sequencer [25]. These sit above the framework layer rather than replacing it.
• Robotic software frameworks. CLARAty defined a Functional Layer and a Decision Layer for reuse across the Rocky, K9 and FIDO rover platforms [26]. ROS has a large ground-robot community, but the measurements in the principal reference volume come from commodity PCs, with no real-time or fault-protection guarantee for flight [23]. A 2025 bridge between the Basilisk astrodynamics simulator and ROS 2 was run on planar air-bearing free-flyers on a desktop CPU, not flight-class hardware [31].

Two older foundations sit under all of these. Rate-monotonic and earliest-deadline-first schedulability conditions for periodic hard-real-time tasks on one processor, derived in 1973, assume independent tasks, zero preemption cost and no blocking, and remain the baseline against which task priority assignment is checked [21]. The SIFT computer put fault masking and reconfiguration into ordinary software voting between independent processors, with reliability numbers that rest on assumed fault rates, not measured ones [20]. cFS inherits the software-implemented, table-driven approach to health and fault response in that lineage; the cited reports do not say so directly, so that link is an inference.

What it is

Four layers [1][2]:

Layer	Contents	Interface
1	Real-time operating system and board support package	OS Abstraction Layer and Platform Support Package APIs
2	core Flight Executive (cFE)	cFE API
3	Applications and shared libraries	cFE API
Tools	Ground system, build system, unit test framework, timing analyzer

The cFE provides five services that the heritage analysis found common to most flight software projects: a Software Bus, Time Services, Event Services, Table Services and Executive Services [3]. The Software Bus is a publish and subscribe inter-application messaging system built on CCSDS packet formats, supporting single and multi-processor configurations. Table Services manage binary files of application-defined parameters that the ground can load and dump at runtime [3]. Event Services carry time-stamped parameterized text messages in four severity classes, filterable per message and per class [1]. Executive Services supply the runtime environment, and because cFE resources are tracked per application, an individual application can be started, stopped or loaded while the vehicle is flying. The framework is developed and maintained to the NASA Class B software process, and the open source release includes all Class B artifacts alongside the source.

The community applications carried by most missions are Checksum, Data Storage, File Manager, Housekeeping, Limit Checker, Memory Dwell, Memory Manager, Scheduler, Stored Command, Health and Safety, CFDP file transfer and a Software Bus network application [3]. Which application object files load at startup is decided by a script file read from a file system in EEPROM, so the load list is data rather than a link map [3].

The eight architecture goals stated for the framework are reducing time to deploy high quality flight software, reducing schedule and cost uncertainty, facilitating formalized reuse, enabling collaboration across organizations, simplifying on-orbit software maintenance over mission lifetimes exceeding ten years, scaling from small instruments to Hubble-class observatories, providing a platform for prototyping, and creating common standards and tools across the center [3]. Features are deprecated only on major versions, with tooling that warns applications using a deprecated feature.

Ported operating systems in the 6.4.2 baseline were POSIX Linux for development, RTEMS, VxWorks, VxWorks SMP and FreeRTOS, each with its own platform support package [1]. The reference distribution ships PROM boot flight software and board support package beneath that layer, and the framework itself has no boot responsibility [3].

Three trades made early fixed the shape of the layering: a custom publish and subscribe software bus over CCSDS packets rather than CCSDS AMS or a COTS message service such as NDDS, a vendor file system used uniformly for code, tables and the data recorder, and support for both dynamic and static application linking so a CubeSat with 800 KB of flash and 2 MB of RAM could still fit the framework [7]. The sizing target explains why the layering stayed thin enough to reach a 6U CubeSat at one end and Hubble-class observatories at the other.

What it cost, measured on GPM

The Global Precipitation Measurement observatory, launched 27 February 2014, is a NASA Class B mission with articulating solar arrays, a gimbaled high gain antenna and nearly fully redundant hardware under flight software control [1]. It flies a RAD750 under VxWorks with 4 MB of EEPROM in two duplicate 2 MB banks and 24 MB of SRAM.

Component	Logical lines of code, non-table	Configuration parameters	EEPROM bytes
cFE	12,930	139 across five services	341,561
CFDP	8,559	33	85,812
Checksum	2,873	15	35,242
Data Storage	2,429	27	40,523
File Manager	1,853	22	16,272
Health and Safety	1,531	45	15,071
Housekeeping	575	8	8,059
Limit Checker	2,074	13	31,026
Memory Dwell	1,035	8	8,617
Memory Manager	1,958	25	15,840
Scheduler	1,164	19	35,809
Stored Command, 124 command sequences	2,314	26	104,960

Source: [1], Table 3.

EEPROM is the most constrained resource on GPM and the cFS occupies about 35 percent of one 2 MB bank; the cFE image and application table images in that column are uncompressed while the application code images are compressed [1]. By lines of code the cFS accounts for 42 percent of the GPM flight software, excluding the VxWorks operating system.

The development cost avoided was estimated with SEER-SEM tuned for NASA missions: building the complete cFS suite from scratch for a Class B mission of GPM’s complexity is 49 person years [1]. Adopting it still costs tuning configuration parameters and adjusting task priorities, put at about 2 person years for a mission of that complexity and class [1].

GPM’s RAD750 and 24 MB of SRAM are generous next to a CubeSat processor, and the port to Dellingr, a 6U CubeSat deployed from the ISS in November 2017, shows what cFS costs when that margin is gone: its Gomspace Nanomind A712d carries a 40 MHz ARM7 and 2 MB of SRAM, not enough to hold the cFE and its applications in RAM at once, so the framework had to execute out of flash, only selected mission applications could be loaded dynamically to RAM, and CFDP file transfer and Housekeeping were dropped entirely to make room [8]. The port required a new OS abstraction layer for FreeRTOS 8.x, after which most of cFS ran unchanged, with the vendor firmware supplying the file systems underneath it, and the engineer who did the port judged cFS a poor fit for that processor, succeeding only because he already knew the framework well [8].

Flight record

Mission	Launch	Processor	RTOS	Role of cFS
Lunar Reconnaissance Orbiter	2009	RAD750	VxWorks	cFE co-developed; cFE API unchanged since
Radiation Belt Storm Probes, JHU APL	2012			cFE
Morpheus, JSC	2013 test flights			cFS
GPM	2014	RAD750	VxWorks	cFS co-developed
LADEE, Ames	2014			cFS
Magnetospheric Multiscale	2015	custom Coldfire command and data handling	RTEMS	cFS
Dellingr 6U CubeSat	2017			cFS

Sources: [1] and [2]. As of 2016 the cFE application programming interface had not changed since the Lunar Reconnaissance Orbiter launch in 2009. Missions then in development ranged from NASA JSC Orion backup flight computer to Dellingr, spanning NASA software classes A through D [2]. The framework exists because the earlier Goddard practice of clone-and-own reuse, copying components from previous missions by functional similarity, left the scope of changes uncontrolled, forced a full verification and validation effort on each new mission and kept no single maintained lineage per component [2].

The open source release of February 2015 covered twelve commonly used applications and completed the stack [1]. A NASA-wide configuration control board drawn from Ames, Glenn, Goddard, Johnson, Langley, Marshall and JHU APL then took ownership, and is responsible for keeping all baseline products at NPR 7150.2B Class B [2].

Whether the code obeys the architecture

An independent static architecture analysis by the Fraunhofer Center for Experimental Software Engineering, using the SAVE tool on the cFS source, checked the design rules that the reuse claim rests on [5]. Two held: cFE applications depend on the cFE core and not the reverse, and no two applications interact directly rather than through the Software Bus. Two deviations were found: a cyclic dependency from the operating system layer back to the core, avoidable by moving one header, and two applications, Memory Manager and File Manager, that reached past the cFE API to include an OS abstraction header directly. Of the six applications examined, Housekeeping, Memory Dwell, Memory Manager, Checksum, File Manager and Limit Checker, all six use Executive Services to initialize, Event Services to report, and the Software Bus to send and receive; only some use Table, File and Time Services directly, but none of the three can be dropped from a build because the first three services depend on them. The analysis was static only, and the authors listed dynamic dependency extraction, message ordering and timing measurement of software bus bottlenecks as work not yet done.

F Prime, the other NASA framework

F Prime is a component and port architecture: active, passive and queued components, a C++ framework with an OS abstraction layer, and XML and SysML models compiled by autocoders into C++ base classes and ground dictionaries [11]. It first flew on ISS RapidScat, with ASTERIA the first CubeSat; Lunar Flashlight, NEA Scout and the Mars Helicopter were in development when the paper was written [11]. The architectural contrast with cFS is that cFS centers on a publish and subscribe bus between independently deployable applications, while F Prime uses statically typed connections resolved at build time [7][9].

The Ingenuity flight software lead gives the reason F Prime was chosen over cFS as portability across bare metal, embedded Linux and ground support equipment with shared code. Ingenuity ran three deployments on three processors, joined across UART by a hub pattern, and about 60 percent of project code was generated by the autocoders with about 20 percent helicopter unique; the metric behind those percentages is not defined [12]. That comparison is a list of properties, not a measured evaluation, and no quantitative cFS versus F Prime footprint comparison exists in the corpus [9][12]. F Prime has been open source under Apache 2.0 since 2017, with internal development from 2013 [14]. Extensions that exist only as prototypes include a delay tolerant networking integration of ION, not tested on flight hardware [15]. A black-box assessment of v3.2 on a Raspberry Pi testbed found no command authentication, no link encryption and recoverable opcode dictionaries, never tested against a flown deployment [13]. No comparable independent security assessment of cFS is held.

Process, assurance and cost

The cFS framework itself is classified NPR 7150.2C Class E and ships artifacts supporting Class B in full and a subset for Class A, so a mission treats it as a bought-in component it must still verify [3]. JPL’s separate certification regime covers the coding process, the code and the coders, with a C standard that bans dynamic allocation and recursion and nightly checks by four static analyzers, reported without defect data [27]. Model-based engineering on SMAP used SysML and UML for architecture, requirements traces and test scripts, self-reported before launch [28]. An ARINC 653 partitioned operating system has been proposed to improve reuse and testability of robotic spacecraft software, demonstrated only on a simulated inverted pendulum, so its overhead on a flight processor is unmeasured [22]. VIPER’s flight, ground and simulation software cost was estimated with SEER-SEM cross-checked against COCOMO II over an analogy set of earlier missions [30], the same model family behind the 49 and 2 person year cFS comparison [1]. The ground systems side is addressed by a multi-mission data system built so that one system serves the developer desktop, testbed and flight operations; it was presented before first use [32].

Adoption on a rover

Resource Prospector, the canceled lunar volatiles mission managed at Ames with the rover built at NASA JSC, ran its rover flight software on cFS. The team’s stated reason was reuse: cFE, the Operating System Abstraction Layer and cFE-compliant applications supplied the core spacecraft functions while rover-specific applications were developed against them. The architecture was exercised on the RP15 rover testbed, taken from concept to a rover driving in the Johnson lunar rock yard within one year and operated by a team distributed across Ames, Johnson and Kennedy; the 2015 build 1 delivered hardware interfaces, basic mobility, waypoint driving, odometry and inertial measurement unit localization, basic error checking and camera services [4]. The RP15 vehicle that flight software ran was a 300 kg, four wheel, offset steered and actively suspended rover with a solar-pointing all-wheel steering mode, sized to a 3 to 4 km traverse requirement and carrying a low-computation laser hazard detector; that mobility design is the direct ancestor of VIPER’s [10].

What adoption costs

Three costs recur in the published accounts. The framework does not supply flight command ingest or telemetry output applications; the open source release carries only UDP-based laboratory versions, and every mission has had to write its own transport-specific versions, which new users report as the hardest part of deployment [8]. The framework is stated to provide Class B artifacts in full and only a subset of what a Class A mission needs [3]. There is no reusable device plug-in design pattern, so hardware interface applications are written from scratch each time [1]. And the coupling runs both ways: as the number of supported platforms grows, applications become harder to keep portable, and as the number of applications grows, supporting a platform becomes harder [3].

A structured comparison of six CubeSat flight software frameworks against seven selection criteria, run for the VCUB1 6U CubeSat mission, picked cFS as the design baseline chiefly on flight heritage and the configuration control board behind it: of the six, only cFS and one other had actually flown, and cFS’s OpenSatKit was judged the most turnkey of the software development kits compared [9].

Langley’s LANDO project plans a ROS 2 modular autonomy framework for autonomous unloading of lunar landers with a crane and names a bridge to cFS; it is a plan with no test data, no achieved performance and no flight data [16]. Of the cFS rover uses, then, Resource Prospector is a prototype and was not flown, and no surface rover flight of cFS is documented in the held sources.

What is not established

• No source holds runtime RAM, CPU utilization, software bus latency or message throughput for cFS. The only footprint is GPM EEPROM image size [1], and the training deck, OpenSatKit paper and architecture briefing carry none [2][3][7].
• The 49 person year build cost is a parametric model output, and the 2 person year adoption cost has no stated basis [1]. The reuse claim behind the product line is not quantified in the architect’s briefing [7].
• Reliability claims for cFS rest on assertion: the OpenSatKit paper gives no defect count or uptime figure, and the single in-orbit application replacement on GPM is an anecdote [2].
• The architecture compliance analysis covered six applications on a 2008 or 2009 baseline, and dynamic dependencies and bus timing were left as future work [5].
• The Dellingr result is one engineer on one vendor board and gives no numeric footprint [8]. The comparative survey scored footprint as yes or no and did not include F Prime [9].
• The Resource Prospector report gives no cFS measurements and does not name the rover processor; the vehicle was canceled in 2018 [4][10].