About the Technology

The Core Flight Software System (cFS) has reduced the costly and time-consuming process of developing software for spaceflight missions

Overview

The Core Flight System (cFS) is a platform, a product line, and a community. The platform is a 3-tiered flight software architecture that provides a hardware and operating system independent application runtime environment. The product line includes software lifecycle artifacts that can be configured and extended to meet the user’s requirements. The community is an actively engaged consortium of private, public, academic, and government organizations working together to continually improve and expand the cFS.

The cFS provides many benefits including

Freely available high quality flight software

Provides common spacecraft flight software functionality

Portable across many platforms

Reduces project cost and schedule risks

Users can focus on mission specific applications

Active user community

History and Heritage

The cFS was initially developed by NASA’s Goddard Space Flight Center (GSFC) over many years based on a rich heritage of successful missions. The cFS components were incrementally developed and publically released. The core Flight Executive (cFE) including the platform abstraction layer was first used on the Lunar Reconnaissance Orbiter (LRO) launched in 2009 and the initial suite of cFS applications was first used on the Global Precipitation Measurement (GPM) spacecraft launched in 2014. The entire cFS software suite was released as open source in January 2015.

Although the cFS was incrementally developed and released a team of senior engineers performed a structured heritage analysis of missions covering more than a decade. The diversity of the heritage missions (single vs. redundant components, varying orbits, different operational communication scenarios, etc.) provided valuable insights into what drove FSW commonality and variability across the missions. The team took the entire FSW life-cycle into consideration, including in-orbit FSW sustaining engineering, as they performed their analysis. They identified system and application level variation points to address the range and scope of the flight systems domain. A primary goal was to enable portability across embedded computing platforms and to implement different end-user functional needs without the need to modify the source code.

Platform

The 3-tiered software architecture with well-defined Application Programmer Interfaces (APIs) for the bottom two layers successfully met the portability goal. Layer 1 contains the Operating System (OS) and Board Support Package (BSP) and access to the functionality in these components is controlled through two APIs: the Operating System Abstraction Layer (OSAL) and the Platform Support Package (PSP). The OSAL and PSP APIs provide a platform independent (OS and hardware) interface that provides common OS and BSP services. Layer 2 contains the core Flight Executive (cFE) that provides five services that were determined to be common across all of the GSFC FSW projects. The APIs have been very stable and the cFE API has remained unchanged since the launch of the LRO in 2009. The APIs and cFE services define an application runtime environment for the applications in Layer 3. The application layer contains thread-based applications as well as libraries (e.g. linear algebra math library) that can be shared among multiple applications.

An essential feature of the cFS platform is the definition of an application as a pluginable component. The cFE enables this feature by providing a core set of services, a runtime environment, and a tool suite for building and hosting flight software applications. The core services include a Software Bus (messaging), Time Management, Event Messages (Alerts), Table Management (runtime parameters), and Executive Services (startup and runtime). The Software Bus provides a publish-and-subscribe CCSDS standards-based inter application messaging system that supports single and multi-processor configurations. Time Management provides time services for applications. The Event Message service allows applications to send time-stamped parameterized text messages. Four message classes based on severity are defined and filtering can be applied on a per-class basis. Tables are binary files containing groups of application defined parameters that can be changed during runtime. The table service provides a ground interface for loading and dumping an application’s tables. Executive Services provides the runtime environment that allows applications to be managed as an architectural component.

The cFS manages EEPROM using a file system and uses a script file to determine which application object files should be loaded during initialization. In turn applications subscribe to cFE services during their initialization. Since cFE resources are managed on a per-application basis the cFE supports starting, stopping, and loading applications during runtime. This allows applications to be developed independent of the platform, very similar to how apps are managed by smart phones. It can also simplify on-orbit maintenance as demonstrated by the Global Precipitation Measurement (GPM) FSW sustaining engineering team in the fall of 2014 when they successfully replaced the file transfer application without disrupting normal science operations.

OSAL Platforms

Operating

System

OSAL

Version

Status

Target

POSIX/Linux

4.1.1

Production

Desktop Dev. use CentOS 6.x/Ubuntu 14.04 32 bit

RTEMS

4.1.1

Production

Flying on MMS Mission RTEMS 4.10/Coldfire

VxWorks

4.1.1

Production

Flying on GPM Mission

VxWorks 6.4/PowerPC

FreeRTOS

4.2.x

In Dev.

GSFC Dellingr CubeSat Mission

FreeRTOS/Arm

VxWorks 6.x

SMP

4.3.x

In Dev.

VxWorks 6.7 LEON3 Dual Core

ARINC653

4.3.x

In Dev.

Green Hills Integrity OS

RTEMS 4.12

+SMP

Future

Future

Future Release

Xenomai Linux

Future

Future

Future Release

cFE 6.42 PSPs

Board/Platform

OSAL Operating System

Status

CentOS/Ubuntu Linux Desktop

POSIX/Linux

Used for development and testing

MMS Custom C&DH Coldfire

RTEMS

1 year in flight on MMS Mission

GPM RAD750

VxWorks

2 years in flight on GPM Mission

Gomspace Nanomind ARM CubeSat

FreeRTOS

Under development for GSFC Dellingr CubeSat Mission

GSFC MUSTANG Dual Core LEON3

VxWorks SMP

Under development for GSFC MUSTANG Dual Core LEON3 architecture

Product Line

The cFS provides a common set of core assets that are tailored, assembled, and augmented in a prescribed way to create a mission-specific FSW solution. The classic software engineering “V-model” shows how the cFS components are used throughout the software lifecycle.

The cFS uses compile-time configuration parameters to implement the variation points. The shaded components are cFS artifacts and the

notation indicates a parameterized artifact. The development of mission-specific components is not shown in the figure and they would follow the same software lifecycle. The integration and system tests activities are white because each mission must perform these activities using an aggregation of cFS and mission-specific components. This lifecycle product line strategy overcame the limited success of the previous code-centric “clone and own” approach where a new project would copy FSW components from one or more previous missions based on functional requirement similarities. This approach typically required a new comprehensive verification and validation effort to be performed for the new mission that severely limited the cost savings of partially reusing source code. In addition a single project-independent lineage for each component was not maintained so the software quality did not necessarily increase with each mission.

Community

As new avionics or operating systems become available, the layered cFS can be adapted and the cFS components can be reused without any changes to the existing software components. It is expected that the cFS catalog will expand with each mission, providing many more choices to mission designers who are looking to optimize schedule, performance, and cost.

A NASA Configuration Control Board (CCB) maintains cFS architecturally significant components and a limited set of platform abstractions implementations. Architecturally significant components are any components that play a role in implementing architectural features which includes a set of applications. The NASA cFS release notes define the assets contained in the NASA release. The NASA releases are licensed under the NASA Open Source Agreement Version 1.3,

Currently only the NASA community can submit change requests and provide code contributions. A future enhancement will allow the non-NASA users to submit change requests. The figure also show 3rd party organizations creating releases. These release could be composed of any combination of a NASA release, proprietary assets, and community assets whose licensing allows it to be included in 3rd party releases. For example an organization may create a release tailored for platforms common in the CubeSat community with a suite of applications also targeted for CubeSats.

Partners

About cFS

The core Flight Software System (cFS) has reduced the costly and time-consuming process of developing software for spaceflight missions.