Home Original page

GitHub - nasa/cFS at techdev-multitarget-bundle

Build Linux Build RTEMS 5

Core Flight System - BUNDLE

The Core Flight System (cFS) is a generic flight software architecture framework used on flagship spacecraft, human spacecraft, cubesats, and Raspberry Pi. This repository is a bundle of submodules that make up the cFS framework. Note the "lab" apps are intended as examples only, and enable this bundle to build, execute, receive commands, and send telemetry. This is not a flight distribution, which is typically made up of the cFE, OSAL, PSP, and a selection of flight apps that correspond to specific mission requirements.

This bundle has not been fully verified as an operational system, and is provided as a starting point vs an end product. Testing of this bundle consists of building, executing, sending setup commands and verifying receipt of telemetry. Unit testing is also run, but extensive analysis is not performed. All verification and validation per mission requirements is the responsibility of the mission (although attempts are made in the cFS Framework to provide a testing framework to facilitate the process).

The cFS Framework is a core subset of cFS, with an extensive ecosystem of applications and tools available throughout the community.

Distributions

This is the open-source version of cFS, released under an Apache 2.0 license. The open source cFS is limited to the framework and common apps, libraries, and tools, which includes and is limited to: cFE, OSAL, PSP, Command Ingest (Lab), Telemetry Output (Lab), Scheduler (Lab), Sample App, Sample Lib, Data Storage, File Manager, HouseKeeping, Health and Safety, Memory Dwell, CFDP File Transfer, CheckSum, Limit Checker, Memory Manager, Stored Command, cFS Ground System, elf2cfetbl, and tblCRCTool. Changes to the open repositories are limited to bug fixes and minor enhancements to those components.

A Government-use (Distro C) version of cFS with features for a full flight mission is available through a Software User Agreement. For more information about government version features or to explore partnerships, please contact the cFS team.

Contact

cFS/cFE is owned and maintained by NASA Goddard Space Flight Center's Flight Software Systems Branch.

The cFS team provides training, support, and subject matter expertise to cFS users across industry and the government. New features/developments can also be done by the cFS team which has significant experience in helping flight projects implement mission-ready flight SW using cFS for various classes of missions, including human-rated (class A) missions. A support agreement may be needed.

To connect with the cFS team, please send an email to cfs-program@lists.nasa.gov.

More information is available on the cFS Website.

Table of Contents

References Documentation

Release Notes

See releases for release history and associated artifacts related to the cFS BUNDLE.

v7.0.0 (Draco): OFFICIAL RELEASE:

  • Note: The cFS bundle structure and build system will be updated in a coming release to include all open source apps and new build commands. An evaluation version of this bundle is available in the techdev-multitarget-bundle branch for feedback.
  • Released under Apache 2.0
  • Includes cFE 7.0.0 (cFE, PSP, framework apps, and framework tools as marked) and OSAL 7.0.0
  • Release artifacts, including Version Description Document

Other elements listed in Related Capability are released under a variety of licenses as detailed in their respective repositories.

Upcoming Releases

Note: Official releases will be created through the NASA software release process.

Known Issues

Historical version description documents contain references to internal repositories and sourceforge, which is no longer in use. Not all markdown documents have been updated for GitHub.

See related repositories for current open issues.

Getting Help

Discussions

You can start a new discussion for discussions, questions, or ideas, in the cFS repository under the Discussions tab.

Join the mailing list

To subscribe to our mailing list, send an email to cfs-community-join@lists.nasa.gov with the word subscribe in the subject line.

The cfs-community mailing list includes cFS users and developers. The cFS Product Team also uses the mailing list to share information on current and future releases, bug findings and fixes, enhancement requests, community meetings, etc.

If you'd like to unsubscribe, send an email with the word unsubscribe to cfs-community-leave@lists.nasa.gov. Mailing list requests are typically processed within 5 minutes.

Contact the cFS Product Team

You can email the cFS Product Team at cfs-program@lists.nasa.gov to explore partnerships and other arrangements for in-depth support.

Setup

Ensure the following software are installed: Make, CMake, GCC, and Git. To setup the cFS BUNDLE directly from the latest set of interoperable repositories:

git clone https://github.com/nasa/cFS.git
cd cFS
git submodule init
git submodule update

The default Makefile and sample_defs/ directory should already be located at the top-level of this repository with the default configurations for building the open source applications.

Build and Run Quick Start

The cFS Framework including sample applications will build and run on the pc-linux platform support package (should run on most Linux distributions). Quick-start is below:

To prep, compile, and run on the host (from cFS directory above) as a normal user (best effort message queue depth and task priorities):

make native_std.prep    # Sets up the build tree
make native_std.install # Compiles the software and stages it to the exe directory
make native_std.runtest # Executes the tests
make native_std.lcov    # Executes lcov to collect coverage metrics

In order to boot CFE, the default linux PSP requires that the working directory be set to the location of the staged binaries:

cd build-native_std/exe/cpu1/
./core-cpu1

Should see startup messages, and CFE_ES_Main entering OPERATIONAL state. Note the code must be executed from the build/exe/cpu1 directory to find the startup script and shared objects.

Other Build configurations

The Makefile system included in this bundle allows multiple output targets/configurations to be built and tested in parallel. Each configuration is given a separate build directory, keeping all the artifacts separate from other build configurations.

The following configurations are defined, which build for the native machine and are intended for development and testing:

  • native_std: the traditional Linux development build, targets the local machine architecture (native), debugging enabled, includes unit tests
  • native_eds: like native_std but enables EDS. This is the reference configuration for EDS development and testing.
  • osal: compiles OSAL in a standalone manner, creates a library that can be linked into any application
  • edslib: complies EdsLib in a standalone manner, creates a library that can be linked into any application

The following configurations utilize cross compilers and require that the respective toolchain is installed on the host (instructions provided separately where relevant)

  • pc686_rtems5: cross compile for the "pc686" target running RTEMS 5, using the toolchain from rtems-tools. The resulting binaries may be executed in QEMU.
  • gr712_rtems5: cross compile for the "gr712" target running RTEMS 5, using the gaisler rcc toolchain
  • rpi_vxworks7: cross compile for the Raspberry Pi running VxWorks 7
  • rpi_linux: cross compile for the Raspberry Pi running Linux
  • qemu_yocto_linux: cross compile for a Yocto/Space Grade Linux target. The resulting binaries can be executed in QEMU. This enables full optimizations (release build).

Other build goals

The following set of goals exist for each configuration:

  • prep: Sets up the build tree
  • compile : Compiles the software, but does not stage it to any output/install directory
  • install : Compiles and stages the software to the output/install directory (suitable for execution)
  • runtest: Executes all the unit tests. (Recommend using -j option to run tests in parallel, depending on available cores)
  • lcov: Computes code coverage metrics (Requires/depends on "runtest" completing and passing)
  • detaildesign: Generates doxygen documentation for the complete mission, all software included
  • usersguide : Generates the CFE users guide documentation
  • osalguide : Generates the OSAL users guide documentation
  • image: Generates an image that can be booted in a container or VM (e.g. Docker or QEMU) if applicable to that configuration. Not all configurations implement this goal.

General build instructions

The Makefiles implement targets following the pattern of:

<config> represents one of the configurations listed above and <goal> represents one of the goals listed above. For example, rpi_linux.install will build the "install" goal using the "rpi_linux" configuration.

Each configuration gets its own output directory based on the configuration name with a build- prefix. So for example, the binaries produced by native_eds targets will be staged under build-native_eds/. This is what allows all the configurations to be built in parallel without interfering with each other.

Send commands, receive telemetry

The cFS-GroundSystem tool can be used to send commands and receive telemetry. For details on using and setting up the Ground System, see the Guide-GroundSystem. Note it depends on PyQt5 and PyZMQ:

  1. Install PyQt5 and PyZMQ on your system. Some systems may also require installing libcanberra-gtk-module.

  2. Compile cmdUtil and start the ground system executable

    cd tools/cFS-GroundSystem/Subsystems/cmdUtil
make
cd ../..
python3 GroundSystem.py

  3. Select "Start Command System" from main window

  4. Select "Enable Tlm"

  5. Enter IP address of system executing cFS, 127.0.0.1 if running locally

  6. Select "Start Telemetry System" from main window

Should see telemetry, can send noops and see command counters increment.

Adding Custom Apps

See the cFE Application Developer's Guide for information about creating new apps. It is encouraged to use sample_app or skeleton_app as a starting point. Once the application has been created, it must be added to targets.cmake to be compiled and to the .scr file to be dynamically loaded at runtime (in a dynamically loaded environment).

Related Capability