Core Flight System

Two Columns

Introduction

About the Technology

The core Flight Software System (cFS) has reduced the costly and time-consuming process of developing software for spaceflight missions. Its flexible, layered architecture creates a development environment where system integrators can rapidly assemble a significant portion of a software system for new missions, test platforms, and technology prototypes, resulting in reduced technical, schedule, and cost risks. The Constellation Programs Lunar Reconnaissance Orbiter (LRO), which launched in June 2009, certified cFE for flight. Several other missions, including the Lunar Atmosphere and Dust Environment Explorer (LADEE), Morpheus, the Global Precipitation Measurement Mission (GPM), Magnetospheric Multiscale Mission (MMS), Radiation Belt Storm Probe (RBSP), the Solar Probe Plus mission, the Cryogenic Propellant Storage and Transfer (CPST) mission, and the Mighty Eagle Lander prototype are using the technology. All are experiencing the benefits of their choice in using the cFS. Each mission will add to the catalog of application components, which in turn will benefit future missions.

Significance of the Technology 

No flight missions are alike, and in the past, neither was the software developed to operate them. Flight software engineers would create custom code that was specific to the hardware the software was interfacing with, spending valuable time and resources designing and testing software to make sure the products meet mission requirements.  By introducing a layered, re-usable software architecture, software engineers can now rapidly peruse a catalog of libraries and applications and select the components they want for their mission. Using the cFS architecture, missions do not have to dedicate valuable resources to developing the common pieces of software required on every mission. Instead, they can use their resources to focus on development of the mission specific applications that run at the top layer of the architecture.  In addition, development systems can be up and running in just a few weeks, not months, as was the case before.  The layered, portable nature of the cFS allows developers to use the architecture on desk-top environments, freeing up expensive and valuable lab resources.  The development completed on a desk-top environment can then easily be integrated on flight hardware without changing a single line of code. In short, cFS reduces time to flight and the risks, and allows future missions to choose from an ever expanding catalog of reusable software components.

Origins

In the past, software portability and adaptability across hardware platforms and operating systems were minimal at best. Standard interfaces across applications were almost non-existent.  Historically a “clone and own” process was being used to develop new mission flight software where heritage mission flight software was used as the starting point for new missions.  The flight software artifacts (requirements, code, documentation, etc.) from a previous mission would be copied and modified according to the new mission requirements.  Porting the software artifacts from a previous mission to the new hardware platform would require extensive, laborious and error prone software requirement and design changes.  The conventional means of developing flight software for a mission was both schedule and resource intensive.  The costly, labor intensive efforts were rarely shared with other organizations.

To reduce flight software costs, Goddard’s Flight Software Branch realized that it needed to address these issues.  Work began on the cFS in 2005.  An exhaustive heritage analysis was performed by a group of senior flight software engineers each having experience on a number of different Goddard missions.  The analysis concluded existence of commonality in the flight software amongst all the missions especially in the discipline of Command and Data Handling (C&DH) flight software systems.  The results of the analysis determined qualified C&DH flight software could be redesigned into a reusable, platform independent software product line.  The reuse would not only include the software, but the artifacts such as requirements, design, test procedures and results, and documentation, saving projects and missions the cost and effort of reinventing these pieces over and over again as was done in the past.  The end result is an architecture that can evolve and is flexible.

Looking Ahead
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.