ソフトウェアの流用について

学会に来ています．

（学会詳細については，次を参照．）

 

前々から引っかかっていたことなのですが，学会中にも「OBC（衛星搭載コンピュータ; On-Board Computer）を過去の PJ（プロジェクト）と同等のものを採用することで，フライトソフトウェアを流用でき，その開発コストを低減できる」という主張を聞き，もやもやしたので，書いておきます．

 

そもそも，全く同じものを再製造するのでない限り，流用はできないはずです．

さらに，ソフトウェアはハードウェアと異なり，「コピーが無料である」ことが大きな強みなわけで，いかなる時でも（OBC が異なっていようとも）常にソースコードが再利用ができないか考えるべきです．

 

という意味で，上のような主張はそのままでは意味をなさず，議論するのであれば，

	センサ・アクチュエータ入出力は抽象化されているので，パラメタ合わせを除いてアプリケーションは再利用できる（＝ハードウェアレイヤは再利用できないことを示唆）．
	OBC 自体は全く同じボードで物理層に変更はないので，デバイスドライバは再利用できる（＝プロトコルスタック全体は再利用できないことを示唆）．

などのような議論にしかならないはずです．

 

別の観点の話もついでにしておきましょうか．

過去の衛星 PJ のソースコードをもってきて，それを initial commit として次の PJ のソフトウェア開発を開発すると，ソフトウェアの信頼性の観点から問題になることが度々あります（とりわけ，パッケージマネージャなどが成熟していない組み込みソフトウェアにおいては）．

このようなことは，研究室配属した直後に経験した大学衛星 PJ でも強い問題感を感じたため，文献 などでも問題提起していますが，ここにも簡単に書いておきます．

 

全く同じ衛星の再製造でない限り，衛星の物理的な差異やミッションの違いによって，既存のソースコードを修正することが確実にあると思います．

例えば，衛星にヒーターが搭載されており，それを識別する enum が次のようになっているとします．

typedef enum
{
  HEATER_ID_PX_PANEL,
  HEATER_ID_MX_PANEL,
  HEATER_ID_BATTERY1,
  HEATER_ID_BATTERY2,
  HEATER_ID_CAMERA,
  HEATER_ID_LENS,
  HEATER_ID_MAX,
} HEATER_ID;

次期 PJ では，バッテリヒーターが 1 つ減って HEATER_ID_BATTERY2 がなくなった場合，

typedef enum
{
  HEATER_ID_PX_PANEL,
  HEATER_ID_MX_PANEL,
  HEATER_ID_BATTERY,
  HEATER_ID_CAMERA,
  HEATER_ID_LENS,
  HEATER_ID_MAX,
} HEATER_ID;

のように修正されるわけですが，きちんとしたソフトウェア設計になっていればともかく，そうなっていないこともしばしばあるような衛星フライトソフトウェアでは，影響範囲が各所に及びます．

ソースコードの責任範囲がしっかりしている，テストがしっかり整備されている，CI が適切に整備されいてる，などの体制があって，初めてこのようなコードを安心して再利用できる（する気になる）わけですが，タイトなスケジュールの中で目先の PJ のみを考えていると，なかなかそうはなっていないことが多いのではないでしょうか？

そうでなければ，過去 PJ の "実績ある" ソースコードであっても，影響範囲を精査し，適切に再検証する必要があるはずです．

 

 

と，いろいろ思ったので，自戒の念を込めてここにメモ書きしておきます．

出典

	日本航空宇宙学会. 第66回宇宙科学技術連合講演会. Retrieved November 4, 2022, from https://branch.jsass.or.jp/ukaren66/
	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.

関連記事