Software Architecture Design Features

The cFS is a software suite that was designed to help develop flight quality software with reduced cost and schedule. The cFS embraces processes such as reuse, development standards, collaboration, and open source. The cFS provides a full suite of innovative features and offers well thought out solutions to the changing flight software application domain.

The pivotal design feature of the cFS, abstracting the software architecture from the hardware and forming the basis of reuse, is component layering. Each layer of the architecture hides its implementation and technology details from the other layers by defining and using standard Application Programming Interfaces (APIs). The internals of a layer can be changed without affecting other layers’ internals and components. 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. The layers include an OS Abstraction Layer (OSAL), Platform Support Package (PSP) layer, core Flight Executive (cFE) layer, and an Application layer containing a set of re-usable libraries and applications.

The OSAL and PSP are the lowest layers in the architecture providing an interface to the project selected hardware platform and Real-time Operating System. The OSAL is a software library that isolates the upper layers of the cFS from the Real-time Operating System. The OSAL provides an API to an abstract real time operating system. The OSAL then provides implementations of this API for several Real Time Operating Systems, such as vxWorks and RTEMS. In addition, implementations are provided for non-real Time Operating Systems, such as Linux, allowing the abstracted software to be developed and tested in a developer friendly desktop environment. The PSP is a software library that contains all of the software needed to adapt the cFS to a particular processor card. The PSP also provides an API to an abstract processor hardware computing system including hardware devices such as memory, I/O ports, and non-volatile memory. The PSP provides implementation of this API for several processors, such as the MCP750, RAD750, Coldfire, PC-Linux and SPARC LEON3 boards.

The middle, core layer provides an application development and run-time environment called the core Flight Executive (cFE). The cFE provides a run time environment, core set of services, and tool suite for building and hosting flight software applications. The cFE’s run time environment supports both static and dynamic linking. The core services include Software Bus (messaging), Time, Event (Alerts), Executive (startup and runtime), and Table services. The cFE defines an API for each service which serves as the basis for application development. Each service comes complete with a built in application that allows users to interface with each service. The cFE Software Bus service provides a publish and subscribe standards-based messaging system that allows applications to communicate with one another on both a single processor and multiprocessor via a network. The cFE software bus minimizes interdependencies and enables dynamic component distribution and interconnection. The cFE services support table driven applications allowing applications to be tuned or changed, both during development and at runtime, without changing the code base. The cFE services also provide plug and play capability where applications can be added and removed at runtime allowing applications to be written, integrated, and tested incrementally. Applications subscribe to cFE services at runtime, making system modifications easy. The tool suite includes a unit test framework for achieving full path coverage of cFS applications. In addition, the tool suite contains a Software Timing Analyzer that provides visibility into the real-time performance of embedded systems software. The cFE defines a standardized Application Programming Interface (API) along with an Application Developers Guide for developing the libraries and applications that sit at the highest cFS layer, the Application Layer.

The Application layer serves as an “app store” where common flight software components that are typically part of a flight software system are available for sharing and reuse. The Application Layer contains a full suite of spacecraft flight software Command and Data Handling (C&DH) applications. The Application layer also serves as the building ground for mission/project specific applications allowing engineers the freedom to focus solely on the specialized features of the software system. The Application layer serves as a sharing ground to support new operations and functions. As more projects/missions use the cFS, the Application layer’s “app store” will grow over time providing a wealth of resources for future developments.

cFS Architecture Layers

Another significant design feature endorsing reuse is the configurable set of requirements and code. The configurable parameters allow the cFS to be tailored for each environment including desk-top and closed loop simulation environments. The architecture comes complete with a reusable set of design documentation, development standards, test artifacts, and user guides.

Using the cFS, new projects/missions start with the baseline code infrastructure and artifacts already completed, tested, and qualified. Configurations are set verses modifying existing requirements, design, or code. Project Development Leads and Developers using the cFS focus solely on the mission specific software. A “divide and conquer” approach for the development of the mission specific software components is utilized. Using the cFS development environment, with the use of virtual machines, new projects/missions prototype and run mission specific flight software in a matter of hours. Developers use the closed loop desk top solutions to write their software from anywhere a laptop can go.

cFS Component Based Architecture

The cFS allows projects at any center to share and exchange software applications and artifacts eliminating the wasteful redundant efforts we have seen in the past. The new paradigm is similar to an “app store” where projects can pick from applications across multiple centers or other agencies and only need to develop the new applications unique to their missions.

cFS multi-platform support also provides opportunities for expansion of the architecture to new software development methods and paradigms such as model based development. Bolstering future growth within a reusable architecture, cFS has the potential to become one of the dominant architecture frameworks for NASA flight software (and simulation and test software).” – NASA Software Architecture Review Board (SARB) Report – Released February 2012.

cFS is a complete software engineering solution that includes a set of components with reusable requirements, source code, design documentation, development standards, unit tests, functional build and system tests, test artifacts, tool suite, user’s guides, and ground system command and telemetry database templates:

  • Provides a common, reusable product line approach to embedded software development
  • Allows missions to focus on mission specific applications
  • Enables collaboration and sharing of applications across organizations
  • Missions can use cFS to prototype and improve their concepts early, resulting in reduced technical, schedule, and cost risks.
  • 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.
  • Supports real-time swapping of software and box-level hardware because of its plug-and-play architecture, which eases integration, technology infusion over time, and maintenance.
  • Adds mission capability because flight software applications are available through the cFS re-use library. Therefore, a team can add functionality even if it does not have time or the budget to create its own.
  • Speeds development because catalog components are re-used rather than coded from scratch. Using the cFS development environment with the use of virtual machines, new projects/missions can prototype and run mission specific flight software in a matter of hours.
  • Lowers flight software costs and risks. All software products come from the re-use library and have been fully tested, qualified, and documented.


Projects across the aerospace industry can benefit greatly by using the Core Flight System (cFS) or similar architectures. This has been recognized by NASA, industry, Department of Defense, US intelligence community, CCSDS, and the European Space Agency (Reference Similar Activities document). Note that cFS developers are actively involved with these other organizations to achieve a broader level of standardization and adoption of such systems. The cFS has introduced a reusable, product-line approach for development of aerospace flight software and to the best of our knowledge is the first mature (TRL8-9) architecture deployed with the potential to provide competitive advantage to US industry (as recognized by Moon Express).

Aerospace projects/missions require the use of specialized, radiation tolerant hardware specific to the mission. Specialized hardware requirements in turn depend upon specialized software. The traditional software development approach at GSFC and across the industry was to review the requirements from previous missions and find software that had similar requirements to the new mission. The software from a previous mission would then be used as a starting point for developing the new software. Porting the software from a previous mission to the new hardware platform would require extensive, laborious, error prone, and costly software requirement and design changes. The conventional means of developing flight software for a mission was both schedule and resource intensive. cFS was created at NASA/GSFC to directly address these inefficiencies.

The cFS was designed as a reusable, platform independent software product line. “This makes the architecture accessible to a range of missions from low-cost technology demonstrators to major science missions.” The cFS simplifies the flight software development process by providing a fully qualified and tested software infrastructure along with reusable artifacts. Users of the cFS need only focus on the software and artifacts exclusive to the mission reducing cost, schedule and risk. Several NASA centers have embraced the cFS architecture creating the potential for the cFS to become a de facto standard for flight software development across NASA. Formulating a standard approach to aeronautical flight software development will promote the sharing of lessons learned and proficiency across the NASA centers and commercial space agencies. GSFC, JSC, and APL have chosen the cFS for all future embedded flight software projects. The number of NASA centers and commercial space agencies requesting use of the cFS on future aerospace projects is steadily growing. GSFC has been contacted by multiple organizations with an interest in the cFS including APL, Moon Express and the Korean Aerospace Research Institute. The existence of a NASA flight software product line with agency level support could have a large impact on the aerospace industry itself with NASA as the leader. Both NASA and its commercial partners will benefit from the cost savings, schedule relief, and reduced risk of flight software development opening the doors to increased missions and technological breakthroughs.

The JSC’s Morpheus Lander is an example of how a technology demonstration with a challenging schedule could be met using the cFS architecture. A GSFC Applied Engineering and Technology Directorate (AETD) monthly message article states “With the Morpheus team able to build and demonstrate the Lander in under a year, the Code 582 developed cFE/cFS flight software has garnered considerable praise at JSC. JSC upper management has stated “how impressed we are at JSC with the Goddard Core Flight Software (cFS)”… “the high quality code base (and architecture) of cFS has been a major enabler”.” The GSFC AETD received a project Morpheus award from JSC for the benefit and support received from the cFS and GSFC AETD. The award plaque states “We could not have made the rapid progress we have without the quality, professionalism, and expertise provided by the GSFC Software Engineering Division and Applied Engineering and Technology Directorate.”


The cFS architecture is suited for use in any embedded software command and control computing system. The Core Flight System (cFS) architecture easily infuses and supports technological advances in hardware. The reusable, adaptable nature of the cFS architecture provides a foundation for producing an increase in science and technology projects and missions, requiring embedded software, at a lower cost and faster development rate. Users of the cFS architecture are able to focus on development of the science and technology with the software infrastructure already in place. This aspect raises the level of innovation and advancement in science and technology in general.


The Core Flight System (cFS) provides a foundation for producing an increase in science and technology projects and missions at a rapid rate. In a time of budget reductions, by lowering cost, schedule, and risk, the cFS becomes an enabler for generating a greater number of successful missions at a faster pace. These are the missions that affect all aspects of life, our curiosity about our world and the universe, and our economic wellbeing. The increase in data generated from environmental missions will help furnish complete global coverage for analyzing the earth’s climatic changes such as global warming, weather predictions, and monitoring for natural disasters such as volcanic eruptions, earthquakes, and tsunamis. The increase in earth and space science data collection will help in answering NASA’s big questions: is there life on other planets, how is the global earth system changing, how did the universe originate and evolve to produce the galaxies, stars, and planets we see today. Increasing space science knowledge will present a clearer understanding of space weather, the solar system, and deep space allowing human beings to travel where they have not gone before. Even the discovery of asteroids maybe heading our way. The increase in technological data will support new advancements in robotics, as well as, earth and space vehicles such as automobiles, rovers, landers, submarines, ships, military vehicles, rockets, launch vehicles, airplanes and helicopters.