HackMDFlight software final selection - cFS versus F'
tags: fs master tm
The first flight software comparison allow to narrow the choice to two frameworks that are relevant : cFS from the Nasa Goddard Space Flight Center and F' from the NASA Jet Propulsion Laboratory. Both are open-source, have a good documentation and a user community. Given their authors, the long-term support is guaranteed. They also have flight heritage with multiple missions.
The goal of this document is to summarise their differences and the impact of choosing one of them on future developments.
Frameworks analysis
cFS
cFS is a very complete tool part of the NOS3 - NASA Operational Simulator for Small Satellites. The goal of NOS3 is to be able to simulate all parts of a satellite.
The cFs itself has four main components. The Core Flight Executive (cFe), the Operating System Abstraction Layer (OSAL) and the Platform Support Package (PSP) and a Application layer. The cFE is an application development and run-time environment. It provides a set of core services including Software Bus (messaging), Time, Event (Alerts), Executive (startup and runtime), and Table services. The cFE defines an application programming interface (API) for each service which serves as the basis for application development. The cFE layer runs on top of the PSP and OSAL layers. Together, they allow the development of portable embedded system software that is independent of a particular Real Time Operating System and hardware platform. The OSAL is a collection of abstraction APIs allowing to easily port the cFS code on different OS and the PSP, a collection of user-provided facilities that interface with a specific hardware platform and is responsible for hardware initialisation.
F'
F' is an open-source framework developped by the NASA JPL. It allows a good scalablitity and modularity. The Framework is composed of discrete components that each manage one part of the system and communicate with each other through ports. There are 3 main services provided with the framework. A lot of already implemented and tested components, an autocoder that generates classes from XML and a complete test suit to test new developped components. An abstraction layer (OSAL) is also provided for some OS like Linux or VxWorks. The framework comes with a ground software (gds). The soft can send packet, gets the telemetry, the events and the logs of FSW. All components are C++ classes and a components instances are class objects. Components are combined together in a topology. The framework provides some taining example and tutorials to get in it.
Portability
cFS
Thanks to the OSAL and PSP layers, cFS can be port to many operating systems. Natively, it can be used on Linux, VXWorks and RTEMS. Many missions used it with FreeRTOS, but the OSAL implementation for this specific OS is not available open-source. According to discussions and feedback we had from team members and FS engineers, porting FreeRTOS to cFS asks "reasonable effort" and is "fairly straightforward". The critical parts are the File System and the Network Interface. Depending on the flight software functionalities and needs, theses parts can be removed or customised (Network interface via UART for example).
Using cFS on FreeRTOS would ask to implement the cFS OSAL
cFS being usable on Linux, high-level implementation (FS logic) can be tested on a standard computer before using the actual OBC. Once tests are required on hardware, only the OSAL has to be changed.
F'
F' claims to be portable by "running on a wide range of processors, from microcontrollers to multicore computers, and on several operating systems." The port to new OS is indicated as "straightforward". A port to FreeRTOS is considered since 2018 according to GitHub. Globally the documentation concerning the OSAL for F' is weak but a "Porting Guide for New Platforms" is planned for the next release. However, the framework can be used baremetal (without OS) and code for this use case exists on GitHub.
Using F' with any RTOS would ask to implement a port.
For now, FreeRTOS was mainly considered. This is due to its existing support with the currently used VexRiscv core (on Saxon SoC). Depending on the core that will be chosen by the OBC pole, we could consider using another RTOS (like RTEMS or VXWorks). It will be necessary to ensure that the RTOS is ported to a RISC-V core and verify its licensing. FreeRTOS has the advantage to be open-source, free and widely used. If need, the VexRiscv core is also Zephyr compatible.
Having the interface document and the typical scenarios from the SE and MD pole will allow to better estimate the needs of the FS and restrict its functionnalities.
Standards
cFS
cFS integrates CCSDS and is PUS compatible.
F'
Concerning F', there is no indication of the used communication protocol. We are waiting on further information (GitHub) concerning this point.
If PUS is not natively supported, we could have to develop a (custom?) PUS implementation and integrate it in the framework. This work is probably time consuming and irrelevant.
Concerning Cubesat Space Protocol that is asked by the EPS, it will require to use the libcsp library. Neither of the two frameworks use it but it seems its integration is a easily feasible.
More generally, we are waiting on Solenix to receive information concerning Elveti to discover its functionnalities and ensure compatibility with the chosen FS.
Licensing
The first one is released under NASA Open Source Agreement and the second one Apache License
v 2.0.
Both frameworks can be used without any restriction
Conclusion
Despite its powerful mechanisms, cFS asks a lot to be handled and used. However, it allows advanced operation and is highly customisable depending on the flight software needs. The OSAL being natively available on RTEMS and VXWorks, the EST could choose any OS for the final implementation with limited impact on the development process.
F' is more recent and way simpler than cFS but seems powerful enough for our use case. Its compatibility with PUS is the major drawback.
