限定なし

JERG-2-100.

システム設計標準

平成 28 年 5 月 20 日制定

宇宙航空研究開発機構

免責条項
ここに含まれる情報は、一般的な情報提供のみを目的としています。JAXA は、かかる情報の正確性、有用性又は適時性を含め、明示又は黙示に何ら保証するものではありません。また、
JAXA は、かかる情報の利用に関連する損害について、何ら責任を負いません。
Disclaimer
The information contained herein is for general informational purposes only. JAXA makes nowarranty, express or implied, including as to the accuracy, usefulness or timeliness of any
information herein. JAXA will not be liable for any losses relating to the use of the information.

発行〒305-8505 茨城県つくば市千現 2-1-1
宇宙航空研究開発機構 安全・信頼性推進部
JAXA（Japan Aerospace Exploration Agency）

目次
1. 適用範囲............................................................................................................................. 1
2. 関連文書............................................................................................................................. 1
2.1 適用文書 ....................................................................................................................... 1
2.2 参考文書 ..................................................................................................................... 1
3. システム設計とは .............................................................................................................. 2
4. システム設計の入力 .......................................................................................................... 4
4.1 上位要求 ..................................................................................................................... 4
4.2 制約条件・前提条件 ................................................................................................... 5
4.3 信頼性要求 ................................................................................................................. 65．運用設計 ............................................................................................................................ 7
5.1 運用設計の流れ ............................................................................................................ 7
5.2 運用イメージ／コンセプト分析 ............................................................................... 7
5.2.1 運用イメージ分析（概念検討フェーズ） ........................................................... 7
5.2.2 運用コンセプト分析（概念設計フェーズ）........................................................ 8
5.3 運用要求分析 .............................................................................................................. 8
5.4 運用方式設計 ............................................................................................................ 8
6. システム設計（狭義） ..................................................................................................... 9
6.1 ミッション要求分析..................................................................................................... 9
6.2 必要な機能の洗い出し（機能要求） ......................................................................... 9
6.3 必要な性能の洗い出し（性能要求） ......................................................................... 9
6.4 システム構成 ............................................................................................................ 10
6.5 システム解析 ............................................................................................................ 10
6.6 サブシステム分解 .....................................................................................................11
6.7 インタフェース設計....................................................................................................11
6.7.1 外部インタフェース ...........................................................................................11
6.7.2 内部インタフェース ...........................................................................................11
7. システムのサイジング ................................................................................................... 12
7.1 サブシステムのサイジング ...................................................................................... 12
7.1.1 電源系サイジング .............................................................................................. 12
7.1.2 通信系サイジング .............................................................................................. 12
7.1.3 テレメトリ・コマンド系サイジング................................................................. 13
7.1.4 推進系サイジング .............................................................................................. 13
7.1.5 姿勢軌道制御系サイジング ............................................................................... 13
7.1.6 熱制御系サイジング .......................................................................................... 14
7.1.7 構体系サイジング ............................................................................................ 14
7.2 衛星の形状設計 ........................................................................................................ 15
7.3 システム要求への反映 ............................................................................................. 15
8. 検証・妥当性確認 ............................................................................................................ 16
8.1 検証 .......................................................................................................................... 16
8.2 妥当性確認 ............................................................................................................... 16
8.3 試験・解析・検査 .................................................................................................... 17
9. システム管理項目 .......................................................................................................... 18
9.1 コンフィギュレーション管理 .................................................................................. 18
9.2 インタフェース管理 ................................................................................................. 18
9.2.1 外部インタフェース .......................................................................................... 18
9.2.1.1 ロケットインタフェース .............................................................................. 18ii

JERG-2-100

9.2.1.2 地上システムインタフェース（衛星管制システム、追跡ネットワークシステム） ........................................................................................................................ 19
9.2.1.3 地上系インタフェース（ミッション運用系システム） ............................. 19
9.2.2 内部インタフェース .......................................................................................... 19
9.3 リソース配分、性能配分とその管理 ....................................................................... 20
9.3.1 配分.................................................................................................................... 20
9.3.2 管理.................................................................................................................... 20
9.3.2.1 質量管理...................................................................................................... 20
9.3.2.2 電力管理...................................................................................................... 20
9.3.2.3 推進薬管理 .................................................................................................. 20
9.3.2.4 信頼度管理 .................................................................................................. 20
9.3.2.5 指向管理...................................................................................................... 20
9.3.2.6 テレメトリ・コマンド管理 ........................................................................ 20
9.3.2.7 温度計測管理 .............................................................................................. 20
9.4 その他のインタフェース管理情報 ........................................................................... 20
9.5 リスク識別と管理 .................................................................................................... 21
9.6 技術の成熟度.............................................................................................................. 22
9.7 信頼性設計・安全性設計・安全管理 ....................................................................... 22
9.7.1 信頼性設計 ......................................................................................................... 22
9.7.2 安全設計 ............................................................................................................ 23
9.7.3 安全管理 ............................................................................................................ 24
9.8 コスト、スケジュール、体制その他 ....................................................................... 24
10. システム設計のアウトプット ...................................................................................... 25
10.1 各フェーズ毎に必要とされるアウトプット概要 ................................................... 25
付録－１ 参考になる図書など ........................................................................................... 26iii

JERG-2-100

1. 適用範囲
本設計標準で記述する「システム設計」は、ミッション要求段階の概念検討からシステ
ム要求書/仕様書作成段階までの設計を主な範囲とする。
但し、基本設計以降のフェーズ（段階）で活かす技術要素、運用設計にも触れている。
なお、本設計標準は、「システム設計」の指標を示すものであり、契約上の適用文書となるものではない。
実際のプロジェクトにおいては、対象となるシステムの規模、複雑さ等のプロジェクトの特質に応じて、本設計標準を指標とし、「システム設計」を具体化すること。また、キューブサット等の小型衛星では適用に際しテーラリングし参考用として使用すること。
2. 関連文書
2.1 適用文書
以下に示す文書は、本設計標準の上位文書であり、特に断りのない限り、記述の範囲で本文書の一部をなす。
(1) 宇宙機設計標準（JERG-2-000）

2.2

参考文書

(1) システムズエンジニアリングの基本的な考え方（BDB-06007B）

1

JERG-2-100

3. システム設計とは人工衛星をはじめ、宇宙機は一般的に大きく複雑で、少人数で開発・製造することができない。そこで、多人数で開発・製造するために、複数の要素に分割する。
このように、複数の要素から構成されている全体を「システム」と呼び、効率的に分割し全体として整合させ、定義することが「システム設計」である。そして、システムを効率的に開発するプロセスや管理をシステムズエンジニアリングと呼ぶ。
宇宙機のシステム設計の全体の流れを図 3-1 に示す。この図にシステム設計全体を示したが、一般的に「システム設計」と言う言葉を用いるときには図 3-1 の全体を示す時もあ
れば、システム設計（狭義）と書いた部分のみを示す時もあれば、図の中の 6.4～6.7 の部分のみを示す時もある。本設計標準において「システム設計」と言う言葉を用いるとき、
特に断り書きが無ければ、図 3-1 の全体を示す。
図 3-1 の流れと本設計標準 4 章以降の順序は可能な限り合わせているが、必ずしも一致しているわけではない。また、図 3-1 の流れは論理的には正しいものの、必ずしも時系列の順序にはなっていないことに注意してもらいたい。
本設計標準の 4 章以降の構成および記述内容は、次の通りである。
4 章にシステム設計の入力になる部分をまとめてある。
5 章にはシステム設計の前提となる運用についてまとめてある。
6 章が、システム設計の本質であり、要求分析・機能分析・性能分析・システム設計・解析・サブシステム設計・インターフェース設計が示されている。
7 章は、システム及びサブシステムのサイジングについて示されている。この章は、6 章の作業をする上で定量化する方法が示されている。
8 章は、検証について示されている。設計し製造された宇宙機は、打ち上げ前に、その機能・性能を解析や試作試験を行うことで、システム・サブシステムレベルで検証する必要がある。検証すべき項目や時期、検証方法は、設計が進んだ段階で検討するのではなく、設計の初期段階から考慮する必要がある。
9 章は、システム設計全般を通して管理すべき項目を挙げている。
10 章は、各フェーズ毎に、システム設計のアウトプットとして、必要となるものを示した。
4 章～10 章には、設計方針のプロセスをどの時点で行うかを明記してはいないが、可能な限り早い時点で、関係者間の合意を取ることが望ましい。

2

JERG-2-100

4 システムの入力

6

システム設計（狭義）

4.1

5.2
運用ｲﾒｰｼﾞ/ｺﾝｾﾌﾟﾄ分析

6.1

上位要求

9

ミッション要求分析/（ﾐｯｼｮﾝ要求含）

6.6

サクセスクライテリア

4.2

5.3
運用要求分
9.1 ｺﾝﾌｨｷﾞｭﾚｰｼｮﾝ管理

5.4.
運用方式設

9.2 インタフェース管理9.3 リソース配分と管理

サブシステム分解

制約条件・

6.2
機能要求

前提条件
4.3

6.3
性能要求

信頼性要求

システム管理項目

9.4 その他のｲﾝﾀﾌｪｰｽ管理

6.4

9.5 リスク識別と管理ｼｽﾃﾑ構成設計

9.6 技術の成熟度
9.7 信頼性、安全

6.5

6.7
ｲﾝﾀﾌｪｰｽ設計

ｼｽﾃﾑ解析

9.8 ｺｽﾄ、ｽｹｼﾞｭｰﾙ、体制

7.3
システム要求8 検証・妥当性確認
8.2

8.1
検証

妥当性確認

10
7 サイジング
7.1
サブシステ

8.3
試験・解析・検査

システム設計のアウトプット

ム
7.2
形状設計

図 3-1 システム設計の全体の流れ （数字は本文書の章・節番号と対応）

3

10.1 各フェーズ毎に必要とされるアウトプット概要

JERG-2-100
4. システム設計の入力
4.1

上位要求

上位要求の主なものはミッション要求である。ただし、ここで言うミッション要求はミッ
ション要求分析後の要求ではなく、最上流のミッション提案や運用イメージである。
ミッションは概ね、表 4.1-1 のように分類できる。
表 4.1-1 ミッションの分類
ミッション種別
観測・計測

リモートセンシ
ング「その場」計測

主な目的と特徴特長

主に電磁波を用いた画像・スペク
トルなどの観測。
- 地球観測 (気象観測等を含む)

地球観測は均質な系統的・包括的な観測を可能とする。
天文観測は地上に比べ大気の影響を受けない。

- 天文観測、などが主な対象となる。
主に分子・イオン、粒子線、電場、磁場などの「その場」の局所的な宇宙環境計測。

地球外太陽系天体の探査に代表される深宇宙探査。軌道投入
や装置駆動などイベント駆動型のミッションが多い。観測、計測
ミッションの性格を伴う。
サービス（気象、通信、測位 社会的、または顧客の要望に応じた宇宙機の特長を生かしたなど）
サービスの提供。多くは観測・計
測ミッションの性格を伴い、サービスは主に通信データを媒介する。
主に微小重量・重力などの宇宙
宇宙環境利用環境を利用した実験、計測。
現実の宇宙環境における宇宙開技術開発
発技術の実証。
探査

4

少なくとも十分な精度では遠隔観測が不可能な唯一の計測手段。局所的だが長期間に渡る均質・系統的なデータの取得。
少なくとも十分な精度では遠隔観測が不可能な、天体の唯一の計測手段。
社会的な関心・インパクト大きさ。
社会、顧客の満足。
多くの場合は公共の利便。

地上では実現できない計測
環境の実現。
地上では実現できない宇宙環境での実証。

JERG-2-100
4.2

制約条件・前提条件

初期設計では、検討を進める上で与条件のみで検討・設計が進められず、確証なしに仮定した条件、または現時点で確定していない条件としての制約条件・前提条件を設定し、設計根拠とする場合がある。このような前提条件の正否は開発リスクとなり、リスク認識・識別をするとともに、それとは別に制約条件・前提条件を識別・管理し、認識の共有化を図る必要がある。
これらの項目はいずれもプロジェクト管理文書として文書化することが求められ、設計・開発資料としてプロジェクトで明確化・共有化することが円滑に設計を進めて行く上で有用であり必要である。
(1) 考慮すべき主なプロジェクト及び外部の制約
a. プロジェクト
予算、スケジュール、搭載機器の指定、他プロジェクトの状況、信頼性要求など
b. ロケット（打ち上げ手段）
サイズ（許容包絡域の形状）、許容質量、対ロケット I/F、打ち上げ時期、投入
軌道、軌道投入条件、射場環境・安全規定 など
c. 開発環境d. 運用環境e. 規制
国内法、宇宙法などの国際規定、電波周波数管理規定、国内外の輸出管理規定、
工業規格、社内規格・規定 など(2) 考慮すべき主な宇宙環境要因
a. 打ち上げ環境
b. 宇宙放射線c. 太陽光d. プラズマe. 高層大気f. 地球 (惑星、衛星)
g. 宇宙塵、スペースデブリ
h. 真空環境i. 無重力・無重量
j. 搭載機器電磁干渉
k. 外乱・擾乱

5

JERG-2-100(3) 考慮すべきミッション要求・ミッション機器がシステムに与える主な制約条件
a. 指向性能要求b. アライメント精度要求
c. 視野要求（含む妨害回避視野）
d. 電波干渉回避要求
e. 熱的条件
f. 形状、構造特性
g. 質量
h. 柔構造特性、擾乱伝達特性
i. 展開、離脱構造
j. 所要電力k. 電磁適合性（EMC/EMI）
l. 出力データ要求
m. テレメトリ、コマンド要求n. 寿命要求

4.3

信頼性要求
信頼性要求は、主に下記の項目からなる。
・ミッション寿命と残存性
・ミッション運用の連続性・継続性

6

JERG-2-100
5．運用設計宇宙機システム設計と並行して、そのシステムの持つ機能・特性を使い、如何にそのシステムに課せられたミッションを達成するか、その方法を検討する必要がある。 その手段が「運用」である。この場合、「運用」に含まれる要素は、宇宙機だけにとどまらず、地上シス
テム（衛星管制システム、追跡ネットワークシステム、ミッション運用系システム）および運用者を含む。
5.1 運用設計の流れ
運用設計の流れの例を図 5-1 示す。宇宙機システム設計と運用設計は、一方が先に決まる
といった上位下位の関係ではなく、双方並行して詳細化を行い、その結果を突き合わせて、
機能面、運用面から過不足がないか、整合性の確認を取りながら、開発を進めていくことが重要である。

図 5-1 運用設計の流れ

5.2

運用イメージ／コンセプト分析

運用コンセプト分析は、開発する宇宙機システムの運用の概念、ミッション要求・システ
ム要求の前提となっている運用に関連する事項を明確にするためにおこなう。
この分析作業では、衛星利用者や運用者などの関係者からの意見、期待、ニーズなどを収
集、分析を行いながら、合意の形成に努める。
5.2.1 運用イメージ分析（概念検討フェーズ）
運用イメージ分析の目的は、ミッション要求に対し、その実現性を裏付ける前提となる運用のイメージをまとめるものとなる。
分析の観点としては以下の 3 つのがあげられる。
(1) システムライフサイクル観点
システム全体のライフサイクルを定義し、そこで定義される各フェーズで必要となる運用のイメージを検討する。
(2) ミッション運用観点
ミッションのサクセスクライテリアに対し、その達成のためにどのような運用が必要かを検討する。
7JERG-2-100(3) バス・地上運用観点
宇宙機システムライフサイクルを通し必要となる、バスシステムの健全性を確認するための運用や、その基盤となる地上システム及びその運用者からなる維持運用を検討する。

5.2.2 運用コンセプト分析（概念設計フェーズ）
運用コンセプト分析の目的は、運用を具体化・詳細化し、運用方針として明確化し、宇宙機システム仕様に反映することである。
特に以下の項目について検討を行う。
(1) 運用方針の明確化
宇宙機システムの持つ機能に基づき、以降の宇宙機システム設計の前提となる地上システムを含むシステム全体としての運用方針（使い方）を明確化する。これには、
地上システムと宇宙機の機能配分および宇宙機の自動化自律化の方針も含む。
(2) 開発コスト、運用コストの観点から重要となる運用方針、要求、機能の識別
特に運用方法によって、開発コスト、運用コストに大きく影響する要素を識別し、運用方針・運用要求を明確化する。
(3) 宇宙機システムの機能・非機能要求との整合性確認
宇宙機システムで定義する機能・非機能要求と、運用方針、運用要求との関係性（トレーサビリティ）を明確化し、齟齬がないかを確認する。

5.3 運用要求分析
運用要求分析の目的は、運用としての要求事項(運用要求)を識別し、運用設計に反映することである。
(1) 運用コンセプトから運用要求を分析する。
運用コンセプトで明確化された運用方針を運用要求へ変換するためには、実際の運用を想定しながら、その状況下で運用方針がどういう前提条件・制約を受けるのかを分析する。
(2) オフノミナル運用要求分析
この段階で明確化すべきオフノミナル想定の詳細度を設定し、分析を行う。
(3) 運用要求と、運用コンセプト、及び宇宙機システム要求（機能・非機能）の対応付け
運用コンセプト文書等の運用要求分析作業のインプット（上位文書）での 記述内容が、宇宙機システム要求にフローダウンされていることを確認する。

5.4

運用方式設計運用方式設計の目的は、定義された運用要求を各システム要素（6.項以降で説明するサブシステムやコンポーネント、地上設備など）へ適切に配分し、そのインタフェース特性（インタフェースの種類、制約）を定義し、各システム要素への運用面からの要求事項を識別することである。
(1) 運用方式設計
識別、定義された運用要求を各システム構成要素へ配分するため必要となる要求の具体化、詳細化（Breakdown）を行う。
8

JERG-2-100(2) 運用方式設計結果と宇宙機システム設計及び運用シナリオとの整合性の確認
運用方式設計結果と、運用要求と元となっている運用方針、背景となる運用シナリオ、
及び、宇宙機システム方式設計結果との対応関係、整合性を確認する。

6. システム設計（狭義）
6.1 ミッション要求分析
ミッションが提案された時点では、目的と手段が混合している場合が多い。ミッションの本来の目的を明確にしていくことが重要であり、ステークホルダーの識別と分析が目的の明確化にあたっての有効な方法である。
また、第三者が判断できるようなミッション目標の達成度合の基準（サクセスクライテリア）についても、ミッション要求分析の対象とする。
6.2 必要な機能の洗い出し（機能要求）
ミッション要求を実現する為の必要、かつ最小限の機能を識別すると以下の通りとなる。
・ミッション機能
・軌道
・通信機能
・電源機能
・姿勢制御機能・軌道制御機能・温度制御機能・構造機能

6.3 必要な性能の洗い出し（性能要求）
機能ごとに、必要とされる性能を割り当てる。
この時、過去の宇宙機のうち同規模の事例が役に立つ場合が多い。
6.2 項までで洗い出された機能性能要求から、システムドライバ（システムパラメータ）を抽出する。ここで言う “システムドライバ”とは、ミッション達成やシステム設計を決定
づけ、開発者が決定すべき、主要な要素と定義する。
ここでは概念検討、システム要求検討、初期システム設計の場面で、特に宇宙機特有の技
術項目に着目して、一般的に検討する必要のある項目を列挙した。
システムドライバ（パラメータ）項目は 6.5 項のシステム解析の項目とほぼ同じであり、9.2 項のシステム配分によって管理する。


一般的な抽出すべきシステムドライバ項目（ガイドライン）
 軌道上サイズ
 質量
 電力
 データ通信
ミッションデータレート要求

ミッションデータ頻度・カバレッジ
ミッションデータの許容遅延
 軌道

軌道要求

軌道変更要求9JERG-2-100










軌道決定・予測精度要求
指向性

指向要求

指向精度

指向安定性

指向方向決定誤差
指向方向変更要求（角度、変更速度）
ミッション機器温度
運用性

運用頻度・カバレッジ

地上検証性
信頼性要求
寿命要求

6.4 システム構成
実際に宇宙機を構成するハードウェア及びソフトウェアの構成を検討すること。
検討にあたっては、考えられる複数の選択肢を検討する。検討においては、ある案では、ある機能要求または性能要求を満たすが、他の機能要求、性能要求を満たせないなど、利益相反が発生する場合があり、選択肢とのシステムトレードオフを行うことになる。
システムトレードオフとしては、6.3 項に示すシステムドライバ・パラメータおよびそれに相当するものが評価対象となるが、サブシステム、コンポーネントレベルで実施されるト
レードオフもある。また、システムドライバ・パラメータ以外にも例えば衛星構体パネルへの機器搭載で複数の案をトレードオフする場合もある。
トレードオフは、技術（実現性、開発要素、等を含む）のみならずコスト、スケジュールなどマネジメント判断が必要となるものが多く、定量的な評価が望まれる。
システム構成検討の主な要点と考慮事項は次の通りである。
(1) 要求機能、性能から電源、通信、データ処理等の主要構成要素のアーキテクチャを選択する。
(2) 既設計/新規の識別を行い、既設計部分／新規部分の制約条件を明確にする。
(3) システム構成案をまとめ、リソース（電力、質量、コスト等）が想定の枠内にバランス良く収まっているかを確認しつつ、選択肢とのトレードオフを行う。
(4) システム構成品目の実装、システムの形状の概要を明らかにするため、衛星形状設計を実施し、衛星形状、機器配置等を衛星システム構成のアウトラインとしてまとめる。衛星形状設計において考慮すべき事項は 7.2 節に示す。

6.5 システム解析
前項までの機能、性能、構成によりミッション要求が実現できることを確認し、設計を最適化するためにシステム解析を行う。
システム解析は、様々なものがある。列挙すると以下のような解析がある。


軌道解析、ロンチウィンドウ解析、放射線解析、回線解析、運用解析、推進薬量解析、指向精度解析、姿勢外乱解析、構造解析、熱解析、機械環境条件解析、視野解析、影解析、電力解析、EMC 解析、帯電・放電解析、コンタミネーション解析、磁気解析、
10

JERG-2-100
信頼性解析、安全性解析（ハザード解析）、デブリ解析
6.6

サブシステム分解

6.3 項で抽出したシステムドライバを元に、システムの機能、性能をサブシステムに分解、配分し、サブシステムに対する要求を設定する。サブシステムは、衛星バスであれば、電源系、テレメトリ・コマンド系、推進系、姿勢軌道制御系、熱制御系、構体系、計装系などに分解される。
6.7 インタフェース設計
衛星システムとインタフェースする主な対象を図 6.7-1 に示す。
外部インタフェースは衛星システムの外部、即ちロケットシステム、地上システムとのイ
ンタフェースと定義する。内部インタフェースは衛星のミッション機器、サブシステム、コンポーネント相互間のインタフェースである。
衛星システムロケットシステムミッション機器

内部 I/F
サブシステム外部 I/F

コンポーネント

地上システム・打ち上げ管制システム
・衛星管制システム
・追跡ネットワークシステム
地上システム・ミッション運用系システム

図 6.7-1 衛星外部、内部インタフェース
インタフェース項目としては機械的インタフェース、電気的インタフェース、熱的インタ
フェースが主なものである。
6.7.1 外部インタフェース
外部インタフェース設計で大きな割合を占めるのはロケットシステムインタフェースと地上システムのミッション運用系システムインタフェースである。
ロケットシステムは打ち上げ手段であり、衛星の形状、大きさ、衛星の耐機械環境などと密接に関係する。
地上のミッション運用系システムはミッションデータの処理を担う。キーとなるのはミッ
ションデータレート、運用方法である。他に地上の衛星管制システムとのインタフェースがあるがこれは設計がかなり進んだ段階で設計する。
6.7.2 内部インタフェース
ミッション機器は本書では内部機器として扱っている。ミッション機器と衛星バスのインタフェースは特に重要である。
ミッション機器の多くは電磁波の送受機能を持つので視野インタフェースも設計する。

11

JERG-2-100
7. システムのサイジング
システムのサイジングは、7.1 項に示すサブシステムのサイジング結果を集計し、7.2 項の衛星形状設計との整合性を取りながら行う。
7.1 サブシステムのサイジング
サイジングは 9.3 項で述べる配分と管理のため、サブシステムの諸元を求めるための設計である。
7.1.1 電源系サイジング
電源系のサイジングは、下記の情報を元に行う。
 機器消費電力
 運用モード 所要ヒータ電力量
 軌道周期 日陰時間プロファイル
 目標寿命など
電源系のサイジングは、次のものになる。
 所要電力量
 供給電力量
 電力制御量
さらに、主に次のサイジングを行う
 太陽電池パネルサイジング 放射線環境、太陽距離、β角などを元に
 SAP 面積、SAP セル貼り付け枚数、発生電力などをサイジング
 電源系 BAT サイジング
 運用モード毎の許容放電深度などを元に BAT セル容量やセルの並列直列数など
7.1.2 通信系サイジング
宇宙機の通信系のサイジングは、下記の情報を元に行う
 通信データ特性
 所要データレート 通信モードとの対応
 所要回線品質
 送信タイミングカバレッジ等
 運用条件
 軌道
 運用モード コンテンジェンシ時の通信モード
 使用可能な地球局など
上記を元に次の項目を求める。
 通信方式
 回線構成 使用周波数 伝送レート 変調方式 回線設計 伝送時間と頻度
 アンテナサイズ
12

JERG-2-100

送信（受信）機の性能及び主要諸元
使用地球局など

7.1.3 テレメトリ・コマンド系サイジング
テレメトリ・コマンド系のサイジングは、下記の情報を元に行う
 運用モード 発生データ量 必要ダウンリンクデータ量
 運用局
 運用時間制約など
上記を元に次の項目を求める。
 出力レート データレコーダ（DR）記録レート
 容量ダウンリンクビットレート
 コマンド形式
 ストアードコマンド等
 アップリンクビットレートなど

7.1.4 推進系サイジング
推進系のサイジングは、、下記の情報を元に行う
 軌道制御要求 軌道制御用スラスタのトータルインパルス要求
 姿勢制御要求 スラスタ数
 推力及び制御トルク
 姿勢制御用スラスタ トータルインパルス要求など
上記を元に次の項目を求める。
 スラスタの種別
 一液、二液、ガスジェット、電気推進など
 サイズ
 個数
 配置などまた、推薬量解析結果に基づき必要推薬量を予測し、タンクのサイズ、個数、タンク容量などを求める。

7.1.5 姿勢軌道制御系サイジング
姿勢軌道制御系のサイジングは、下記の情報を元に行う
 姿勢制御精度要求
 姿勢方向変更要求（角度、変更速度）
 自然外乱トルク 内部擾乱トルク
 角運動量など
上記を元に次の項目を求める。
 センサ系要求仕様
 アクチュエータ駆動則 ホイール／CMG
13

JERG-2-100



 トルク
 角運動量 電力
 質量
磁気トルカ諸元などを

7.1.6 熱制御系サイジング
熱制御系のサイジングは、下記の情報を元に行う
 衛星の放熱面
 熱伝導面 ヒートパイプなど
 MLI 包絡面
 伝導結合部分など、上記を元に次の項目を求める。
 各機器搭載パネルごとに外部および内部熱環境との熱的収支を勘案
 外部熱入力算出
 温度予測解析 熱的干渉確認さらに下記をサイジングする。
 ヒータ容量 放熱面積 放熱パスなど
7.1.7 構体系サイジング
構体系のサイジングは、下記の情報を元に行う
 ロケットとのインターフェース
 包絡域など
 打上げ環境 剛性条件 準静的加速度条件
 正弦波振動環境条件
 音響環境条件
 分離衝撃環境条件
 軌道上での環境・制約
 柔軟構造物としての特性 擾乱など上記を元に次の項目を選定する。
 一次構造の構成方式
 構造部材の種類
さらに下記を求める。
 構造方式
 構造物の静特性、動特性、安定性
 部材、部品の構成
 寸法、材質など

14

JERG-2-1007.2

衛星の形状設計

衛星システムの形状設計における要点、考慮事項には様々のものがあり、設計としてはイタレーションを繰り返し、且つ重要事項から開始するので一概に形状設計の順番を示すのは難しい。
ここでは衛星全体の形状設計としての考慮事項例を示す。

衛星全体の形状設計考慮事項例・ 構体形状 ロケットフェアリング制約
 構造様式
 放熱面積 視野確保 ミッション機器インタフェース
・ 構造様式
 荷重パス インテグレーション性 指向要求（含む擾乱）・ 熱制御様式
 運用姿勢太陽条件
 放熱面配置
 発熱分布 軌道条件 日陰条件・ 太陽電池パネル様式
 必要(要求）電力
 剛性要求 機器視野確保
 SAP 回転自由度
 影条件

7.3 システム要求への反映
前項までで上げた作業をシステム要求書に反映する。
反映された「システム要求」や、それに付随する「ハードウェアイメージ」を用いて、ミッション要求を満足していることを確認する。
「ミッション要求」の実現が技術的に困難と判断されれば、ミッション要求変更を提案し、要求元（ステークホルダー）と調整する。
ここまでの作業を何度か繰り返した後、ミッション要求からシステム要求が整合性が取れれば、次の設計フェーズに進む。

15

JERG-2-100
8. 検証・妥当性確認
宇宙機のサブシステムやコンポーネントは、打ち上げ前に、検証、妥当性確認として要求される機能・性能が満たされることを確認する必要がある。実績のあるサブシステム・
コンポーネントは検証、妥当性確認方法が明確であるが、新規に開発するものは、どのような方法で確認するかを明確にしておかないと、システム開発・製造に大きな影響を与える可能性がある。
そのため、検証、妥当性確認は、宇宙機のシステム設計と独立に作成されるものではな
く、早い段階から、システム設計の一環として、要求されるミッションや仕様の設定と検証方法はセットで行われるべきものである。
検証、妥当性確認は、4 章から 7 章で述べるシステム設計の各作業結果として作成される製品・成果物が要求事項と合致しているかを確認する行為であり、単独の確認行為ではな
く、一連の戦略性のあるものとしてシステム開発の個々のステップにおいて実施するものである。
検証と妥当性確認についてはその違いを把握することが重要である。英語で検証は
Verification、妥当性確認は Validation と言う。ここでは表 8-1 の通り定義する。
表８−１ 検証、妥当性確認の定義
Verification 検証
製品の機能・性能が客観的証拠を提示することにより、規定要求事項を満たされていることを確認するプロセス
Validation
妥当性確認
当該システムが意図した利用目的・動作環境において意図した機能・性能を有していることを確認するプロセス

この検証、妥当性確認は、各開発・試験段階において、戦略的に確認行為を、開発作業を開始する前に全体検証及び妥当性確認計画として立案し実施することが重要である。試験設備などの検証、妥当性確認を行うために必要な装置の、利用・新設計画も必要である。
8.1

検証

検証（Verification）はシステム要求に合致するかどうかの確認を行うもので、類似性解析、検査、試験、審査の５つの方法で行う。システム要求/システム仕様のみならず、サブシステム設計、コンポーネント設計に対しても同様の確認を行う。それぞれの要求・仕様に対して、どの方法で検証するかを明確化する必要がある。
検証活動においては、各要求・仕様に対し実施された検証内容及びその結果のトレーサ
ビリティを維持する必要がある。
なお、衛星打ち上げ後に軌道上で検証（軌道上試験）を行う場合もある。
8.2

妥当性確認

妥当性確認（Validation）の目的は、開発しているシステムが、意図した利用目的を達成することができるかを確認する活動である。より実運用、フライトを想定した確認が必要となる。妥当性確認活動の計画を立案する際は、開発形態を想定し、どのような確認行為が、どの段階で必要となるかを吟味する必要がある。
開発方針、開発形態によっては、打上げ後に軌道上での動作確認、妥当性確認を行うことも考えられる。地上での妥当性確認の際は実運用時に想定される環境、入力が厳密に再現出来ないので、含まれる誤差、想定を評価したうえで、使用目的に合致することを確認し、妥
当性確認とする。

16

JERG-2-100
8.3

試験・解析・検査(1)

試験
検証及び妥当性確認計画において、その手段が試験とされた要求・仕様に対し、そこで規定される機能・性能が満たされていることを、実環境、または実環境を模擬した試
験環境を用いて確認する。
設計上想定される異常などを模擬した試験や、想定される最大負荷を想定した試験を
行う。

(2)

解析
解析は、試験により全ケースの確認が困難な場合の補完手段として、また、試験による確認が困難な場合の代替え手段として実施される検証行為である。解析結果は文書化により見える化し、保管される必要がある。

(3)

検査
物品が仕様、図面などに合致していることを、計測、目視により確認する行為である。
例：システム構成など。検査については、その種類、範囲、重要さに応じて詳細に記述
され、実施日、検査担当者名、合否判定及びその結果（必要に応じて写真）を記録し保管する必要がある。

17

JERG-2-100
9. システム管理項目
システム設計の全般にわたり、管理しなければならない項目は次のものである。概念設計
段階では、これらを念頭に管理計画を立案する事。システム設計に別途管理標準が適用される場合はそれを優先する。
9.1

コンフィギュレーション管理

コンフィギュレーションは構成であり、宇宙機及び関連する地上設備などの構成を指す。
コンフィギュレーション管理は、設計、製作、試験及び運用の全ライフサイクルで、システ
ム又は構成品目の機能的及び物理的特性を識別し、常に最新状態を維持、記録、提供する技
術的及び管理的プロセスである。
「常に最新」が要点である。変更が生じたにも関わらず放置
するとインタフェースなどに齟齬が生じ、多大なロスが発生する。
特に、技術変更は目的とするシステム又は構成品目の性能、開発経費、開発スケジュール、
安全性、信頼性、保全性、互換性、補給支援、インタフェース等の重要事項に影響を及ぼす
ので、変更の際は慎重に検討をしなければならない。変更は不具合の源のひとつと考えても過言ではない。
9.2

インタフェース管理

9.2.1 外部インタフェース
インタフェースには外部インタフェースと内部インタフェースがある。外部インタフェース
は最終的にはインタフェース管理仕様書で規定する。例として以下のような管理仕様書がある。
(1)ロケットシステムとのインタフェース(2) 衛星管制システムとのインタフェース(3) 追跡ネットワークシステムとのインタフェース(4) ミッション運用系システムとのインタフェース
9.2.1.1 ロケットインタフェース
衛星・探査機システムを打ち上げるロケットとの間では、システム設計にも関わる諸事項を調整し、規定する必要がある。システム設計に当たっては、打上げロケットのユーザーズ
マニュアル等に記載されている情報をもとに打上げロケットとの適合性について検討するとともに、ロケットとの調整が必要となるシステムの固有事項を洗い出す必要がある。
ロケットとのインタフェース条件として規定すべき事項のうち、打上げロケットによらず共通的なものを以下に例示する。
(a) 打上げ時期(b) 打上げ方式(c) 軌道要素及び軌道投入条件(d) 機械的インタフェース

座標軸
衛星包絡域・搭載寸法

質量特性

衛星分離部

フェアリング
衛星固有振動数(e) 電気的インタフェース
18

JERG-2-100

アンビリカルライン
電気的ボンディング
コマンド／テレメトリ
電波環境適合性(f) 環境条件（打上げ時、地上ハンドリング時）

機械環境

熱環境
(g) 射場設備インタフェース

9.2.1.2 地上システムインタフェース（衛星管制システム、追跡ネットワークシステム）
JAXA の追跡管制は基本的には、筑波宇宙センターの衛星運用管制システム（SMACS）と相模原管制センターの汎用衛星試験運用ソフトウェア(GSTOS)から行われている。
具体的なインタフェース項目は使用局、トラッキング・テレメトリおよびコマンド（TT&C）と軌道（力学）である。使用局とは追跡管制にどの局を使うかである。TT&C は搬送波、テ
レメトリ信号特性、コマンドフォーマットなどが、軌道では軌道決定や軌道制御コマンドなどがインタフェース項目である。
9.2.1.3 地上系インタフェース（ミッション運用系システム）
ミッション地上系の主な業務は運用計画立案とミッションデータの受信及びそれに続く、ミッションデータ処理、配付及び保存である。従って、運用プロファイルすなわち衛星にとっては電力プロファイルに直結するのでインタフェース調整が必要である。データ量が少ない場合はテレメトリ回線でミッションデータをダウンロードする場合があり、TT&C とのイ
ンタフェースが発生する。ミッション機器の HK データも TT&C とインタフェースがある。

9.2.2 内部インタフェース
サブシステム、コンポーネントインタフェースはインタフェース管理文書（ICD）で規定する。サブシステムは複数のコンポーネントから構成される。コンポーネント間のハーネスは、特殊なハーネスを除き一般的にはシステムが用意する。
ICD はサブシステム ICD とそのサブシステムを構成するコンポーネント ICD から成る。

・品目リスト・サブシステム系統図
・サブシステム接地系銃図
・各コンポーネント ICD
・各ワイヤハーネス図19

JERG-2-100
9.3

リソース配分、性能配分とその管理

9.3.1 配分
宇宙機システムの質量、電力、推進薬、信頼度、テレメトリ、コマンド、ヒータ、温度計
測点などはリソース配分項目であり、指向誤差などは性能配分項目である。配分の方法は初期設計にはボトムアップでデータを吸い上げ、システム側が横並びにして経験や実績値をもとにマージンを織り込んで配分する。
9.3.2 管理基本設計以降は配分されたリソースや性能をトップダウンで管理する。マージンは集中型とし、システムが管理する。これらのリソースは表にまとめ、以降の設計及び製造の管理に用いる。
各種マージンについては、ミッションの特性や設計の進捗により、変化する事を考慮する。
9.3.2.1 質量管理
ミッション機器とバスのサブシステムの質量を管理する。これに適切なマージンを見込む。
このマージンはシステム設計側で持つ。このマージンは設計の進捗に伴い徐々にゼロに近づく。
9.3.2.2 電力管理
電力の管理も質量配分と同様にミッション機器とバスのサブシステム別に行う。但し、電力は機器のオン、オフ及び運用のプロファイルで変化があるので平均値とピーク値で管理する。配分には適切なマージンを設定する。
9.3.2.3 推進薬管理
推進薬は宇宙機の軌道変更、保持、姿勢制御に用い、各々の機能に対して管理する。なお、デブリ発生防止の観点から廃棄運用時のデオービット用の推進薬も必要となる。推進薬には適切なマージンを設定する。
9.3.2.4 信頼度管理
信頼度は例えば”打上げから 5 年後における宇宙機システムの残存確率は、0.8 以上とする。
“といった要求となる。システム設計者あるいは信頼性技術者は，信頼度ブロック図を作成し，各サブシステム/機器に必要な信頼度を配分し管理する。サブシステム/機器の設計者
は部品の故障率等にもとづいて予測値を算出する。
9.3.2.5 指向管理
指向管理は衛星の基準軸に対する誤差を極力抑えるための管理である。スタートラッカー、
太陽センサといった姿勢制御用のバス機器、ミッション機器である観測センサなど衛星の指向に関わる機器に対して管理する。アライメント、経年変化、熱歪、擾乱などに細分化して配分する。
9.3.2.6 テレメトリ・コマンド管理
運用イメージ、コンセプトを考慮し各サブシステム、コンポーネントに対して、テレメト
リとコマンドを配分し、管理する。
テレメトリについては新規開発機器、特にミッション機器には多く配分すべきである。万一不具合が発生した場合、原因の特定につながる可能性が大きいからである。
9.3.2.7 温度計測管理
熱制御関係の配分であり、温度制御のためのヒータと温度計測点を配分し、管理する。
9.4

その他のインタフェース管理情報

その他、システムのインタフェース管理情報として以下のものがある。
20

JERG-2-100・極性管理・使用周波数管理
・残留磁気管理・取り扱い条件管理
これらの管理情報は基本設計以降に使われる。
9.5

リスク識別と管理

一般的に、リスクには、技術リスク、コストリスク、スケジュールリスクおよびプログラ
ムリスクの４種類があり、その４つのリスクの相互関係を図 9.5-1 に示す。
宇宙機システムでは、新規技術、不確定要素、マージン、部品材料などが主な技術リスクである。
リスクも要求・要望の実現性に対する危険・不安定要素として、システム概念設計の段階から抽出し、その発生可能性・重大度(影響度)で識別し、認識をプロジェクト内で共有化する必要がある。
特に技術リスクに着目すれば、初期設計段階でのリスク識別はその後の重点化すべき開発・検証要素の抽出ができ、開発コスト予測を導く。妥当なリスク識別はその後の開発計画
を円滑にする。

図 9.5-1 リスクの種類とその関係

21

JERG-2-100

9.6 技術の成熟度
技術成熟度 (TRL) は、TRL は技術リスクの識別とそのリスクの低減の為に用いるものであり、TRL とそれに伴う検証計画はプロジェクト指針の重要なものである。TRL が低い場
合は技術リスクとして識別し、考慮する。

9.7

信頼性設計・安全性設計・安全管理

9.7.1 信頼性設計
信頼性設計はある程度システム設計が進んでから開始する。
ここでは信頼性設計の基本的な考え方を紹介する。
(1) 設計余裕の確保及び故障リスクの最小化
機器等に付加されるストレスに対して余裕のある設計の採用や製造工程の特別な管理などにより、故障のリスクを許容出来るレベル以下にする。特に、冗長系を採用出来な
いあるいはしないシステム上の単一故障については、設計余裕を取るように配慮すること。
(2) 故障許容設計
故障及び人的過誤により、システムが致命的な状態に至らないようにする。システムの特性を考慮し、必要に応じて適切な冗長化(常用冗長・待機冗長等)、故障の伝搬・波及防止等の対策を検討する。
(3) 信頼度配分にもとづく定量的予測と実証
必要に応じて MIL-HDBK-217 等による信頼度の定量的な予測を行い、信頼度配分を満足させる。重要な品目については適宜、信頼度実証の方法を採用する。
(4) 単純化、標準化
部品の点数は減らせば減らすほど信頼度も上がり、宇宙機の質量も減り、コストも下がる。従って、設計の初期段階で要求される機能が本当に必要かどうか十分吟味するこ
22

JERG-2-100とが重要である。また、環境条件、運用（使用）条件を考慮した上で高い技術成熟度(TRL)にある機器を採用することも重要である。
(5) 信頼性管理品目の識別信頼性確保のため、製造、検査、試験、整備、運用の各段階に於いて、重要な特性を管理すべき品目を識別する。この品目は、クリティカル品目リスト（CIL）としてリスト化し管理する。クリティカル品目の選定基準は、以下をガイドラインとする。

故障すると人命、重要な財産、およびミッションの喪失となる品目、あるいはミッションの達成に重大な影響を及ぼす品目。

プロジェクトマネージメント上のリスクが極めて高い品目。
9.7.2 安全設計
安全設計はプログラム的には以下のフェーズで活動するように要求されている。
(1) 概念／予備設計段階（フェ－ズ０）(2) 基本設計段階（フェ－ズⅠ）(3) 詳細設計段階（フェ－ズⅡ）(4) 製造・試験段階（フェ－ズⅢ）(5) 運用段階
安全設計の原則は以下の 3 段階となっている。
基本的に故障許容設計を行う
リスク最小化設計を行う
リスク評価を行う

故障許容設計とは、以下を言う。
(1) 二重の故障、一つの故障と一つの人的過誤の組合わせ、及び二重の人的過誤がカタス
トロフィックハザードを引き起こさないこと。
(2) 一つの故障又は一つの人的過誤がクリティカルハザードを引き起こさないこと。
(3) システムはフェイルセーフ及びフールプルーフであること。
(4) 一次的故障により、人に負傷をもたらすような二次的又は付随的な故障が発生しないこと。
(5) 電源供給等の途絶に対し、一定時間安全が維持できること。
(6) エネルギ源との間に必要な数の独立したインヒビットによりハザードを制御していること。
a. カタストロフィックハザードを引き起こす潜在的な能力のある機能に対しては、エネルギ源との間に最小限３つの独立したインヒビットを持つこと。そのうち、２つのインヒビットはモニタができること。
b. クリティカルハザードには最小限２つの独立したインヒビットを持つこと。

リスク最小化設計が適用される分野としては、下記が挙げられ、適用する際は検証データを示す必要がある。
・構造
・圧力容器
23

JERG-2-100
・圧力配管及び継ぎ手・火工品(Pyrotechnic Device)
・メカニズム（機構）・材料選定（適合性、可燃性等）
原則の最後の段階、リスク評価については 9.5 項を参照されたい。

9.7.3 安全管理システムの安全管理はハザード解析が主となる。
(1) 概念設計/計画決定段階のハザ－ド解析システムについてのハザードの識別並びに対応策の検討を行うとともに、安全要求を設定する。
その内容は次のとおりである。
a. システムの運用において考えられるハザードを有する部位、場所を明らかにする。
b. 使用予定材料、部品等で特にハザードを有する物質を識別する。
c. 試験、運搬、取扱い、運用等で考えられるハザードを明確にする。
d. インタフェースに関する安全上の問題を明確にする。
e. ハザードに対する予想される事故等の程度を明らかにする。
(2) 基本設計段階以降の ハザード解析
基本設計段階において、概念設計/計画決定フェーズで識別したハザードに基づき、より詳
細にハザード解析を行い、ハザ－ドの識別、影響の及ぶ範囲、対応策を明らかにするとともに詳細な安全要求を設定すること。
ハザ－ド解析は、開発品目及びその運用に係るハザ－ドを、ライフサイクルのすべてにわ
たって、体系的かつ論理的に識別・評価する手法である。
なおハザード解析は、開発品目のライフサイクルで遭遇する最悪の環境条件を考慮して実施する。また、ハザ－ド解析の実施にあたっては、過去のプロジェクトからの教訓等を十分に取り入れること。

9.8

コスト、スケジュール、体制その他

コスト、スケジュール、体制はプロジェクトマネジメント（PM）の範疇とされる。
一方、コスト、スケジュールはシステム設計の制約条件、与条件でもあることに注意すべ
きである。

24

JERG-2-100

10. システム設計のアウトプット
10.1

各フェーズ毎に必要とされるアウトプット概要

プロジェクト準備
審査

プロジェクト移行
審査

プリフェーズ A

フェーズ A

概念検討

概念設計

ミッション定義
審査
(MDR)

計画決定

システム要求審査(SRR)

フェーズ B

フェーズ C

フェーズ D

基本設計

詳細設計

製作・試験

システム定義
審査
(SDR)

基本設計
審査
(PDR)

詳細設計
審査
(CDR)

開発完了
審査

γ打ち上げ

射場
整備

フェーズ E
初期運用 定常運用

打上げ準備完了
審査
（LRR）

審査

フェーズ E
フェーズ F
後期利用（廃棄を含む）

定常運用終了審査

定常運用移行
審査必要とされるアウトプット

ﾐｯｼｮﾝ定義審査（MDR）

ミッション要求書（案）システム要求審査(SRR)

システム要求書、運用コンセプト

システム定義審査(SDR)

システム仕様書

25

JERG-2-100
付録－１ 参考になる図書など
ここに示した図書は、宇宙機のシステムをより深く理解するのに役に立つものである。
必要に応じて、参考にしていただきたい。
(1) "Space Mission Analysis and Design", 4th edition, Peter Fortescue, Graham Swinerd, John Stark,
John Wiley & Sons, Inc. (2011)(2) "NASA Systems Engineering Handbook", NASA SP-2007-6105 Rev1 (2007)(3) "NASA Systems Engineering Processes and Requirements w/Change 1 (11/04/09)", NASA NPR
7123.1A (2009)(4) "NASA General Safety Program Requirements (w/Change 7 dated 2/25/11)", NASA NPR 8715.3C(2011)(5) "Systems Engineering Fundamentals", Department of Defense, Defense Acquisition University
Press (2001)(6) "System engineering general requirements", Third issue, ESA/ESTEC ECSS-E-ST-10 C (2009)(7) "Verification", Second issue, ESA/ESTEC ECSS-E-ST-10-02C (2009)(8) "Testing", Second issue, ESA/ESTEC ECSS-E-ST-10-03C (2012)(9) "Space environment", Second issue, ESA/ESTEC ECSS-E-ST-10-04C (2008)(10)"Technical requirements specification", Third issue, ESA/ESTEC ECSS-E-ST-10-06C (2009)(11)"Method for the calculation of radiation received and its effects, and a policy for design

margins", First issue, ESA/ESTEC ECSS-E-ST-10-12C (2008)(12)"Calculation of radiation and its effects and margin policy handbook", First issue,

ESA/ESTEC ECSS-E-HB-10-12A (2010)(13)"Project planning and implementation ", Third issue revision 1, ESA/ESTEC ECSS-M-ST-10

C Rev.1 (2009)(14)"Safety", Third issue, ESA/ESTEC ECSS-Q-ST-40 C (2009)(15)"Test Like You Fly: A Risk Management Approach", J. White and C. Wright, in the 6th

National Space System Risk Management Symposium, the Aerospace Corporation (2005)

26