修士二年角川です。

先月末に5th UNISEC Space Takumi Conference
for Practical Study of Problem Finding and Solving in Space Systems
にて
超小型人工衛星開発における技術継承プロセスの提案〜ALOS-2相乗り副衛星「SPROUT」開発プロジェクトにおけるシステムズエンジニアリング〜
というタイトルで発表させていただきました。



このテーマは、どうすればプロジェクトが成功に近づくのか?という疑問から私自身が修士1年の時に持ち込んだ研究テーマです。外部の方々の前で発表する機会をいただけたとはいえ、今回の発表を通して、問題点が定量化されていない、定性的で抽象的すぎて議論しにくいのではないかと考え、より定量的にまた、具体的な事象を蓄積していくことが必要であると反省しました。



Takumi conference前半部では各大学衛星の運用に関する評価が話題となっていて、後半部分はこれから日本の宇宙システム開発どうしていくべきなのかといった点が話題になっていました。また超小型衛星RG研究会ではほどよし信頼性工学に関して議論が行われました。今回は、前半部分に絞った点に関して自身の考えを述べさせていただこうと思います。

conferenceではそれぞれの大学・研究機関個々の衛星開発プロジェクトの枠を超えて、衛星開発ワーキンググループとして衛星開発をもっとよくしようという試みがなされていました。具体的にはそれぞれの発表の方、自身の研究室やプロジェクトにて起きた、衛星システムに関する不具合やそれに対する地上での対処や、意思決定の失敗を取り上げておられました。このような失敗を各大学・研究機関間で共有しそれぞれのプロジェクトに教訓として取り入れていくといったような流れになっていて大変すばらしいと感じました。
巷ではリコール隠しとか、不具合の隠蔽などが問題となっている中で、規模は異なるのかもしれませんし、重大な事故には至っていないものの、責任を背負う覚悟をもって事象を表に出し、より超小型衛星開発を発展させようという流れで議論がなされていたからです。

SPROUTのプロジェクト、宮崎研の衛星開発の中でももっと積極的にこのような流れを取り入れていくべきだと思いました。

超小型衛星開発において衛星システムは一発勝負です。一度打ち上げてしまえば、システムに修正を加えることができないからです。そのため開発段階では実際の宇宙環境を想定して繰り返し検証を行って万全を尽くしてきました。しかし、検証漏れは人間が作ったものである以上どうしても出てきてしまいます。
宮崎研究室として、現段階で大事なのはプロジェクトとしてそれに対処することが「できるのか」、「できないのか」を明確にしておくことだと思います。仮に、衛星システムに故障があっても、地上局側で対処出来れば、プロジェクトとしては成功です。逆にプロジェクトのミッション要求が衛星システムの故障よって満たされず、その故障に対して地上側でなんらかの対処ができない場合、それはプロジェクト失敗に値します。「できるのか」「できないのか」あいまいにしたままではプロジェクト成否の評価すらできなくなってしまいかねないと思います。
前々回前回のブログで紹介しました、SPROUT5年間の運用に関する技術継承問題において言えば、(SPROUTは研究室のB3,B4,M1,M2で運用していますが)運用に関して軌道上で起きた故障・エラー・不具合の対処に関しては開発のコアメンバーの間で暗黙的に処理されていることが多く、その事象と対策はプロジェクト全体で共有されていない点が多々あります。そのため、現段階では衛星システムに対する命令(運用の要件定義からコマンド作成・確認・送信)は開発コアメンバーしかできない状況です。
このような問題にアプローチするためにも、もっと積極的に毎週のSPROUTミーティングの場などにおいて不具合事象・対処に言及し、プロジェクト全体として共有すべきなのではないかと思います。プロジェクト全体で共有する方向性を掲げることで技術継承の促進も期待できると考えています。(SPROUTプロジェクトには次期衛星NEXUS開発プロジェクトメンバーも参加している)
なぜなら、不具合事象そのものやそれに対する対処を理解することはSPROUTのプロジェクト全体(開発プロセス、運用システム・衛星システム・地上局システムetc…)を網羅的に理解することにつながるからです。
このような不具合事象・対処に関する共有を促進するために、以下のような「不具合事象記録」というエクセルシートを運用していきたいと思います。



次回のブログは学部3年の川添くんお願いします。