株式会社アークエッジスペース https://arkedgespace.com/ 人工衛星開発のための C2A フレームワークとその開発体験 sksat 1

自己紹介 ・sksat（えすけーさっと） ・ArkEdge Space Inc. コンピューティング基盤部　/　筑波大学情報学群情報科学類（休学中） ・宇宙オタク -> パソコンオタク -> 宇宙パソコン野郎 ・やってた: OS、x86エミュレータ、数値計算、小型ハイブリッドロケット、自宅サーバ ・やってる: C2A フレームワーク、シミュレーション基盤、CI/CD、姿勢制御系、社内システム、... ・気持ちがあるところ: 実在する複雑性の咀嚼と妥当な対処の案組み ・セキュリティ・キャンプ全国大会2024　開発コース　探査機自作ゼミ講師 ↖これ中指じゃないです 2


超小型人工衛星 ・元々の人工衛星：長期の開発（5～10年）、高い打ち上げコスト →もっと小さく／安く／速く作りたい ・1U（10cm x 10cm x 10cm）を単位とした CubeSat という分野 ・コストを1/100以下に ・アークエッジ・スペースは 3U、6U などの人工衛星を開発 20cm 10cm 30cm ©NASA 30cm 3


アークエッジ・スペース ・東大中須賀・船瀬・五十里研究室での CubeSat 開発をベース ・超小型人工衛星の企画・設計～運用まで総合的なソリューション提供 ・IoT、リモートセンシング、月のインフラ構築、深宇宙探査などに幅広く対応 ・人工衛星の共通部分（バスシステム）の開発を重視 ADCS 
 ・MTQと粗センサによる姿 勢制御 
 電源
 ・バッテリー小型化 
 標準バスOBC 
 通信
 ・1周波数帯利用による 
 ダウンサイジング 
 標準6Uバス α
 低価格モデル
 ADCS 
 ・高性能スタートラッカ 
 ・精/粗2種類のセンサ 
 ・超高精度姿勢制御則 
 電源
 ・バッテリー容量強化 
 ・電源制御基板強化 
 ミッションIF 
 ・ミッション機器制御 
 専用基板の搭載 
 標準バスOBC 
 通信
 ・HKデータとミッションデータ で別周波数帯・データレート 
 標準6Uバス β
 高性能モデル
 4


アークエッジ・スペースにおける技術的な挑戦 ・複数種類／多数の人工衛星の同時開発という挑戦 ・人工衛星自体の開発コストを劣線形にしなければならない ・我々が作るもの △人工衛星 ◎人工衛星を作るための仕組み ↓ ・汎用的なバスシステム ・再利用性の高い HW／SW 設計 ・開発体験の向上 5


分散システム的な人工衛星の設計 ・複数の OBC（On-Board-Computer）が協調動作 ・中心に MOBC（Main OBC）がいるスター型のトポロジ ・姿勢制御や熱制御などの責務ごとに OBC を分割されている ・専門ごとにチームを分割可能に ・各 OBC で動くソフトウェアは C2A というフレームワークを使用 ・単体での開発／試験のためのサポート ・HW は分割されていても同じ体験で開発 ・認知負荷の軽減 ・通信プロトコルも揃えられる 6


C2A ・衛星搭載ソフトウェア（FSW）のフレームワーク ・元々東大中須賀・船瀬・五十里研究室で開発 ・現在は AE がコア部分を開発・メンテナンス ・https://github.com/arkedge/c2a-core（OSS） ・MIT ライセンス ・特徴 ・小さな OS ・高い移植性 ・あらゆる動作を「コマンド」として扱う ・TlmCmdDB：「コマンド」と「テレメトリ」のスキーマ管理／コード生成 ・CCSDS SpacePacket 等の第一級サポート 7


C2A の移植性の高さ ・コア部分の実装は C89 ・必須な外部依存関数は memchr(), bsearch() のみ ・シンプルな実装も optional で提供 ・実用上は stdint.h（相当のもの）と printf() も欲しい ・シングルスレッド ・スケジューリングは手動 ・他に必要なもの：定期的な C2A_core_main() の実行 ・定期的に実行されさえすればよいので、雑には無限ループでよい ・ハードウェア依存部分は C2A HAL としてインターフェースを定義 ・様々なアーキテクチャ／スペックのマイコンにすぐ移植可能 8


・C2A：Command Centric Architecture ・「リアクションホイールを回す」「MRAM を初期化する」のような「コマンド」がたくさんある ・役割／粒度としてはシステムコールやマイクロカーネルの IPC のようなもの ・できるだけ処理を細かく分割し、できるだけコマンドとして表現する、という思想 ・システムコールレベルの細かな処理を地上からも実行可能 ・コマンドの種類 ・リアルタイム（RT）：即時実行 ・タイムライン（TL）：時間を指定して実行 ・ブロック（BL）：コマンド群を１つのコマンドとして扱う BLC すべてが「コマンド」 9
 RTC TLC 時刻指定 時間

TlmCmd DB ・https://github.com/arkedge/c2a-tlmcmddb/ ・「コマンド」と「テレメトリ」のスキーマ定義 ・CSV／JSON からコード生成／定義読み込み ・各種設定や設計情報も JSON で記述 ・別の職能／部署／組織との界面をコード化 ・ex：MOBC と AOBC、衛星開発と地上局システム開発 ・調整が会議からコードレビューになる → ◎再現性　◎非同期コミュニケーション 10


軌道上再構築能力 ・人工衛星は非修理系 →「打ち上げた後からでもどうとでもなる」とすごくうれしい ・タイムライン ・時系列上に細かい単位のコマンドを並べる ・実行時に事実上のプログラミングができる ・ブロックコマンドとその組み換え ・毎回すごく細かいプログラミングをするのは無駄 ・ある程度の処理の単位をブロックコマンドにまとめて抽象化 ・ブロックコマンドの追加や内部のコマンド列の修正（組み換え） 11


EL/EH：Event Logger / Event Handler ・非修理系なので、何かが起きて文鎮になると困る ・FDIR：Fault Detection, Isolation, and Recovery ・「何か」を事前にすべて想定するのは難しい ・イベントログ：EL ・色々な処理にイベントログを仕込んでおくことができる ・EL は普段は単にログとして使う ・イベントハンドラ：EH ・特定の EL の際に発火するイベントハンドラも書くことができる ・発火するのはブロックコマンド ・EH のルールやブロックコマンドを後から組み替える → 不測の自体にも対処可能 12


Rust の活用と 開発体験向上のためのツール開発 13

Rust ・システムプログラミング言語 ・LLVM ベース → 多くの ISA に対応 ・環境構築が rustup で一発 ・Cargo：優秀なパッケージマネージャ／ビルドシステム ・C言語との相互運用性◎ ・Satellite Software Development Framework With Rust That Improves Developer Enablement ・rustdoc によるドキュメント自動生成 ・強力な静的型検査 ・ex：マルチスレッドでのリソース競合をコンパイル時に防げる ・コンパイル時の安全性チェック ・ex：unsafe な領域の明示 14
 Image credit: Rust Foundation (CC-BY)

なぜ Rust を使うか？ ・Rust の開発体験が良いから ・環境構築がラク：crosstool-ng で GNU toolchain をビルド、とかしなくていい ・crates.io に豊富な資産がある ・組み込みから Web バックエンドまで同じ言語で開発できる ・コミュニティが活発（組み込み Rust 含め） ・Cargo が優秀（C/C++ にはマトモなパッケージマネージャが無い！！！） ・C2A との相互運用がしやすいから ・C言語との相互運用がしやすい ・C2A に Web 系の概念や資産を持ち込んでより便利にできる ・言語機能が優秀だから（よく言われるがちなこと） ・言語機能が豊富で表現力が高い：trait や generics、unsafe の明示などなど ・強力な静的型検査 15


Cargo を任意パッケージマネージャとして使う ・C/C++ はマトモなパッケージマネージャが無くてつらすぎる ・資産の再利用があまりにもやりにくい ・Cargo はパッケージマネージャとして非常に優秀 ・build.rs で自由にビルドロジック書き放題 ・0 byte の lib.rs を生やして C だけのライブラリもパッケージング ・c2a-core や C2A のアプリケーションを crate として管理 ・Git submodule から semver による管理に ・Rust への段階的な移行も容易になる ・あらゆるモノが git clone & cargo run できるようになる ・開発開始のコストを減らす／オンボーディングをシンプルに 16
 Cargo logo credit: Rust Foundation (CC-BY)

C2A（C言語）と Rust の相互運用 ・FFI のための型：std::ffi, core::ffi ・bindgen が超便利 ・Cのヘッダを読んでグルーコードを自動生成 ・doxygen-rs を使ってC言語側のコメントを rustdoc に持ち込む ・既存の概念（ハードウェア抽象化レイヤ）を trait などで抽象化 → FFI 部分を proc macro で自動実装 ・Web 系の概念／実装を持ち込む ex：C2A が WebSocket を喋れるように 自動生成 17


組み込み Rust ・LLVM ベースなので多様な ISA に対応（ARM, RISC-V, …） ・core 標準ライブラリが便利 ・ex：core::fmt で書式文字列が使える（printf 実装不要） ・no_std 環境で動く crate（ライブラリ）も充実 ・強力な型システムも便利 ・ex：ピンアサインのミスをコンパイルエラーにできる ・unsafe な領域が明示できる（あることは問題ではない） ・開発環境：VSCode + probe-rs が最強 ・F5 で書き込んで普通に breakpoint 打てる ・設定も Git 管理できる（全員が同じ開発体験） ・defmt で簡単にログ出力（SWD 経由） 18


SILS：Software in the loop Simulation ・組み込み SW あるある：毎回実機に書き込んで試すのが面倒！！！ ・人工衛星搭載 SW あるある：実機に書き込んだところで宇宙環境の模擬ができない！！！ ・特に姿勢制御関係 ・実 SW（C2A）を x86 や AArch64 にクロスビルド + HW 依存部や宇宙環境を模擬 ・宇宙環境のシミュレータを接続することで宇宙環境特有の処理の検証も可能に ・AWS にデプロイして試験や運用訓練にも活用 C2A「人工衛星を制御するぞ......！」 センサの模擬 アクチュエータ の模擬 19


HW 接続の仮想化 ・kble：Virtual Harness Toolkit ・色々なストリームの接続（UART など）を WebSocket に引き出す ・物理的な接続より上のレイヤ（フレーミング後など）での接続も可能 ・FSW は仮想化（SILS）した上で一部機器だけ実機、のような接続も可能 衛星内の接続も模擬 通常（実機など） 20
 SILS（with kble）

C2A DevTools ・運用／試験時にやりたいこと != 開発時にやりたいこと ・開発時にはすぐ使えるシンプルなツールが欲しい ・テレメトリ／コマンド操作のみができる Web アプリ ・バックエンドや DSL は地上局システムと共通 ・WebSocket, TypeScript, React ・Zenn：リアルタイム通信用のコネクションをタブ間で共有してます 21


OSS 活動 ・https://github.com/arkedge/c2a-core：FSW フレームワーク ・https://github.com/arkedge/gaia：地上局システムのコア部分 ・試験システムや開発者向けツールもこれをベースにしている ・https://github.com/arkedge/kble：ハードウェア接続の仮想化ツール ・宇宙環境シミュレータも東大研究室から公開・開発協力：https://github.com/ut-issl/s2e-core/ ・各種フレームワーク／ツールの公開 → 業界の SW 力向上／共通言語化を目指す 22