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.