人工衛星を開発することが目的ではない
目的が手段になっているってよく聞く言葉じゃないですか。
人工衛星を作りたいから作った。
単純に作りたいから作っただけですと、作ることに専念してしまい、作った後どうするのか、目的を見失ってしまいます。
技術を証明するなら、1号機だけでいい。
では、2号機目はどうするのか。
もしそのプランができていなければ、2号機目を作り出す意欲が失われてしまいます。
1号機目であれば、勢いのまま、すべてを巻き込み進めることができたでしょう。
しかし1号機で知ってしまったんですね。
人工衛星の開発にはやっぱり時間とお金がかかってしまうこと。
1号機を開発した後の先を見据えていくことはとても大事です。
では、だれが見据えていくのでしょうか、システム設計者・システムエンジニアであり、プロジェクトマネージャーであったりするのではないでしょうか。
もちろん単一のプロジェクトではなく、継続する可能性が高いプロジェクトにおいてですが。
まあ、システムマネジメントの話は置いておきましょう。
ただ、ずっと先を見すぎていてもダメです。
人工衛星を開発していると、手前のことを忘れてしまいます。
一つはロケットです。
軌道へ運ぶロケットの存在は大事です。
ただ、ロケットは人工衛星の構造設計に関わるので、機械システムが気を付けていれば問題はありません。
もう一つは地上局、地上システムです。
人工衛星が軌道上から送ってくる電波を取得できる施設が必要です。
人工衛星の各機器に要求される機能・性能を追いすぎていて、システムインテグレーションを忘れてしまいます。
システムインテグレーションは人工衛星システムだけではありません。地上システムとのシステムインテグレーションもあります。
インテグレーションは簡単にいうと、ドッキングテストです。
お互いにうまく嚙合わせることができるのか、噛み合ったとして、想定通りのデータを吐き出すことができるのか、どんなエラーが考えられ、エラーが発生することを再現できるか、などを確認します。
その筋ではRF適合試験という電波の噛み合わせもその一つです。
地上システムとのインテグレーションもそうなのですが、人工衛星の運用も見ていかなければいけません。
人工衛星の運用は主に姿勢系が関わってきます。
あくまで関わってきているだけで、姿勢系だけが考えるものではありません。
構造系はもちろん、制御系、電力・電源系、通信系などたくさんのサブシステムが関わってきます。
その時に、システム設計者から忠告を受けてから直すのは、致命的なリスクを潜ませながら開発を進めるのと同じです。
サブシステム側も運用について学ぶとともに、システム設計者も情報を多く出し、共有していかなければいけません。
キーマンが少なければ少ないほど、次号機の開発は楽になりますが、技術の継承がされないと、2世代～3世代程度の人工衛星の開発で技術者が途切れてしまいます。
故に、人工衛星を開発することを目的とせず、データを取得し、どのような運用で進めるかを含めるといった目的をつけて進めた方がいいのではないでしょうか。
衛星屋は運用や地上システムに興味が薄い、のではなく余裕がない
地上システムの開発者からすると、人工衛星の開発側の人間が、運用に対してとても興味が薄く感じることがあります。
こんなに考えているのになぜ情報を出さないんだ、ってね。
この情報がでないと、どんなに致命的か分かっているのか、ってね。
一つの理由は手一杯で余裕がないのです。
自分の手の中に溢れすぎた課題・問題の数々に立ちふさがれてしまい、一歩ずつ進めるのが精一杯なのです。
地上システムは、詳細ではないのですが、人工衛星の動きの概要を知る必要があります。
人工衛星のシステム設計者にとても近い立場にいるのです。
運用を知らないサブシステム側からすると、突然知らない言葉で地上システムが攻めてくるように感じるのです。
これらは単純なコミュニケーション不足の良い例です。
それでも人工衛星が運用できているのは、お互いにマージンを取り、分界点を作り管理しているからです。
地上システムと衛星システム、両方を理解していけば、高い性能を生み出すことができると考えられないでしょうか。
あるいは、それぞれの不都合な部分を覆うだけの情報量を出せばいいのです。
一つの解が、多量の人工衛星を打上げることです。
地上システムにとって不都合な人工衛星は無視して使える人工衛星を使えばいいだけなのです。
壊れた人工衛星は論外ですが、不都合な人工衛星分を補う量の人工衛星があればいいのです。
不都合な人工衛星は電波が受信できるかできないかに分けられます。
言ってみれば単純作業なのです。
多くの人工衛星の運用は自動化に動いています。
静止衛星はもちろん、周回衛星も導入しています。
地上システムの運用も複雑でなければ機械的作業に任せればいいのです。
ちなみに複雑な運用というと、最近でいう探査衛星はやぶさ2や国際宇宙ステーション(ISS)が挙げられます。
通常運用を気にする地上系、緊急事態を気にする衛星系
どうも地上システムは通常運用を気にするのですが、人工衛星側が考えるのは緊急事態の運用ということが多いように思えます。
人工衛星側が緊急事態をメインで考えるのは、開発方式にあるのかもしれません。
システムエンジニアリングですと、リスクを上げて、リスクに対する対策を考えて進めていきます。
人工衛星の設計の前提に通常の運用があるのですが、通常の運用案は初期に考えられます。
そこで成立していれば、そのまま進めると意識が行ってしまい、開発が進んでいってしまいます。
実際は、概念設計、基本設計、詳細設計あるいは地上検証モデル、フライトモデル(打上げ完成モデル)で人工衛星の設計は変わっていきます。
設計の変更は、地上システムに影響があることを忘れてしまうのです。
アンテナの駆動速度以上に駆動する姿勢であったり、送信データに使用する時間の考え方の違いでいつまでたっても受信できなかったり、データの送信速度が合わなかったりするのです。
少し話が出た時間についても、人工衛星の中には衛星時間、地上時間、GPS時間を含めて、各コンポーネントでカウントしている時間など、時間だけでも悩むのです。
人工衛星はあくまで手段であり、目的は運用してデータを取得することを開発者は念頭に置いておかなければ、最後に破綻してしまう。
それが人工衛星開発なのです。(本当か？笑)
