The Flight Software Framework code for the EIVE project.
Go to file
2021-01-03 13:58:18 +01:00
action cmake init, printChar tests 2020-12-07 01:40:10 +01:00
container all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
contrib/sgp4 renormalized files 2020-09-18 13:15:14 +02:00
controller all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
coordinates msvc tests 2020-12-20 15:32:03 +01:00
datalinklayer all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
datapool all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
datapoollocal all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
defaultcfg all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
devicehandlers all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
doc Fixed file ending of devicehanlder remake 2020-12-22 15:35:23 +01:00
events all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
fdir all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
globalfunctions all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
health all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
housekeeping cmake fixes 2020-12-12 18:32:24 +01:00
internalError all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
ipc all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
logo Added the new logos, colors are WIP at the moment 2020-11-30 18:30:58 +01:00
memory all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
modes Merge branch 'development' into mueller/cmake-init 2020-12-09 10:07:22 +01:00
monitoring all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
objectmanager all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
osal all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
parameters all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
power Merge branch 'development' into mueller/cmake-init 2020-12-10 17:23:09 +01:00
pus all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
returnvalues cast added 2020-11-02 14:45:10 +01:00
rmap clened up a bit 2020-12-13 22:12:57 +01:00
serialize all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
serviceinterface added change for windows 2021-01-03 13:25:42 +01:00
storagemanager all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
subsystem all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
tasks all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
tcdistribution all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
thermal cmake fixes 2020-12-12 18:32:24 +01:00
timemanager all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
tmstorage now it compiles 2020-12-22 15:49:31 +01:00
tmtcpacket all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
tmtcservices all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
unittest all cstdout uses wrapped in preprocessor defines 2021-01-03 13:58:18 +01:00
.gitignore Added .gitignore for eclipse project files 2018-07-12 17:13:04 +02:00
.gitmodules unittest now contained directly 2020-10-20 17:11:23 +02:00
CHANGELOG Merge branch 'development' into mueller/tmtcservices-update 2020-12-22 15:37:22 +01:00
CMakeLists.txt removed abi flags, are part of cross compile file now 2020-12-28 16:49:43 +01:00
fsfw.mk and now it compiles 2020-12-12 00:01:36 +01:00
FSFWVersion.h Version number 2020-11-13 15:09:00 +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 updated docs, added new doc folder 2020-12-22 13:23:19 +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.

Intended Use

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 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 tested on the STM32H743ZI-Nucleo board.

How to Use

The FSFW example provides a good starting point and a demo to see the FSFW capabilities and build it with the Make or the CMake build system. Generally, the FSFW is included in a project by compiling the FSFW sources and providing a configuration folder and adding it to the include path. 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.

Structure

The general structure is driven by the usage of interfaces provided by objects. The FSFW uses C++11 as baseline. The intention behind this is that this C++ Standard should be widely available, even with older compilers. The FSFW uses dynamic allocation during the initialization but provides static containers during runtime. This simplifies the instantiation of objects and allows the usage of some standard containers. Dynamic Allocation after initialization is discouraged and different solutions are provided in the FSFW to achieve that. The fsfw uses run-time type information but exceptions are not allowed.

Failure Handling

Functions should return a defined ReturnValue_t to signal to the caller that something has gone wrong. Returnvalues must be unique. For this the function HasReturnvaluesIF::makeReturnCode or the Macro MAKE_RETURN can be used. The CLASS_ID is a unique id for that type of object. See returnvalues/FwClassIds.

OSAL

The FSFW provides operation system abstraction layers for Linux, FreeRTOS and RTEMS. A independent Host OSAL is in development which will provide abstraction for common type of host OSes (tested for Linux and Windows, not for MacOS yet). The OSAL provides periodic tasks, message queues, clocks and semaphores as well as mutexes.

Core Components

The FSFW has following core components. More detailed informations can be found in the core component section:

  1. Tasks: Abstraction for different (periodic) task types like periodic tasks or tasks with fixed timeslots
  2. ObjectManager: This module stores all SystemObjects by mapping a provided unique object ID to the object handles.
  3. Static Stores: Different stores are provided to store data of variable size (like telecommands or small telemetry) in a pool structure without using dynamic memory allocation. These pools are allocated up front.
  4. Clock: This module provided common time related functions
  5. EventManager: This module allows routing of events generated by SystemObjects
  6. HealthTable: A component which stores the health states of objects

Static Ids in the framework

Some parts of the framework use a static routing address for communication. An example setup of ids can be found in the example config in "defaultcft/fsfwconfig/objects/Factory::setStaticFrameworkObjectIds()".

Events

Events are tied to objects. EventIds can be generated by calling the Macro MAKE_EVENT. This works analog to the returnvalues. Every object that needs own EventIds has to get a unique SUBSYSTEM_ID. Every SystemObject can call triggerEvent from the parent class. Therefore, event messages contain the specific EventId and the objectId of the object that has triggered.

Internal Communication

Components communicate mostly over Message through Queues. Those queues are created by calling the singleton QueueFactory::instance()->create().

External Communication

The external communication with the mission control system is mostly up to the user implementation. The FSFW provides PUS Services which can be used to but don't need to be used. The services can be seen as a conversion from a TC to a message based communication and back.

CCSDS Frames, CCSDS Space Packets and PUS

If the communication is based on CCSDS Frames and Space Packets, several classes can be used to distributed the packets to the corresponding services. Those can be found in tcdistribution. If Space Packets are used, a timestamper must be created. An example can be found in the timemanager folder, this uses CCSDSTime::CDS_short.

Device Handlers

DeviceHandlers are another important component of the FSFW. The idea is, to have a software counterpart of every physical device to provide a simple mode, health and commanding interface. By separating the underlying Communication Interface with DeviceCommunicationIF, a device handler (DH) can be tested on different hardware. The DH has mechanisms to monitor the communication with the physical device which allow for FDIR reaction. Device Handlers can be created by overriding DeviceHandlerBase. A standard FDIR component for the DH will be created automatically but can be overwritten by the user. More information on DeviceHandlers can be found in the related documentation section.

Modes, Health

The two interfaces HasModesIF and HasHealthIF provide access for commanding and monitoring of components. On-board Mode Management is implement in hierarchy system. DeviceHandlers and Controllers are the lowest part of the hierarchy. The next layer are Assemblies. Those assemblies act as a component which handle redundancies of handlers. Assemblies share a common core with the next level which are the Subsystems.

Those Assemblies are intended to act as auto-generated components from a database which describes the subsystem modes. The definitions contain transition and target tables which contain the DH, Assembly and Controller Modes to be commanded. Transition tables contain as many steps as needed to reach the mode from any other mode, e.g. a switch into any higher AOCS mode might first turn on the sensors, than the actuators and the controller as last component. The target table is used to describe the state that is checked continuously by the subsystem. All of this allows System Modes to be generated as Subsystem object as well from the same database. This System contains list of subsystem modes in the transition and target tables. Therefore, it allows a modular system to create system modes and easy commanding of those, because only the highest components must be commanded.

The health state represents if the component is able to perform its tasks. This can be used to signal the system to avoid using this component instead of a redundant one. The on-board FDIR uses the health state for isolation and recovery.

Unit Tests

Unit Tests are provided in the unittest folder. Those use the catch2 framework but do not include catch2 itself. See README.md in the unittest Folder.