About the Technology
The Core Flight Software System (cFS) has reduced the costly and time-consuming process of developing software for spaceflight missions
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.
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.
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.