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 [1].

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 [1][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 [1][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].

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].

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 [1]. 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 [1].

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.

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].

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 [1]. 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].