220426 ISDPメモ

ISDP

Space Mission Engineering

ミッションには二通りの考え方がある。
Needs-Driven: 問題から始まって方法を考える方法。多くの宇宙ミッションがこの形を解く。
例）宇宙の中で調べたい天体がある
Capability-Driven: 新しい技術・方法論から始まってそれらでできることを考える方法。
例）イオンエンジンを開発していてそれを使って何かしたい

Space Mission Engineering Process

宇宙ミッションの設計では、これらのプロセスを行き来する必要がある。
① 要求・制約を定義する
a. 大きな（量的な）目標・制約を定義。具体的な数値はあとからついてくるので数に固執しない。
b. 主要なプレイヤーを定義（誰がそのミッションの影響を受けるのか）→これを考えることでよりよい要求につながることがある。
c. プログラムのタイムスケールを定義：スケジュール
技術的なプロジェクトの計画・スケジューリング・想定は非常に難しい。
d. 量的なニーズ、要求と制約を推定する。
例）
○○ロケットを使わなければならない→質的（qualitative)
○○ロケットを使うので、ペイロードは□□キロ以下にしなければならない→量的（quantitative)
② Mission Architectures, Conceptsを定義
Mission Architecture: ミッションで何が使うことができるか。
例）どんな装置が使えるのか、どんな地上局の機能があるのか
Mission Concepts: それらの機能を組み合わせてどのようなことをするのか。
a. mission architecturesを定義
b. mission conceptsを定義
c. どれが大きな課題になるかを考え、主要な制約を定義
例）電気推進を使う→多くの電力を使用するが、その電力はどうやって得るのか？

③ さまざまなMission Conceptsを評価する。
a. 機能の評価＆システムの変更。質的な評価も十分に有効。
b. ミッションの効用を計算。たくさんの計算が必要。
c. ベースラインとなるmission conceptとarchitectureを定義。ここから実際に物を作ってテストを始めることができる。試験をしていくうちに前に戻って改善することがある。
d. 量的な制約を要求を改善する。
e. iterate and explore other alternatives

Q. What is the difference between constraints and requirements?
Constraints: Limitation (power, mass, size) on your spacecraft. Borderline of the designing space.
Requirements: Specification to the system. Targets the systems need to meet.

④ どのサブシステムがどの仕事をするのか、どのシステムが何をしなければならないのかを定義
a. システムの制約を定義
b. それらの制約をシステムの要素に割り当て

Introduction to Mission Elements

Mission Elementsの種類

・Subjects（≒Target） 例）サンプルリターンの場合：訪れる天体、
・End users：誰が恩恵を受けるのか 例）通信衛星の場合：インターネット利用者（この場合Subjectsでもある）
・Mission Operations (≒Schedule, Timescale)：いつ検査をするのか、いつエンジンを使うのか
・Orbit/Trajectory：とても重要。どこに行くか。どれくらい速く移動するか。宇宙機自体の設計ではないが、非常に大切。
非常に大事な役職の一つに：Astrodynamicistsがある。
・Launch Vehicle：これにより行ける場所、持っていける重量、打ち上げ時の衝撃などが決まる
・Ground Segment：通信システム（アンテナなど）

System Boundary：この内側にあるものはコントロールできるもの。
上の中でコントロールできないもの：Subjects, End users

・Spacecraft Subsystems

  • Payload
  • Propulsion：
  • Attitude Determination & Control (ADCS)：微小重力環境でどこを向いているかを知る
  • Guidance, Navigation & Control (GNC)：位置を変える
  • Command & Data Handling (C&DH)：例）頭脳＋神経、郵便局のようなもの。計算してその結果出てくる命令を分配する
  • Telemetry, Tracking & Command (TT&C)：通信システム。宇宙機が地上と通信する。基本的にはラジオ。

Communicationという単語を使わない理由は以下のような二つの通信があるため。
External：地上局との通信
Inernal：他のサブシステムの部分に対する通信

  • Electrical Power System (EPS)：どうやってパワーを得るか。ソーラーパネルだけでなくバッテリーやpower distribution systemなどの機能もここに含まれる。
  • Bus/Structure：構造。宇宙機の骨格。
  • Thermal Control：熱の移動・利用。

このように役割分担することで、管理がやりやすくなる。仕事量はサブシステムによって異なるため、実際の役割分担はもっと工夫する必要がある。

Systems Engineering

How do you eat an elephant?→ One bite at a time!

Mission Concepts: どのようなことを成し遂げたいのかという質的な目標。
↓
System Requirements: Mission Conceptsを達成するための要求。
例）どれくらいの画質、どれくらいのスパンで撮影するのか、赤外線なのか
Types of requirements:

  • Performance Requirements: 宇宙機がどのような機能をもっていなければならいのか
  • Operational Requirements: 宇宙機をどのような環境で動かさなければならないのか
  • Constraints: 設計上の制限

Requirements should be:

  • Necessary：要求には理由がないといけない
  • Quantitative：数値のような量的な基準がなければならない
  • Verifiable：数値・条件で明確に評価できなければならない

新出用語:
EPS: Electric Power System
BOL: Beginning Of Life
↓
機能の割り当て
どのサブシステムがこれらの要求を達成するのか。
例）どの部品が地球との交信を担うのか
基本的に部品それぞれが明確な一つの役割を持っているためやりやすいことが多い。
↓
サブシステムの要求
どのような
↓
詳細設計
基本的な工学・応用科学の法則に基づいて設計。

  • Structural mechanics & vibrations
  • Electronics & EM
  • thermodynamics & heat transfer
  • Control theory & software

Use common techniques

  • Simple analysis/ calculation
  • CAD/ 3D Modeling
  • Numerical analysis & simulation

詳細設計がV-modelの底。ここから統合がはじまる。
↓
Subsystem Verification & Validation
それぞれのサブシステムを評価する。
↓
System integration
"Putting it all together"
サブシステムが干渉せず、互換性があることを確認する。

統合の際に確認する部分

  • Communication/ Data

例）そのフォーマットは対応しているか、ハーネス・コネクタはちゃんとつながるか

  • Functional

例）太陽パネルは十分な電力を供給しているか

  • Physical

例）物理的に接触している部分が緩んでいないか

  • Vibrational：

例）振動がサブシステムをどのように影響するか

  • EM Radiation

例）信号・電波が干渉していないか

  • Charge/Grounding

例）片側に電荷がたまったときにどうするか

  • Thermal

例）ある部品は低温に保たなければいけないかもしれない vice versa

Verification & Validation
Verification: "Does the design meet the specification?"
Validation: "Does the specification meet the mission concept?"

Verification methods:

  • Analysis:
  • Test: run the component
  • Inspection: measuring the hardware
  • Demonstration: test for software
  • Similarity: looking at similar systems that worked in the past