The Flight Software Framework code for the EIVE project.
Go to file
2022-04-11 14:35:16 +02:00
automation Changing build to -j4 from -j to lessen load on build server 2022-03-03 16:03:06 +01:00
cmake Introducing documentation with Sphinx 2021-12-01 11:17:28 +01:00
contrib using _ instead of - now 2021-08-02 20:55:03 +02:00
docs docs update 2022-02-14 16:31:13 +01:00
hal Merge branch 'development' into mueller/small-mgmlis3-tweak 2022-03-28 15:05:24 +02:00
misc Merge remote-tracking branch 'upstream/development' into mueller/cfdp-pdus 2021-12-06 16:12:06 +01:00
scripts Merge branch 'development' into gaisser_unit_test_internal_error 2022-02-28 15:19:44 +01:00
src delete data from ipc store if reply fails 2022-04-11 14:35:16 +02:00
tests Merge remote-tracking branch 'upstream/development' into mueller/version-getter-upstream 2022-03-14 14:38:27 +01:00
.clang-format small tweaks and fixes 2021-12-07 13:14:57 +01:00
.gitignore works 2021-10-11 15:07:52 +02:00
.gitmodules unittest now contained directly 2020-10-20 17:11:23 +02:00
CHANGELOG.md changed hal linux uart baudrate and bits per word to enums 2022-03-24 15:44:32 +01:00
CMakeLists.txt cmake lists update to suppress large warning 2022-03-24 16:54:41 +01:00
LICENSE updating code from Flying Laptop 2018-07-12 16:29:32 +02:00
NOTICE Added the new logos, colors are WIP at the moment 2020-11-30 18:30:58 +01:00
README.md try readme tweak 2022-02-22 11:40:31 +01:00

FSFW Logo

Flight Software Framework (FSFW)

The Flight Software Framework is a C++ Object Oriented Framework for unmanned, automated systems like Satellites.

The initial version of the Flight Software Framework was developed during the Flying Laptop Project by the University of Stuttgart in cooperation with Airbus Defence and Space GmbH.

Quick facts

The framework is designed for systems, which communicate with external devices, perform control loops, receive telecommands and send telemetry, and need to maintain a high level of availability. Therefore, a mode and health system provides control over the states of the software and the controlled devices. In addition, a simple mechanism of event based fault detection, isolation and recovery is implemented as well.

The FSFW provides abstraction layers for operating systems to provide a uniform operating system abstraction layer (OSAL). Some components of this OSAL are required internally by the FSFW but is also very useful for developers to implement the same application logic on different operating systems with a uniform interface.

Currently, the FSFW provides the following OSALs:

  • Linux
  • Host
  • FreeRTOS
  • RTEMS

The recommended hardware is a microprocessor with more than 1 MB of RAM and 1 MB of non-volatile memory. For reference, current applications use a Cobham Gaisler UT699 (LEON3FT), a ISISPACE IOBC or a Zynq-7020 SoC. The fsfw was also successfully run on the STM32H743ZI-Nucleo board and on a Raspberry Pi and is currently running on the active satellite mission Flying Laptop.

Getting started

The Hosted FSFW example provides a good starting point and a demo to see the FSFW capabilities. It is recommended to get started by building and playing around with the demo application. There are also other examples provided for all OSALs using the popular embedded platforms Raspberry Pi, Beagle Bone Black and STM32H7.

Generally, the FSFW is included in a project by providing a configuration folder, building the static library and linking against it. There are some functions like printChar which are different depending on the target architecture and need to be implemented by the mission developer.

A template configuration folder was provided and can be copied into the project root to have a starting point. The configuration section provides more specific information about the possible options.

Adding the library

The following steps show how to add and use FSFW components. It is still recommended to try out the example mentioned above to get started, but the following steps show how to add and link against the FSFW library in general.

  1. Add this repository as a submodule

    git submodule add https://egit.irs.uni-stuttgart.de/fsfw/fsfw.git fsfw   
    
  2. Add the following directive inside the uppermost CMakeLists.txt file of your project

    add_subdirectory(fsfw)
    
  3. Make sure to provide a configuration folder and supply the path to that folder with the FSFW_CONFIG_PATH CMake variable from the uppermost CMakeLists.txt file. It is also necessary to provide the printChar function. You can find an example implementation for a hosted build here.

  4. Link against the FSFW library

    target_link_libraries(${YourProjectName} PRIVATE fsfw)
    
  5. It should now be possible use the FSFW as a static library from the user code.

Building the unittests

The FSFW also has unittests which use the Catch2 library. These are built by setting the CMake option FSFW_BUILD_UNITTESTS to ON or TRUE from your project CMakeLists.txt file or from the command line.

The fsfw-tests binary will be built as part of the static library and dropped alongside it. If the unittests are built, the library and the tests will be built with coverage information by default. This can be disabled by setting the FSFW_TESTS_COV_GEN option to OFF or FALSE.

You can use the following commands inside the fsfw folder to set up the build system

mkdir build-Unittest && cd build-Unittest
cmake -DFSFW_BUILD_UNITTESTS=ON -DFSFW_OSAL=host -DCMAKE_BUILD_TYPE=Debug ..

You can also use -DFSFW_OSAL=linux on Linux systems.

Coverage data in HTML format can be generated using the CodeCoverage CMake module. To build the unittests, run them and then generare the coverage data in this format, the following command can be used inside the build directory after the build system was set up

cmake --build . -- fsfw-tests_coverage -j

The coverage.py script located in the script folder can also be used to do this conveniently.

Building the documentations

The FSFW documentation is built using the tools Sphinx, doxygen and breathe based on the instructions provided in this blogpost. If you want to do this locally, set up the prerequisites first. This requires a python3 installation as well. Example here is for Ubuntu.

sudo apt-get install doxygen graphviz

And the following Python packages

python3 -m pip install sphinx breathe

You can set up a documentation build system using the following commands

mkdir build-docs && cd build-docs
cmake -DFSFW_BUILD_DOCS=ON -DFSFW_OSAL=host ..

Then you can generate the documentation using

cmake --build . -j

You can find the generated documentation inside the docs/sphinx folder inside the build folder. Simply open the index.html in the webbrowser of your choice.

The helper.py script located in the scriptfolder can also be used to create, build and open the documentation conveniently. Tryhelper.py -h for more information.

Formatting the sources

The formatting is done by the clang-format tool. The configuration is contained within the .clang-format file in the repository root. As long as clang-format is installed, you can run the apply-clang-format.sh helper script to format all source files consistently.

Index

1. High-level overview
2. Core components
3. Configuration
4. OSAL overview
5. PUS services
6. Device Handler overview
7. Controller overview
8. Local Data Pools