PLAINニュース第175号
Page 2

宇宙情報システム講義第２部 これからの衛星データシステムはこうなる
（第２回　衛星の機能モデル）

山田 隆弘
宇宙情報・エネルギー工学研究系

　今回からは「衛星の機能モデル」の話をします。

　前回もお話ししたように、今までは衛星の搭載機器の機能設計については何の決まりもありませんでした。それぞれの搭載機器の設計者が「こういう機能をこのように実現しよう」と自分で考えます。そして、その機能を使うために地上から送るコマンドのフォーマットも自分で決めますし、機能の実行結果を確認するためのテレメトリのフォーマットも自分で考えます。

　この方法は、設計者が自分の思い通りに何でも決められますので、設計者にとっては良い方法のようにも思えます。しかし、過去の衛星の設計例を調べてみたら、似たような機能でも設計者が異なると全く違った風に設計されていることが分かったのです。さらに、機能設計の結果を表現するための決まりもありませんので、設計結果の説明の仕方も人によってバラバラですし、設計結果の説明が不十分である場合も多かったのです。

　こうなると、搭載機器を運用する人は、別々の設計者の書いた別々の説明を読んで理解しなければいけませんし、設計者の説明が不十分な場合は運用者が試行錯誤をしながら設計者の意図を再現するということもありえます。

　しかし、これでは運用者の負担が大きくなりますし、間違いが起こる可能性も大きくなります。そこで、「衛星の機能設計はこのように行って下さい」という決まりを作ることにしたのです。この決まりが「衛星の機能モデル」です。

　このモデルは、ソフトウェアの世界で使用されているオブジェクト指向と呼ばれる技術を参考にしました。オブジェクト指向では、オブジェクトという概念を使い、プログラムのまとまりをオブジェクトという単位としてまとめます。そして、複数の色々なオブジェクトを組み合わせることによってプログラムを作るのです。

　「衛星の機能モデル」でもこの考えを参考にし、機能オブジェクトという概念を使い、搭載機器の機能のまとまりを機能オブジェクトという単位としてまとめます。そして、複数の色々な機能オブジェクトを組み合わせることによって搭載機器の機能設計を行うのです。

　機能オブジェクトの詳細は、次回以降で詳しく説明しますが、「衛星の機能モデル」の基本的な考え方は、衛星の機能を、それがソフトウェアで実現されていてもハードウェアで実現されていても、外からはソフトウェアに見えるように設計しましょうということなんです。

　ところで、「衛星の機能モデル」では機能オブジェクトの概念を規定しているのですが、「こういう機能はこのような機能オブジェクトを使って実現しましょう」ということまでは規定していないのです。しかし、似たような機能を別々の設計者が別々に設計していては効率が悪いので、将来は「こういう機能はこのような機能オブジェクトを使って実現しましょう」という典型的な機能オブジェクトをあらかじめいくつか作っておき、個々の設計は典型的な機能オブジェクトを拡張することによって行えるようにしたいと思っています。このような典型的な機能オブジェクトの集合のことをモデルライブラリと私は呼んでいますが、モデルライブラリの開発がこの次の重要なステップです。

　さて、機能オブジェクトという概念を用いて搭載機器の機能設計を行うと、個々の搭載機器の機能設計の結果を機能オブジェクトの特徴として表せるようになります。こうなると、どんな搭載機器であろうと、機能設計結果が統一的に表現できますので、運用者が設計者の意図を理解するのが今までよりも容易になります。さらに、機能オブジェクトの特徴を表現するのに共通の言語（例えば XML）を使用すれば、機能オブジェクトの特徴を格納したデータベースが作成できます。今までの衛星情報ベース (SIB) は、コマンドとテレメトリに対する付加情報として搭載機器の機能に関する情報も多少は格納していましたが、現在開発中の SIB2 では、搭載機器の機能情報を機能オブジェクトの特徴として格納することになります。

　さらに、機能オブジェクトを遠隔制御するためのプロトコルとして衛星監視制御プロトコルを開発しました。このプロトコルを使うことによってコマンドとテレメトリのフォーマットが統一されます。また、衛星監視制御プロトコルに従って規定されたコマンドとテレメトリのフォーマットも SIB2 に格納されます。

　これらの概念の間の関係を図１に示します。次回 は機能オブジェクトの話をします。

図１　衛星の機能モデルと他の概念との関係