JP6362529B2 - 観測要求管理プログラム、観測要求管理方法、および情報処理装置 - Google Patents

Description

本発明は、観測要求管理プログラム、観測要求管理方法、および情報処理装置に関する。

地球の周囲を、各種の人工衛星が周回している。人工衛星には、カメラやセンサなどの観測機器が搭載されている。人工衛星は、観測機器を用いて、宇宙や地球などの観測対象を観測する。例えば地球観測衛星は、地球から発せられる電波、紫外線、可視光などを観測することができる。

人工衛星の中には、地球観測衛星のように、国の機関や研究機関など、様々なユーザが利用できるものがある。各ユーザは、自身の使用するコンピュータを用い、人工衛星を用いた観測に関する観測要求を、人工衛星を管理するセンタのサーバに送信する。センタでは、受信した観測要求が競合しないように調整を行い、観測要求に応じた観測を実施するように、人工衛星に命令を送信する。

人工衛星は、命令に従って観測機器による観測を行う。そして人工衛星は、観測によって得られたデータを、地上の受信局に送信する。地上では、受信局が受信したデータを、観測要求元のコンピュータに送信する。

なお多くのユーザが人工衛星を使用しようとすると、使用する人工衛星のリソース（資源）の競合が生じる。競合が生じるリソースとしては、例えば人工衛星から受信局への通信リソースがある。すなわち人工衛星と受信局とが交信できるのは、人工衛星が受信局の頭上の一定の範囲内にある期間に限られる。そのため、人工衛星から受信できるデータ量に制限がある。人工衛星に対する観測要求が大量にあると、すべての観測要求に応じた観測結果を、受信局で受信できない場合がある。そこでセンタでは、観測要求を送信したユーザの優先度などに基づいて、実行する観測要求を決定している。

なお、競合が発生したときの調整技術としては、例えば全タスクを対象として優先度をより細かく調整可能な通信端末装置が考えられている。またデータ通信の調整に関する技術として、ノードが次に要求する伝送データの転送量を親局に事前に送信することにより、帯域幅制御をダイナミックに行える集中制御方法がある。

特開２００９−１３０７０８号公報 特開２００４−１５８９６５号公報

人工衛星を用いた観測の観測要求数が過大となったとき、ユーザの優先度により競合解決を行うと、常に優先度の高いユーザの観測要求が実行対象として採用されることとなる。この場合、優先度の低いユーザは人工衛星を利用した観測ができない。そこで、ユーザの優先度に応じて、各ユーザが使用できるリソース量を先に決め、各ユーザについて予め決められたリソース量の範囲内で実行可能な分の観測要求を実行対象とすることも考えられる。しかし、この場合、優先度の高いユーザの観測要求を確実に実行しようとすると、優先度が高いユーザへのリソースの配分比率を高くすることとなり、優先度が低いユーザには極少量のリソースしか配分できない。その結果、優先度が低いユーザの観測要求を十分に実行することができない。

１つの側面では、本件は、優先度が低いユーザが使用可能なリソースの割合を高めることを目的とする。

１つの案では、以下の処理をコンピュータに実行させる観測要求管理プログラムが提供される。コンピュータは、まず複数のユーザそれぞれについて、使用が許容される人工衛星のリソース量を示し、人工衛星を使用する優先度が高いユーザほど大きな値の、使用許容量を算出する。次にコンピュータは、複数のユーザからの複数の観測要求に基づいて、複数のユーザそれぞれが使用を要求するリソース量を示す要求量を算出する。そしてコンピュータは、要求量が使用許容量以下である第１のユーザにおける該要求量と該使用許容量との差分に応じた値を、要求量が使用許容量を超えている第２のユーザの該使用許容量に加算する。

１態様によれば、優先度が低いユーザが使用可能なリソースの割合を高めることが可能となる。

第１の実施の形態に係る情報処理装置の例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 人工衛星からデータを送信できる期間の例を示す図である。 サーバのハードウェアの一構成例を示す図である。 サーバのリソース配分機能を示すブロック図である。 ユーザ情報記憶部の一例を示す図である。 観測要求記憶部の一例を示す図である。 観測要求による観測期間と観測領域との一例を示す図である。 観測計画記憶部の一例を示す図である。 観測手順の一例を示すシーケンス図である。 リソース割り当て処理の手順の一例を示すフローチャートである。 調整前の要求量と配分量とを示すグラフである。 ユーザの余裕量を示す図である。 再定義された配分率曲線の例を示す図である。 新たに余裕が生まれたユーザの例を示す図である。 ２度目の再定義後の配分率曲線の例を示す図である。 調整対象のユーザの観測要求の例を示す図である。 優先度の調整範囲を示す図である。 リソース割り当て結果を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る情報処理装置の例を示す図である。情報処理装置１０は、コマンド送信／データ受信局２を介して人工衛星１と交信できる。人工衛星１は、例えば地球観測衛星である。人工衛星１には、観測機器が搭載されており、情報処理装置１０からの命令に従って、地球または宇宙空間の観測を行う。

情報処理装置１０は、ユーザからの観測要求に応じた命令を人工衛星１に送信し、人工衛星１に観測を行わせる。ユーザから大量の観測要求を取得した場合、情報処理装置１０は、人工衛星１のリソースをユーザに分配し、各ユーザに分配されたリソースの範囲内で、そのユーザの観測要求の実行を許可する。情報処理装置１０は、リソースを分配する際に、優先度の低いユーザに対しても、できるだけ多くのリソースが割り当てられるようにするため、以下のような記憶部１１と演算部１２とを有する。

記憶部１１は、人工衛星１を使用する複数のユーザからの複数の観測要求３ａ，３ｂ，・・・を記憶する。複数の観測要求３ａ，３ｂ，・・・は、例えば観測対象の領域ごとに発行される。

演算部１２は、複数のユーザそれぞれについて、使用が許容される人工衛星１のリソース量を示し、人工衛星１を使用する優先度が高いユーザほど大きな値の、使用許容量を算出する。各ユーザの使用許容量の合計は、人工衛星１が提供するリソースの総量である。使用の対象となるリソースは、例えば人工衛星１からのダウンリンクで受信できるデータである。例えば演算部１２は、ユーザの優先度と使用許容量との関係を表す曲線（配分率曲線４）を生成し、その配分率曲線４に基づいて、複数のユーザそれぞれの優先度に対応する使用許容量を算出する。配分率曲線４は、例えばユーザの優先度を変数として、使用許容量を求める関数「使用許容量＝Ｆ（優先度）」で定義できる。

次に演算部１２は、複数のユーザからの複数の観測要求３ａ，３ｂ，・・・に基づいて、複数のユーザそれぞれが使用を要求するリソースの量を示す要求量を算出する。例えば複数の観測要求３ａ，３ｂ，・・・には、観測時に使用するリソースに関する情報が含まれている。例えばカメラの画像の解像度や画像の取得頻度などの情報である。これらの情報に基づいて、１つの観測要求を実行したときに、観測結果取得時のダウンリンクで使用する通信量が、使用を要求するリソース量として求められる。観測要求に応じたリソース量をユーザごとに合計することで、各ユーザが使用を要求するリソースの量が求まる。なお、複数の観測要求３ａ，３ｂ，・・・内に、使用するリソース量を示す数値が含まれていてもよい。ユーザの各観測要求で要求されるリソース量の合計が、そのユーザの要求量である。図１では、各ユーザの要求量が棒グラフで表されている。

そして演算部１２は、要求量が使用許容量以下である第１のユーザにおける要求量と使用許容量との差分（余裕量）に応じた値を、要求量が使用許容量を超えている第２のユーザの使用許容量に加算する。余裕量に応じた値は、例えば、差分を第２のユーザ数で等分した値である。図１では、余裕量は破線の矩形で表されている。

ユーザの優先度と使用許容量との関係を表す配分率曲線４が生成されている場合、例えば演算部１２は、第１のユーザにおける余裕量に応じた値だけ、曲線の位置を、使用許容量が大きくなる方に移動する。図１の例では、配分率曲線４が上方に平行移動される曲線（配分率曲線５）が得られる。例えば演算部１２は、関数「使用許容量＝Ｆ（優先度）＋Σ余裕量／第２のユーザ数」（Σは余裕量の総和を示す）により、新たな曲線を再定義する。そして演算部１２は、曲線の再定義により、要求量が使用許容量以下となるユーザが新たに生じた場合、そのユーザの余裕量により、曲線をさらに再定義する。このような曲線の再定義が、要求量が使用許容量以下となるユーザが生じなくなるまで繰り返されることで、最終的な配分率曲線５が得られる。

配分率曲線５が求まると、演算部１２は、複数の観測要求３ａ，３ｂ，・・・のうち、実行対象とする観測要求を決定する。例えば演算部１２は、第１のユーザの観測要求のすべてを実行対象に決定する。また演算部１２は、第２のユーザの観測要求を順番に選択し、選択するごとに、それまでに選択した観測要求で要求されるリソース量を積算する。そして演算部１２は、積算結果が使用許容量以下であれば、選択した観測要求を実行対象に決定する。演算部１２は、積算結果が使用許容量を超えた場合、選択した観測要求を実行対象とする優先度を下げる。観測要求の優先度が下げられることで、その観測要求が実行対象から除外される。

演算部１２は、実行対象に決定された観測要求で要求されるリソース量のユーザごとの合計を、そのユーザが使用可能なリソースとして、ユーザに割り当てる。図１では、要求量を示す棒グラフのうち、割り当てられたリソース量に相当する部分に斜線が引かれている。なおユーザは、使用するリソースの量が割り当てられたリソースの範囲内であれば、実行する観測要求の内容を変更することもできる。

このような情報処理装置１０によれば、優先度が高いユーザにおいてリソースの使用許容量に余裕があれば、余裕分のリソースが、他のユーザに振り分けられる。その結果、優先度が低いユーザが使用できるリソースの割合を増加させることができる。しかも最初に定義した配分率曲線４では、優先度が高いユーザほど多くのリソースが振り分けられているため、優先度の高いユーザは、要求量に応じた十分な量のリソースの割り当てを受けることができる。

なお、演算部１２は、例えば情報処理装置１０が有するプロセッサにより実現することができる。また、記憶部１１は、例えば情報処理装置１０が有するメモリにより実現することができる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。
図２は、第２の実施の形態のシステム構成例を示す図である。観測要求を管理するサーバ１００は、ネットワーク２０を介して、複数の端末装置３１，３２，３３，・・・に接続されている。端末装置３１，３２，３３，・・・は、人工衛星４０による観測を行うユーザが使用するコンピュータである。人工衛星４０は、例えば地球観測衛星である。さらにサーバ１００は、ネットワーク２０を介して複数のコマンド送信／データ受信局４１，４２，４３，・・・に接続されている。コマンド送信／データ受信局４１，４２，４３，・・・は、人工衛星４０が観測機器を用いて観測したデータを、人工衛星４０から受信する。

ユーザは、端末装置３１，３２，３３，・・・を用いて、観測要求をサーバ１００に送信する。サーバ１００は、受信した観測要求のうち、人工衛星４０で提供できるリソースに応じた量の観測要求を選択し、その観測要求に従った命令を、人工衛星４０に送信する。人工衛星４０への命令は、例えばコマンド送信／データ受信局４１，４２，４３，・・・を介して送信される。人工衛星４０は、受信した命令に従ってカメラ・センサといった観測機器を制御し、観測結果を示すデータを蓄積する。そして人工衛星４０からコマンド送信／データ受信局４１，４２，４３，・・・へデータが送信される。コマンド送信／データ受信局４１，４２，４３，・・・は、受信したデータをネットワーク２０経由でサーバ１００に送信する。サーバ１００は、実施された観測要求の送信元である端末装置に、その観測要求に応じた観測結果のデータを送信する。

なお、人工衛星４０からコマンド送信／データ受信局４１，４２，４３，・・・にデータを送信できるのは、所定の期間に制限される。
図３は、人工衛星からデータを送信できる期間の例を示す図である。人工衛星４０は、所定の衛星軌道５１に沿って地球の周囲を周回している。他方、地上に設定されたコマンド送信／データ受信局４１は、そのコマンド送信／データ受信局の頭上の所定の可視範囲内が、人工衛星４０からデータを受信できるデータ受信可能域５２となる。人工衛星４０は、衛星軌道５１を周回する過程で、一定の期間だけ、データ受信可能域５２内に滞在する。人工衛星４０は、その期間内だけ、観測したデータをコマンド送信／データ受信局４１に送信できる。なお地球上には複数のコマンド送信／データ受信局４１，４２，４３，・・・が設けられている。そのため、人工衛星４０は、衛星軌道５１の１回帰内に、データを送信できる期間が複数回発生する。「回帰」は回帰衛星が同じ軌道に戻ってくる衛星固有のサイクルである。例えば陸域観測技術衛星２号（ＡＬＯＳ−２）であれば１４日を１回帰として同じ軌道に戻ってくるよう制御されている。

人工衛星４０から提供可能な通信リソースの量（データ量）は、人工衛星４０がデータ受信可能域内に滞在する期間と、データの通信速度とによって決まる。人工衛星４０は、データを送信できる可視範囲内で観測を行ったり、または可視範囲外ではデータレコーダに記録し、可視範囲内で再生する運用を行ったりする。

このように、人工衛星４０から受信できるデータ量に限りがあるため、大量の観測要求のすべてを実施するのは困難である。そこでサーバ１００が、観測したデータ量が、受信できるデータ量の範囲内となるように、実施する観測要求を決定する。サーバ１００は、例えばプロセッサを有するコンピュータである。

図４は、サーバのハードウェアの一構成例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１０も、図４に示したサーバ１００と同様のハードウェアにより実現することができる。

サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

以上のようなハードウェアにより、サーバ１００が、人工衛星４０の通信リソースのユーザへの配分の最適化を行う。すなわちサーバ１００は、優先度の高いユーザほど多くのリソースが使用できるようにリソースを配分する。このときサーバ１００は、優先度が低いユーザにも、ある程度のリソースが割り当てられるようにする。そしてサーバ１００は、割り当てられた量のリソースの一部しか使用しないユーザがいる場合、余った分のリソースを、優先度が低いユーザを含め、リソースが不足しているユーザに再配分する。このようにすることで、リソースの有効利用を図り、優先度が低いユーザにも可能な限り多くのリソースを配分することができる。

図５は、サーバのリソース配分機能を示すブロック図である。サーバ１００は、ユーザ情報記憶部１１０、観測要求記憶部１２０、観測計画記憶部１３０、観測結果記憶部１４０、リソース割り当て部１５０、計画立案部１６０、および運用部１７０を有する。

ユーザ情報記憶部１１０は、人工衛星４０を用いた観測の結果を利用するユーザの情報を記憶する。観測要求記憶部１２０は、ユーザが使用する端末装置３１，３２，３３，・・・から受信した観測要求を記憶する。観測計画記憶部１３０は、立案された観測計画を記憶する。観測結果記憶部１４０は、人工衛星４０が観測装置を用いて観測した観測データを記憶する。ユーザ情報記憶部１１０、観測要求記憶部１２０、観測計画記憶部１３０、および観測結果記憶部１４０としては、例えばサーバ１００のメモリ１０２またはＨＤＤ１０３の記憶領域の一部が使用される。

リソース割り当て部１５０は、ユーザごとに、使用可能なリソースを割り当てる。例えばリソース割り当て部１５０は、端末装置３１，３２，３３，・・・から送られた観測要求を、観測要求記憶部１２０に格納する。そしてリソース割り当て部１５０は、ユーザ情報記憶部１１０と観測要求記憶部１２０とを参照し、ユーザごとに、人工衛星４０から１回帰内に使用可能なリソースを割り当てる。リソース割り当て部１５０は、リソースの割り当て結果（割り当てたリソース量、実行対象とされた観測要求など）を、各ユーザが使用する端末装置３１，３２，３３，・・・に送信する。

計画立案部１６０は、各ユーザが割り当てられたリソース量の範囲内で考え直した観測要求に基づいて、人工衛星４０を用いた観測計画を立案する。計画立案部１６０は、立案した観測計画を、観測計画記憶部１３０に格納する。

運用部１７０は、観測計画記憶部１３０に格納されている観測計画に従って、人工衛星４０を制御し、人工衛星４０に対して、観測機器を用いた観測を実行させる。人工衛星４０の制御は、例えば人工衛星４０に対する制御コマンドなどの命令の送信によって行われる。

また運用部１７０は、人工衛星４０が送信した観測データを、コマンド送信／データ受信局４１，４２，４３，・・・経由で受信し、観測結果記憶部１４０に格納する。運用部１７０は、データの取得要求を端末装置から受信すると、その端末装置に、観測結果記憶部１４０内のデータを送信する。

なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

次に、各記憶部に格納される情報のうち、観測計画に関連する情報について詳細に説明する。
図６は、ユーザ情報記憶部の一例を示す図である。ユーザ情報記憶部１１０には、例えばユーザ管理テーブル１１１が格納されている。ユーザ管理テーブル１１１には、ユーザの識別子に対応付けて、優先度が設定されている。優先度は、数値が高いほど、優先度も高いものとする。

図７は、観測要求記憶部の一例を示す図である。観測要求記憶部１２０には、例えば観測要求管理テーブル１２１が格納される。観測要求管理テーブル１２１には、観測要求番号、ユーザ、観測開始日時、観測終了日時、観測領域、優先度、および観測内容の欄が設けられている。

観測要求番号の欄には、受信した観測要求の識別番号が設定される。ユーザの欄には、受信した観測要求の送信元のユーザの識別子が設定される。観測開始日時の欄には、観測を開始する日時が設定される。観測終了日時の欄には、観測を終了する日時が設定される。観測領域の欄には、観測対象の領域を特定する情報が設定される。例えば観測対象の領域は、多角形の頂点の座標を示す緯度・経度によって特定される。優先度の欄には、観測要求ごとの優先度が設定される。例えば、優先度の値が大きいほど、優先度が高くなる。観測内容の欄には、観測に使用する観測機器や、観測時の観測機器の動作モードなどの観測内容に関する情報が設定される。

観測要求では、観測開始日時と観測終了日時とにより、観測期間が示される。また観測領域により、観測対象の領域が示される。
図８は、観測要求による観測期間と観測領域との一例を示す図である。図８では、観測要求ごとのリソース占有範囲が、ブロック５３〜５９で示されている。図８の縦軸は日時であり、その縦軸に垂直な平面には、地表の位置を示す座標軸（ｘ軸、ｙ軸）が定義されている。観測要求のリソース占有範囲は、観測期間（ブロック５３〜５９の高さ）と観測領域（ブロック５３〜５９の底面形状）とで表される。

異なるブロックで重なる領域がある場合、それらのブロックに対応する観測要求間で競合が生じることを示す。競合が生じる場合、原則として、一方の観測要求のみが実行可能である。そこで、例えば競合を生じさせる複数の観測要求のうち、最も優先度が高い観測要求が実行される。競合解消処理は、例えば各ユーザへのリソース割り当て後に、計画立案部１６０で行われる。

このように、地域と期間を同時に扱う座標系が定義され、観測要求で使用するリソースがブロック５３〜５９で表される。観測要求で使用するリソースを立体構造で表すことで、開始／終了日時と観測対象の領域（２次元）との関係が明確となり、サーバ１００により競合の有無が容易に判断できる。また図８のように立体化した画像をモニタ２１に表示すれば、観測要求で使用されるリソースを、視覚的に容易に認識できる。

また、観測要求は、観測対象の領域ごとに出される。人工衛星４０から地球を観測する場合、所定の領域を観測することで、防災または科学調査などにおける意味のある解析を行うことができる。そのため第２の実施の形態では、観測対象の領域ごとに、その領域を観測する観測要求を、実行対象として採用するか否かを判断する。

図９は、観測計画記憶部の一例を示す図である。観測計画記憶部１３０には、例えば観測計画管理テーブル１３１が格納される。観測計画管理テーブル１３１には、人工衛星の１回帰ごとの期間を示す回帰番号に対応付けて、その回帰中に実行する実行対象の観測要求のリストが設定される。

以上のような情報を用いて観測計画が立案され、その観測計画に従って人工衛星を用いた観測が行われる。以下、人工衛星を用いた観測の手順について説明する。
図１０は、観測手順の一例を示すシーケンス図である。ユーザは、端末装置３１を用いて、１以上の観測要求６１をサーバ１００に送信する（ステップＳ１０１）。観測要求６１には、端末装置３１を使用するユーザの識別子、観測開始日時、観測終了日時、観測領域、優先度、および観測内容などの情報が含まれる。このとき送信される観測要求６１はドラフト版であり、要求量絞り込み前である。例えば、割り当てられるリソース量を考慮せずに、ユーザが希望する観測を人工衛星に実施させるための観測要求６１が送信される。

観測要求６１を受信したサーバ１００では、リソース割り当て部１５０が、端末装置３１を使用するユーザに対するリソースの割り当てを行う（ステップＳ１０２）。そしてリソース割り当て部１５０は、ユーザに割り当てたリソース量を示す割り当てリソース通知６２を、端末装置３１に送信する。割り当てリソース通知６２には、例えば、ユーザの観測要求に応じて実行した観測により得られた観測データの、人工衛星から１回帰内に受信可能なデータ量が含められる。

割り当てリソース通知６２を受信した端末装置３１では、割り当てリソース通知６２に応じて、割り当てられたリソース内での観測要求が立案される（ステップＳ１０３）。例えばユーザは、割り当てられたリソース量内で効果的な観測結果が得られるように、各観測要求における観測内容を修正する。例えばユーザは、カメラの動作モードを変更し、画像の解像度を下げたり、画像の取得間隔を長くしたりといった修正内容を、端末装置３１に入力する。端末装置３１は、修正された正規版の観測要求６３をサーバ１００に送信する。

サーバ１００の計画立案部１６０は、正規版の観測要求６３に応じて、人工衛星４０の観測計画を立案する（ステップ１０４）。観測計画には、例えば、人工衛星の回帰ごとに、その回帰内でどの観測要求を実行するのかが示される。計画立案部１６０は、立案した観測計画６４を端末装置３１に送信する。端末装置３１では、観測計画６４を格納する（ステップＳ１０５）。

その後、サーバ１００は、立案した観測計画に従って人工衛星４０を運用し、観測結果を示す観測データを取得する（ステップＳ１０６）。観測データは、観測結果記憶部１４０に格納される。そしてサーバ１００から端末装置３１へ、端末装置３１を使用するユーザの観測要求に基づいて取得された観測データが、観測結果６５として送信される。端末装置３１では、観測結果６５に基づいて観測実績が管理される（ステップＳ１０７）。なお、リソース割り当て処理（ステップＳ１０２）、観測計画立案処理（ステップＳ１０４）、および観測運用処理（ステップＳ１０６）は別のサーバ上で実行することもできる。例えばリソース割り当て処理はユーザ管理用のサーバで実行し、観測計画立案処理や観測計画立案処理は衛星管理用のサーバで実行させてもよい。

次に、リソース割り当て処理（ステップＳ１０２）の詳細について説明する。
図１１は、リソース割り当て処理の手順の一例を示すフローチャートである。なお、以下の処理は、サーバ１００に設定された所定の時期に実行される。

［ステップＳ１１１］リソース割り当て部１５０は、観測調整対象期間（例えば２年）内の未調整の回帰の１回帰分（例えば１４日分）の観測要求を観測要求記憶部１２０から取得する。例えばリソース割り当て部１５０は、調整対象の１回帰の期間内の観測期間を有する観測要求を、観測要求記憶部１２０から取得する。

［ステップＳ１１２］リソース割り当て部１５０は、取得した１回帰分の観測要求のユーザを抽出する。
［ステップＳ１１３］リソース割り当て部１５０は、抽出したユーザの優先度に基づいて、配分率曲線を定義する。配分率曲線は、ユーザの優先度に応じた、そのユーザに割り当てるリソース量（配分量）を示す曲線である。この配分量は、第１の実施の形態における使用許容量の一例である。配分率曲線は、優先度が高いユーザほど多くのリソースを割り当てるように定義される。例えば、一次関数または二次関数などの関数で配分率曲線を定義できる。配分率曲線により算出される各ユーザの配分量の合計は、人工衛星４０で提供されるリソースの総量となる。

［ステップＳ１１４］リソース割り当て部１５０は、抽出したユーザの中から、順番にユーザを選択する。例えばリソース割り当て部１５０は、優先度の高いユーザから順に、ユーザを選択する。

［ステップＳ１１５］リソース割り当て部１５０は、選択したユーザのすべての観測要求による要求リソースの総量（要求量）が、配分量以下か否かを判断する。要求量が配分量以下の場合に、そのユーザはリソースの配分量に余裕がある。その余裕分のリソースを他のユーザに使用させることで、リソースの有効利用が図れる。

個々の観測要求のリソース量は、その観測要求の観測内容と観測期間とから算出できる。例えば配分するリソースが、人工衛星４０からの受信データであるものとする。この場合、観測要求の観測内容が、所定時間間隔でのカメラ撮影であれば、観測期間に基づいて撮影回数が算出できる。また撮影時のカメラの解像度から、撮影１回当たりの写真のデータ量が計算できる。撮影１回当たりのデータ量に撮影回数を乗算した結果が、リソース量となる。該当ユーザの観測要求が複数あれば、各観測要求のリソース量の合計が、そのユーザの要求量となる。

ユーザの要求量が配分量以下であれば、処理がステップＳ１１６に進められる。ユーザの要求量が配分量より多ければ、処理がステップＳ１１７に進められる。
［ステップＳ１１６］リソース割り当て部１５０は、余裕量を元に、配分率曲線を再定義する。例えばリソース割り当て部１５０は、ステップＳ１１３で定義した配分率曲線が「配分率＝Ｆ（ｘ）」という関数（ｘは、ユーザの優先度を示す整数）で表せる場合、配分率曲線を「配分率＝Ｆ（ｘ）＋ｐ／ｎ」と再定義する。ｐは余裕量を示す正の実数であり、ｎは未選択のユーザ数を示す自然数である。その後、処理がステップＳ１２２に進められる。

［ステップＳ１１７］リソース割り当て部１５０は、選択しているユーザの観測要求を１つ選択する。
［ステップＳ１１８］リソース割り当て部１５０は、選択しているユーザの観測要求で要求するリソース量を積算する。

［ステップＳ１１９］リソース割り当て部１５０は、リソース量の積算結果が、選択したユーザへのリソースの配分量を超過したか否かを判断する。配分量を超過した場合、処理がステップＳ１２０に進められる。配分量を超過していなければ、処理がステップＳ１２１に進められる。

［ステップＳ１２０］リソース割り当て部１５０は、選択した観測要求の優先度を下げる。このとき、選択した観測要求の優先度は、初期段階に設定された優先度範囲の最下位値より下にさげられる。例えば観測要求の優先度の範囲が「１〜３２」であり、ユーザによる優先度の初期設定可能範囲が「１７〜３２」である場合を考える。この場合、リソース割り当て部１５０は、観測要求の元の優先度から「１６」を減算する。これにより、優先度を操作した観測要求は、優先度を操作していない観測要求よりも低い優先度となる。

［ステップＳ１２１］リソース割り当て部１５０は、選択したユーザの観測要求のうち、未選択の観測要求があるか否かを判断する。未選択の観測要求があれば、処理がステップＳ１１７に進められる。すべての観測要求が選択済みであれば、処理がステップＳ１２２に進められる。

［ステップＳ１２２］リソース割り当て部１５０は、ステップＳ１１２で抽出したユーザの中に、未選択のユーザがあるか否かを判断する。未選択のユーザがあれば、処理がステップＳ１１４に進められる。すべてのユーザが選択済みであれば、処理がステップＳ１２３に進められる。

［ステップＳ１２３］リソース割り当て部１５０は、観測調整対象期間内のすべての回帰に関して、観測要求を調整済みか否かを判断する。すべての回帰の観測要求が調整済みであれば、処理が終了する。観測要求を未調整の回帰があれば、処理がステップＳ１１１に進められる。

このようにして、回帰ごとに、実行する観測要求の調整が行われる。以下、１回帰分の観測要求の調整例を示す。
図１２は、調整前の要求量と配分量とを示すグラフである。グラフの縦軸はリソース量である。横軸には、ユーザ名が優先度順に並べられている。図中、右側のユーザほど、優先度が高い。各ユーザが要求するリソース量（要求量７１）は、棒グラフで示されている。優先度に応じて各ユーザに割り当てられるリソース量（配分量）は、配分率曲線７２で示されている。

図１２に示すように、配分率曲線７２に従えば、優先度の高いユーザほど、多くのリソースが割り当てられる。しかし、優先度が高いユーザほど多くのリソースを使用するとは限らない。例えば災害対応や事故対応を目的として人工衛星４０を使用するユーザは、災害や事故が発生していない期間は、それほど多くのリソースは使用しない。そのため要求量が配分量以下となる場合がある。図１２の例では、「防災室」、「海上保安庁」、および「Ｆ」は、要求量が配分量以下である。これらのユーザは、配分量に余裕がある。

図１３は、ユーザの余裕量を示す図である。図１３において破線で示した部分が、各ユーザの余裕７３に相当する。余裕７３は、ユーザの配分量と要求量との差分である。余裕７３がある場合、配分率曲線７４を再定義することで、余裕量分のリソースを他のユーザに振り分けることができる。

図１４は、再定義された配分率曲線の例を示す図である。再定義後の配分率曲線７４は、リソースの配分量に余裕があったユーザの余裕量分が、それ以外のユーザの配分量に上乗せされている。その結果、グラフ中、再定義後の配分率曲線７４は、再定義前の配分率曲線７２を、上に平行移動した位置に配置される。

配分率に余裕があったユーザへ割り当てるリソース量は、要求量で確定する。それ以外のユーザの要求量は、再定義後の配分率曲線７４を用いて検討される。図１４の例では、「防災室」、「海上保安庁」、および「Ｆ」まで、要求量分の割り当てが確定し、それらの余裕７３分のリソースを再配分した状況が示されている。

再定義後の配分率曲線７４に基づいて、割り当てるリソース量が未確定のユーザへの配分量が求められる。これにより、優先度は高いが要求量の少ないユーザに配分されたリソースの一部を、配分量よりも要求量の多いユーザに無駄なく割り当てることができる。

なお、ユーザの優先度は変えていないため、衛星運用系の計画立案処理で要求が競合（観測領域と観測日時が重複）した場合は、予め設定されていた優先度に従って競合解決されることになる。

配分率曲線７４の再定義により、配分量に余裕が生まれるユーザが新たに生じることがある。
図１５は、新たに余裕が生まれたユーザの例を示す図である。図１５の例では、ユーザ「Ｃ」と「Ｇ」について、配分率曲線が再定義されたことで、新たに配分量に余裕７５，７６が生まれている。この場合、ユーザ「Ｃ」と「Ｇ」に割り当てるリソース量は、そのユーザの要求量に確定する。新たに生じた余裕７５，７６に相当するリソース量は、割り当てるリソース量が未確定の他のユーザに、さらに再配分できる。

図１６は、２度目の再定義後の配分率曲線の例を示す図である。「Ｃ」、「Ｇ」の新たな余裕を次のユーザの配分率に上乗せすると、配分量が更に増えた新たな配分率曲線７７を再定義することができる。配分率曲線７７に基づいて、リソース量が未確定の他のユーザにリソースを再配分すれば、「Ｄ」、「経産省」、「環境省」、「Ｉ」にとっては元の配分率曲線７４に比べてリソース割り当ての配分が増加することとなる。

このようにして、配分量に余裕のあるユーザが存在する限り、配分率曲線を繰り返し定義される。再定義された配分率曲線を用いてもリソースの要求量に対して配分量が不足するユーザについては、一部の観測要求についてのみ実行対象とされる。

例えばユーザは、複数の領域について観測する場合、１領域当たり１つの観測要求を送信する。領域は、図８に示したｘ軸とｙ軸との座標で指定される。またユーザの優先度とは別に、観測要求にも優先度が設定される。この場合、観測リソース調整において実行するか否かの判断は、領域単位で調整される。すなわち領域に対応する観測要求ごとに、実行するか否かが決定される。例えば、図１６の例では、ユーザ「Ｄ」、「経産省」、「環境省」、「Ｉ」の順にユーザが選択され、実行する観測要求の調整が行われる。

図１７は、調整対象のユーザの観測要求の例を示す図である。図１７には、ユーザ「Ｄ」が観測しようとする領域ごとの観測要求８１，８２，８３，・・・が示されている。図１７では、観測要求８１，８２，８３，・・・の高さが、その観測要求に従った観測で使用するリソース量を示している。

ユーザ「Ｄ」の観測要求８１，８２，８３，・・・が選択されるごとに、観測要求に応じた観測で使用するリソース量が積算される。このような処理が、観測要求に応じたリソース量の積算値が配分量をオーバするまで繰り返される。配分量は、例えば、最後に定義された配分率曲線７７の式に、ユーザ「Ｄ」の優先度を代入して算出される。

観測要求に応じたリソース量の積算値が配分量を超過した場合、そのとき選択されている観測要求の優先度が下げられる。例えば元の優先度に対して固定値（ユーザが設定可能な優先度の幅よりも大きな値）分、優先度が下げられる。これにより、衛星運用系の計画立案において、優先度が操作された観測要求と、優先度が操作されていない観測要求とに競合が発生すると、優先度が操作されていない観測要求の方が、実行対象として採用される。また、優先度が操作された観測要求どうしでは、操作前の優先順に従って競合解決される。

このようなユーザごとの観測要求の優先度の調整が、ユーザ「Ｄ」、「経産省」、「環境省」、「Ｉ」それぞれに対して行われる。
図１８は、優先度の調整範囲を示す図である。図１８に示すように、各ユーザの要求量のうち、配分率曲線７７の上に出る部分のリソース量を要求する観測要求について、優先度が下げられる。

すべてのユーザの観測要求の優先度の調整が終了すると、優先度が調整されていない観測要求が実行対象とされる。そして実行対象とされた観測要求に応じた観測で使用されるリソース量が、各ユーザに割り当てられる。

図１９は、リソース割り当て結果を示す図である。図１９において、曲線７８より下の部分が、各ユーザに割り当てられるリソース量を表している。各ユーザに割り当てられるリソース量の合計は、最初に定義された配分率曲線７２に基づいて算出される各ユーザの配分量の合計と同じとなる。

このように、第２の実施の形態では、予め定義した配分率曲線に従って、ユーザごとの観測要求の採用率（実行対象として選択される割合）をコントロールできる。そのため、例えば優先度の低いユーザがまったく観測データを取得できない、というようなことがなくなる。

しかも、要求量はユーザごとに異なり、配分率曲線に基づいて得られる配分量が、ユーザの要求量より余裕のある場合もある。第２の実施の形態では、この余裕分のリソースが、配分量が不足している他のユーザに振り分けられる。最初に定義される配分率曲線７２では、優先度が高い方のユーザに対して、より多くのリソースを振り分けている。そのため、余裕が生じるユーザは、優先度が比較的高いユーザである可能性が高く、リソースが不足するユーザは、優先度が比較的低いユーザである可能性が高い。その結果、余裕分のリソースの、配分量が不足しているユーザへの振り分けにより、優先度の低いユーザに割り当てるリソースの割合を高めることができる。また、最初に定義される配分率曲線７２において、優先度が高い方のユーザに対してより多くのリソースを振り分けているため、特に優先度が高いユーザに対しては、そのユーザが使用する分のリソースを確実に割り当てることができる。

なお、優先度の低いユーザの観測要求を実行させるために、実行する観測要求を人手で調整することもできる。しかし、観測要求は、２年間で３０万件に達する場合もあり、実行するすべての観測要求を人手で調整するのは困難である。その結果、人手で調整しようとすると、比較的優先度の高いユーザの観測要求間での調整で手一杯となってしまう。それに対し、第２の実施の形態に係るサーバ１００を用いれば、実行する観測要求の調整が自動化されるため、すべての優先度の観測要求についての調整を容易に行うことができる。

さらに第２の実施の形態では、観測要求として意味のある単位（観測対象の領域）で、その観測要求を実行するか否かが決められる。例えば、図８に示すように、観測対象の領域と観測期間とを表すブロック単位で、観測要求が扱われる。配分量を超過した分の観測要求は、ブロックごと（領域単位）に優先度が下げられる。これを繰り返すことによって配分率曲線に従った観測リソース調整が、人工衛星４０を用いた観測において意味のある単位で行われ、適切な調整が実現できる。

また第２の実施の形態では、割り当てたリソースをユーザに通知する。これにより、ユーザにとっては事前にどれだけの観測要求が実行対象とされるかを知ることができる。そして各ユーザは、与えられたリソースの範囲で自由に、各観測要求について実行対象とするか否かを変更することもできる。

第２の実施の形態では、計画立案の前に観測要求の調整を行っている。これにより、計画立案部１６０に未調整の大量の観測要求が送られてくることが抑止され、計画立案部１６０は、実行可能な量の観測要求を受け付けることができる。これにより、計画立案部１６０における観測計画立案の負荷を下げることができる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 人工衛星
２ コマンド送信／データ受信局
３ａ，３ｂ，・・・ 観測要求
４，５ 配分率曲線
１０ 情報処理装置
１１ 記憶部
１２ 演算部

Claims (5)

1. コンピュータに、
   複数のユーザそれぞれについて、使用が許容される人工衛星のリソース量を示し、前記人工衛星を使用する優先度が高いユーザほど大きな値の、使用許容量を算出し、
   前記複数のユーザからの複数の観測要求に基づいて、前記複数のユーザそれぞれが使用を要求するリソース量を示す要求量を算出し、
   要求量が使用許容量以下である第１のユーザにおける該要求量と該使用許容量との差分に応じた値を、要求量が使用許容量を超えている第２のユーザの該使用許容量に加算する、
   処理を実行させる観測要求管理プログラム。
2. 使用許容量の算出では、ユーザの優先度と使用許容量との関係を表す曲線を生成し、該曲線に基づいて、前記複数のユーザそれぞれの優先度に対応する使用許容量を算出し、
   差分に応じた値の加算では、前記第１のユーザにおける該要求量と該使用許容量との差分に応じた値だけ、前記曲線の位置を、使用許容量が大きくなる方に移動させる、
   請求項１記載の観測要求管理プログラム。
3. 前記コンピュータに、さらに、
   前記第１のユーザの観測要求のすべてを実行対象に決定し、
   前記第２のユーザの観測要求を順番に選択し、選択するごとに、それまでに選択した観測要求それぞれで要求されるリソース量を積算し、積算結果が使用許容量以下であれば、選択した観測要求を実行対象に決定し、積算結果が使用許容量を超えた場合、選択した観測要求を実行対象から除外する、
   請求項１または２記載の観測要求管理プログラム。
4. コンピュータが、
   複数のユーザそれぞれについて、使用が許容される人工衛星のリソース量を示し、前記人工衛星を使用する優先度が高いユーザほど大きな値の、使用許容量を算出し、
   前記複数のユーザからの複数の観測要求に基づいて、前記複数のユーザそれぞれが使用を要求するリソース量を示す要求量を算出し、
   要求量が使用許容量以下である第１のユーザにおける該要求量と該使用許容量との差分に応じた値を、要求量が使用許容量を超えている第２のユーザの該使用許容量に加算する、
   観測要求管理方法。
5. 人工衛星を使用する複数のユーザからの複数の観測要求を記憶する記憶部と、
   前記複数のユーザそれぞれについて、使用が許容される人工衛星のリソース量を示し、前記人工衛星を使用する優先度が高いユーザほど大きな値の、使用許容量を算出し、前記複数の観測要求に基づいて、前記複数のユーザそれぞれが使用を要求するリソース量を示す要求量を算出し、要求量が使用許容量以下である第１のユーザにおける該要求量と該使用許容量との差分に応じた値を、要求量が使用許容量を超えている第２のユーザの該使用許容量に加算する演算部と、
   を有する情報処理装置。

Images