開発及び運用の効率化に向けた

(1)

平成 30年度（2018 年度）学位論文（修士）

開発及び運用の効率化に向けた

自己適応型衛星アーキテクチャに関する研究

Study on Self-adaptive Satellite Architecture for Efficient Development and Operation

首都大学東京大学院

システムデザイン研究科システムデザイン専攻航空宇宙システム工学域博士前期課程

学修番号氏名

17891503 淺野弘久指導教員佐原宏典教授

平成 31年（2019年）1月25 日

(2)

(3)

摘要

人工衛星は多種多様な要求を満たすことを理由に，大型化かつ多機能化が進み，現代まで発展を遂げてきた．そのような流れの中で2000年代，大学を中心に重量50kg程度の超小型衛星が提案され，この概念が急速に広まった．一般に人工衛星は，過酷な環境下で運用されるため，宇宙環境に対する耐性や信頼性が求められる．しかし，万全な対策を行っていながらも実際に軌道上の衛星は異常や故障が発生しているのが実状であり，ミッション成功率の向上が求められている．これらの背景には厳しいリソース制約と同時に，現在の超小型衛星の多くが集中システムアーキテクチャを採用していることも影響している．集中システムは，1つの強い権限を持ったメインサブシステムの下に他のサブシステムが繋がるため，ソフトウェアの開発を分散することが難しく，システム統合段階で不具合混入の発見が難しい．そのため，システム統合段階において，システム検証の工数が増加し，それに伴い費用も増大してしまう．そこで，システム統合段階においてシステム検証の容易な新しいアーキテクチャへの転換が求められている．

我々首都大学東京宇宙システム研究室では課題解決のためのアーキテクチャとして「共有系を含む分散型アーキテクチャ「（DACSS）」を提案している．本アーキテクチャは全てのサブシステムのデータを共有するための共有系を有し，共有系の枠組みを定めることでインターフェース調整が容易となる．そのため，システム統合段階においてシステム検証の工数が少なく済み，システム検証の費用も抑えられると考えられてきた．しかしこれまでの研究では，開発効率化につながる標準化は議論されてきたものの，運用を含めた議論はされてこなかった．本研究では自己適応の技術を応用したアーキテクチャを「自己適応型衛星アーキテクチャ」として提案し，これらの課題に取り組んだ．

第 1 章では，これまでの超小型衛星が開発されてきた背景を述べ，それに関する実態と課題を明らかにし，本研究の目的を述べた．

第2章では，自己適応システムと従来型の衛星アーキテクチャの概略を述べた上で，人工衛星における自己適応方針を1．軌道上パラメータ変更，2．軌道上コンポーネント変更，3．軌道上状態遷移テーブル変更，

という3つの方針を掲げた．また，自己適応方針をもとに従来設計を取り入れつつ，自己適応型衛星アーキテクチャの設計を行った．また同様に，本アーキテクチャに新たに加わる自己適応サブシステムの設計も行った．また，開発効率化を想定し，モジュール性を意識したソフトウェア構造も示した．その上で，自己適応手法を考案し示した．

第3章では，第2章で示した3つの方針とそれに対応した自己適応手法の成立性を図るため，コンポーネント変更機能，状態テーブル変更機能の3種類の適応機能においてそれぞれシミュレーションを行った．

パラメータ変更機能におけるシミュレーションにおいて，バッテリー要求値を動的に変更させることによってパラメータ変更機能が成立することを示すことができた．コンポーネント変更機能におけるシミュレーションにおいて，しきい値判定で適応動作を行うことで，コンポーネント変更機能が成立することを示すことができた．状態テーブル変更シミュレーションにおいて，緊急回避の状態テーブル変更と，アドバンスト用のミッションを行う状態テーブル変更，どちらのテーブル変更機能も成立することを示すことができた．

第4章では，従来アーキテクチャと提案したアーキテクチャのシステム規模を算出しその比較を行った．

算出されたシステム規模から作業工数の見積もりを行い，その結果を考察した．開発の効率化に向けた考察では，モジュラー度の高いアーキテクチャを実装するために，従来のシステムモデルに共有系を加えたモデルや自己適応型衛星アーキテクチャに共有系を加えたアーキテクチャのシステムモデルが適しているとし，

設計の再利用を行うことで開発効率の向上に寄与するとした．運用の効率化に向けた考察では，予めパラメータ変更並びに，コンポーネント変更，テーブル変更を実装しておくことで，運用効率の向上に寄与することに加え，ミッション成功率の向上にも寄与するとした．

第5章では，これまでの章を総括し，自己適応型衛星アーキテクチャが開発及び運用の効率化に寄与するという結論と本研究が示す今後の展望を述べた．

(4)

i

図目次

図 1.1 人類月面上陸¹⁾ ...1

図 1.2 日本初の人工衛星おおすみ」²⁾ ...1

図 1.3 衛星コンステレーションの³⁾ ...1

図 1.4 人工流星プロジェクト⁴⁾ ...1

図 1.5 UNISEC生まれの超小型衛星⁵⁾ ...2

図 1.6 超小型衛星の需要予測⁶⁾ ...2

図 1.7 超小型衛星のミッション成功数と失敗数⁷⁾ ...2

図 1.8 超小型衛星の軌道上生存日数⁷⁾ ...2

図 1.9 不具合発生日⁸⁾ ...3

図 1.10 不具合の混入理由⁸⁾ ...3

図 1.11 故障時におけるミッション影響度⁸⁾ ...3

図 1.12 対処後のミッション影響度⁸⁾ ...3

図 1.13 新アーキテクチャの提案¹⁰⁾ ...4

図 2.1 Rainbow アーキテクチャ¹⁴⁾ ...7

図 2.2 中央集中型アーキテクチャの例 PROCYON」¹⁵⁾...8

図 2.3 分散型アーキテクチャの例 NEXUS」¹⁶⁾ ...9

図 2.4 共有系を含む分散型アーキテクチャDACSSの概念図 ... 10

図 2.5 自己適応アーキテクチャの概念図 ... 11

図 2.6 状態決定サブシステムの機能設計 ... 12

図 2.7 状態遷移テーブル ... 13

図 2.8 自己適応サブシステムの基本的構成 ... 14

図 2.9 ソフトウェア機能の構造化¹⁷⁾ ... 15

図 2.10 ソフトウェア変更の階層的構造¹⁸⁾ ... 15

図 2.11 自己適応の実行コマンド ... 16

図 3.1 基本的な遷移表におけるバッテリー値の推移 ... 21

図 3.2 パラメータ変更した遷移表におけるバッテリー値の推移 ... 21

図 3.3 基本的な遷移表におけるMMへのデータ転送量の推移 ... 22

図 3.4 パラメータ変更した遷移表におけるMMへのデータ転送量の推移 ... 22

図 3.5 基本的な遷移表におけるダウンリンクデータ量の推移 ... 23

図 3.6 パラメータ変更した遷移表におけるダウンリンクデータ量の推移 ... 23

図 3.7 基本的な遷移表における状態遷移の推移 ... 24

図 3.8 パラメータ変更した遷移表における状態遷移の推移 ... 24

図 3.9 パラメータ変更した遷移表における自己適応回数の推移 ... 25

図 3.10 パラメータ変更した遷移表におけるバッテリー要求値とミッション要求値の推移 ... 25

図 3.11 コンポーネント変更を施さなかった場合のバッテリー値の推移 ... 29

図 3.12 コンポーネント変更を実施した場合のバッテリー値の推移 ... 29

図 3.13 コンポーネント変更を施さなかった場合のMMへのデータ転送量の推移 ... 30

図 3.14 コンポーネント変更を実施した場合のMMへのデータ転送量の推移 ... 30

図 3.15 コンポーネント変更を施さなかった場合のダウンリンクデータ量の推移 ... 31

図 3.16 コンポーネント変更を実施した場合のダウンリンクデータ量の推移 ... 31

図 3.17 コンポーネント変更を施さなかった場合の状態遷移の推移 ... 32

(7)

iv

図 3.18 コンポーネント変更を実施した場合の状態遷移の推移 ... 32

図 3.19 コンポーネント変更を実施した場合のNon-SAFE Counterの推移 ... 33

図 3.20 コンポーネント変更を実施した場合のコンポーネント切り替えの様子 ... 33

図 3.21 コンポーネント変更を実施した場合の自己適応回数の推移 ... 34

図 3.22 コンポーネント変更を実施した場合のバッテリー要求値とミッション要求値の推移 ... 34

図 3.23 緊急回避用の状態テーブルSET2 ... 37

図 3.24 追加ミッション用の状態テーブルSET3 ... 38

図 3.25 SET2へのテーブル変更におけるバッテリー値の推移 ... 39

図 3.26 SET2へのテーブル変更におけるMMへのデータ転送量推移 ... 39

図 3.27 SET2へのテーブル変更におけるダウンリンク量の推移 ... 40

図 3.28 SET2へのテーブル変更における状態変更の様子 ... 40

図 3.29 SET2へのテーブル変更における適応動作回数の推移 ... 41

図 3.30 SET3へのテーブル変更におけるバッテリー値の推移 ... 42

図 3.31 SET3へのテーブル変更におけるMMへのデータ転送量推移 ... 42

図 3.32 SET3へのテーブル変更におけるダウンリンク量の推移 ... 43

図 3.33 SET3へのテーブル変更における状態変更の様子 ... 43

図 3.34 SET3へのテーブル変更における適応動作回数の推移 ... 44

図 4.1 従来の衛星アーキテクチャのシステムモデル ... 48

図 4.2 自己適応型衛星アーキテクチャのシステムモデル ... 49

図 4.3 従来のシステムモデルに共有系を加えたモデル ... 49

図 4.4 自己適応型衛星アーキテクチャに共有系を加えたアーキテクチャのシステムモデル ... 50

図 4.5 工数見積もり結果を人数と月数で表した図 ... 56

図 4.6 サクセスレベルと複雑度の関係 ... 63

図 4.7 製品アーキテクチャ特性による分類²⁵⁾ ... 64

(8)

v

表目次

表 1.1 ミッションの影響度定義⁸^） ...3

表 2.1 各サブシステムとそのID ... 16

表 2.2 DMにおける各状態のIDの例 ... 16

表 3.1 ORBISの諸元 ... 18

表 3.2 シミュレーション時間条件... 18

表 3.3 日照時における電源入力 ... 19

表 3.4 各種状態における消費電力... 19

表 3.5 1秒間にやり取りするデータ量 ... 19

表 3.6 基本的な遷移表 ... 20

表 3.7 パラメータ変更を行う遷移表 ... 20

表 3.8 パラメータ変更シミュレーションにおける ... 26

表 3.9 パラメータ変更シミュレーションにおける ... 26

表 3.10 コンポーネント変更シミュレーション ... 35

表 3.11 コンポーネント変更シミュレーション ... 35

表 3.12 SET2における各状態の消費電力 ... 37

表 3.13 SET2へのテーブル変更シミュレーション ... 41

表 4.1 従来の衛星アーキテクチャのシステムモデルのシステム規模見積もり結果 ... 51

表 4.2 自己適応型衛星アーキテクチャのシステムモデルのシステム規模見積もり結果 ... 51

表 4.3 共有系を用いたアーキテクチャのシステムモデルシステム規模見積もり結果 ... 52

表 4.4 自己適応型衛星アーキテクチャに共有系を加えたアーキテクチャの ... 52

表 4.5 規模要因とプロジェクト特性の対応関係²²^） ... 55

表 4.6 コスト要因とプロジェクト特性の対応関係²²^） ... 55

表 4.7 COCOMMOⅡによる工数見積り結果 ... 56

表 4.8 従来の衛星アーキテクチャのサブシステム複雑度結果 ... 60

表 4.9 従来の衛星アーキテクチャのシステム複雑度結果 ... 60

表 4.10 自己適応型衛星アーキテクチャのサブシステム複雑度結果 ... 60

表 4.11 自己適応型衛星アーキテクチャのシステム複雑度結果 ... 60

表 4.12 共有系を用いたアーキテクチャのサブシステム複雑度結果 ... 61

表 4.13 共有系を用いたアーキテクチャのシステム複雑度結果 ... 61

表 4.14 自己適応型モデルに共有系を加えたアーキテクチャのサブシステム複雑度結果 ... 61

表 4.15 自己適応型モデルに共有系を加えたアーキテクチャのシステム複雑度結果 ... 61

表 4.16 サクセスレベルの定義 ... 63

表 4.17 設計を再利用した場合を考慮した結果 ... 65

表 4.18 自動走行システムにおける段階の例 ... 66

表 4.19 自動走行システムにおける段階を利用した ... 66

(9)

vi

(10)

vii

(11)

1

第 1 章序論

1. 1 背景

1. 1. 1 宇宙開発の歴史と超小型衛星の出現

アポロ 11 号によりニール・アームストロングらが人類初の月面着陸（図 1.1）を果たしてから，本年で 50 年を迎える．人類は宇宙に向かうたびに失敗と成功を何度も繰り返し，苦渋と歓喜を手にしてきた．そして世界の宇宙開発は新たな局面を迎え，現在では民間ベンチャーによる月旅行への気運が高まるまでになってきている．日本においても例外ではない．1970年に日本初の人工衛星おおすみ」（図 1.2）の打上げからおよそ49年もの歳月が過ぎ，民間ベンチャーによる宇宙ビジネスが展開されるまでに成長・発展してきている．

図 1.1 人類月面上陸¹⁾ 図 1.2 日本初の人工衛星おおすみ」²⁾

米ソ 2 国間の互いの技術力顕示に始まった宇宙開発競争は，冷戦終結を境に研究開発から商用利用へと大きく舵を切った．商用利用として開発された衛星の代表に通信「・放送衛星や気象衛星が挙げられる．これらの衛星は静止軌道に配備され，特定の地域を継続的に通信「・観測を行ってきた．また地球規模の環境問題や国際協力の動きから，世界規模で全面的に地球を観測する需要も増えてきた．そこで，衛星コンステレーション「（図 1.3）という新たな概念が出現した．衛星コンステレーションは，複数の軌道面に複数の衛星を配備することで地球を全面的にかつ継続的に監視，観測，通信を行うものである．宇宙利用の敷居も下がりつつある昨今の宇宙利用は，もはや宇宙開発は国の研究開発にとどまらず民間の衛星ビジネスまで波及するようになった．衛星コンステレーションを利用した高速インターネット通信網，エンターテインメントの立場から人工的に流れ星を発生させるプロジェクト（図 1.4），また学術研究の分野からは大学による深宇宙探査ができるまでに広がっている．これらの発展に大きなはずみを与えたのが「超小型衛星”の出現である．

図 1.3 衛星コンステレーションの³⁾ 図 1.4 人工流星プロジェクト⁴⁾

(12)

2

1. 1. 2 超小型衛星の出現と未来

人工衛星はコストが膨大であることや多くの要求を満たすことを理由に，大型化かつ多機能化が進み，現代まで発展を遂げてきた．そのような潮流の中で，2000 年代大学を中心に超小型衛星が提案された．超小型衛星の定義は資料によって揺らぐこともあるが，概ね100kg以下の衛星を超小型衛星と定義している．

超小型衛星の概念は急速に広まり，衛星開発は国家機関で行うものであるという固定観念を変えた．そして近年，超小型衛星の開発には大学や民間企業など多くの団体が参入しており「（図 1.5），今後もその需要増加が期待されている「（図 1.6）．開発黎明期では，技術実証や工学教育が主な用途とされてきたものの，近年ではコンステレーションや深宇宙探査など，より高度化したミッションも出現してきている．

図 1.5 UNISEC生まれの超小型衛星⁵⁾ 図 1.6 超小型衛星の需要予測⁶⁾

1. 1. 3 超小型衛星の課題

一般に人工衛星は，過酷な環境下で運用されるため，宇宙環境に対する耐性や信頼性が求められる．しかし，いくら万全な対策を行っていても実際に軌道上の衛星は異常や故障が発生しているのが実情である．そのため，大学で行われている超小型衛星の開発では失敗している団体も少なくない（図 1.7）．また，特に 50kg級となると，生存日数として運用中の目標まで到達している団体（図 1.8）は少なくなっており，ミッション成功率の向上が求められる.

図 1.7 超小型衛星のミッション成功数と失敗数⁷⁾ 図 1.8 超小型衛星の軌道上生存日数⁷⁾

(13)

3

また文献⁸⁾による大学衛星における不具合発生状況を調査した結果によると，初期故障が多いことが分かっている（図 1.9）．特に25日以内に全体の半数の不具合が発生し，グラフの形状がバスタブ曲線の初期故障と偶発故障の区間に非常に酷似した形になっている．大学衛星の不具合発生要因として，軌道上不具合が45%とほぼ半数を占めており主な原因である（図 1.10）．

図 1.9 不具合発生日⁸⁾ 図 1.10 不具合の混入理由⁸⁾

以下に示した図 1.11と図 1.12はミッションの影響度をもとに大学衛星の故障時とその対処後における故障が及ぼしたミッションへの影響度の結果である．また，ミッション影響度のレベルの定義を表 1.1に示す．Level 1が41%と大多数を占めているおり，また不具合への対処後にはLevel 0とLevel 1の割合が約72%

になっていることが分かる．すなわち，故障を早期発見することでその後ミッションを継続させる可能性が大きくなることが分かる．ミッション成功率が，さほど高くはない大学衛星にとってミッションを遂行することは，非常に意義のあることである．「

図 1.11 故障時におけるミッション影響度⁸⁾ 図 1.12 対処後のミッション影響度⁸⁾

表 1.1 ミッションの影響度定義⁸⁾

Level ミッション影響内容

Level 0 ミッション遂行影響なし

Level 1 ミッション遂行能力低下

Level 2 ミッション遂行能力一部損失

Level 3 ミッション遂行能力損失

Level 4 全機能損失

(14)

4

不具合混入の背景には，様々な理由が考えられるが，一つに大学衛星がもつ環境が影響していると考えられる．一般に大学衛星のメンバーは，その大学の学生で構成されている．そのため，技術者自体それほど経験豊富であるわけではなく，また開発メンバーも多くて十数人と限られる．また，実際に衛星が打ち上がったあとも，学生が運用するという条件を考慮し，地上局の設計も行わなければならない．そのため，超小型衛星開発は，その規模にあったプロジェクト・マネジメントを実施していかなければならない．

超小型衛星の利点は短期開発「・低価格化であるが，実際にはそこまで低価格化に貢献していない．図 1.13 は衛星の顕在化する需要と開発費用を質量比で割った値を図式化したものである．これらの背景として当研究室が考えている原因は，現在の超小型衛星の多くが集中システムアーキテクチャを採用していることだとしている．集中システムは，1つの強い権限を持ったメインサブシステムの下に他のサブシステムが繋がるため，ソフトウェアの開発を分散することが難しい．そのため開発費用がかさみ，超小型衛星といえどもコストパフォーマンスにすぐれない一面がある．こういった背景を踏まえ，短期開発が可能かつ低コストを実現するような新しいアーキテクチャへの転換が求められている．

1. 1. 4 従来型衛星アーキテクチャの課題

現在，首都大学東京宇宙システム研究室では衛星アーキテクチャの研究を進めている．いままで研究を進めてきた例として共有系を含む分散型アーキテクチャ（DACSS：Distributed Architecture with a common

Signboard Subsystem）」が挙げられる．DACSSは，全てのサブシステムのデータを共有するためのサブシス

テム共有系を有することが一つの特徴である．各サブシステムは共有系を介してデータのやり取りを行い，

自律して動作する仕様となっている．このシステムにより各サブシステムは共有系のみとなり，共有系の枠組みを定めることでインターフェース調整が容易となる他，各サブシステムの機能が明確化され分散して開発することが可能となっている．またシステム検証段階においても，その検証数が少なくなり費用も抑えられると考えられてきた．このアーキテクチャは堀田の文献¹⁰⁾でその利点が示されている．

しかし，これまでの研究では開発効率化につながる標準化は議論されてきたものの，運用の効率化を含めた議論はされてこなかった．そこで本研究ではソフトウェア工学の分野で議論されている自己適応システムの技術を応用する．自己適応システムとは，実行時に起こる変化を検知し，要求を満たし続けるようソフトウェアの構造「・振る舞いを自身で変更するシステムである．このシステムを応用することで，初期故障に対する自律的な対処が可能になると考えている．本研究では自己適応の技術を利用した「自己適応型衛星アーキテクチャ」を提案し，以上の課題に取り組む．

図 1.13 新アーキテクチャの提案¹⁰⁾

(15)

5

1. 2 目的

1. 1 節の背景を踏まえ，本研究では衛星開発とその運用の効率化を目標に以下に3つの目的を定める．

１．自己適応型衛星アーキテクチャの設計と提案を行う．

２．自己適応型衛星アーキテクチャの機能が成立することを示す．

３．自己適応型衛星アーキテクチャの開発効率化と運用効率化に向けた議論を行う．

(16)

6

第 2 章自己適応型衛星アーキテクチャの設計と提案

本章では自己適応や従来の衛星アーキテクチャ設計についての概略や説明を行い，自己適応型衛星アーキテクチャの設計と提案を行っていく．

2. 1 自己適応システム

本節では，自己適応アーキテクチャに用いる自己適応システムの概略，また自己適応アーキテクチャのフレームワークの1つであるRainbowシステムについての説明を行う．

2. 1. 1 自己適応システム

自己適応システムとは，実行時に起こる変化を検知し，要求を満たし続けるようソフトウェアの構造「・振る舞いを自身で変更するシステムである ¹¹⁾．自己適応システムの定義は以下の要素を有していることとなる．

① 環境やソフトウェア自身を監視する．

② 現在のソフトウェア自身を評価する．

③ 機能，性能，ゴールなどの要求を満たすために，ソフトウェア自身の構造・振る舞いを変更する．

また，ZaveとJacksonが定義した要求と仕様に関するモデル¹²⁾によると，

𝑆，𝐷 | = 𝑅 （ 2.1 ）

と定義されている．ここで，Sはソフトウェアの仕様，Dはシステムの実行環境に関するドメインプロパティ，Rはシステムが充足すべき要求を指し，上式の意味は，SはDの環境下でRを充足することを意味する.

11)

ソフトウェアの仕様Sは開発環境D下で動作した場合，要求Rを従属させるように決定させなければならない．しかし，実行環境が変化し当初の仕様では要求を従属させることができなくなる場合がある．その場合，新たに更新されたD’において要求Rを従属させることのできる新たなソフトウェア仕様S’を決定さ せ，ソフトウェア仕様S’に基づきソフトウェアの修正を行う．自己適応とは，環境の変化に伴い，要求を満たすためにソフトウェアを自動修正するものといえる．

(17)

7

2. 1. 2 Rainbowシステム¹⁴⁾

自己適応システムの一つに Rainbow システムがある．Rainbow システムのアーキテクチャの概要図を図 2.1 に示す．Rainbow システムはユーザニーズ，リソース，障害状況の変化に対応するための動的再構成のアーキテクチャとして提案されているものである．このシステムは自己適応の適用と自己適応の処理を追加する際のコスト削減を課題としており，様々なソフトウェアに応じて対応可能なシステムとして定義している．

Rainbow システムは，モデルマネージャ層，制約評価層，適応エンジン層，適応実行層の4つのレイヤで

構成されており，それぞれ特有の役割を持つ．モデルマネージャ層は，対象システムを監視・解析を行い，

モデルを評価する層である．また，制約評価層は特定のルールを定めそれを評価する層である．適応エンジン層は，得られたデータをもとに戦略や計画を立てる層である．そして適応実行層は対象システムが，適応実行処理が可能な際に適応エンジン層で得られた戦略「・計画を実行する層である．以下各層の特徴を簡易的に示した．

① モデルマネージャ層

対象システムを監視・解析を行い，モデルを評価する層

② 制約評価層

特定のルールを定め，それを評価する層

③ 適応エンジン層

得られたデータをもとに戦略や計画を立てる層

④ 適応実行層

適応実行処理が可能な際に適応エンジン層で得られた戦略・計画を実行する層

図 2.1 Rainbow アーキテクチャ¹⁴⁾

本論では，この Rainbow システムのフレームワークを用いることで自己適応型衛星アーキテクチャの設計を行っていく．

(18)

8

2. 2 従来の衛星アーキテクチャ

本節では，従来に多く見られた中央集権型のアーキテクチャ，分散型アーキテクチャ，そして本研究室で開発を進めている共有系を用いた分散型アーキテクチャの特徴説明を行っていく．

2. 2. 1 中央集中型アーキテクチャ

現在までに打ち上げられた超小型衛星のアーキテクチャの中で最もよくみられるアーキテクチャが中央集中型のアーキテクチャである．以下の図 2.2は，東京大学と宇宙航空研究開発機構「（JAXA「：Japan Aerospace

eXploration Agency）が共同開発した超小型衛星「 PROCYON」のシステム構成図である．本アーキテクチャ

では各センサやアクチュエータが直接OBC（On-Board Computer）とデータのやりとりをしている．そのため，システムの構成が非常に簡素となり，データフローの理解がしやすい．また，搭載コンポーネントを最小限の構成で留めることができ，計算量が少なく小規模の衛星には適したアーキテクチャといえる．しかし，

計算量が大規模になる衛星だと，並列処理ができないためにOBCに高負荷の処理が加わることになる．そのため，この中央集中型アーキテクチャの構成は，計算量の少ない衛星に限られる．また，周りに搭載されている機器はすべてOBCと接続されているため，組み合わせ的に試験工数が増加し，コンポーネントが増えるごとに大きな工数がかかってしまうという懸念もある．

図 2.2 中央集中型アーキテクチャの例 PROCYON」¹⁵⁾

(19)

9

2. 2. 2 分散型アーキテクチャ

分散型アーキテクチャは，中央集権型アーキテクチャの機能を分割し独立させた構成をとっている．図 2.3 は日本大学と日本アマチュア衛星通信協会が開発した技術実証衛星 NEXUS」のシステム構成である．

分散型アーキテクチャではサブシステム毎にOBCがあり，中央集中型のものとは異なり，それぞれ機能単位で開発を行うことが可能である．また，機能単位での試験により，統合試験工数は機能単位の組み合わせで済む．また分散型アーキテクチャの利点として，各機能で再利用可能であること，また分散開発を行うことで開発時間の短縮に繋がるという点が挙げられる．しかし，中央集中型と比較すると同様のシステムを構築した際にコンポーネント数が増加してしまうことや，システムの構築が複雑になることが欠点として挙げられる．つまり，計算量が少ないシステムには適合せず，計算量の多いシステムや多少規模の大きい衛星には適しているアーキテクチャといえる．

図 2.3 分散型アーキテクチャの例 NEXUS」¹⁶⁾

(20)

10

2. 2. 3 共有メモリを用いた分散型アーキテクチャ

従来型アーキテクチャに基づいて本研究室では，共有系を用いた分散型アーキテクチャの提案と開発を進めている．図 2.4 に当研究室で開発している共有系を含む分散型アーキテクチャ（DACSS：Distributed Architecture with a Common Signboard Subsystem）の概念図を示す．本アーキテクチャのコンセプトは，分散型のメリットである再利用性や分散開発のしやすさを従来の分散型アーキテクチャより高めることである．

本アーキテクチャには共有系という衛星内の全情報を統括するサブシステムがある．各サブシステムは，共有系へのアクセスを通じて他系の情報を得ることができる仕組みとなっている． OBCからのメッセージを受けて動作するのとは違い，各サブシステムはそれぞれのシステムが共有系へのアクセスを持って状態を取得し自律動作を行う．つまり，各サブシステムは，OBC の命令を待つ時間がなくなり，その時間は他の機能に回すことが可能となる．また，すべてのサブシステムはCAN Busに接続されるため，各サブシステムの物理的インターフェースはCAN Busに接続することで終わる．そのため，サブシステム毎の追加や削除が容易に済み，再設計時の労力が少なく済む．また，堀田の文献¹⁰⁾で議論されているように，DACSSは共有系の標準化を目指している．各サブシステムはその標準設計の枠組みに従うことによって，物理的インターフェースのみならずミドルウェア層での開発効率の向上にも期待されている．

図 2.4 共有系を含む分散型アーキテクチャDACSSの概念図

(21)

11

2. 3 自己適応型衛星アーキテクチャの設計

本節では，2. 1 節の自己適応システム， 2. 2 節の従来型アーキテクチャの特徴を踏まえ，自己適応型衛星アーキテクチャの設計と提案を行っていく．

2. 3. 1 人工衛星における自己適応方針

衛星運用において高いミッション要求に応えることや運用時の労力低減が求められるため，軌道上において自律性が高くなる衛星アーキテクチャ設計が望まれる．また，衛星開発時において開発労力を減らすことも同時に求められるため，衛星に簡易な方式で多様な機能を組み込めるように本アーキテクチャを構成したい．その目的に合致するよう人工衛星の自己適応方針として以下3つを掲げる．

① 軌道上パラメータの自律的変更

運用初期段階で，生じる姿勢制御パラメータやミッションパラメータ，遷移条件のパラメータ，その他バスシステムを構成するパラメータの自律的変更を図る機能である．

② 軌道上コンポーネントの自律的変更

軌道上において，不具合等を対象にソフトウェアコンポーネントの自律的変更を図る機能である．主に対象とする不具合は，ソフトウェアが解決できる範囲で設定される．状態遷移時の異常や機能実行時におけるリセットの対策やリアクションホイールのアンローディング調整などがこのコンポーネント変更にあたる．

③ 軌道上状態遷移テーブルの自律的変更

軌道上における，最悪状態への対処や付加機能の追加への対応を目的に遷移テーブルの変更を行う機能である．軌道上にて追加の状態遷移定義や既存遷移テーブルへの変更を行う．

2. 3. 2 自己適応型衛星アーキテクチャの基本構成

自己適応型衛星アーキテクチャの概念図を図 2.5に示す．本アーキテクチャの基本的構成は，状態を決定する状態決定系「（DM「：Decision Maker）の直下に各サブシステムが接続され，DMの命令により各サブシステムは各機能を動作させる．また，適応動作の提案を行うサブシステムとして自己適応サブシステム「（SA :

Self-Adaptive）をDMと接続させる．自己適応サブシステムは衛星の状態を管理し，状態に則したプランを

提示することが役割である．

図 2.5 自己適応アーキテクチャの概念図

(22)

12 以下にそれぞれのサブシステムの役割を記載する．

・状態決定系：DM（Decision Manager）

状態遷移表を持ち，各サブシステムの状態を一意に決定させる機能を有する．

・データ処理系：C&DH（Command & Data Handling）

衛星が取得したデータ処理を行う．また地上からのコマンド処理もこの系で行う．自己適応型衛星アーキテクチャでは，この機能を自己適応系に委ねた設計となっている．

・通信系：COMM （Communication）

衛星が取得したデータを地上局に送信を行う．また，地上局からのアップリンクを受付け，それをC&DH 系に送信する．

・ミッション系：MISN （Mission）

衛星ミッションを行う系で，ミッションにより得たデータをC&DH系に送信する．

・姿勢決定制御系：ADCS （Attribute Decision Control Subsystem）

センサを利用して姿勢を推定する機能と，推定された姿勢から目標の姿勢へ制御させる機能を持つ．場合によって姿勢決定系「（ADS）と姿勢制御系「（ACS）に分けられることもあるが，本アーキテクチャでは統合した系となっている．

・電源系：EPS （Electric Power Subsystem）

電源制御や電流値の測定や構体の温度測定を行う．

・自己適応系：SA （Self-Adaptation）

本アーキテクチャでは，C&DH系の役割も担い，衛星のデータを統括し，データの監視と解析，プランの変更と実行を行う．

2. 3. 3 自己適応型衛星アーキテクチャの状態決定サブシステム設計

本項では，状態決定サブシステムDMの機能設計について説明を行う．DMの機能設計を図 2.6に示す．

DMの機能は以下の4つである．

1．遷移状態の決定

2．SAへの衛星内データの転送

3．COMMへのダウンリンクデータの転送 4．自己適応コマンドの取得とその反映

図 2.6 状態決定サブシステムの機能設計

(23)

13

状態遷移テーブルは図 2.6の様に設計した．状態遷移テーブルは，基本的に衛星毎に異なる遷移テーブルを持つことになるが，今回はリアクションホイールによる姿勢制御を行う想定で設計を行った．基本的な構成は，初期状態としてWAKEUP からスタートし，各状態はSTANBY を通して状態を切り替える設計となっている．

図 2.7 状態遷移テーブル

以下に各状態の定義とその説明を行う．

0：WAKEUP

システムの起動状態を表す．この状態では，各種イニシャライズなど初期の機能を実行する．

1：STANDBY

システムの待機状態を表す．この状態では，各状態に遷移する準備等を行う．サブシステムの状態が整い次第，別の状態に遷移する．

2：MISSION

ミッションの開始「・実行「・終了，一連の状態を表す．この状態では，ミッション開始をし始め，各サブシステムからMISSIONデータやHKデータなどの情報を取得し，SAに転送を行う．

3：DOWNLINK

ダウンリンクの開始「・実行「・終了，一連の状態を表す．この状態では，ダウンリンクを開始し始め，SA から受けたダウンリンクデータをCOMMに転送し，地上局にデータを送信する．

4：SAFE

衛星のバッテリーが低下した際に，充電を行う状態である．この状態では，衛星を構成する消費電力が高いコンポーネントの電源を落とし，バッテリーが充電されるまで，各種機能を抑える状態となる．

5：UNLOADING

姿勢制御系のアクチュエータであるリアクションホイールの回転数が飽和した際に，アンローディングを行う状態である．

6：ADAPTIVE

衛星の適応動作を行う状態である．この状態では，SAで行われた提案プランに基づき，１パラメータ変更，２ソフトウェアコンポーネント変更，３テーブル変更のコマンドを実行し，DMや各サブシステムの適応動作を行う．

(24)

14

2. 3. 4 自己適応型衛星アーキテクチャの自己適応サブシステム設計

自己適応サブシステムSAの基本構成を図 2.8に示す．自己適応サブシステムでは，DMから転送された衛星データを貯蓄し，衛星データを元に異常等がないかどうかを検出する．また，異常等が見られた場合に，

提案プランとして新たな方策を提案し，適応実行によって DM にコマンドを送信する設計となっている．

自己適応サブシステムは，４つの機能で構成される．以下に４つの機能の説明を示す．

① モデルマネージャ（MM：Model Manager）

衛星データの取得やデータの整理「・監視を行う．加工された衛星データはMMが所有するメモリに保存される．

② 制約評価（CE：Constraint Evaluator）

衛星内での異常発見やパラメータ解析などを行う．異常発見をした場合は，その内容を適応エンジンに転送される．

③ 適応エンジン（AE：Adaptation Engine）

制約「・評価の機能から転送された情報を元に，適応動作として，1．パラメータ変更，2．コンポーネント変更，3．テーブル変更の提案プランを策定する．提案プランの策定内容は適応実行機能に転送される．

④ 適応実行（AX：Adaptation eXecutor）

適応エンジンによって策定された提案プランを取得し，DMの状態から，適応実行可能な場合に提案プランの実行を行う．

図 2.8 自己適応サブシステムの基本的構成

(25)

15

2. 3. 5 ソフトウェア機能構造

自己適応サブシステムSAで行われる適応動作を実行させるために，DMや各サブシステムに共通するソフトウェアの機能構造の仕組みについて概説する．図 2.9にソフトウェア機能構造化の模式図を示す．

DMや各サブシステムは，各状態を表現する遷移テーブルを有している．その遷移テーブルの中に構成されている機能を分割し，番号を割り振ったものをソフトウェアコンポーネントとして定義する．また，各ソフトウェアコンポーネントにおいて，その中で変更される変数などをパラメータとして定義する．

SAで行われる適応動作においてパラメータ変更はそのソフトウェアコンポーネントを構成しているパラメータを変更するということである．また同様に，ソフトウェアコンポーネント変更は，遷移テーブルを構成するソフトウェアコンポーネントを変更するということを意味する．また，遷移テーブル変更は遷移テーブルそのものを変更するということを意味する．

図 2.9 ソフトウェア機能の構造化¹⁷⁾

適応実行を行うにあたり，実施リスクを考慮する必要がある．そのソフトウェア規模ソフトウェア変更の階層的構造と実施リスクの図を図 2.10に示す．この図は，ソフトウェアの変更規模によって，どれほどの実施リスクを伴うかというものを図式化したものであり，それぞれの実施リスクはパラメータ変更は Lv0，コンポーネント変更はLv1，定義テーブル変更はLv2に当たり，Lvが上がるに連れて大きくなっていく．

また，軌道上においてメモリの部分書き換えやメモリの全書き換えを行うことも想定されるが，本論文で変更するレベルはLv2までとしている．

図 2.10 ソフトウェア変更の階層的構造¹⁸⁾

(26)

16

2. 3. 6 自己適応化手法

適応動作は，SAの適応実行の機能により行われる．適応実行機能は，DMがSTANDBY状態に入った際，

提案プランがあれば実行される設計としている．また，適応実行の際に DM に送信される自己適応コマンドのプロトコルを図 2.11の様に設計した．ADPTATION Numberは適応動作コマンドの番号を示している．

SUBSYSTEM Numberは表 2.1に示す各サブシステムのID割当を表している．またCHANGE Numberは適応実行を行う項目を表している．STATE IDは各サブシステムにおける，状態テーブルのIDを指している．

表 2.2にDMにおける状態IDの例を示す． STATEID IDと同様にCOMPONENT ID，PARAMETER IDを設計した．ここまでのフレームが適応動作の実行フレームであり，実行フレームを送信した後に適応動作に関

わる値VALUEを送信する仕組みとしている．

図 2.11 自己適応の実行コマンド

表 2.1 各サブシステムとそのID 表 2.2 DMにおける各状態のIDの例サブシステム名 ID