<?xml version="1.0" encoding="UTF-8" ?><rdf:RDF 
  xmlns="http://purl.org/rss/1.0/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xml:lang="ja">
  <channel rdf:about="http://w.atwiki.jp/komatsu/">
    <title>ISSL 新人教育情報共有うぃき</title>
    <link>http://w.atwiki.jp/komatsu/</link>
    <atom:link href="https://w.atwiki.jp/komatsu/rss10.xml" rel="self" type="application/rss+xml" />
    <atom:link rel="hub" href="https://pubsubhubbub.appspot.com" />
    <description>ISSL 新人教育情報共有うぃき</description>

    <dc:language>ja</dc:language>
    <dc:date>2008-01-18T14:22:56+09:00</dc:date>
    <utime>1200633776</utime>

    <items>
      <rdf:Seq>
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/2.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/14.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/19.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/7.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/4.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/44.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/22.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/43.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/41.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/komatsu/pages/42.html" />
              </rdf:Seq>
    </items>
	
		
    
  </channel>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/2.html">
    <title>メニュー</title>
    <link>https://w.atwiki.jp/komatsu/pages/2.html</link>
    <description>
          </description>
    <dc:date>2008-01-18T14:22:56+09:00</dc:date>
    <utime>1200633776</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/14.html">
    <title>７３号教室鍵のローテーションについて</title>
    <link>https://w.atwiki.jp/komatsu/pages/14.html</link>
    <description>
          </description>
    <dc:date>2008-01-14T00:05:05+09:00</dc:date>
    <utime>1200236705</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/19.html">
    <title>PDR</title>
    <link>https://w.atwiki.jp/komatsu/pages/19.html</link>
    <description>
          </description>
    <dc:date>2008-01-14T00:03:50+09:00</dc:date>
    <utime>1200236630</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/7.html">
    <title>次回の講習会内容と日程</title>
    <link>https://w.atwiki.jp/komatsu/pages/7.html</link>
    <description>
          </description>
    <dc:date>2008-01-13T23:55:53+09:00</dc:date>
    <utime>1200236153</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/4.html">
    <title>新人研修のページ</title>
    <link>https://w.atwiki.jp/komatsu/pages/4.html</link>
    <description>
          </description>
    <dc:date>2008-01-13T23:54:44+09:00</dc:date>
    <utime>1200236084</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/44.html">
    <title>2008年度トップページ</title>
    <link>https://w.atwiki.jp/komatsu/pages/44.html</link>
    <description>
      ＊＊ISSL 新人教育情報共有Wikiへようこそ！
-メールで送られてきたパスワードを用いてログインし利用してください。(ログインしない状態では、このトップページ以外は閲覧することが出来ません)
-Wikiはみんなで気軽にホームページ編集できるツールです。[[@wikiの基本操作&gt;http://atwiki.jp/guide/category2.html]]を参考にしてください。
-全てのページを全てのログインユーザが閲覧・編集できるようになっています。
-研修に関する情報は[[新人研修のページ]]から取得してください。できるだけ頻繁にチェックするようにしてください。
-研修内容の詳細については量が多いので、[[新人研修内容詳細]]として別立てのページを作成しています。

＊＊新人研修のページ
[[新人研修のページ]]:本サイトのメインコンテンツです。新人研修に関する全ての情報をまとめています。

＊＊新人研修内容詳細
[[新人研修内容詳細]]には研修内容の詳細が記載されています。

＊＊次回の講習会
[[次回の講習会内容と日程]]には次回の講習会の開催日時と日程に関する情報が記載されています。

＊＊堀研SNSサーバ
[[堀研提供のSNS&gt;http://nlab-sns.ai.rcast.u-tokyo.ac.jp:8080/?m=pc&amp;a=page_o_login]]にて、日々の活動の進捗報告をしてください。
詳細は[[ISSL SNS]]を読んでみてください。

＊＊中須賀研DAVフォルダ
[[中須賀研DAVフォルダ&gt;https://dav.space.t.u-tokyo.ac.jp/share2/新人研修/]]には新人研修の資料が全て保存されています。
すでにみなさんのアカウントを利用してアクセスすることが可能です。詳細は[[新人研修のページ]]。

＊＊その他にもいろいろな機能満載！！
-[[@wikiプラグイン&gt;http://atwiki.jp/guide/category17.html]]
-[[@wiki便利ツール&gt;http://atwiki.jp/guide/category32.html]]
-[[@wiki構文&gt;http://atwiki.jp/guide/category16.html]]

＊＊分からないことは？
-[[@wiki ご利用ガイド&gt;http://atwiki.jp/guide/]]
-[[よくある質問&gt;http://atwiki.jp/guide/category1.html]]
-[[@wikiへお問い合わせ&gt;http://atwiki.jp/guide/contact.html]]
等をご活用ください    </description>
    <dc:date>2008-01-13T23:48:17+09:00</dc:date>
    <utime>1200235697</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/22.html">
    <title>SMAD勉強会の記録</title>
    <link>https://w.atwiki.jp/komatsu/pages/22.html</link>
    <description>
      *SMAD勉強会の記録
新人研修プログラムのSMAD理解の攻略ページです。
これから勉強会を重ねて理解が深まり次第、ページを更新していきましょう。


新人研修SMAD会は4/30(月)の19時スタート、場所は大学院講義室の予定だそうです。


**1章　宇宙ミッションの分析と設計のプロセス
衛星開発全体の流れについて
object（なにをするか）とmission concept（それをどうゆう方法や機能で達成するか）を最も安価に達成する過程をまとめている。
・[[１－１]] 序論と概要
・[[１－２]] 宇宙ミッションのサイクル
・[[１－３]] ミッション目的の定義
・[[１－４]] ミッションの需要、要求、制約の初期推定
　文責　田中
**[[2章　ミッション特性の決定]]
・2.1　ミッションコンセプトの洗い出し
・2.2　ミッション構成を決める
・2.3　システムドライバーを決める
・2.4　システム構成の特性決定
・[[2章　ミッション特性の決定]]ページへ
　　文責　清水　(特に後半は乱雑です)
**[[3章　ミッション評価]]
・3.1　Driving Requirementsの洗い出し 
・3.2　ミッション分析 
・3.3　ミッションの有用性の評価
・3.4　ミッションコンセプトの選定
・[[3章　ミッション評価]]ページへ
　　文責　清水　(大雑把なので気付いたことがあれば追加してください)
**4章　要求の定義
・4.1　システム開発における要求の役割
・4.2　要求分析と性能割り当て
・4.3　要求明細書 
・4.4　まとめ 
・[[4章　要求の定義]]ページへ
　　文責　清水　(話し合い前)
**5章　宇宙ミッションの幾何学
・5.1　天球上の幾何学の序論
・5.2　宇宙から見た地球の幾何学
・5.3　地上の受信者から見える衛星の軌道
・5.4　地図作成と指向精度のデータ貯蓄の発展
**6章　天文学の序論
・6.1　ケプラー軌道
・6.2　軌道摂動
・6.3　軌道制御
・6.4　打ち上げ可能時間帯
・6.5　軌道補正
・[[6章　アストロダイナミクスの序章]]ページへ
**7章　軌道と配置の設計
・7.1　軌道設計プロセス
・7.2　地上適用範囲
・7.3　速度増分割り当て
・7.4　地球参照衛星の軌道選定
・7.5　Transfer軌道、Parking軌道、宇宙参照軌道の選定
・7.6　配置(布陣)設計
**[[８章　宇宙環境と生存能力]]
・8.1　宇宙環境
・8.2　過酷さと生存要求
・[[８章　宇宙環境と生存能力]]ページへ
　　　文責　三川
**[[9章　ミッション機器の設計とサイジング]]
・9.1　ミッション機器の種類　
・9.2　ミッション機器の設計とサイジングの概要
・9.3　対象の選定
・9.4　観測ペイロードの概要
・9.5　可視、赤外線観測ペイロードの設計
・9.6　ペイロードのサイジング
・9.7　FireSatのペイロード
・[[9章　ミッション機器の設計とサイジング]]ページへ
　　　文責　清水
**[[10章　衛星の設計とサイジング]]
・10.1　要求、制約と設計プロセス
・10.2　衛星の構成
・10.3　設計リスト(？)
・10.4　衛星のバスの設計
・10.5　衛星設計のイタレーション
・10.6　例
・[[10章　衛星の設計とサイジング]]ページへ
　　　文責　三川
**11章サブシステム
・11.1　ADCS系
・11.2通信系
・[[11.3　C&amp;DH系]]
　　　　文責　清水
・[[11.4　電源系]]
　　　　文責　清水
・11.5熱系
・11.6構造系
・11.7航法系

**[[12章　衛星製作と試験]]
製作、試験の流れ上の注意事項などが書いてある。また信頼性設計についての記述もある。
・12.1　Engineering Data(技術資料) 
・12.2　高信頼の機器を作る 
・12.3　検査と品質保証 
・12.4　認定計画
・12.5　認定試験の流れ
・12.6　打ち上げ場での作業
・[[12章　衛星製作と試験]]ページへ
　　文責　清水
**[[13章　通信の基本設計概念]]
・13.1　通信機器
・13.2　データレート
・13.3　リンク設計
・13.4　機器のサイジング
・13.5　特記事項
・[[13章　通信の基本設計概念]]ページへ
**14章　ミッションオペレーション
・14.1　ミッションオペレーションの概要
・14.2　衛星のオペレーション
・14.3　職員の訓練
・14.4　ミッション計画
・14.5　工学的補助
・　[[第十四章：ミッションオペレーション]]
**15章　地上局の設計とサイジング
・15.1　地上局の設計プロセス
・15.2　地上システムの基本要素
・15.3　典型的な地上局
・15.4　専用システム構造物の代わりになるもの
・15.5　設計における重要な点の考察
・　[[１５章]]：地上システム設計のページへ　
　文責　田中
**16章　衛星のコンピューターシステム
・16.1　要求の配分
・16.2　CPU資源の推算
・16.3　開発、試験、統合
**17章　宇宙推進システム
・17.1　推進系の選定とサイジング
・17.2　ロケット推進の基本
・17.3　ロケットの種類
・17.4　構成要素の選定とサイジング
・17.5　多段化
**[[18章　打ち上げシステム]]
・18.1　基本的な打ち上げロケットの考察
・18.2　打ち上げシステム選定プロセス
・18.3　衛星設計外装設計と環境の決定
・[[18章　打ち上げシステム]]ページへ
　　　　文責　清水
**19章　宇宙算術と信頼性
・19.1　宇宙算術
・19.2　宇宙ミッションコンセプト吟味中の信頼性
**[[20章　コストモデリング]]
・20.1　コスト分析の序章
・20.2　数値的コスト推定プロセス
・20.3　コスト推定の関係
・20.4　その他の話
・20.5　FireSatの例
・[[20章　コストモデリング]]ページへ
　　文責　荒堀
**21章　ミッション設計の限界
・21.1　考察の原理と方針
・21.2　軌道デブリ―人災
**[[22章　低コストの衛星の設計]]
・22.1　低コストの宇宙システムの設計
・22.2　小型宇宙システムの能力と適合性
・22.3　小型化した衛星技術のFireSatへの適用
・22.4　大きいシステムから小さいシステムへの設計
・22.5　低コスト宇宙システムの経済性
・22.6　低コスト宇宙システムの注釈つきの関係書目
・[[22章　低コストの衛星の設計]]ページへ
　　　一部抜粋　文責　清水
**終章　SMAD(宇宙ミッションの分析と設計)の適用
・E.1　SMADの後期ミッション時期への適用
・E.2　現存する宇宙計画から学べること
・E.3　将来の傾向    </description>
    <dc:date>2007-04-30T02:14:50+09:00</dc:date>
    <utime>1177866890</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/43.html">
    <title>22章　低コストの衛星の設計</title>
    <link>https://w.atwiki.jp/komatsu/pages/43.html</link>
    <description>
      *&amp;size(150%){22章　低コストの衛星の設計}
　・小型衛星(miniture satellite)とは一般に200kg以下
　・最近の進歩は目を見張るものがある。
　・低コスト、単開発サイクルが売り。
**&amp;size(120%){序章：小型衛星の歴史}
　・&#039;&#039;初期の宇宙システム&#039;&#039;　　～1965
　　　・打ち上げロケットの性能のため、重量が限られていたため、小型
　　　・Telestar…衛星中継TV
　　　・VELA…地球観測衛星。
　　　・OSCAR(Orbiting Satellite Carrying Amateur Radio)…5kg
　　　・その他軍事衛星など。
　　　・このころの開発期間は1年半程度
　・&#039;&#039;小型衛星技術の継続適用&#039;&#039;　1965～1985
　　　・世界では月着陸などが出来るほどの大型推進が可能となり、衛星大型化の一途
　　　・一方でラジオ衛星が発展を続けていた。
　　　・大きな進歩として太陽電池による電池の充電が可能となる。それにより寿命が大幅増
　　　・また、一方でヨーロッパや日本などが宇宙分野に乗り出し小型衛星からはじめる
　・&#039;&#039;近代低コストシステム&#039;&#039;
　　　・OSCARシリーズは10、11までなりかなり信頼性の高いものとなっていた。
　　　・革新的技術として&quot;degital store and forward commnication&quot;。
　　　　　データを保存して好きなときに受け取ることが出来る。これにより世界規模の
　　　　　メールシステムのようなサービスが可能に。大型衛星では不可能なサービス。
　　　・時を同じくしてNASAが&quot;Get Away Special&quot;と呼ばれる、小型(&lt;68kg)なら低コストで宇宙まで
　　　　　運んでくれるサービスを開始。安定性のためのweightの代わりに搭載する
　　　・低コスト、Get Away Specialで打ち上げられる制限内でのバスの高性能化、store and forward 
　　　　　により、小型衛星も航空宇宙産業の本流に戻ることとなる
　　　・ALEXIS…X線顕微鏡実験衛星。45kgの高性能バスを実現。
　　　・この時代の小型衛星は10年前の大型衛星と同じ働きをするほどになっていた。
　　　・一方で一般的な衛星は、機器の小型化にもかかわらず全重量を増やし続けていた
**&amp;size(150%){22.1　低コストの宇宙システムの設計}
　　・小型化技術とは、ミッション要求を最小化することで打ち上げコストを抑えている
　　・小型衛星ではどうしても応えられないミッション要求もある
　　・単位重さあたりの打ち上げ費は一般の10～20倍安い。
　　・ミッションリスクは増えるが、それにより節約できるコストは大きい。
　　　大きなコスト、重量層に繋がる冗長設計はクリティカルな所にしか組まない。
　　　それでも実際、かなりの成功記録がある(AMSAT)
　　・開発チームも少人数で済むため、情報共有などがしやすい。各部に所属している人が一人なら情報伝達の
　　　手間が省ける。しかし、全ての人が重要なので一人でも欠けると痛手となる。
　　・運用を出来るだけユーザーサイド(たとえば個人PCなど)にさせるようにするべき。人手不足を解消するため。
　　　そのために運用の単純化をする。
　　・開発期間が少ないため、ちょっとの開発遅れが大幅なコスト増に繋がるためスケジューリング管理が重要になる。
　　・品質管理は全員で補助的にする。重要視するべき項目を絞って重点的に見る。
　　・コンポーネント選択の基準は、以下の4つ
　　　　・それのエラーがミッション失敗を意味するか、あるいは精度を落とすだけか
　　　　・宇宙環境のシミュレーションがどれだけ正確に出来るか
　　　　・それを使わないことによるコスト(性能、資金)はどれだけか
　　　　・それにより目標の信頼性に達することが出来るか
　　・コスト削減のためとはいえ、試験をしないのはリスクが高すぎる。致命的なところの試験と
　　　全機能試験だけをすることで簡易的に信頼性を確かめる。
　　・小型化したCPUは物理的な条件を補佐してはくれないため、そこは単純化により補う。　　　
**&amp;size(150%){22.2　小型宇宙システムの能力と適合性 }
&amp;size(150%){22.2.1　小型宇宙システムの性能}
・姿勢安定
　　　・小型衛星では三軸制御は既にあきらめている。
　　　・もっとも単純なものが「制御しない」。低軌道で地上へのデータレートも低いならこれで十分。
　　　・地球への指向性が欲しいならGG(Gravity Gradient)。受動的でほとんど何もいらない
・電力
　　　・以下のことにより要求は小さいと思われる
　　　　　　・いろいろな効率的な方法を組み合わせて使える
　　　　　　・軌道が低いため地上へのリンクが少ない
　　　　　　・表面積が体積に比べて比較的大きくなる
　　　・一般にソーラーパネル＋NiCd or鉛酸二次電池。
　　　・リスクが少ないためフルタイムデジタル充電制御など新技術が試せる
・通信
　　　・情報が安い。100万ドルで中央処理装置数個並みのデータを供給できる
　　　・１PASSの間で、たった５Wパワーで１Gbitものデータを供給できる
・打ち上げ
　　　・大型衛星の余った空間や重量を使った輸送は劇的に安い
　　　・PegasusやScout、Conestogaといった小型ロケットの余剰スペースに載る場合は制約が厳しくなる
　　　・STS、GAS、CSCPに基づく場合、コストに管理費が含まれるため、少し高くなる。
　　　・Ariane、Deltaはペイロードの宣伝のために打ち上げ空間を提供するためたくさんの小型衛星を積む。
&amp;size(150%){22.2.2　小型、低コストシステムの台頭}
　　・小型衛星技術はCPUとメモリの小型、省電力化によるものが大きい。
　　　　最近の8.5kgの諸機能は15年前の500kgのものより高い。
　　　　一方、放射線の集積回路への影響が大きな問題となってきた。ここにはまだ発展の余地がある。
　　・通信機、ビーコン、熱制御機器、姿勢制御機器などの電力消費は小さくなりにくいため、要求として残る。
　　　　それに対して、太陽光発電の効率アップや充電効率アップで対応してきた。
　　・光学系ミッションの要求に対しては焦点面制御やデータ圧縮技術などで小型でも高性能が出せる。
　　・自動化が進み、一種のロボットのようになっている
　　・軌道上分散ネットワークを利用したミッションなど小型衛星に適したミッション要求も出てきた
・まとめると、あらゆる技術進歩(情報、固体情報検知、自動化、電力)が小型衛星技術に繋がった
&amp;size(150%){22.2.3　潜在的機能}
　　・最初は多数(400個)のランダム軌道小型衛星による全世界監視。軍事目的。迎撃難。
　　・小型衛星による安価な光学写真ミッション。
　　・AMSATと公共あるいは政府機関との合同による小型静止軌道衛星。リアルタイム通信の補佐や
　　　　ごく小規模ユーザーに対する静止軌道衛星サービス。
**&amp;size(150%){22.3　小型化した衛星技術のFireSatへの適用 }
**&amp;size(150%){22.4　大きいシステムから小さいシステムへの設計} 
　　・長さをある割合で小さくすると、面積は2乗小さくなり、体積は3条小さくなるという話
　　・電力において、消費電力を重さ(体積、3乗)に比例するとすると、発生電力は面積(2乗)に比例するため有利。
　　・熱環境において、熱容量は体積比例なので、大きいと距離に対して3乗倍の温度差が発生する。
　　・構造において、加重は体積(３乗)に対して、強度は圧力の２乗比例で小さいほうが有利
　　・一方、どうしても小さくならないバス機器もあるため、ミッション系に割かれる重量の割合が小さくなる
**&amp;size(150%){22.5　低コスト宇宙システムの経済性}
**&amp;size(150%){22.6　低コスト宇宙システムの注釈つきの関係書目}


　　　　　　    </description>
    <dc:date>2007-04-30T02:12:13+09:00</dc:date>
    <utime>1177866733</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/41.html">
    <title>第十四章：ミッションオペレーション</title>
    <link>https://w.atwiki.jp/komatsu/pages/41.html</link>
    <description>
      **第十四章　ミッションオペレーション
*序章
mission operationとは衛星の制御やデータ配信、はたまたその計画作成をふくむ一連の活動である。（Fig14-2を見ると良く分かる）
以後そのままmisson operationという言葉を使います。（和訳しないほうが感覚的にいい気がする）

misson operationは衛星の生涯コストに大きく影響します。
misson operationの要素をしっかり理解することでコスト削減や、効果的なオペレーションを達成できます。
misson operationのコストと複雑さは、人、自動化の度合い、ソフトウェアの量が大きく影響されます。
１４－１はミッションの複雑さがコストや効率に大きく影響される話。
１４－２は現在の衛星運用についてのまとめ
１４－３は人員育成について
１４－４は衛星運用のプランナーについての話
１４－５は工学的補助についえの要求のまとめ

table14-1は全てのまとめであろうスタッフレベルとmisson operationのコストを見積もる過程がまとめられてあります。

まあここからはつれづれと書いてある順に書きます。

*14.1　ミッションオペレーションの概要
misson operationの主な要素は以下の三つ
衛星のバスの命令、制御を行うチーム
要求を活動に落とし込むプランナー
衛星を健康にたもち、データをユーザの要求に合わせる技術スタッフ
である。
Fig14-1にそれらの人々の義務がのっています。

そのあとの段落には
早期の衛星のミッション決めフェーズで決定したことがいかに運用のコストや効率に影響するかということが書いてあります。

衛星ミッションの主な要素は、
衛星デザイン
地上局のシステムデザイン
misson operation
です。
それらの要素をトレードし、イタレーションすることで衛星のコストやミッションの成功率の改善につながる。

今後の議論をするために衛星を三つのタイプに分けてtable14-2にまとめてある。
これらを分けて議論することで衛星の複雑さやmisson operationのサイジング（チーム編成など）がやりやすくなります。。

*14.2　衛星のオペレーション 
衛星のオペレーションとは衛星への制御と命令をつかさどるチームの全ての活動を含みます。
このセクションでは特に衛星のオペレーション活動について述べられており、ミッションの予算や効率に大きく響く要素を確認します。
衛星オペレーションの流れはFig14-2にまとめられてあり、コレを見れば分かるように打ち上げ前から打ち上げ後にまで及びます。

オペレーションチームの話
オペレーションチームの構成を決定する主な要素は
・衛星の活動の量および複雑さ
・コマンドおよび取得のスケジューリング
・衛星が見える時間の長さ
・チームメンバーの教育
・チームメンバーのクロストレーニング（二分野にわたる教育）
・道具や資源
これらの要素をかんがみて、かつtable14-3を選考にしてチームの構成や要求を決定します。
衛星とサブシステムが複雑になればなるほどオペレーションは高くつき、チームのメンバー変更に敏感になっていく。

衛星の見える時間についての話
Fig14-3にも示されているようにパスによってオペレーションは大きく変わる。
我々はtable14-3をオペレーションチームの設計をするガイドとして用いる。

複数の衛星を運用する話
一つの地上システムで複数の衛星を運用するときのオペレーションの変化。

以上のことをふまえてチームの構成が決定したらどれだけのチームを配置するか、システムの自動化も候補にいれつつ決定していく。
table14-4がチーム数を変化するとき、条件がどのように変化するかの例。

その後モニターやテレメの送信の自動化、知識獲得方コンピュータが紹介され、このへんの自動化も含めてトレードしようと書いてある。
自動化することによるメリット（テレメを早く反応して送信できる、疲れているときに良い）がつらつらと書かれてあった。

今までの部分は衛星のバス系についての話で次からはペイロードのモニターとコマンドの話。
バス系のほうが優先順位が高い。
ペイロードのオペレーションにおいて注意するのは、
健康状態を保つ、コマンド、データの取得配信
である。
データをダウンリンクする話が書いてある。
データの貯蓄容量が増えている。

まとめ
衛星の動向を調べるとはオペレータが衛星や他のポジションを知る訓練としてよい。
またオペレータとエンジニアの意思疎通ができ、チームの士気があがる。

*14.3　職員の訓練 
ここはさらっと。
Table14-5に衛星の飛行中に起こることとどうやって解決してきたかが述べられている。
オペレーターには
テレメ
コマンドを送る過程
コミュニケーションのプロトコル
緊急事態の対策
衛星と地上局の容量と制限
衛星が軌道に入る前の入ってすぐの運用のプラン
を理解させるのが最終目標。

あと衛星運用のトレーニングにはシミュレーターを使うとよいとかそんな話。

*14.4　ミッション計画をする
ミッションを計画するとはその通りミッションを計画すること。
（この章ではオペレーション的な側面がつよいか。）
我々はミッションプランニングを通して様々な要求を実際のオペレーション活動に落とし込まないといけない。
衛星の開発戦略とユーザからの要求、オペレーションチームの特性、地上設備を帳尻合わせるように計らう。
ミッションプランニングはmisson operationの最初の要素となる。

以下すこし具体的な話

地上システムを選定する話
使う地上システムをプランニング
これは[[１５章]]でもあるが出来合いのシステムをつかうか新しく使うか

衛星の位置決めについての話
日々の運用で必要な衛星の姿勢や位置決めをランニング
スターセンサを用いることが多いが、目的の軌道のスターセンサのファイルを作る必要がある。
また衛星の姿勢を現すハウスキーピングデータもいる。

ペイロードのプランニング
バス系と異なり、ユーザの要求によって左右される。
ユーザの要求に対応したコマンドファイル、アップリンクの設計。
ペイロードの運用もバスと同じく一つの衛星を運用するか、複数の衛星を運用するかで大きく変わる。
ただバスの運用に重きをおくのでペイロードへのユーザの要求は満たせないこともあってよい。

*14.5  技術者として衛星の運用をサポートする
engineering supportの目的は衛星と地上局システム運用をユーザの要求に合わせること。
技術者は取得されたテレメを解析し、衛星のコンポーネントとサブシステムの動きに仮説をたてることで上記のことを達成する。
つまりこの章で述べられている工学的補助とは運用データから情報を読み取り、ユーザの要求に答えれるように衛星を運用することである。
このセクションでは工学的補助がどのようにmisson operationに関わっているか、そしてどのようにコストを減らすかが書いてある。

基本的にengineering supportは衛星の機能を調べる。
バッテリーの残量や軌道など重要。

衛星の軌道変更、維持
かなりの自動化が進んでいる。
コンピュータの計算したコマンドを他のツールで評価し、プランナーがコマンドファイルをつくる。
それを仲間が衛星のモニタリングをしながらタイミングを指示し送る。

地上局の維持
衛星と異なるのは直接アクセスできること。
主にソフト分野で技術者がいることが重要。

軌道上での衛星の回復、修正
最近engineering supportとして行われている例もあると紹介されていた。

まとめ
長期にわたって衛星を運用する場合はengineering supportが重要。
高度な技術者を育成するのは確かにコストがかかるが、衛星に機能を沢山持たせるよりはコストが下がる傾向にある。
ドキュメントをしっかり残すこと、技術者の配置、それに伴う権限の分担がコストや効率に大きく影響する。
技術者が異常を発見し、修正、していくことが長期運用の秘訣である。    </description>
    <dc:date>2007-04-29T02:41:00+09:00</dc:date>
    <utime>1177782060</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/komatsu/pages/42.html">
    <title>10章　衛星の設計とサイジング</title>
    <link>https://w.atwiki.jp/komatsu/pages/42.html</link>
    <description>
      *&amp;size(150%){10章　衛星の設計とサイジング}

*&amp;size(150%){10.1 要求条件、制約条件と設計プロセス}
・スタートは要求条件と制約条件のベースライン作り(Table10-3)
　→各章のロードマップ的なもの
・初期段階における設計決定やトレードオフ(Table10-4)


*&amp;size(150%){10.2 宇宙機の構成}
・設計アプローチを決定→全体配置→サブシステムの性能割り当て
　→イタレーションで詳細配置決定
・２つの方法論
　①Top-down方式：全体設計→設計要求割り当て
　②Bottom-up方式：詳細設計を統合→設計要求割り当て
・Configuration driver：宇宙機構成の決定因子(Table10-5)
　→ココには宇宙機のコンポーネント設計の概算方法もあり。
・宇宙機のサイズの決定方法：Table10-6
・Fig.10-1に様々な宇宙機の構成が紹介されている。
　・太陽電池アレイの搭載方法：①筐体上　②パネル上
　　→初期構成では電力要求と筐体上に十分な面積をとれるかを確認。→10.3
　・姿勢制御ではバスとペイロードの両方の指向性から考える。→10.4.2
　　→各機器は２軸を制御することにより１つの明確な方向性を持つ。
　　ex）Spin stabilization：シンプルで堅牢な制御方法(ロバスト)。
　　　　(Dual-spinでは逆方向に回転するPlatform部を持つ。)
　　→姿勢制御方式は太陽電池アレイの設定にも影響する。
　　　→スピン制御：筐体上
　　　　３軸制御：パネル上　...
　・慣性モーメントを増加させるブーム：重力傾斜制御

*&amp;size(150%){10.3 設計Budget}
・Budget：そのコンポーネントの設計におけるあらゆるパラメータのリスト。(P.4参照)
・推進剤Budget作成
　・軌道維持などの速度変化や姿勢制御への推進剤要求を評価することで作成する。
　・典型的な４つの要素：①速度制御用　②姿勢制御用　③マージン(～25%)　④残余(1～2%)
　　→Table10-7を参照。(ロケット方程式：速度増分→推進剤質量)
・電力Budget作成
　・ペイロードの電力要求をバスの電力推算に加味して電力Budgetを評価する。
　・電力Budget作成のアウトライン(Table10-8)
　　→①作動電力Budgetを用意(Table10-9)→ペイロードやサブシステムに必要な電力を推算。
　　　　→作動モードがいくつかある場合は別個に推算。
　　　　→必要最大電力(Peak power needs)に注意！
　　　②電池サイジング：電池寿命や電力要求から電池容量の選定
　　　③ミッション期間中の電池劣化を評価。
　　　　→BOL電力はこれを考慮に入れる！
　　　　→劣化は軌道高度や放射線環境に依存する。(静止軌道で30%/10years)
　・充電電力要求も考慮する。(10.4.6)
・重量Budget作成
　・ペイロードの重量要求をバスの重量要求に加味して重量Budgetを評価する。
　・宇宙機重量の足し合わせ方法：Table10-10
　　→ペイロード重量：宇宙機ドライ重量の15～50%
　　→構造重量：投入重量の8～12%
　　→熱系重量：ドライ重量の2～5%
　　→その他の系は詳細情報がないと推算できない。(10.4.3、17)
　　→これらの25%を未知の新機器用に付加しておく。
　　→統合時に発生する余分な重量のために1～2%のマージンも必要。
・信頼性Budgetの作成
　・宇宙機の許容性能と許容寿命の達成可能性を決定することで評価する。
　・概念設計時に信頼性設計はスタートする。(Table10-11)
　　・４つのステップ
　　　①ミッション達成基準を設定。
　　　②基準の各要素を満たせる可能性を数字で決める。この計算の基本原則を選定する。
　　　③H/WとS/Wに信頼性要求を割り当てる。
　　　④システムの信頼性を評価し、イタレーションで最大化する。
　　　　また、いつ失敗するかを洗い出し排除していく。(10.5.2)

*&amp;size(150%){10.4 宇宙機のバス設計}
ココはサブシステムの話のようなんで省略。
10.4.1 推進系
10.4.2 ADCS
10.4.3 通信系
10.4.4 C&amp;DH系
10.4.5 熱系
10.4.6 電源系
10.4.7 構造系


*&amp;size(150%){10.5 宇宙機設計の統合}
&amp;size(150%){10.5.1 宇宙機サイズ}
・筐体体積、面積などの簡易推算方法→Table10-29
・密度の平均値：79kg/m3 (20～172kg/m3)
・太陽電池アレイ面積の推算→10.4.6
　→慣性モーメントが著しく増加する。
　→さらに全投影面積に影響を与え、空力的抵抗や太陽風圧に対する推算にも影響する。
　→これらの関係はTable10-30を参照。
&amp;size(150%){10.5.2 寿命と信頼性}
・信頼性は設計者がコントロールできるパラメータである。
　→故障する場合を認識し、許容レベルまで故障を制限できる(あるいは除去できる)ように設計を調整する。
　→①消耗品を明確にする。
　　②故障のミッションへの影響を考慮し、単一故障点を除去する。
　→統計学的にミッション達成可能性を計算し、許容レベルに落とし込む。
　　(このプロセスは正確ではないが、有用である！)
・達成基準をより明確に、より数値的にすることで、より容易に設計要求に盛り込むことができる。
・Single-string reliability model
　→成功するために必要な設備や機能の最小構成要素をリスト化する。
　→これをブロック図に示す。
　→これは多くの場合、１本道で表されるはずである。
　→詳細設計段階で、別の道やバックアップ用の道を足していく。
　　(このとき、信頼性の強化とコストの増大に気を配る！)
・より信頼性のある機器を作るには？
　→認識対象をある仕様書部に限定し、設計にストレスをかける。
・故障曲線は「バスタブ型」である。
　→初期は故障率が高い。(by &quot;Infant mortality&quot;)
　　対策：慎重な製作、試験、導通テスト(Burn-in)
　→EOL付近では消耗によりまた故障率が上昇する。
　　対策：消耗品は十分なバックアップを搭載する。
　→この間の故障は主にランダム的な要素による。
・「良い設計」：ある程度故障に耐え、劣化しても機能を果たすことができること。
・Failure Modes Effects and Critically Analysis(FMECA)
　→故障し得る機器を認識し、その効果を分析する方法。
　→ポイントは単一故障点の洗い出しと除去。
　→除去できない場合は、発生確率を制御できなければならない。
・故障モードの分析方法
　ex) All-part method：宇宙機の各パーツの故障の影響を調べる方法。
　　　→正攻法で効果があり、行いやすい。
　ex) Jury method：失敗談を先人から聞き、同様の失敗を未然に防ぐ方法。(Jury：陪審員)
　→打ち上げから展開、テレメトリで故障を検知しコマンドで修正するという一連の流れをシミュレーションするのも効果的！    </description>
    <dc:date>2007-04-29T00:53:34+09:00</dc:date>
    <utime>1177775614</utime>
  </item>
  </rdf:RDF>
