往時宇宙飛翔物体 システム機械設計屋の彼是

往時宇宙飛翔物体 システム機械設計屋の彼是 宇宙blog

人工衛星の設計・製造・管理をしていた宇宙のシステム・機械設計者が人工衛星の機械システムや宇宙ブログ的なこと、そして、横道に反れたことを覚え書き程度に残していく設計技術者や管理者、営業向けブログ

【宇宙機と機能】人工衛星システムの機能ブロックは必要?

システムとサブシステムの役割の一つ

f:id:MSDSSph:20191112231854j:plain

提供:NASA

人工衛星に限らないかもしれませんが、大人数でプロジェクトを進める場合それぞれの機能を明確にしておく必要があります。

 

宇宙機でよくあるサブシステムの区分も機能をメインに置いて、宇宙機というシステムで必要な機能を明確に示しています。

これは複雑とも感じられる宇宙機の機能を専門家でなくともわかりやすく説明することに役立っていました。国主導のプロジェクトであるため、専門家でない人向けに説明するために分かりやすく説明するという面が強く出ていたのではないかと類推しています。

 

実際の仕組みはそれぞれのサブシステムが重なり合って、お互いの分界点と協力するべき部分が複雑になっていました。

 

ただ、機能を明確にすることで、プロジェクトのメンバーが途中で入ってきても概要の把握がしやすいという利点がありました。各サブシステムがどのサブシステムと密接に関わってきているか分かりやすいため、何をどこに、だれに聞けばいいか分かりやすい仕組みでもありました。

 

これは大人数で進めるプロジェクトであるため、少人数の場合は対面的に分けているだけで、実際は複数のサブシステムを同じ人物が切り盛りしているということもあるでしょう。逆に、複数のサブシステムを切り盛りしている人をシステム担当として人工衛星の全体を確認していく立場に据え置くようにしていきます。プロジェクトによりますが。

 

さて、サブシステムを担当する場合、サブシステム内の中で通常時や緊急時でそれぞれ対応できるように設計していきます。それはサブシステムに限らず、機器製作側にもあります。買い物と呼ばれる既製品の購入の場合は、提示されている仕様を人工衛星に搭載する前提で進める必要があります。プロジェクトを進める上で、既製品の機能で過不足ある部分はサブシステム側が取り持って機能を補完します。サブシステムの範疇を超える場合はシステムとして人工衛星全体で機能を補完します。

 

機器からサブシステムへ、サブシステムからシステムへ、さらに人工衛星システムから、地上局も含めたプロジェクト全体のシステムへそれぞれ機能を渡していくことはよくよくあることです。

 

この時に必要となるのは、機能分析となります。

 

人工衛星における機能ブロック図の必要性

f:id:MSDSSph:20191112232209j:plain

人工衛星に必要な機能分析を行うにあたり、ユーザーがいる場合は明確です。ユーザーからの要求を聞き出し、人工衛星に必要な機能を分析することです。

ユーザーがいない場合は、必要なニーズを分析するか、研究に基づいて必要な目標を洗い出していきます。

 

これはソフトウェアでよく言われる要求定義と同じです。

 

NASAJAXAのページでシステムエンジニアリングが提示されているのはこれが理由なんですね。

www.nasa.gov

ssl.tksc.jaxa.jp

 

システムが複雑になるほど、その機能も多種多様になっていきます。

機能ブロックは、サブシステムであったり機器がどの役割を担っているか機能を明確にしていくものです。

 

電気回路設計をしたことのある人であれば、部品を添えた部品ブロック図を作成することもあるかと思います。

部品ブロックは機能ブロックと必ずしも同じではないのです。

対外的にみると、その部品がどのような機能を持っているか分からない場合、ブロック図の全体像を理解できなくなります。各部品について一つ一つ聞いていくのも、各部品の機能を別に出しで明記していくことになり、ブロック図でまとめた効力を薄れてしまいます。

もう一つは、機能を上のシステムに移動させる場合、部品や機器を別のサブシステムに搭載するだけではなく、その部品や機器の持つ機能が重要になります。

 

別のサブシステムに機能を追加する場合、各サブシステムに全く同じ部品や機器を搭載するわけではないのです。別のサブシステムの特性にあった部品であったり、プログラムの内容、信号の出力方法、全く別の手段で同じ機能を再現するからです。

もちろん、同じ部品で同じ回路を搭載した方が、全体のリスクを考えても優位ですし、基本はその方向に動くかと思いますが、一度別のサブシステムに渡した機能がそんなに簡単に搭載できるともかぎらないのです。

 

システムの把握には、機能ブロック図のような概念的なものがないと理解の進みが悪くなります。

これは効率的というより、ブラックボックスとなる部分を減らし、リスクを回避するという面の方が多くなります。

 

機能を示し、各機能のブロックがどのように結びついているか明確になれば、軌道上の不具合も論理的に追いやすくなるということです。

機能ブロックの代わりに部品を置くと、不具合発生時に部品が故障したことは明確だが、その影響範囲がどのように及ぶかは、設計担当者の一握りしか分からなくなります。

設計担当者の一握りしか分からないと、不具合に対する対策案もその一握りの人しか案が出せなくなります。なんの機能が故障したのか分からなければ、他のサブシステムで対応可能なのか、その人の情報を待たなくてはいけません。

 

正直、とても時間の無駄になってしまうのです。

 

人工衛星は宇宙に出ていったら、ほとんど手を出すことができなくなります。故障が発生した時に素早く対応することが必要であれば、事前に素早く情報を共有できる土台を作っていた方が良いです。

 

もちろん人工衛星買い切りの場合、故障を切り捨てて、残った機能でどう人工衛星を活用していく場合は、また話は別かもしれませんが。