概要
F´ は NASA JPL が開発したコンポーネント駆動型フレームワークであり、フライトソフトウェアや組み込みシステムの構築に使用されます。モデリングツール、C++ カーネル、再利用可能なコンポーネントを提供しており、小型衛星や機器に適しています。
README プレビュー
A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework\n\n\n\n\n#\nF´ (F Prime) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications. Originally developed at the [Jet Propulsion Laboratory](https://www.jpl.nasa.gov/), F´ has been successfully deployed on [several space applications](https://fprime.jpl.nasa.gov/overview/projects/). It is tailored but not limited to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments.\n\n**Please Visit the F´ Website:** [https://fprime.jpl.nasa.gov](https://fprime.jpl.nasa.gov/) for more information.\n\n\n## What does F´ provide\n\n- An architecture that decomposes flight software into discrete components with well-defined interfaces\n- A C++ framework that provides core capabilities such as message queues and threads\n- Modeling tools for specifying components and connections and automatically generating code\n- A growing collection of ready-to-use components\n- Testing tools for testing flight software at the unit and integration levels.\n\nLearn more about [F´ key features](https://fprime.jpl.nasa.gov/overview).\n\n\n## System Requirements\n\nThe following system requirements apply to your workstation for developing F´ applications. To see the list of supported platforms on which F´ applications can run on, see [Supported Platforms](./docs/user-manual/framework/supported-platforms.md).\n\n1. Linux, Windows with WSL, or macOS operating system\n\n2. [git](https://git-scm.com/)\n\n3. [Python 3.10+](https://www.python.org/downloads/), [virtual environments](https://docs.python.org/3/library/venv.html), and [PIP](https://pypi.org/project/pip/)\n\n4. [Clang](https://clang.llvm.org/) or [GNU C and C++ compilers](https://gcc.gnu.org/) (e.g. gcc and g++)\n\n\nClick to Expand: How to Verify System Requirements\n\n2. `git --version`\n\n3. `python --version` and `python -m venv -h`. Your system might use an alternate like `
FAQ (5)
トラブル対応F´ Svc/Health のユニットテストで到達不能なテスト本体を修正するにはどうすればよいですか？
Svc/Health/test/ut/HealthTester.cpp を編集します。warningTlm() 内の早い段階の return; を削除し、ISF-HTH-002 の警告タイムアウトアサーションが実行されて、期待される HLTH_PING_WARN イベントが検証されるようにします。nominal2CmdsDuringTlm() 内の早い段階の return; も削除し、disable/enable コマンドによって発行される HLTH_CHECK_ENABLE イベントを考慮します。後続のゼロイベントアサーションの前に、これらの期待イベントをクリアします。プロダクションコードの変更は必要ありません。リビルドして Svc_Health_ut_exe を実行します。11 件すべてのテストがパスするはずです。
トラブル対応STOP_XMIT_CATALOG に続いて BUILD_CATALOG を実行した際に、遅れて到着した fileDone によって発生する F´ DpCatalog の FATAL アサートを修正するにはどうすればよいですか？
これは F´ PR #5797 で修正されており、2026-09-30 に devel ブランチへマージされました。F´ のチェックアウトまたは依存関係を、その PR を含む devel のコミットに更新してから、リビルドしてください：
git fetch origin
git merge origin/devel # or rebase/cherry-pick PR #5797 as appropriateこの修正では、古い fileDone の処理を変更し、DpCatalog.cpp:801 で FW_ASSERT に到達する代わりに既存のリカバリーパスを使用するようにしました。送信状態をクリアし、待機中のコマンドを完了させ、警告イベントを発行します。
修正前の影響を受けるコミットでは、回避策としてコマンドを直列化してください：STOP_XMIT_CATALOG の後、BUILD_CATALOG を発行する前に、FileDownlink が現在のファイルの fileDone(STATUS_OK) を返すのを待ってください。前のファイルがまだ送信中の間に CLEAR_CATALOG に続いて BUILD_CATALOG を使用しないでください。同じアサートが発生します。
トラブル対応古いディクショナリを使用している場合や不明なパケット記述子を受信した場合に、F´ GDS がダウンリンク/テレメトリを警告なく停止する問題を修正するにはどうすればよいですか?
PR #368 の修正を含むリリースに fprime-gds をアップグレードするか、パッチ適用済みの main ブランチをインストールしてください:
pip install --upgrade fprime-gds
# or, if needed:
pip install "fprime-gds @ git+https://github.com/nasa/fprime-gds.git@main"この問題は Distributor.on_recv で発生します。ここでは DeserializeException はキャッチされますが EnumMismatchException はキャッチされないため、未知のディスクリプタが受信スレッドを停止させてしまいます。古いバージョンでは ValueError: 65536 is not a valid DataDescType として現れることがありますが、v4.4.0 ではサイレントに失敗する可能性があります。このパッチは EnumMismatchException をキャッチし、警告をログに記録し、不正なパケットをスキップして処理を継続します。
当面の回避策: GDS に接続しているデプロイメントビルドと完全に一致するビルドで生成された辞書を使用してください。v4.0.0 の辞書と v4.4.0 のデプロイメントを混在させないでください。破損に起因するパケットについては、一致する辞書では防ぐことができないため、アップグレードが必要です。
トラブル対応fprime-merge-dictionary で --name を使用した際に発生するエラー "match() missing 1 required positional argument: 'string'" を修正するにはどうすればよいですか？
これは fprime-merge-dictionary CLI におけるバリデーションのバグです。識別子の正規表現がユーザー指定の名前なしで呼び出され、文字列全体との一致ではなく前方一致が使用されています。
一時的な回避策: --name を省略してください。すると、コマンドは生成されたデプロイメント名を使用します。
fprime-merge-dictionary --output combined.json first.json second.json恒久的な修正: 修正を含むバージョンに fprime-gds を更新するか、parse_arguments() 内の名前のバリデーションを次のような呼び出しから:
re.match(IDENTIFIER_PATTERN)次のように変更してください:
re.fullmatch(IDENTIFIER_PATTERN, args.name)fullmatch により、Combined のような有効な識別子は受け入れられ、Combined-extra や Combined\n のような無効な値は出力ファイルが書き込まれる前に拒否されます。
トラブル対応fprime CommandDispatcher のユニットテストで、重複しているまたは順序が乱れた TESTCASE 番号を修正するには？
fprime v4.4.1 において、これは TEST_CASE のトレーサビリティラベルにおける表面的なコピー&ペーストの誤りであり、GoogleTest の失敗や機能的なバグではありません。Svc/CmdDispatcher/test/ut/CommandDispatcherTestMain.cpp を編集し、ノミナルテストは 102.1.x 配下、オフノミナルテストは 102.2.x 配下に維持した上で、ソース内の順序どおりに一意の ID を割り当ててください。有効な振り直しの一例は次のとおりです: ClearSequenceTracker を 102.1.3 から 102.2.6 に変更し、重複している 102.2.5 の CommandQueueOverflow を 102.2.7 に変更し、既存の 102.2.9、102.2.6、102.2.7、102.2.8 の各テストをそれぞれ 102.2.8、102.2.9、102.2.10、102.2.11 に振り直します。cd Svc/CmdDispatcher && fprime-util check --ut で確認してください。メンテナーによれば、これらの番号ラベルは非推奨であるため、変更せずに残しておいてもテストの実行には影響しません。