機能モデルに基づいた
衛星搭載機器の設計について
宇宙科学研究本部 山田隆弘
第２版 2007年10月22日

1

目次
第１章
第２章
第３章
第４章
第５章

概要
衛星の機能モデル (FMS)
衛星監視制御プロトコル (SMCP)
衛星情報ベース２ (SIB2)
汎用衛星試験運用ソフトウェア (GSTOS)

本資料は以下の文書に基づいている。
1. 衛星の機能モデル (FMS)、GSTOS 201-0.6、2007年10月19日
2. 衛星監視制御プロトコル (SMCP)、 GSTOS 200-0.7、2007年10月19日
3. 衛星情報ベース２定義書 (DSIB2)、 GSTOS 300-0.6、2007年10月19日

2

第１章

概要
（機能モデルに基づいた設計の概要を説明する）

3

今までの搭載機器設計◆◆◆

今までの搭載機器の設計では、機能設計（ここでは、搭載機器の機能をテレメトリとコマンドを用いてどのように運用するかを決定することを機能設計という）についての基準がなく、搭載機器毎に機能設計をバラバラに行っていた。
そのために、各々の搭載機器の機能設計には、次のような労力が必要であった。
 その搭載機器の機能をテレメトリとコマンドを用いてどのように運用するかを決定する。
 上記の決定の結果をどのように記述すべきかを検討する。
 テレメトリとコマンドのフォーマットを決定し、テレメトリを出力する方式とコマンドを解釈する方式を設計する。
 テレメトリとコマンドのフォーマットをSIBに登録する。
搭載機器の機能設計方法を統一することにより、上に示した労力を軽減することが可能になる。

4

機能モデルに基づいた設計◆◆◆

ここでは、搭載機器の機能設計方法を統一するために、機能設計に対する統一的な枠組みを提案する。この枠組みのことを機能モデルと呼ぶ。
搭載機器を試験運用するシステムや搭載機器の情報を格納するデータ
ベース(SIB2)も搭載機器が機能モデルに基づいて設計されているということを前提として設計される。これにより、試験運用システムやデータベースの開発も効率化される。
ここでは「試験運用システム」という用語は、単体試験装置、衛星試
験装置、衛星運用装置、搭載自律運用機能のすべての総称として用い
る。
搭載機器

SIB2

試験運用
システム

機能モデル
5

搭載機器を監視制御する方法
◆

◆
◆
◆

◆

搭載機器を試験運用システム（単体試験装置、衛星試験装置、衛星運用装置、搭載自律運用機能の総称）を用いて監視制御するためには、搭載機器と試験運用システムの間に何らかの通信媒体が必要である。
この通信媒体には、無線回線、有線回線（イーサネットやSpaceWire等)、共有メモリなど様々な特性を有する物が使用され得る。
搭載機器と試験運用システムとの間の通信方式（プロトコル）は、使用される媒体の性質に基づいて設計されるべきである。
衛星と地上の間の無線回線の特性（すなわち、帯域幅は狭く、間欠的にしか接続されない）に合わせて設計した通信方式として衛星監視制
御プロトコル (Spacecraft Monitor & Control Protocol, SMCP) と呼ばれる方式を用意する。
それ以外の通信媒体に合わせたプロトコルも順次用意する。

搭載機器

通信媒体

試験運用
システム

衛星監視制御プロトコル6衛星情報ベース２ (SIB2)◆

衛星情報ベース２(Spacecraft Information Base 2, SIB2)には、以下の情報が格納される。
 機能モデルに従って設計された搭載機器の機能 衛星監視制御プロトコルに従って設計されたテレメトリとコマン
ドメッセージ衛星の機能モデル

衛星監視制御プロトコル

搭載機器の
機能

テレメトリ／コマンドメッセージ

SIB2
7

第２章

衛星の機能モデル（衛星／搭載機器の機能モデルの内容を説明する）

8

機能モデルの意義
◆
◆

◆

◆

◆

機能モデルとは、衛星および搭載機器（今後はこれらを総称して衛星と呼ぶ）の機能設計に対する統一的な枠組みである。
この枠組みは、機能の構成方法と運用方法に対する抽象的な枠組みであり、「この機能はこのように設計せよ」という具体的な指針は与えない。
「この機能はこのように設計せよ」という指針は、典型的な機能に対する設計結果をモデルライブラリとして提供する予定である。個々の搭載機器の機能設計は、可能な限りモデルライブラリを利用して頂きたい。
第３章で説明する衛星監視制御プロトコルは、衛星が機能モデルに従って設計されていることを前提としている。衛星が統一的なモデルに従って設計されていれば、衛星と試験運用システムとの間のプロトコルも統一的に設計することができ、試験運用システムも統一的に設計することができる。
第４章で説明する衛星情報ベース２も、衛星が機能モデルに従って設計されていることを前提としている。衛星が統一的なモデルに従って設計されていれば、その情報を格納するデータベースも統一的に設計することができる。
9

機能モデルの概要
◆
◆

◆

◆

◆

ここでは、衛星（あるいは搭載機器）の機能とは、衛星が軌道上で実施する観測や実験などの仕事を抽象化して表したものである。
この抽象化とは、衛星の仕事に関して衛星の外部から見える部分のみに注目し、その仕事が衛星内部でどのようになされるかは取捨することによってなされる。
衛星の機能は複雑であるが、複雑な機能を設計するには、様々な機能をまとまり毎にまとめると設計しやすくなる。このよう機能のまとまりを機能オブジェクトと呼ぶ。
機能オブジェクトの概念は、オブジェクト指向プログラミングにおけるオブジェクトの概念に基づいている。ただし、オブジェクト指向プ
ログラミングでは、まずクラスを定義し、オブジェクトはクラスより動的に生成されるが、衛星は永続的に存在するものなので、ここでは実存する個々の機能を表すオブジェクトを基本的な存在として考える。
複数の機能オブジェクト定義に共通な部分は、テンプレートとして規定する。このように複数の機能オブジェクトを生成するためのテンプ
レートを機能クラスと呼ぶ。

10

機能オブジェクトの概念
◆

◆
◆

◆

◆

機能オブジェクトは、衛星の機能の単位であり、衛星の機能を規定する上で一つにまとめて規定すると規定しやすいあるいは理解しやすい機能を一つにまとめたものである。
機能オブジェクトは、他の機能オブジェクトを一つあるいは複数個含
むことができる。
衛星全体も一つの機能オブジェクトであり、複数の機能オブジェクトを含む。それらの各々の機能オブジェクトも一つあるいは複数の機能
オブジェクトを含み得る。あらゆる機能オブジェクトは、衛星全体を表す機能オブジェクトに直接あるいは間接的に含まれている。
ある機能オブジェクトに含まれる機能オブジェクトをその機能オブジェクトの子機能オブジェクトと呼ぶ。また、子機能オブジェクトを含む機能オブジェクトを親機能オブジェクトと呼ぶ。
機能オブジェクトは、それが有効な時と無効な時とがある。機能オブジェクトが無効な時は、その機能オブジェクトはすべての動作を停止している。ある機能オブジェクトが有効であるか無効であるかは、その機能オブジェクトの親オブジェクトの状態によって決定される。
11

機能オブジェクトの規定◆

機能オブジェクトは以下の概念を用いて規定される。
 アトリビュート• 機能オブジェクトのそのときの状況を表すパラメータ
 オペレーション• 機能オブジェクトが実行する動作
 アラート• 機能オブジェクトが特別な事態の発生を外部に通知する機能 ビヘイビア• 機能オブジェクトの動作の規則
 診断ルール• 機能オブジェクトが正常に動作しているかどうかを外部から診断するためのルール

12

アトリビュート（１）◆◆◆アトリビュートは、機能オブジェクトのその時の状況を表すパラメー
タであり、ある定められた集合内の値を取る。
アトリビュートには、機器のモードを表すような離散的なものと温度を表すような連続的なものとがある。また、アトリビュートには単純な型（Enumerationや整数）を持つものと複合的な型（配列やレコー
ドなど）を持つものがある。
アトリビュートにはオペレーションの起動によって機能オブジェクトの外部（他の機能オブジェクトあるいは衛星外部）より値を設定できるものとそうでないものとがある。

13

アトリビュート（２）◆◆◆アトリビュートの値は、機能オブジェクトが有効で、かつ、機能オブジェクトが一つあるいは複数の特定の状態にあるときのみ有効になる。アトリビュートが無効な状態においては、外部から値を設定することはできない。アトリビュートが無効な状態でアトリビュートの値を読み出してもその値に意味はない。
アトリビュートは、それが無効から有効になったときに特定の値を持つことがある。この値をアトリビュートの初期値と呼ぶ。
連続値を取るアトリビュートの場合は、そのアトリビュートの値がその値を超えたら機能オブジェクト危険になるというリミット値（上限値と下限値）を指定することができる。また、そのようなアトリ
ビュートの場合、アトリビュートの値がその値を超えたら注意を喚起
すべきというリミット値（上限値と下限値）を指定することもできる。さらに、アトリビュートの値が意味を持つ上下限値も指定できる。

14

オペレーション
◆

◆
◆

◆

◆

オペレーションは、機能オブジェクトが実行する動作である。オペ
レーションには、一つあるいは複数のアトリビュートの値を設定するためのものも含まれる。
オペレーションは外部（他の機能オブジェクトあるいは衛星外部）からの信号を受信することによって起動される。
オペレーションの実行の結果として一つあるいは複数のアトリビュー
トの値が変化する。また、オペレーションの実行結果として状態が遷移する場合もあり、この場合は、現在の状態を表すアトリビュートの値が変化する。
オペレーションが正しく実行されたことは、そのオペレーションの実行の結果として値が変化すべきアトリビュートの値の変化によって検証される。
オペレーションは、機能オブジェクトが一つあるいは複数の特定の状態にあるときにのみ実行される。機能オブジェクトの状態があるオペ
レーションを実行できない状態にあるときにそのオペレーションを実行するための信号を受信しても無視される。
15

アラート
◆

◆

◆

◆

アラートは、その機能オブジェクト内部で発生した事象を外部（他の機能オブジェクトや衛星外部）に伝えるための機能である。アラート
は何らかの信号によって外部に伝えられる。
機能オブジェクトの内部の変化を外部（他の機能オブジェクトや衛星
外部）に伝えるための機能は、アトリビュートの値やその変化を伝えることによっても実現できるが、アラートは事象の発生を積極的に外部に伝えるために用いられる。
各々の事象は、一つあるいは複数のアトリビュートとその値の変化によって規定される。アトリビュート値の変化としては、ある絶対値への移行（例えば、アトリビュート値がOFFになる）と変化の量（例えば、アトリビュート値が一つ増える）のいずれかを指定する
アラートには、事象毎に関連するアトリビュートの値、および、その事象を説明するためのパラメータを付加して伝えて良い。

16

ビヘイビア（１）
◆
◆
◆

◆

◆
◆

機能オブジェクトのビヘイビア（振る舞い）は、状態の概念を用いて規定される。
機能オブジェクトのビヘイビアは、一つあるいは複数の状態遷移図（あるいは状態遷移表）によって表せられる。
状態の遷移は、オペレーションの実行あるいは機能オブジェクト内の事象の発生によって引き起こされる。状態遷移は、あらかじめ定められた方法でしか起こらない。
状態遷移図は、有効な時と無効な時とがある。状態遷移図によって、
1. 機能オブジェクトが有効な時に有効になるもの、
2. 機能オブジェクトが有効であり、かつ、機能オブジェクトが別の状態遷移図の特定の状態にあるときに有効になるものがある。
機能オブジェクトは、その時に有効なすべての状態遷移図において、その状態遷移図中の一つの状態にある。
状態遷移図が有効となったときに最初に取る状態を初期状態という。
各々の状態遷移図は、０あるいは一つの初期状態を持つ。
17

ビヘイビア（２）◆◆◆機能オブジェクトが現在どの状態にあるかは、一つの状態遷移図につき一つのアトリビュートの値によって示され、このようなアトリ
ビュートを状態アトリビュートと呼ぶ。状態アトリビュートは、その状態遷移図に含まれるすべての状態名をその値として取る。状態アト
リビュートは、それに関連する状態遷移図が有効な時のみ有効となる。
機能オブジェクトは、その時の状態によって有効なオペレーション（実行可能なオペレーション）と有効なアトリビュート（その値が正しい意味を持つアトリビュート）が変化する。すなわち、状態は、その時点で機能オブジェクトがどのような行動を起こし得るかを規定するための概念である。
各々の遷移毎にその遷移にかかる最大時間と最小時間を指定することができ、その遷移を引き起こすオペレーションを実行してから指定された最大時間を経過しても遷移が起きない場合や指定された最小時間を経過せずに遷移が起きた場合は、その機能オブジェクトは正しく動作していないと診断される。
18

診断ルール◆◆◆

診断ルールは、機能オブジェクトが正常に動作しているかどうかを外部から診断するときに使用されるルールである。
診断ルールは、その機能オブジェクト（サブ機能オブジェクトやサブサブ機能オブジェクトなども含む）が有する複数のアトリビュートの値に対する論理式として表され、その論理式の値が真であれば機能オ
ブジェクトは正常、偽であれば機能オブジェクトは以上であると診断される。
一つのアトリビュートの上限あるいは下限によって診断を行う場合
は、そのアトリビュートにリミット値を設定することによって診断が
なされる。

19

機能オブジェクト例（X̲A機能オブジェクト）◆◆

X̲A機能オブジェクト
 X̲A機能オブジェクトはX̲SubSystemという機能オブジェクトに含まれ、Ｘサブシステム内のX̲Aというコンポーネント全体の機能を記述するために用いられる。
 X̲A機能オブジェクトはX̲A1機能オブジェクトとX̲A2機能オブジェクトをサブ機能オブジェクトとして含み、それらはこのX̲A
コンポーネントで実行される処理に対応する。
X̲A1機能オブジェクトとX̲A2機能オブジェクトは、X̲A機能オブジェクトがRUN状態（後述）にあるときのみ有効である。
X_SubSystem
X_A
X_A1

X_A2

20

X̲A機能オブジェクトのビヘイビア（１）◆X̲A機能オブジェクトはX̲A̲OnOffとX̲A̲RunStopという二つの状
態遷移図を有する。
 X̲A̲OnOffはOFFとONという二つの状態を有し、初期状態はOFFである。
 X̲A̲RunStopはSTOPとRUNという二つの状態を有し、初期状態
はSTOPである。X̲A̲RunStopは、機能オブジェクトの状態がONの時のみ有効である。

OFF

STOP

X_A_PowerOn
X_A_PowerOff

X_A_Start
X_A_Stop,
ErrorDetect

ON

RUN

21

X̲A機能オブジェクトのビヘイビア（２）◆◆X̲A機能オブジェクトの現在の状態はX̲A̲OnOffとX̲A̲RunStopという二つの状態アトリビュートの値によって示される。
 状態アトリビュートX̲A̲OnOffは、OFFとONのいずれかをその値として持つ。
 状態アトリビュートX̲A̲RunStopは、STOPとRUNのいずれかをその値として持つ。状態アトリビュートX̲A̲RunStopは、機能オ
ブジェクトの状態がONの時のみ有効である。
状態遷移はオペレーションの実行あるいは事象の発生により引き起こされる。
 ErrorDetectは事象名であり、この事象の発生によりこの遷移が引き起こされる。
 他のトリガーはすべてオペレーション名であり、これらのオペ
レーションに実行によりこれらの遷移が引き起こされる。

22

X̲A機能オブジェクトのアトリビュート
◆

◆

◆
◆

X̲A機能オブジェクトは以下のアトリビュートを有する。
 X̲A̲OnOff
 X̲A̲RunStop
 X̲A̲ErrorStatus X̲A̲CheckMode
状態アトリビュート X̲A̲OnOffとX̲A̲RunStopの値は、この機能オブジェクトのその時の状態を表す。
外部からの設定 X̲A̲CheckModeのみが外部から値を設定できる。
有効無効
 X̲A̲OnOffはどの状態においても有効 X̲A̲RunStopXとA̲ErrorStatussとX̲A̲CheckModeはON状態のときのみ有効23

X̲A機能オブジェクトのオペレーション◆◆◆

X̲A機能オブジェクトは以下のオペレーションを有する。
 X̲A̲On
 X̲A̲Start X̲A̲Stop X̲A̲Off X̲A̲SetCheckMode
X̲A̲SetCheckModeは、アトリビュートX̲A̲CheckModeに値を設定するために使用される。
これらのオペレーションは、それぞれ機能オブジェクトの状態が以下のものであるときに実行される。
X̲A̲OnOFF
X̲A̲Start
ONかつSTOPX̲A̲Stop
ONかつRUN
X̲A̲Off
ON
X̲A̲SetCheckMode
ON
24

X̲A機能オブジェクトのアラート
◆
◆
◆

◆

X̲A機能オブジェクトは、ErrorDetectというアラートを発生する。
このアラートは、状態遷移図に現れるErrorDetectという事象の発生を外部に伝えるためものである。
事象ErrorDetectは、「アトリビュートX̲A̲ErrorStatusの値がNORMAL以外に変化すること」
として定義される。
アラートErrorDetectには、アトリビュートX̲A̲ErrorStatusの値が付加される。

25

第３章

衛星監視制御プロトコル (SMCP)（機能オブジェクトを外部から監視制御するためのメッセージのやりとりの方法を説明する）

26

衛星監視制御プロトコルの意義◆◆

今までの衛星開発では、コマンドとテレメトリのフォーマットおよびそれらのシーケンスは搭載機器毎にバラバラに制定されていた。
本プロトコルを制定する意義は、コマンドおよびテレメトリメッセー
ジの構成方法およびシーケンスをすべての衛星およびすべての搭載機器で統一することにより、以下のものの開発を効率的に行えるようにすることである。
１）搭載ソフトウェア
２）地上で試験や運用に使用されるソフトウェア
３）衛星の情報を格納するデータベース

27

衛星監視制御プロトコルの概要
◆

◆

◆

◆

本プロトコルは、衛星および衛星に搭載される機器（以下では、これらを総称して衛星と呼ぶことにする）を監視制御するためのコマンドおよびテレメトリの内容（以下ではメッセージと呼ぶ）の構成方法およびメッセージの伝送シーケンスを規定する。
本プロトコルは、衛星の機能が衛星の機能モデルに従って規定されていることを前提としており、機能オブジェクトを外部より通信回線を用いて監視制御するためのメッセージの構成方法およびメッセージの伝送シーケンスを規定している。
本プロトコルは、通信回線として衛星̶地上間で使用される典型的な無線回線（すなわち、帯域幅は狭く、間欠的にしか接続されないような回線）が使用されることを前提としている。
それ以外の特性を有する回線が用いられる場合、あるいは、特別なデータ処理上の要求がある場合にも本プロトコルを適用できるように
本プロトコルの変化形を今後制定する予定である。

28

メッセージの実現方法◆◆◆

本文書では、コマンドメッセージとテレメトリメッセージの概念的な構成を規定する。
これらのメッセージは、下位のプロトコルとしてメッセージベースのもの（例えば、Space Packet Protocol）を使用する場合は、パケットのユーザデータ領域にデータ単位として格納される。この場合は、各々のメッセージのフォーマットは、SIB2に登録される。
下位のプロトコルとしてメモリアクセス型のもの（例えば、Remote
Memory Access Protocol）が使用される場合は、メッセージで規定されているID類は、メモリのアドレスに対応づけられる。この場合も、個々のID値とメモリアドレスとの対応関係、および、それぞれのメモリアドレスに格納されるデータフォーマットの定義はSIB2に登録
される。

29

コマンドメッセージの概要◆

コマンドメッセージは以下の種類に分類される。
1. ACTIONコマンド• 機能オブジェクトのオペレーションを起動する
2. GETコマンド• VALUEテレメトリの発生を促す

30

コマンドメッセージのフォーマット
◆

ACTIONコマンド
1. FOID
2. Command Seq. Count (Opt)
3. Command Type ID
4. Operation ID
5. Parameter(s) (Opt)
FOID = 機能オブジェクトID◆

GETコマンド
1. FOID
2. Command Seq. Count (Opt)
3. Command Type ID
4. Attiribute/Format ID

Format IDは複数のアトリ
ビュートの組を指定するのに用いる31

テレメトリメッセージの概要◆

テレメトリメッセージは以下の種類に分類される。
1. VALUEテレメトリ•
機能オブジェクトのアトリビュートの値を読み出す• 以下の２種類がある（ただし、フォーマットは同一）•
機能オブジェクトが一定の頻度で送信するもの（周期VALUEテレメトリ）•
GETコマンドの応答として送信するもの（応答VALUEテ
レメトリ）
2. VALUE CHANGEテレメトリ• 機能オブジェクトのアトリビュートの値の変化を通知する
3. NOTIFICATIONテレメトリ• 機能オブジェクトのアラートの発生を通知する
4. ACKテレメトリ• 機能オブジェクトがコマンドメッセージを受信したことを通知する
32テレメトリメッセージのフォーマット◆VALUEテレメトリ
1. FOID
2. Telemetry Type ID
3. Attiribute/Format ID
4. Attiribute Value(s)◆NOTIFICATIONテレメトリ
1. FOID
2. Telemetry Type ID
3. Alert ID
4. Attribute Value(s)◆VALUE CHANGEテレメトリ
1. FOID
2. Telemetry Type ID
3. AttiributeID
4. Attiribute Value◆

ACKテレメトリ
1. FOID
2. Telemetry Type ID
3. Command Seq. Count (Opt)
4. Received Command
Messsage (Opt)

Format IDは複数のアトリ
ビュートの組を指定するのに用いる
33

コマンド対テレメトリ相互作用（総則）◆◆

機能オブジェクトがコマンドメッセージを受信した場合、機能オブジェクト毎およびコマンド種類毎ににより、以下に示すいずれかのパターンのテレメトリメッセージを発生するものとする。
ACKテレメトリ 機能オブジェクト毎に、コマンドメッセージを受信する毎にACK
テレメトリを発生するか否かを決める。発生する場合は、その機能オブジェクトが受信したすべてのコマンドメッセージに対してACKテレメトリを発生する。

34

コマンド対テレメトリ相互作用◆◆

ACTION 無応答• 機能オブジェクトは、コマンドを受けることによって特別なテレメトリを発生することはない。
• コマンド実行の検証は、そのACTIONコマンドに対応したオペ
レーションによって値が変化するところのアトリビュートを含む周期VALUEテレメトリによって行う。
 結果応答• 機能オブジェクトは、オペレーションの実行経緯や実行結果を
そのACTIONコマンドによって値が変化するアトリビュートの値の変化としてVALUE CHANGEテレメトリを用いて通知する。
GET 機能オブジェクトは、コマンドを受けることによって要求された
アトリビュートを含む応答VALUEテレメトリを発生する。
35

第４章

衛星情報ベース２ (SIB2)（衛星情報ベース２に格納される情報の内容について
説明する）

36

衛星情報ベース２の意義
◆
◆

◆

◆

衛星情報ベース２(SIB2)は、現行のSIB1を拡張したものである。
SIB1は、基本的に、コマンドおよびテレメトリのフォーマットを定義するものであるが、機能的な情報（コマンドのサクセスベリファイ情報やテレメトリのリミット値）もコマンドおよびテレメトリの各項目に付随させるような形で格納するようになっている。
SIB2では、機能的な情報は、機能オブジェクトの定義として格納する。これにより、機能的な情報は、機器の機能設計に近い形で格納される。
SIB2にデータを入力するためのツールとしては、SIB1と同様なExcel
ベースのものを構築中であるが、将来は機能設計支援ツールのようなものを開発し、そのツールがSIB2の内容を自動的に生成できるようにしたいと思っている。

37

衛星情報ベース２の概要
◆
◆
◆

◆

◆

SIB2は、機能定義部と情報定義部に分かれる。
機能定義部は、衛星の機能を機能オブジェクトの概念を使用して定義する。
情報定義部は、衛星監視制御プロトコルで規定されているメッセージのデータ形式（フォーマット）、あるいは、メッセージとメモリとの対応関係を定義する。
これらの情報は、様々な形式（例えば、表形式あるいは図形式）を用
いて入力あるいは編集され得るが、具体的な入力あるいは編集方式は別途規定する。取りあえずは、Excelベースのものを用意する。
これらの情報は、XML形式のファイルとして保存され、SIB2を作成するアプリケーションもSIB2を利用するアプリケーションもXMLファイ
ルをアクセスする。このファイルのフォーマットを規定するためのSchemaは、文書として発行する。

38

機能定義部の内容（機能オブジェクト定義１）
機能オブジェクト毎
１）名前
２）サブ機能オブジェクト
３）アトリビュート
４）オペレーション
５）アラート６）状態遷移図
７）診断ルール
８）このオブジェクトが有効となる親オブジェクトの状態◆

アトリビュート毎
１）名前
２）外部から値を設定可能か
３）データ型
４）その値が有効となる状態
５）初期値
６）注意を喚起するリミット値
７）危険を知らせるリミット値
８）値が意味を持つ上下限値◆39機能定義部の内容（機能オブジェクト定義２）
オペレーション毎
１）名前
２）それを実行できる状態名３）アトリビュート
４）（アトリビュート以外の）パラメータ
５）変化するアトリビュート
◆

アラート毎
１）名前
２）値を通知すべきアトリビュー
ト３）パラメータ◆

40機能定義部の内容（状態遷移定義）
状態遷移図毎
１）名前
２）状態
３）遷移
４）状態遷移図が有効となる条件
◆ 状態毎
１）名前
２）初期状態か否か◆

遷移毎
１）遷移を引き起こすトリガーの種類（オペレーション実行か事
象発生か）
２）トリガーの内容（オペレー
ション名、パラメータ名、パラ
メータ値、あるいは事象名）
３）遷移が出発する状態の名前
４）遷移が到達する状態の名前
５）遷移にかかる最大時間６）遷移にかかる最小時間◆41情報定義部の主要内容
フォーマット毎
１）名前
２）アトリビュート
３）GET可能であるか否か
４）周期的に通知されるか否か◆ アトリビュート毎
１）GET可能であるか否か
２）周期的に通知されるか否か
３）値が変化したときに通知されるか否か
４）エンコーディング規則
５）アトリビュート値のビット長◆

ACTIONコマンド毎
１）機能オブジェクト
２）オペレーション
３）アトリビュート
４）（アトリビュート以外の）パラメータ
５）対応したテレメトリメッセー
ジのパターン◆ GETコマンド毎
１）機能オブジェクト
２）アトリビュートあるいはフォーマット◆ NOTIFICATYION毎
１）アラート２）アトリビュート
３）パラメータ
◆

42

第５章

汎用衛星試験運用ソフトウェア(GSTOS)（機能モデルに従って開発された衛星を試験し運用するための汎用ソフトウェアについて説明する）

43

汎用衛星試験運用ソフトウェアの意義
◆
◆

◆
◆
◆

衛星の試験および運用で必要となる機能毎にソフトウェアを開発する。
機能毎に開発されたソフトウェアの組み合わせ方をフェーズ毎および装置毎に変えることによって、様々なフェーズ（単体試験、総合試
験、飛行運用、自律運用など）および様々な装置（衛星管制装置、QL
装置など）で必要となる機能を実現できる。
また、SIB2の内容を置き換えることによって、様々な衛星に適用できる。
このようにすれば、複数の衛星、複数のフェーズ、複数の装置で共通に利用できる汎用の衛星試験運用ソフトウェアが開発できる。
データ伝送および蓄積機能については、既に機能毎の開発がなされているので、SDTP、データ分配装置、データ蓄積装置などは現在のものをそのまま使用する。また、送受信機なども基本的には（新たな伝送速度などの要求がない限り）現在のものが使用可能である。

44

ソフトウェアの基本体系

SIBアクセスツール？
SIB

応用ソフトウェア群

機能定義

機能定義
アクセスツール

監視制御
ソフトウェア群

情報定義

情報定義
アクセスツール

データ変換
ソフトウェア群

SIB作成ツール

SIB整合性確認ツール

45

単体試験システム（例）
搭載機器
単体試験装置
コマンド発行
ソフトウェア
SIB

テレメトリ監視ソフトウェア
データ変換
ソフトウェア群
搭載プロトコル(SpaceWire)46

衛星試験システム（例）
衛星試験装置衛星

コマンド発行
ソフトウェア
テレメトリ監視ソフトウェア

SIB

QL装置

データ変換
ソフトウェア群

テレメトリ監視ソフトウェア

ＳＤＴＰ

送受信機

データ変換
ソフトウェア群
ＳＤＴＰ
47

衛星運用システム（例）衛星管制装置
コマンド検証装置
コマンド計画検証
ソフトウェア

衛星診断
ソフトウェア
コマンド発行
ソフトウェア
テレメトリ監視ソフトウェア

SIB

衛星
（飛行中）

QL装置

データ変換
ソフトウェア群

テレメトリ監視ソフトウェア

ＳＤＴＰ

送受信機

データ変換
ソフトウェア群
ＳＤＴＰ
48

衛星搭載自動運用システム（例）搭載データ処理系

搭載機器

自律運用
ソフトウェア
コマンド発行
ソフトウェア
SIB
テレメトリ監視ソフトウェア
データ変換
ソフトウェア群
搭載プロトコル(SpaceWire)49