0. 概要
NASAが開発しているcFSのドキュメントを読解してみる。
TitleはcFS Deployment Guideで、Githubにアップロードされている。リビジョンは6.5 (30 Jun 2017現在)。
https://github.com/nasa/cFE/blob/master/build/cFS%20Deployment%20Guide.docx
実装については以下の記事を読んで頂きたい。
https://qiita.com/harmegiddo/items/874251811d01672595df
1.0 文書範囲 / DOCUMENT SCOPE
本稿では、NASAが開発したcore Flight System (cFS)のセットアップ、ビルド、ロード、実行に必要な手順を詳細に説明している。説明する手順はGSFC Classic Buildシステムの使用を前提としている。またドキュメントの付録にはCMAKEを使用してcFSをセットアップ及び構築する方法について書かれている。
2.0 概要 / OVERVIEW
cFSは以下のコンポーネントで構築されている。
- cFE (core Flight Executive)
- OSAL (Operating System Abstraction Layer)
- CFE_PSP (Platform Support Package, a.k.a. PSP)
- cFS Applications
本稿では、この4つのコンポーネントすべてを統合するために必要な情報を提供し、サポートされているプラットフォームで実行できるようにする。
2.1 CFSの互換性表 / CFS COMPATIBILITY CHART
3.0 CFSコンポーネントの統合 / INTEGRATE THE CFS COMPONENTS
cFSを動作させるためには、Section 2.0の4つのコンポーネントをcFS mission tree (a.k.a the mission template)に統合させる必要がある。このmission treeは、4つのコンポーネントのmakefileやドキュメントを含んだディレクトリーのことである。cFEのオープンソースリリースは、cFEとPSPがmission treeに統合されている。詳しくはオープンソースリリースに付属しているReadmeを参照して頂きたい。なお、4つのコンポーネントの統合についても同様に行われている。コンポーネントのコピーを推奨ディレクトリに置き、そのパスを対応する環境変数に設定する。
3.1 ミッションツリー / THE CFS MISSION TREE
ミッションツリーは4つのcFSコンポーネントを統合するためのフレームワークを提供する。図3.1にミッションツリー(ディレクトリ)を示す。
トップレベルのmissionはプロジェクト名に合わせて名前が変更される。
buildディレクトリには各ビルドプラットフォームのサブディレクトリが含まれる。デフォルトでは、1つのビルドプラットフォームでcpu1 (pc-linux環境用)がある。このディレクトリにはmakefile、設定ファイルcFE startup script(後述)がある。他のハードウェアで動かす場合には、cpu2、cpu3のように、cpu1をコピーして、そのハードウェアに合ったように設定ファイルを変更すればよい。cpu(番号)のディレクトリ名は基本的には、ターゲットのプラットフォーム名となる。典型的な飛行機のプロジェクトの場合は、COTS、ETU、FLIGHTなどの3つのビルドプラットフォームを持つ。
なお、setvars.shファイルには、以下の環境変数が含まれている。
export CFS_MISSION=`pwd`
export APP_DIR=$CFS_MISSION/apps
export CFE_DIR=$CFS_MISSION/cfe
export OSAL_DIR=$CFS_MISSION/osal
export PSP_DIR=$CFS_MISSION/psp
app、cfe、osal、pspのディレクトリは、各cFSコンポーネントのディレクトリツリーを保持するためのものである。新しくプロジェクトを作るときは基本的にこの形でよい（しかし、従う必要はない。）。
もし、このディレクトリ構造と異なる構造にしたい場合は、setvars.shのパスを書き換える必要がある。
3.2 ビルドプラットフォームの指定 / SPECIFY THE BUILD PLATFORM
本節ではビルドプラットフォームの指定手順について述べる。
3.2.1 Select Target
Select the target platform by editing the mission/build/cpux/cfe/cfe-config.mak. The target platform
is selected by choosing a supported CFE_PSP and OS. There are four platforms supported by cFS.
They are PC-Linux, MCP750/vxWorks6.4, Rad750/vxWorks6.4 and MCF5235/RTEMS. Refer to
the file comments for more detail.
3.2.2 Specify cFE File Extension
Specify the extension for the cFE core executable file by editing the $CFS_MISSION/build/
cpux/Makefile. Set the extension to “bin” for Linux and “o” for vxWorks.
CFE_CORE_EXE_TYPE:=bin
3.2.3 Specify App File Extension
Specify the extension for the application object files by editing the $CFS_MISSION/build/
cpux/Makefile. Set the extension to “so” for Linux and “o” for vxWorks.
CFS_APP_EXE_TYPE:=so
3.3 INTEGRATE THE CFE
To integrate the cFE into the mission template, the entire cfe-project directory tree can be placed in the
mission template ($CFS_MISSION/cfe) directory or another location on the file system. Set the
CFE_DIR variable in the setvars.sh file to the top directory in the cFE tree. If the recommended
directory is used, set the variable to:
export CFE_DIR=$CFS_MISSION/cfe
The following file copy steps are performed later by the “make config” step. There is no need to do
this manually. They are shown here because they are needed to integrate the cFE.
cd $CFE_DIR (defined in previous step)
cp fsw/cfe-core/src/inc/cfe_es_perfids.h $CFS_MISSION/build/mission_inc
cp fsw/mission_inc/cfe_mission_cfg.h $CFS_MISSION/build/mission_inc
cp fsw/platform_inc/cpux/cfe_msgids.h $CFS_MISSION/build/cpux/inc
cp fsw/platform_inc/cpux/cfe_platform_cfg.h $CFS_MISSION/build/cpux/inc
3.3.1 Removing CFE Table Services
It is possible to build the CFE without including Table Services. This is only applicable if the
mission does not intend to use any cFS applications that require CFE type table services, or the
mission intends to provide custom table services. If CFE Table Services are removed, the CFE
makefile will no longer try to make the Table Services application and the link makefile will no longer include the Table Services object module in the CFE-CORE. Even if excluded from the build,
the Table Services source and header files will remain in the CFE source tree.
The environment variable EXCLUDE_CFE_TBL in the setvars.sh file controls whether, or not, the
CFE Table Services application is included in the CFE-CORE. The value of EXCLUDE_CFE_TBL
must be set equal to TRUE to cause Table Services to be excluded from the CFE-CORE. Any
definition of EXCLUDE_CFE_TBL that does not set the value equal to TRUE (or no definition at
all) will result in the inclusion of Table Services. The default setvars.sh file contains the line "#
EXCLUDE_CFE_TBL=TRUE", but note that the "#" symbol marks this line as a comment. Simply
remove the "#" symbol to enable the definition that excludes CFE Table Services.
Removing Table Services reduces the size of the CFE-CORE load file and also reduces the amount
of RAM memory required to load the cFE. Each development environment will have unique savings.
The numbers from a test performed using an MCP-750 platform with a GCC compiler are provided
here for reference:
Size of cFE binary load file with Table Services: 830,969
Size of cFE binary load file w/o Table services: 721,466
Amount of available RAM after loading cFE with Table Services: 76,513,488
Amount of available RAM after loading cFE w/o Table Services: 77,151,984
3.4 INTEGRATE THE OSAL
To integrate the OSAL into the mission template, place the entire OSAL directory on the file system
and specify the location in the setvars.sh file. The entire OSAL directory tree can be placed in the
mission template ($CFS_MISSION/osal) directory or any other location on the file system. Set the
OSAL_DIR variable in the setvars.sh file to the top directory in the OSAL tree. If the mission template
directory is used, set the variable to
export OSAL_DIR=$CFS_MISSION/osal
The copy command shown below is performed later by the “make config” step. There is no need to do
this manually. It is shown here because it is needed to integrate the OSAL.
cd $OSAL_DIR (defined in previous step)
cp build/inc/osconfig.h $CFS_MISSION/build/cpux/inc
3.5 INTEGRATE THE PSP
To integrate the CFE_PSP (cFE Platform Support Package) into the mission template, the entire
cfe_psp directory tree can be placed in the mission template ($CFS_MISSION/psp) directory or any
other location on the filesystem. Set the PSP_DIR variable in the setvars.sh file to the top directory in
the cfe_psp tree. If the mission template directory is used, set the variable toL
export PSP_DIR=$CFS_MISSION/psp
3.6 BUILD THE CFE, OSAL AND PSP
Although it is not necessary, it is possible to build the cFE, OSAL and PSP before integrating
applications.
Go to the top directory in the mission template (where the setvars.sh file is located).
Run the setvars script:
[... mission]$source setvars.sh
cd into the $CFS_MISSION/build/cpux directory:
[... mission]$ cd $CFS_MISSION/build/cpux
Type ‘make clean’ at the prompt:
[... cpux]$ make clean
To let the make process copy the cFE and OSAL configuration files, type ‘make config’ at the prompt.
Typically this step is needed only one time, just prior to building the code the first time.
[... cpux]$ make config
Use ‘make distclean’ to undo the ‘make config’ steps.
If necessary, adjust the cFE and OSAL configuration files in the /mission/build area. For location and
filename details, see the earlier steps to integrate the cFE and OSAL.
Type ‘make’ at the prompt:
[... cpux]$ make
Verify that the cfe-core executable file is present in the $CFS_MISSION/build/cpux/exe directory.
For vxworks, the cfe-core executable is cfe-core.o. For linux, the executable is core-linux.bin
3.7 アプリケーションの統合 / INTEGRATE THE APPLICATIONS
cFE上で実行される全てのアプリケーションは図3.7に示すディレクトリ構造を持っている必要がある。網掛けの部分はオプションとなる。
srcディレクトリにはアプリケーションのすべてのcファイルとヘッダファイル(private)が含まれている。
platform_incディレクトリにはミッションによって調整された単一CPUのスコープを持つヘッダファイルが含まれている。これには、msgids.hファイルとプラットフォーム構成ファイルが含まれる。
mission_incディレクトリには、ミッションによって調整され、全てのcpuで横断的に用いるヘッダーファイルが含まれている。これには、該当する場合ミッション設定ファイルが含まれる。
The public_inc directory contains header files that may be accessed by other applications and have the
scope of a single cpu. This would include files that may define structures, constants or function
prototypes that are needed by other applications on the same cpu. For example, the cfs_lib app contains
a header file named cfs_utils.h in its public_inc directory.
The for_build directory contains the low level makefile needed to build the app. It must follow a
specific format. Use an existing cFS makefile as a template. This file will be copied to the
mission/build area. If the application uses tables, a table makefile is also contained in this directory and
must be copied to the mission/build area.
The unit_test directory will contain all the files needed to run the unit test as well as files that show the
results of running the unit test. This would include a makefile, driver files, output files and a gcov file
for each c file.
The tables directory must contain the source files for the application’s default table definitions. If the
application does not have any tables, this directory will not exist.
To integrate a cFS Application into the mission template, follow the steps below.
3.7.1 Place Application In $APP_DIR
Copy the entire application directory tree to the directory specified by $APP_DIR in the setvars.sh.
By default, the APP_DIR is set to $CFS_MISSION/apps.