１．これまで自分が関わってきた C2A (Command Centric Architecture)

C2A (Command Centric Architecture) とは，これまで中須賀研究室が開発してきた，人工衛星のフライトソフトウェア（アーキテクチャ）です．

一度打ち上げてしまうとソフトウェアの書き換えもなかなかできない人工衛星において重要な軌道上再構成能力と，短い期間で学生が入れ替わっていく大学という環境で重要なソースコードの再利用性に優れたアーキテクチャです．

 

詳細は，せっかくOSS化したC2Aの公開リポジトリのドキュメント（2021/11/30現在，ほぼ何も書かれてないですが．．．近いうちにpushしておきます．）を参照してもらうとして，きっとそこには書かないだろう，C2Aの歴史についてを少しだけ書きたいと思います．

フライトソフトウェアのユーザーランドの個別実装（それぞれのアプリケーションやドライバではなく），その中核部分（Linux kernel的な部分．後述するC2A Core）を話のスコープとします．

 

 

C2Aは，中須賀研究室の超小型衛星ほどよし３，４号機あたりから開発が始まっており，ログを見る限りは初期部分はほぼ滝澤さんによって開発されてきました．

この成果は，2014年の彼の博士論文『再利用性と軌道上再構成能力に優れた 衛星ソフトウエア・アーキテクチャに関する研究』にまとめられています．

2013年後半ごろからC2Aの雛形のようなコードが誕生し始め，博士論文の段階でC2Aが（だいたい）リアルタイムOSとして動くためのタスク管理とタスクスケジューリング機能，C2Aのコンセプトである高い軌道上再構成能力が出来上がっていました．

 

その後，別の超小型衛星PROCYONにて，滝澤さんの卒業に伴い開発が中島さんに徐々に移り，衛星の運用において重要な機能が実装され，C2A自体も整理（揺れている実装が固まったり，各所の役割が明確化されていったり）されていきました．

この時点でのC2Aの基本機能・コンセプトや運用時のあれこれは中島さんのジャーナル論文『Command-centric architecture (C2A): Satellite software architecture with a flexible reconfiguration capability』に詳細が載っています．

 

2016年，更に別の超小型衛星EQUULEUSの開発が始まり，翌年，僕がB4で中須賀研究室に入り，CDHとして開発に参加しました．

当時のC2A（というより研究室のフライトソフトウェア全般？）に対する第一印象は，なるほどこれが大規模なCプログラミングか，とか，知識が属人化しまくってて，バグにハマったときなどに後から言われて「それ知らんがな」となることが多くて辟易する，とか，衛星の運用が全然わからない（運用経験がない）のに開発なんてできるのか？，とか，そんなところでした．

 

M1にもなると，諸々の知識と経験を得て様々な問題がわかるようになっていき，ある種神聖不可侵だったC2A 中核部分（≒カーネル部分）をごにょごにょいじり始めました．

神聖不可侵と表現したのは，CDH以外のメンバはアプリケーションレイヤのさらに上層しか触りませんし，CDHメンバも現在動いている中核部分に不用意な修正を加えてバグらせたくないという考えがあったからです．

M1から修論休み（研究室独自の制度．この期間は衛星プロジェクトから離脱し，研究に専念する）に突入するM2の11月頃までで，いろいろやりましたが，記憶に残るものでいうと，次のことなどに注力していたと思います．

	当時は研究室オンプレで全く冗長化されてなかったSVNサーバーを更新し，冗長化（とはいえオンプレ）
	C2Aにちらばっている，多少のソフトウェア開発経験がある人ならわかる明らかにやばいコードをひたすら潰す作業
	unsafeすぎるコードを潰す作業
	EQUULEUS OBC (On Board Computer) ではMRAMとNAND FLASHという複数種潤沢な不揮発メモリを搭載したことに伴う，不揮発メモリのドライバ，ミドルウェア（抽象化）
	軌道上でプログラム全体を安全に書き換える，全再プロ（全プログラム再書き換え）スキーマの構築

気づけば，EQUULEUS OBCのフライトソフトウェアにおける（SVNが出す）code authorshipは，35%以上を僕が占めていました．

M2の修論休みからは後輩や博士の先輩に引き継いだので，最後の作り込み（運用シナリオやFDIRの落とし込みや運用訓練で出てきた問題の解決）作業があまりできなかったのは今でもちょっと心残りではありますが．

 

修論明け，研究室の次期衛星プロジェクトが発足すると，まず，オンプレSVNをやめ，（当時privateリポジトリの制限があったGitHubではなく）無料のGitLabへ研究室インフラを移行し，これまで何もレビューも受けずに各々が独自判断でtrunck commit/mergeしていた開発フローを，Marge Requestの発行と（実質的に）僕のレビューを必須にする開発フローへ変更しました．

また，先輩（柳田さん．EQUULEUSフライトソフトウェアの最後の作り込みは概ね彼によるところが大きい）との協力でCIやテスト環境を整えましたし，Doxygenでのドキュメントの仕組みを整備したりしました．

（テストCIは柳田さんによるところが大きく，このおかげで，この後デグレを気にせずガンガン中核部分を大規模改修することができた．）

 

そして，再利用性と安全性を高める，C2Aの全体像を大きく変更する大改修を行いました．

それは，これまで密結合だったC2Aのユーザーランドと中核部を整理し，その中核部を特定のハードウェアや計算リソースなどを想定しない "C2A Core" として分離することです（ここらへんは僕の独断と偏見で決定・実装したのですが，C89でこういう事するのが結構つらく，公開したrepositoryを見てもらうと察せる通り，もうちょいどうにかしていきたいポイントでもあります．）．

C2A Core概略図

これには，次のような効果，意図があります．

	再利用性があるとはいえ，次の衛星では前の衛星のソフトウェアをほぼそのままの状態では使用はできず，ハードウェア非依存部やC2Aの中核部分ですらパラメタチューニングや微修正が必要であった．パラメタを明確化し，Core部分のロジックは共通のものを使えるようにすることで，再利用性が高まり，また，不適切な修正や修正漏れがなくなり安全性が高まる．
	アーキテクチャも計算リソースも異なる複数のOBCで，Coreを共通化でき，他のプロジェクトメンバはユーザーランドの開発に集中できる．
	C2Aに詳しくない開発者が不用意にCoreを触らなくて済む．
	１つの衛星に複数のC2A搭載OBCがあるとき，それらのOBC間通信が統一的な仕組みで実現される．

 

EQUULEUS開発時代に執筆した学会論文『Design and Development of Low-cost and Highly Reliable C&DH Subsystem for Deep Space Nano Satellites』に，EQUULEUSのOBCのハードウェア仕様を載せていますが，だいたいこんなもんです．

EQUULEUS OBCのハードウェア仕様

今までは，「このボードで動くソフトウェアを開発すること ＝ C2Aを開発すること」，でしたが，分離以降は，特定のボードのフライトソフトウェアはまずC2A Coreを参照しつつ，その上にそのOBCごとのユーザーランドを実装していく開発に変わりました．

そしてC2A Coreは，RAMがこれよりも1桁も2桁も小さいOBCや，もっと計算リソースの潤沢なOBCでも同じC2A Coreが使えることを確認しながら，開発を進めています．

 

このような次期衛星プロジェクトの序盤での環境整備，C2Aそれ自身のアップデートについては，来年のISTSにて，発表予定です．

２．C2AのOSS化

C2AのOSS化については，M1ぐらいの頃から思い始め，別の話もあり，研究室の助教もそれなりの関心は持ってくれるものの，実務的，研究室風土的，その他様々な要因や制限で進んでいませんでした．

数ヶ月前，とある諸々があり，がっとOSS化の作業を進められることになり，各種調整も乗り越え，ようやく先週頃にしれっと次のOrganizationとrepositoryで公開しました．

 

Organization: https://github.com/orgs/ut-issl

C2A Core repository: https://github.com/ut-issl/c2a-core

C2A開発のかんばん: https://github.com/orgs/ut-issl/projects/1

 

今の所，C2Aとその周辺ツールを公開していますが，そのうち，C2Aを特定のボードで動かすことを想定したC2A sampleや，衛星シミュレータ，地上局ソフトウェアなどもOSS化していく予定です．

 

 

GitHubでOSS化されると，いろいろとopenな場でできるというのがそもそもやりやすいし，GitHub Actionsを始めとする様々なエコシステムが使えることもメリットです．

また，中須賀研究室ではない人の知見をお借りできるところが最高です．

例えば，最近だと@sksat_ttyが，CIまわりや安全性，ソフトウェア開発としての正しい（王道な）やり方，といった，ソフトウェア技術の遅れている宇宙業界にいると疎くなりがちな部分でサポートしてくれていて，助かってる ＆ 学びになってます．

３．今後

これは，研究室の方針などは全く関係のない，僕個人の考えです．

 

C2Aは，今後は，人工衛星フライトソフトウェアのなかでも，固い部分をになう（MOBCや，重要コンポーネントの組み込みや，PICなど低リソースで動くデバイス）ソフトウェアとして，安定して使っていければいいのかなと思っています．

もう少しリッチでリスクの取れるような部分は，例えばフライトソフトウェアをRustで書いてみる，とか，既存のリッチなOSを載っけてしまって，その上でソフトウェアを開発する，など，別の進むべき道があると思っています．

 

C2の開発項目は．短期的には，イベント処理スキーマの実装や衛星システムの絶対時刻対応，その他の抽象化など，やることは山積みで，なかなか長期的なもろもろを考える時間もないんですけれどもね．

 

 

2022/02/17 追記

Rustで，とは，これを意図していました．

　『無職に飽きたので人工衛星のソフトウェアをRustで作っています』 - Write and Run

 

先日起業した 株式会社アークエッジ・スペース (ArkEdge Space Inc.) では，本気でRustで衛星搭載フライトソフトウェアを開発しています．

先進的な言語での，かつモダンな開発体験での宇宙開発に興味がある方は，お気軽にお声がけください！

４．出典

	滝澤 潤一, 再利用性と軌道上再構成能力に優れた 衛星ソフトウエア・アーキテクチャに関する研究. 東京大学 博士論文, 2014.
	Ryo Suzumoto., et al., Design and Development of Low-cost and Highly Reliable C&DH Subsystem for Deep Space Nano Satellites. 32nd International Symposium on Space Technology and Science, 2019-f-33, 2019.
	Shintaro Nakajima., et al., Command-centric architecture (C2A): Satellite software architecture with a flexible reconfiguration capability. Acta Astronautica, Vol. 171, No.208, 214, 2020.
	Ryo Suzumoto., et al., Improvement of C2A (Command-Centric Architecture) Reusability for Multiple Types of OBCs and Development of Continuous Integration Environment for Reliability of Flight Software. 33rd International Symposium on Space Technology and Science, 2022.

関連記事