SIB2/GSTOS(Spacecraft Information
Base version2/Generic Spacecraft
Test and Operations Software)の開発状況
西村佳代子、松崎恵一、宮野喜和、宮澤秀幸、高木亮治、永松弘行、
長木明成、福田盛介、山田隆弘、馬場肇（ISAS/JAXA）

1.SIB2/GSTOS概要◇SIB2(Spacecraft Information Base version2)とは・・・
人工衛星に関する情報を格納するためのデータベース（従来の衛星運用システムではSIBを使用していた）◇GSTOS(Generic Spacecraft Test and Operations Software)とは・・・
人工衛星の試験と運用に使用される汎用のソフトウェア群
SIB2に基づいて動作する(SIB2の内容を置き換えることによって、様々な衛星に適用することが可能)

◇衛星運用とは◇【目的】
衛星がミッションを果たすために衛星の状態監視、衛星の制御をを行う。
【必要なもの】・地上局設備
衛星とデータを送受信し、送受信するデータの処理を行う。
・衛星運用設備衛星の軌道を決定・予測する。
衛星の制御計画を立てる。
衛星の状態データ（テレメトリ）を監視し、衛星への制御データ（コマンド）を生成する。

◆従来の衛星運用システム◆

問題点 3
衛星毎の新規性がほとんどない箇
所でもプロジェクト毎に開発・運用問題点 4
属人的な開発が行われてきたため、維持管理に必要な設計情報が不足

問題点 2
計画検証ツールは、衛星の打上前後に、若手研究者が作成し、科学的な生産性を落とすと共に、リスク要因となっていることが多い

これらの問題点が、衛星開発コスト、スケジュールに大きく影響を与える

問題点 1
搭載機器の設計の記述レベルが設計者毎に異なる電子的管理が不十分で非効率的

問題点を解消するためにSIB2/GSTOSの開発を行う
問題点 1
搭載機器の設計の記述レベルが設計者毎に異なる
電子的管理が不十分で非効率的・機能モデルによる衛星設計を実現
・従来を凌ぐ利便性の実現
問題点 2
計画検証ツールは、衛星の打上前後に、若手研究者が作成し、科学的な生産性を落とすと共に、リスク要因となっていることが多い

・計画検証系の汎用ツール化
問題点 3
衛星毎の新規性がほとんどない箇所でもプロジェクト毎に開発・運用・衛星毎の差分開発の極小化・装置からソフトウェア化することで、運用部隊による定常運用の実現
問題点 4
属人的な開発が行われてきたため、維持管理に必要な設計情報が不足
・利用者が理解可能な資料を整備
・JAXA側が差分開発を継続できるよう資料を整備

目標

◇SIB2/GSTOSの主開発対象◇

GSTOS on-lineソフトウェア
コマンド発行ソフトウェア
・・・衛星への制御データを生成する
状態監視ソフトウェア
テレメトリ監視ソフトウェア
・・・衛星の状態データを監視する
GSTOS off-lineソフトウェア
コマンド計画検証ソフトウェア
・・・衛星のコマンド計画を作成する
テレメトリ診断ソフトウェア
・・・衛星の状態データを診断する

SIB2XMLスキーマ定義
SIB2関連ソフトウェア
SIB2作成ツール
SIB2整合性チェックツール
SIB2構成管理ツール
・・・SIB2を作成し、管理する
これらについて、MMO、SPRINT-A、ASTRO-H、はやぶさ2共通に開発を行う。

◇開発方針◇•••••on-lineソフトウェアについては、従来のシステムと同レベルの機能を保持する
off-lineソフトウェアについては、既存のソフトウェアの機能の取捨選択を行う
衛星試験・運用で最低限必要なSIB2とon-lineソフトウェアの検討・開発から着手
検討フェーズでは、各衛星プロジェクトと協力し、従来システムに対する改善要求の洗い出しや、衛星設計との矛盾がないように設計検討を行う
上記の改善要求などについては、共通部と衛星固有部とに区別し、共通部の開発をSIB2/GSTOSチームで担当し、衛星固有部については、衛星プロジェクト側で担当することとする◇目標レベル◇
ミニマムサクセス-プロジェクトにともかく提供すること-従来システムで実現していた基本的な機能を実現すること
フルサクセス-属人性の排除・文書化-従来システムで実現していたすべての機能を実現すること
エクストラサクセス-その他の新機能の実装◇開発スケジュール◇（ミニマムサクセス）

2.開発状況◇SIB2関連◇[現状]
SIB2XMLスキーマ定義及び、SIB2作成ツールなどの各ツールの開発完了⇒維持管理フェーズ
4つの衛星試験にて現在使用中[従来システムとの相違点]
・SIB2定義の記法として、状態遷移や機能オブジェクトなどUML的な概念を導入した(機能モデルによる衛星設計の実現)。
・ツールをより充実させ、ユーザの負担を軽減した。
各搭載機器の担当がそれぞれ別ファイルとしてSIB2定義を行っても、コピペ等することなく、別ファイルのままで扱える。
その他、メーカーが独自で持っていたツールについても洗い出し、機構で内容を把握し、維持管理できるようにした。
(画面定義ファイル作成ツール、メモリ管理表、冗長系定義)
・SIB2作成ツールでは、XMLファイルを源泉とし、インポートも可能とした。
・条件付きリミット定義、繰り返し、グラフ定義は未対応[課題]
文書レベルが一部まだ不十分
システム構成が検討不足⇒ユーザの意見を収集し、改善作業を進めていく
SIB2/GSTOSチームにて、SIB2システムの構成見直し

◇GSTOS on-lineソフトウェア◇[現状]
コマンド発行ソフトウェア、状態監視ソフトウェア、テレメトリ監視ソフトウェアの開発完了⇒維持管理フェーズ
4つの衛星試験にて現在使用中[従来システムとの相違点]
・従来と同等の機能を保持し、従来と同じシステム構成とすることが可能
コマンド発行ソフトウェア
・コマンド計画の文法(CHECK文、WAIT_UNTIL文)を追加し、それに対応する機能を追加した
状態監視ソフトウェア
・従来の状態監視端末をソフトウェア化
テレメトリ監視ソフトウェア
・ユーザ要求を踏まえ検索性など機能向上
・新規画面定義を行えるようにした・C言語の関数による変換、任意の関数式による変換を扱えるようにした[課題]
文書レベルが一部まだ不十分⇒ユーザの意見を収集し、改善作業を進めていく
ASTRO-Hプロジェクトでは、単体試験での使用例もあるが、GSTOSプロジェクトとしては未対応(現状ではシステム試験から対応。)

◇GSTOS off-lineソフトウェア◇
コマンド計画検証ソフトウェア
[現状]
開発完了
⇒衛星固有部とのインテグレーションフェーズ[従来システムとの相違点]
計画作成部(コマンド計画を出力する機能部：従来のISACS-PLN相当)と計画検証部(計画の妥当性を検証する機能部)に区別して開発を進めた。
従来システムでは、計画検証部は、衛星プロジェクトそれぞれで、衛星打ち上げ前後に、インハウスでツールを作成するなどして対応していた部分
計画作成部
運用要求内容を記述する言語の見直しを行い、Rubyを母言語としてORLGを定義した。
優先度や時刻の割付方法について明確にした。
使用頻度が低いと思われる機能（モード切替、ダイナミックマクロ）については現段階では 未対応とした。

計画検証部
衛星毎の差が大きいことと、MMOでは既に一部ツールを作成していたこともあり、まずは、近地球に対象をしぼって共通部の開発を行った。
一つのソフトウェアではなく、複数のツール群として開発し、ツールは衛星毎に入れかえられるようなモジュール構造とした。
衛星固有部とのインテグレーションが必要ではあるが、従来より衛星プロジェクトの負担は少なくなった。

◇GSTOS off-lineソフトウェア◇
テレメトリ診断ソフトウェア
[現状]
開発完了
⇒維持管理フェーズ
2月からSPRINT-A衛星試験で使用される予定。

[従来システムとの相違点]
他のソフトと重複していた機能の整理を行い、まずは、テレメトリを診断した結果のメール送信機能に限定している（グラフ機能、診断知識入力インタフェースについては未対応）◇その他◇
各ソフトウェアや文書類の最新版をユーザがスムーズに入手できるように、専用webページを作成し、公開している。
(各衛星プロジェクトに対して、アカウントを発行し、ダウンロードできるユーザについては制限をかけている。)

3.まとめ• 全体的にメーカによる開発は一段落し、維持管理フェーズに入っている。
• 目標の達成度は以下の通り。
ミニマムサクセスは達成し、現在は維持管理をしながらフルサクセスを狙っている。
○機能モデルによる衛星設計を実現○従来を凌ぐ利便性の実現○計画検証系の汎用ツール化○衛星毎の差分開発の極小化☆装置からソフトウェア化することで、運用部隊による定常運用の実現☆利用者が理解可能な資料を整備☆JAXA側が差分開発を継続できるよう資料を整備• 複数の衛星試験が並行しているが、GSTOSとして、不具合や改善内容の水平展開を効率よく行うことができている。

付録

【衛星運用の大まかな流れ】
1.運用前準備
1-1.軌道予測値から運用に使用する地上局と時間を決める。
1-2.衛星の搭載機器で何をしたいか決める。
1-3.コマンド計画を作成する（コマンド計画検証）。
2.運用
2-1.衛星にコマンドを送信する（コマンド発行）。
2-2.衛星の状態を監視する（テレメトリ監視）。
2-3.地上局と衛星間の距離を計測する。
2-4.衛星の状態をチェックし（テレメトリ診断）、状態によっては、ユーザにメールで通知する。
3.運用後
3-1.計測した距離から、軌道予測値を計算する。