JAMSATトランスポンタ N3TRP 開発記 S/W編
はじめに
これまで、大学生さんサポートとして、CubeSat衛星開発にいくつか関わってきましたが、
如何せん主役は学生さん、伝えることの喜びは感じていたしたが、持てるエネルギーは発散しきれずにいて、もやもや感も感じていました。
そんな中、アマチュア無線家向けに衛星を利用した無線中継機器(以下トランスポンダ)の製作・運用を行っている団体
JAMSAT(The Japan Amature Statellite Association/日本アマチュア衛星通信協会)さんの存在を知ることになりました。
次なるステップになると感じて、2021年年頭にJAMSATの門を叩いたところ、
運良く次期トランスポンタ開発サイクルの初期段階だったこともあり、また S/W要員を募集していることもあって
すんなり仲間に加えて頂けたました。[^1] [1]
そして2022年末、開発プロセスが一段落し、衛星投入を待つ段となりましたので、
私が担当した部分(S/W 上位レイヤ)の開発記を記そうと思います。
トランスポンタ概要
JAMSATトランスポンタは、日本大学奥山研究室が主体となって製作している衛星'てんこう2'のサブシステムとして登載されます。
主な機能(ミッション)は
- 144MHz帯の地上波を受信し、430MHz帯電波に変換して地上に向けて発射する
- 430MHz帯および5.8GHz帯のCWビーコンを発射する
- てんこう2登載カメラが撮影した静止画像を地上に転送する
です。
てんこう2の詳細については、日大理工学部のサイトをご覧ください。
トランスポンタの詳細については、今後JAMSATが公開予定の記事をお待ちください。(公開され次第URLを記載します)
構成
てんこう2とトランスポンタの相関関係を図に示しますと次にようになります。
なお、てんこう2は、複数のユニットから構成されていますが、便宜上制御部ユニットであるOBC(On Board Computer)のみ取り上げています。
上記に掲げたミッションの内、一部はトランスポンタ独自の判断で動作しますし、一部は母体である'てんこう2'と協調しながら遂行するという関係になっています。
要求仕様
トランスポンタ 開発マネジャーから提示された要求仕様は
トランスモード(TRP)、430MHz帯 CWビーコン発信モード(TCW)、5.8GHz帯CWビーコン発信モード(58G)、画像情報パケット送信モード(FSK)の4つモードを持った上で、
TRPモード/TCWモード/58Gモードは、シーケンスとして動作させる。加えて、OBCから要求に応じて任意のタイミングで、TRPモード/58Gモードを実行させるともに、
てんこう2の主要ミッションの一つである静止画像データ転送(FSKモード)にも任意のタイミングで応じる。
なお、画像データ転送は、1パケット168 Bytes単位で行い、FSK変調して送出する。
というものでした。
図にすると次の様になります。
RTOS採用へ
要求仕様の複雑さあり、また、本業との兼ね合いで時間的制約もあり、でしたので、
JAMSAT衛星開発としては過去実績なしということでしたが、RTOS利用することを提案しました。
投入されたら一切手を出せない宇宙空間利用においては、高い信頼性・安定性が求められ、新規モノは躊躇されることが多いのですが、
未知の領域に踏み出すことを良しとしてくれたJAMSAT上層部のチャレンジ精神に感謝です。[^2]
[2]
今回採用したRTOSは、FreeRTOSです。Amazonが買収したことで、Amzone FreeRTOSと銘を打たれたRTOSではありますが、
今回使用するのは、トランスポンタユニットに登載されるMPUがSTMicroelectronics社製 STM32L4シリーズであることもあり、
同社が提供する統合開発環境"STM32CubeIDE"に付随している CMSIS-RTOSを使用します。
CMSIS-RTOSのAPIは、Amazon FreeRTOSとも、オリジナル(買収前)のFreeRTOSのAPIとも異なる仕様になっており、
オリジナルFreeRTOSのAPIをラップする形で ARM社が策定したものになっています。
また、CMSIS-RTOSには、ARM社製CPU Cortex-M系用のCMSIS-RTOS V1とCortex-A系のCMSIS-RTOS2 V2の2バージョンが存在しますが、
今回使用するSTM32L4シリーズは、Cortex-M系なので、V1を利用します。
IDEに付属という形で提供されるRTOSではありますが、タスク管理(生成・遷移・破棄)はもちろん、イベント管理、排他処理、タスク間通信 等のAPIが
提供されているので[^3][3]、要求されている機能は実現できそうです。また、リソース単位の取捨選択もでき、OSのコンパクト化も出来そうです。[^3]
実際、STM32L4リファレンスボートを使った本番実装の前のお試し実装でも、これまで経験したRTOSと遜色はありませんでした。
ソフトウエア構成
アーキテクチャ
トランスポンのソフトウェアブロックは、図の様に大きく3つのレイヤに分けて設計しました。
最上位が、OBCとのI/F層、次段が、トランスポンタ制御層、そして、 トランスポンタ固有H/WドライバとOSを含む層です。(図は、H/W層も加えています。)
このソフトウエアレイアを意識しつつ、次項で示すタスクを定義しています。
タスク構成
トランスポンタ/SWレイヤの上位層は、結果的には5つのタスクで構成されることになりました。
- OBC通信タスク
- コマンド処理タスク
- ステートマネージャタスク
- ビーコン生成タスク
- 画像データ転送タスク
OBC通信タスク
トランスポンタとOBC間の通信はUARTです。本タスクは、OBCからのメッセージ受信とOBCへのメッセージ送信のみを行っています。
データバッファリングには、STM32/UARTブロックが持つ、FIFOを利用しています。
コマンド処理タスク
OBC通信タスクが受信したOBCからのメッセージをRTOOS/Queueを介して受取り、パース後、OBCメッセージに応じてミッション機能管理タスクに指示を出します。
ステートマネージャタスク
OBCからの指示がなければ、決めれたタイムスケジュールに従って、TRPモード/TCWモード/58Gモードの遷移を行います。
OBCから指示があれば、実行中の機能を停止、もしくは一時停止させて、要求に応じて TRPモード、TCWモード、58モード、もしくは FSKモードのいずれかを機能させます。そして、所望時間経過後、タイムスケジュールに基づいたシーケンス処理に戻ります。
ビーコン生成タスク
トランスポンタが提供する状態情報を取得し、ビーコンとしてパケット化を行います。送信は、ミッション管理タスク内で行います。
当初は、ミッション機能管理タスク内の一処理でしたが、状態情報の取得に4チャネル分ADCを行っていて時間を要する上に
OBCリクエストがあれば、ADCを中断してリクエスト処理に応じたいというリクエストがあり、タスク独立化を行いました。
画像データ転送タスク
ミッション機能管理タスクからキックされるサブタスクです。
OBCから転送されてくれる画像情報をプリアンブル+168B単位で受け取り、FSK変調して、送出します。
通信に占有される時間が比較的長いので、通信エラーを想定したやや複雑な受信処理を行っています。
そのため、サブタスクとして扱っています。
記事の今後について
以上が、トランスポンタおよびトランスポンタを制御するソフトウェアの概要となります。
今後は、FreeRTOS/APIとの奮戦について、ポエムではなく、テクニカルレポートとして深掘りしていく予定です。ただし、先に言い訳ですが、本業が忙しくなり記事を投稿するタイミングは23年秋頃になりそうです。この記事の存在も忘れ去られそうですね。
なお、現状(2023年初)としては、ストレステストも無事終え、RTOS採用による弊害にも見受けられない様です。ただ、宇宙空間では動作保証は未知数ですが。その前に、無事に衛星軌道に投下されていることを願っています。
Discussion