(57)【特許請求の範囲】
【請求項１】
人工天体の管制のためのコマンドによって構成されるコマンド計画を生成する制御をコンピュータに行わせるコンピュータ・プログラムであって、
実行させたいコマンドにその希望順位を付して一つ以上記述した運用要求データを、複数であるｎ個取得し、
前記ｎ個の運用要求データのそれぞれに優先順序をつけて並べた運用要求ファイルを、前記優先順序のつけ方が異なるように、ｎＰｎ通りの全ての順列を生成することにより、前記順列のおのおのに対して該順列により前記優先順序がつけられた一つの前記運用要求ファイルを作成することによって、ｎＰｎ個作成し、
前記運用要求ファイル内において並べられた優先順序が先である運用要求データを優先し、各運用要求データ内においては該運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記ｎＰｎ個の運用要求ファイル各々について前記コマンド計画を生成する、
ことを含む制御を前記コンピュータに行わせることを特徴とするコンピュータ・プログラム。
【請求項２】
前記ｎ個の運用要求データについて生成された複数の前記コマンド計画のおのおのについて、前記コマンド計画に反映された各コマンドの希望順位に基づいて評価点を算出し、
前記評価点に基づいて、前記複数のコマンド計画をソートして出力させる、
ことを更に含む制御を前記コンピュータに行わせることを特徴とする請求項１に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、人工天体の管制計画を生成する技術に関する。
【０００２】
【従来の技術】
人工天体は、通常、予め決定されたコマンド計画に基づいて管制される。ここで、コマンドとは、人工天体に対する作業管制指令であり、コマンドに基づいて、人工天体において作業が行われる。
【０００３】
このコマンド計画を生成するためには、まず、人工天体の利用者は、コマンド計画立案者に対して、人工天体に行わせるミッション、サブミッション、人工天体の安全運行、機体の維持保全等に関するコマンド（運用要求）を記述した運用要求データを提示する。
【０００４】
コマンド計画立案者は、コマンド計画生成システムを用いて、その運用要求データの内容に基づいて、コマンド計画を記述するコマンド計画ファイルを生成する。その際、コマンド計画に矛盾や抵触がないようにする。生成されたコマンド計画ファイルは管制システムに入力され、管制システムは、コマンド計画ファイルの記述にしたがって、人工天体に対してコマンドを送信する。
【０００５】
コマンド計画生成システムの従来技術として、例えば、日本公開特許公報、特開平６−２６６４１７号において開示される作業計画決定方式や、特開２００１−２３３３００において開示される「人工衛星の運用計画生成システム及び方法」が挙げられる。
【０００６】
このコマンド計画は、バス系計画に属するコマンドと搭載系計画に属するコマンドから構成される。バス系計画は、人工天体それ自体の安全運行、機体の維持保全、その他人工天体の運用を続行させるために必要な作業計画である。搭載系計画（又は観測系計画）は、人工天体のミッション、例えば観測、に関する作業計画である。
【０００７】
ところで、人工天体は、各々１台ずつがミッションに応じて特別注文生産され、その生産には莫大な費用と技術力が投資されている。人工天体は、宇宙科学技術分野の熾烈な国際競争の所産であり、国策上も重要な国家戦略プロジェクトである。
【０００８】
また、人工天体のミッションは単に最先端の宇宙科学技術の進展にとどまらず実用としても気象観測、ＧＰＳ（Global Positioning System）、通信衛星などのように、人々の身近な生活に深く関係し、科学技術研究分野だけでなく、社会的にも重要な役割を果たしている。
【０００９】
万一、杜撰で無謀な作業計画を実行する事によって、このような人工天体に例えば電圧の枯渇や温度異常等のトラブルが生じることになれば、人工天体のミッションの遂行が困難となり、最悪の結果として、人工天体が軌道から離脱したり、地上に落下したりすることにもなりうる。これでは、莫大な費用と技術力の投資が無駄になり、人々の生活にも不便を与える事になりかねない。
【００１０】
したがって、人工天体には、万全の運行管理、作業計画、安全管理が厳しく要求されている。故に、人工天体のコマンド計画の作成においては、伝統的にバス系計画が搭載系計画よりも絶対的に優先されている。
【００１１】
なお、昨今、人工天体の用途及びニーズの拡大（ミッションの巨大化）並びに人工天体技術の発展に伴い、人工天体を利用する利用者の数は増加し、人工天体に搭載される装置の種類及び量は増大している。例えば、観測衛星の分野では、従来は、教育機関等の限られた機関が主たる利用者であったが、それ以外の層からの利用者も増加している。従って、バス系計画のコマンドを記述した運用要求データ及び搭載系計画のコマンドを記述した運用要求データ共に、数が増加し、その内容も複雑化している。
【００１２】
【発明が解決しようとする課題】
上記公報において開示されたコマンド計画生成システムでは、「バス系計画の絶対優先」の考え方が前提となって、成功実績が積み上げられている。
【００１３】
「バス系計画の絶対優先」の考え方それ自体は、安全思想に根ざすものであり、誤りではない。しかしながら、他方では、バス系計画を優先しすぎるあまり、人工天体が安全無事に運用されていることそれ自体が自己目的化し、観測などの人工天体本来のミッションの適正な遂行が相対的に阻害されているという問題があった。
【００１４】
言い換えると、従来技術によれば、仮にバス系計画に属するコマンドと搭載系計画に属するコマンドとで人工天体のリソースが競合する場合、管制運用計画全体の中でバス系計画が合理的と考えられる程度以上にリソース・マージンを確保していたとしても、「バス系計画の絶対的優先」の考え方に基づいて、搭載系計画に属するコマンドが必ずバス系計画に属するコマンドに対して譲歩することになる。これはその分だけ、人工天体の本来のミッションに関する搭載系計画が縮退することを意味する。
【００１５】
運用要求データが増加し、多様化してきているような状況下で、従来のように、全てのバス系計画を搭載系計画に対して絶対的に優先させると、搭載系計画に属するコマンドをほとんど反映しないコマンド計画が生成されてしまうという問題があった。
【００１６】
本来の目的に立ち返れば、バス系計画は人工天体のその打ち上げ目的を最大限に全うするためにこそ、優先させることが認められていると考えるべきである。バス系計画が搭載系計画よりも絶対的に優先されることによってバス系計画が従来確保していた各種リソースが、搭載系計画に解放されることがあれば、相対的に搭載系計画が従来よりも多くコマンド計画に採用される可能性が拡大すると考えられる。
【００１７】
上記課題に鑑み、人工天体の運用管制及び計画決定の特性に配慮しつつ、予め設定された優先度に基づいて、特定のコマンド、例えばバス系計画に属するコマンドを偏重するのではなく、バス系計画及び搭載系計画の全てのコマンドが合理的にバランスしたコマンド計画の生成を支援することを可能とし、延いては宇宙科学技術の進展に貢献することを可能とすることが、本発明が解決しようとする課題である。
【００１８】
【課題を解決するための手段】
以下、図１を参照しながら、上記課題を解決するための手段について説明する。図１は、本発明の原理図である。上記課題を解決するために、図１に示すように、本発明の１態様によれば、人工天体の管制のためのコマンドによって構成されるコマンド計画を生成するコマンド計画生成装置において、運用要求受付手段１、処理優先度制御手段２及びコマンド計画生成手段３を備えるように構成する。
【００１９】
運用要求受付手段１は、実行させたい複数のコマンドとその希望順位を記述する運用要求データを人工天体の利用者等から受け付ける。
処理優先度制御手段２は、運用要求受付手段１が受け付けた複数の運用要求データを、順序をつけて並べることにより、運用要求ファイルを作成する。より具体的には、処理優先度制御手段２は、順列、つまり、複数の運用要求データの中から順に１つずつ取り出して順序付けて並べる事により、運用要求ファイルを生成する。各運用要求データの並べられる順序は幾通りもあり、その数だけ、運用要求ファイルは生成される。運用要求データの並べ方に制限がない場合、一般に、運用要求ファイルの総数は、順列の総数と同数である。
【００２０】
コマンド計画生成手段３は、前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記コマンド計画を生成する。
【００２１】
処理優先度制御手段２が順列に従って、幾通りもの運用要求データの処理順序を生成し、各々の処理順序に従って複数の運用要求ファイルを生成する。この運用要求ファイル内の運用要求データは、先に並べられた順に人工天体のリソースを自由に使用できるため、先に並べられた運用要求データは、後続の運用要求データよりも有利である。従って、先に処理される運用要求データの優先度は、後続の運用要求データよりも高くなる。
【００２２】
従って、本発明に係わるコマンド計画生成装置によれば、バス系計画に属するコマンドを記述する運用要求データを絶対的に優先させるのではなく、順列に従って、全ての運用要求データのうちいずれを優先させる場合についても同様にコマンド計画を生成する。従来は、予め定められた優先度に従って、コマンド計画を生成するだけであった。
【００２３】
これにより、バス系計画をむやみに優先させず、優先度を柔軟に変更させ、変更された優先度それぞれに対応するコマンド計画を生成することを可能とする。延いては、バス系計画に属するコマンド及び搭載系計画に属するコマンドが合理的にバランスしたコマンド計画の生成を可能とする。
【００２４】
また、コマンド計画立案者は、このようにして生成された複数のコマンド計画を比較する事により、バス系計画に属するコマンドと搭載系計画に属するコマンドの合理的なバランスを検証評価するためのデータを得ることができる。
【００２５】
なお、以上は「搭載系計画をバス系計画よりも優先させたい」という考え方に基づくものではなく、管制運用計画全体の中でバス系計画が適切・合理的に優先されているかをチェックする必要があるという考え方に基づくものである。
【００２６】
また、上記構成において、コマンド計画生成装置は、さらに天体シミュレータ４を備える事としてもよい。コマンド計画を生成する際に、天体シミュレータ４は、コマンド計画生成手段３からコマンドを取得し、取得されたコマンドを実行した場合の人工天体の状態をシミュレートする。シミュレーションの結果、取得されたコマンドを実行した場合に人工天体に不具合が生じる等のエラーが生じると判定された場合、そのコマンドはコマンド計画に反映されない。
【００２７】
さらに、また、上記構成において、コマンド計画生成装置は、更に、コマンド計画評価手段５を備えることとしてもよい。コマンド計画評価手段５は、コマンド計画生成手段４によって生成されたコマンド計画を評価する。その際に、コマンド計画評価手段５は、運用要求データに記述された複数のコマンドのうち、希望順位が高いコマンドが多く採用されているコマンド計画ほど評価点が高くなるように評価する。さらに、コマンド計画評価手段５は、評価点に基づいて、生成されたコマンド計画をソートし、ソート結果をユーザの端末に出力させる。
【００２８】
これにより、コマンド計画立案者は、このソート結果に基づいて、バス系計画と搭載系計画とのバランスを検証妥当性・合理性の評価を行うことによって、最終的に人工天体に送信するコマンド計画を決定することが可能となる。また、人工天体の利用者は、自分が出した運用要求データの内容がどのようにコマンド計画に反映されたのかを知り、出来上がったコマンド計画を迅速に検討することができる。
【００２９】
また、本発明の別の態様によれば、人工天体の管制のためのコマンドにより構成されるコマンド計画を生成するコマンド計画生成方法において、実行させたい複数のコマンドとその希望順位を記述する複数の運用要求データを取得し、順序をつけて並べられた前記複数の運用要求データからなる運用要求ファイルを複数作成し、前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記複数の運用要求ファイル各々について前記コマンド計画を生成する、ことを含むようにする。このコマンド計画生成方法も、上記コマンド計画生成装置によって実現される機能と同様の手順を行うことにより、上記コマンド計画生成装置と同様の作用・効果が得られるため、上記課題を解決することが可能である。
【００３０】
また、上記コマンド計画生成方法において行われる手順と同様の制御をコンピュータに行わせるコンピュータ・プログラムも、そのプログラムをコンピュータに実行させることによって、上記課題を解決することが可能である。さらに、上記プログラムを記録したコンピュータ読み取り可能な記録媒体から、そのプログラムをコンピュータに読み出させて実行させることによっても、上記課題を解決することができる。
【００３１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。なお、同じ装置等には同じ参照番号をつけ、説明を省略する。
【００３２】
図２に、本実施形態に係わるコマンド計画生成装置１０を含むシステムの構成を示す。図２に示すように、コマンド計画生成装置１０は、人工天体の利用者の端末（不図示）及びコマンド計画立案者の端末（不図示）と、ネットワークを介して、又は直接に、接続されている。
【００３３】
人工天体のメーカや、放送通信会社等の利用者は、人工天体に実行させたいコマンドを記述する運用要求データを作成し、コマンド計画生成装置１０に登録させる。ここで、コマンドは、人工天体を管制するためのバス系計画及び搭載系計画のいずれに属するコマンドであっても良い。また、運用要求データは、利用者が実行を希望する希望順位に対応して複数のコマンドを記述することとしてもよい。
【００３４】
コマンド計画立案者が、コマンド計画生成装置１０の処理優先度制御部１２を起動させると、コマンド計画生成装置１０は、受け付けた複数の運用要求データを順に並べる事により運用要求ファイルとし、このファイルをバッチ処理することによりコマンド計画を生成し、生成されたコマンド計画を点数で評価する。そして、コマンド計画生成装置１０は、生成されたコマンド計画を示すコマンド計画ファイル及び各コマンド計画の評価点をコマンド計画立案者及び・又は利用者の端末に出力させる。なお、本実施形態によれば、バス系計画を搭載系計画に対して絶対的に優先させるというような、予め決定された運用要求データの優先度はない。運用要求データの優先度は、コマンド計画生成装置１０によって制御される。
【００３５】
以下、コマンド計画生成装置１０の構成について説明する。図１に示すように、コマンド計画生成装置１０は、運用要求受付部１１、処理優先度制御部１２、コマンド計画生成部１３、天体シミュレータ１４、コマンド計画評価部１５、運用要求テーブル１６、処理順定義テーブル１７、コマンド計画ファイル格納部１８、運用要求反映ポート格納部１９及び評価点テーブル２０を備える。
【００３６】
運用要求受付部１１は、運用要求データを人工天体の利用者から受け付け、受け付けた運用要求データを運用要求テーブル１６に書き込む。
処理優先度制御部１２は、運用要求受付部１１が受け付けた運用要求データのそれぞれを処理する際の順序である処理順序を生成する。その際、処理優先度制御部１２は、原則的に考えられる全ての通りの処理順序を生成する。そして、処理優先度制御部１２は、全ての通りの処理順序を処理順定義テーブル１７に書き込む。さらに、処理優先度制御部１２は、処理順序に従って複数の運用要求データを順に並べる事により、運用要求ファイルを生成する。ここで、生成される運用要求ファイルの総数は、処理順序の通りの数と同じである。
【００３７】
ここで、先に処理される運用要求データは、まだ確保されていない人工天体のリソースを自由に使用できるため、後続の運用要求データよりも有利である。従って、先に処理される運用要求データの優先度は、後続の運用要求データよりも高い。故に、各運用要求データの処理順序は、各運用要求データの処理優先度を示すともいえる。
【００３８】
処理順序は、順列、つまり、複数の運用要求データの中から順に１つずつ取り出して全ての運用要求データを順序付けて並べる事により、決定される。ここで、各運用要求データの異なる並べ方、つまり処理順序の通りの総数は、順列の総数と同数である。例えば、５つの運用要求データが運用要求テーブル１６に格納されている場合、これらの運用要求データの処理順序は、順列の総数＝5Ｐ5＝５！＝５×４×３×２×１＝１２０、つまり１２０通りある。
【００３９】
コマンド計画生成部１３は、処理優先度制御部１２によって生成された各々の運用要求ファイルについて、以下の処理を行う。まず、コマンド計画生成部１３は、運用要求ファイルで並べられた順序が先である運用要求データから順番に、コマンドを取得する。コマンド計画生成部１３がコマンドを取得すると、天体シミュレータ４は、取得されたコマンドを実行した場合の人工天体の状態をシミュレートする。シミュレーションの結果、取得されたコマンドを実行した場合に人工天体に不具合が生じる等のエラーが生じると判定された場合、そのコマンドはコマンド計画に採用されない。判定後、コマンド計画生成部１３は、次の処理順序の運用要求データについて同様の処理を行う。なお、運用要求データは、利用者の希望順位に対応して複数のコマンドを記述する。コマンド計画生成手段３は、運用要求データに記述された複数のコマンドのうち、希望順位が高い方を先に取得する。
【００４０】
コマンド計画が生成されると、コマンド計画生成部１３は、生成されたコマンド計画を示すコマンド計画ファイル及びそのコマンド計画において運用要求データの内容がどのように反映されたのかを示す運用要求反映レポートを作成し、処理優先度制御部１２に出力する。処理優先度制御部１２は、コマンド計画ファイル及び運用要求反映レポートを、それぞれ、コマンド計画ファイル格納部１９及び運用要求反映レポート格納部１８に書き込む。
【００４１】
天体シミュレータ１４は、人工天体の状態をシミュレートする。各日時における人工天体の状態のシミュレート結果は、天体状態時系列テーブル(不図示）に、時系列に格納される。
【００４２】
コマンド計画評価部１５は、運用要求反映レポートに基づいて、コマンド計画生成部１４によって生成されたコマンド計画を評価する。その際に、コマンド計画評価部１５は、運用要求データに含まれる複数のコマンドのうち、希望順位が高いコマンドが多く採用されているコマンド計画ほど評価点が高くなるように評価する。なお、希望順位の評価点への変換は、希望順位と評価点の対応を示す評価点テーブル２０に基づく。
【００４３】
以下、図３から図６を用いて、運用要求テーブル１６、処理順定義テーブル１７、運用要求反映レポート格納部１８、コマンド計画ファイル格納部１９及び評価点テーブル２０のデータ構造について説明する。
【００４４】
まず、図３を用いて運用要求テーブル１６について説明する。運用要求テーブル１６は、運用要求受付部１１によって利用者から受け付けられた運用要求データを格納する。運用要求データは、１以上のコマンドを記述する。ここで、運用要求データに、第１希望のコマンド、第２希望のコマンド、というように、実行を希望する希望順位を付けて複数のコマンドを記述する事が可能である。そのために、運用要求データは、項目として、運用要求データの名称、利用者が実行を希望する順位である希望順位、希望順位ごとに、コマンドの実行を希望する日時であるコマンド実行希望日時及びコマンドを含む。各運用要求データは名称によって識別される。
【００４５】
図３に、運用要求テーブル１６に格納される運用要求データの一例を示す。図３には、「機器α観測」という名称をもつ運用要求データが示されている。図３に示すように、運用要求データ「機器α観測」には、第１希望のコマンド及び第２希望のコマンドが記述され、さらに、この第１希望及び第２希望のコマンドをコマンド計画に反映する事が必須ではないことが記述されている。なお、コマンド計画に反映することが必須でないコマンドは、バス系計画に属するコマンドであることが多い。
【００４６】
次に、図４を用いて処理順定義テーブル１７について説明する。処理順定義テーブル１７は、運用要求データの処理順序を定義する処理順定義レコードを格納する。上述のように、処理優先度制御部１２は、処理優先度を複数の運用要求データの中から順に１つずつ取り出して全ての運用要求データを順序付けて並べる事により、処理順定義レコードを生成する。処理順定義テーブル１７に格納される処理順定義レコードの数は、順列の総数と同じである。図４に示すように、処理順定義レコードは、運用要求データの名称の並びを項目として含む。ここで、処理順定義テーブル１７の行は可変長であることとしてもよい。
【００４７】
図４には、名称がそれぞれ「機器α観測」、「バス機器βのＨＫ（House Keeping：状態監視）１」及び「バス機器Θのメンテ（メンテナンスの略）」である３つの運用要求データの処理順序が、全通り格納されている。この処理順序に基づいて、コマンド計画生成部１３は、各運用要求データをコマンド計画に反映する処理を行う。例えば、図４に示す処理順定義テーブル１７の１行目に示される処理順定義レコードに基づくと、先に運用要求データ「機器α観測」が処理され、次に運用要求データ「バス機器βのＨＫ１」が処理され、最後に運用要求データ「バス機器Θのメンテ」が処理される。同様に２行目に示される処理順序に基づくと、先に運用要求データ「機器α観測」が処理され、次に運用要求データ「バス機器Θのメンテ」が処理され、最後に運用要求データ「バス機器βのＨＫ１」が処理される。
【００４８】
３つのデータの順列であるため、順列の総数は、３！＝３×２＝６であるから、図４に示すように、このような処理順序が全部で６つ処理順定義テーブル１７に格納されている。なお、上述のように、先に処理される運用要求データほど、優先度は高くなる。
【００４９】
従来技術によれば、「バス系計画の絶対優先」の考え方に基づいて、各運用要求データに予め固定的な優先度がつけられていた。しかし、本発明によれば、各運用要求データに予め固定的な優先度をつけない。コマンド計画生成装置１０は、各運用要求データの優先度を全通り作成し、各通りそれぞれについて、コマンド計画を作成する処理を行う。
【００５０】
次に、図５を用いて運用要求反映レポート格納部１８について説明する。運用要求反映レポート格納部１８は、運用要求反映レポートを格納する。運用要求反映レポートは、コマンド計画に反映されたコマンドが、どの運用要求データに記述されているのか、その希望順位は何位であるのかを示す。図５に示すように、運用要求反映レポートは、項目として、コマンド計画に反映されたコマンドを記述する運用要求データの名称、そのコマンドが開始される日時を示す先頭年月日時刻及び、そのコマンドの希望順位を含む。運用要求データに記述されたコマンドがコマンド計画に反映されるごとに、コマンド計画生成部１３によって１行レコードが追加される。
【００５１】
図５の例において、コマンド計画生成部１３が、図４に示す処理順定義テーブル１７の１行目に示された処理順序に基づいて、「機器α観測」、「バス機器べーたのＨＫ１」及び「バス機器Θのメンテ」の３つの運用要求データを処理した場合の運用要求反映レポートを示す。図５によれば、運用要求データ「機器α観測」に記述されるコマンドのうち、コマンド計画に反映されたコマンドは、第１希望のコマンドであり、また、同様に、運用要求データ「バス機器βのＨＫ１」及び「バス機器Θのメンテ」記述されるコマンドのうち、コマンド計画に反映されたコマンドは、ともに第２希望である事が分かる。
【００５２】
コマンド計画ファイル格納部１８は、コマンド計画生成部１３によって生成されたコマンド計画を示すコマンド計画ファイルを格納する。コマンド計画ファイルは、コマンド計画に反映されたコマンドを示す。コマンド計画ファイルについては、従来と同様であるため説明を省略する。
【００５３】
最後に、図６を用いて、評価点テーブル２０について説明する。評価点テーブル２０は、希望順位と、その希望順位のコマンドがコマンド計画に反映された場合の評価点の対応を示す。評価点テーブル２０内のデータは、コマンド計画生成装置１０のユーザ、つまりコマンド計画立案者による入力に基づく。図６において、例１と例２が示されている。例１は、第１希望のコマンドがコマンド計画に反映されることを重視し、第１希望のコマンドがコマンド計画に反映された場合の評価点と、第２希望以下のコマンドが反映された場合の評価点とを大きく異なるように設定した評価点テーブルの例を示す。例２は、逆に、第１希望のコマンドがコマンド計画に反映された場合の評価点と、第２希望及び第３希望のコマンドがコマンド計画に反映された場合の評価点とが同じになるように設定した評価点テーブルの例を示す。コマンド計画立案者は、人工天体の運用時期等に即して柔軟に評価点テーブル２０の内容を変更できる。
【００５４】
以下、コマンド計画生成装置１０において行われる処理の手順について説明する。コマンド計画生成装置１０にコマンド計画を生成させるのに先立ち、まず、利用者は、運用要求データを作成し、その運用要求データをコマンド計画生成装置１０に登録させる。利用者の端末とコマンド計画生成装置１０とが不図示のネットワークを介して接続されている場合、登録はｆｔｐ（file transfer protocaol）やｓｃｐ（secure commerce protocol）等を用いて運用要求データを転送することとしてもよい。
【００５５】
運用要求受付部１１は、利用者から受け付けた運用要求データに文法エラーなどが無いか文法チェッカで検証する。そして、運用要求受付部１１は、運用要求データが所定の書式に則って作成されている場合、利用者が作成した運用要求データを受け付けて、運用要求テーブル１６に書き込む。基本的に、運用要求受付部１１は、随時運用要求データを受け付ける。次に、コマンド計画立案者は、所定のタイミングで処理優先度制御部１２を起動させ、コマンド計画生成装置１０にコマンド計画を生成させる。
【００５６】
続いて、コマンド計画を生成する処理の流れについて説明する。コマンド計画を生成する際、まず、処理優先度制御部１２は、運用要求データの処理順序を定義する。以下、図７を用いて処理優先度の制御処理について説明する。
【００５７】
図７に示すように、最初に、処理優先度制御部１２は、運用要求テーブル１６に格納されている運用要求データを１つずつ取り出して順に並べる事により、処理順序を生成し、生成された処理順序を記述する行レコード、つまり処理順定義レコードを処理順定義テーブル１７に書き込む（Ｓ１０）。その際、上述のように、処理優先度制御部１２は、１つの処理順序を生成するのではなく、互いに異なる複数の処理順序を生成する。ここで、生成される互いに異なる処理順序の数は、順列の総数に相当する。後述のコマンド計画の生成処理では、先に処理される運用要求データが残っている人工天体のリソースを確保する、つまり優先される。その為、１つの処理順定義レコードに定義された順序が、１回のコマンド計画の生成処理における運用要求データの優先度を決定する。
【００５８】
続いて、処理優先度制御部１２は、処理順定義レコードに基づいて、コマンド計画生成部１３にコマンド計画を生成する処理を行わせる。そのために、まず、処理優先度制御部１２は、処理対象となる処理順定義レコードを、処理順定義テーブル１７の０行目に初期化する（Ｓ１１）。
【００５９】
さらに、処理優先度制御部１２は、今まで処理対象であった処理順定義レコードが処理順定義テーブル１７のｎ行目とすると、次の処理対象となる処理順定義レコードを、ｎ＋１行目に設定する（Ｓ１２）。
【００６０】
続いて、処理優先度制御部１２は、処理順定義テーブル１７の全てのレコードについての処理を終了したか否か判定する（Ｓ１３）。全てのレコードについて処理を終了した場合（Ｓ１３：Ｙｅｓ）、処理優先度の制御処理を終了する。この後、コマンド計画の評価処理が行われる。
【００６１】
まだ、全てのレコードについて処理を終了していない場合（Ｓ１３：Ｎｏ）、処理優先度制御部１２は、処置対象となっている処理順定義レコードに基づいて、処理順序が１番となっている運用要求レコードを先頭にして順番に運用要求レコードを並べることにより、運用要求ファイルを作成する。そして、その運用要求ファイルをコマンド計画生成部１３に出力し、コマンド計画生成部１３を呼び出してコマンド計画の生成処理を行わせる（Ｓ１４）。
【００６２】
コマンド計画の生成処理は、処理優先度の制御処理のサブフローである。コマンド計画生成部１３は、その運用要求ファイルに基づいてコマンド計画を生成することができた場合、そのコマンド計画を示すコマンド計画ファイル及び、そのコマンド計画で反映された各コマンドの運用要求データにおける希望順位を示す運用要求反映レポートを処理優先度制御部１２に出力する。処理優先度制御部１２は、そのコマンド計画ファイル及び運用要求反映レポートをそれぞれ、コマンド計画ファイル格納部１９及び運用要求反映レポート格納部１８に格納し、Ｓ１２に戻る。コマンド計画を生成することができなかった場合、コマンド計画生成部１３は、コマンド計画を生成することができなかったことを示すエラー情報を処理優先度制御部１２に出力し、処理はＳ１２に戻る。このコマンド計画生成部１３による処理について、詳しくは後述する。
【００６３】
上述のように、処理優先度制御部１２は、バス系計画と搭載系計画のいずれに属するのかに関係なく、全ての運用要求データを同様に扱い、順列に基づいて各運用要求データの処理順序、つまりは優先度を決定する。そして、処理優先度制御部１２は、１つだけの運用要求ファイルを生成して優先度を固定的にするのではなく、異なる処理順序の数に応じて異なる運用要求ファイルを生成する。
【００６４】
図８に運用要求ファイルの構造の一例を示す。図８に示すように、運用要求ファイルは、処理順が最初である運用要求データを先頭にして処理順に並べられた運用要求データによって構成される。また、運用要求データが複数のコマンドを記述する場合、運用要求データ内では、希望順位が最も高いコマンドを先頭に、コマンドが並べられている。
【００６５】
以下、図９を用いてコマンド計画の生成処理について説明する。なお、この説明において、説明の都合上、処理順定義テーブル１７内の各行の処理を順次処理である様にフローチャートをつくっているが、各行の処理は並行処理でもよい。
【００６６】
図７のＳ１４において、処理優先度制御部１２が、運用要求ファイルを入力ファイルとしてコマンド計画生成部１３を呼び出すと、図９に示すコマンド計画の生成処理が開始される。まず、コマンド計画生成部１３は、処理の開始にあたり、天体シミュレータ１４とのインターフェースとなる天体状態時系列テーブル（不図示）、コマンド計画ファイル及び運用要求反映レポートを初期化する（Ｓ２０）。
【００６７】
続いて、コマンド計画生成部１３は、運用要求ファイルから、運用要求データを１つ読み込む（Ｓ２１）。なお、運用要求データは、運用要求ファイルの先頭から順に、つまり、優先度の高い順に読み込まれる。
【００６８】
コマンド計画生成部１３は、運用要求ファイル内の全ての運用要求データを処理し終えたか否か判定する（Ｓ２２）。全ての運用要求データを処理し終えている場合（Ｓ２２：Ｙｅｓ）、コマンド計画生成部１３は、コマンド計画ファイル及び運用要求反映レポートを処理優先度制御部１２に出力し、図７に示すメインフローに復帰する。
【００６９】
全ての運用要求データを処理し終えていない場合（Ｓ２２：Ｎｏ）、コマンド計画生成部１３は、Ｓ２１で読み出した運用要求データについての処理をはじめる。そのために、コマンド計画生成部１３は、Ｓ２１で読み出した運用要求データから最も希望順位が高いコマンドを読み込む（Ｓ２３）。
【００７０】
コマンド計画生成部１３は、運用要求データ内の全てのコマンドについて処理し終えたか否か判定する（Ｓ２４）。全てのコマンドを処理し終えている場合（Ｓ２４：Ｙｅｓ）、Ｓ２９に進む。Ｓ２９については後述する。そうでない場合（Ｓ２４：Ｎｏ）、コマンド計画生成部１３は、Ｓ２３で読み込んだコマンドを天体シミュレータ１４に出力する（Ｓ２５）。
【００７１】
天体シミュレータ１４は、天体時系列テーブル(不図示）に格納されている人工天体の状態を示す情報及びそのコマンドに基づいて、そのコマンドをコマンド計画に反映した場合の人工天体の状態をシミュレートし（Ｓ２６）、さらに、そのシミュレーション結果にエラーがないか否か判定する（Ｓ２７）。例えば、そのコマンドをコマンド計画に反映することによって人工天体に不具合等が生じる場合、シミュレーション結果にエラーがあることになる。なお、シミュレーション及びエラーの有無の判定は公知であるため詳しい説明を省略する。
【００７２】
シミュレーション結果にエラーがある場合（Ｓ２７：Ｎｏ）、処理はＳ２３に戻る。エラーがない場合（Ｓ２７：Ｙｅｓ）、コマンド計画生成部１３は、そのコマンドをコマンド計画に反映する。さらに、コマンド計画生成部１３は、運用要求反映レポート格納部１８に格納されている運用要求反映レポートに１行追加し、コマンド計画に反映されたコマンドの希望順位及び先頭年月日時刻を記録する。また、Ｓ２６で得られたシミュレーション結果は、天体状態時系列テーブルに格納され、後続の処理に用いられる。（Ｓ２８）。
【００７３】
Ｓ２９において、コマンド計画生成部１３は、運用要求反映レポート格納部１８に１行追加し、その運用要求データに記述されているコマンドをコマンド計画に反映できなかった旨を記録する。
【００７４】
続いて、コマンド計画生成部１３は、その運用要求データに記述されているコマンドが、必ずコマンド計画に反映されなければならない必須のコマンドであるか否か判定する（Ｓ３０）。この判定は、運用要求データに、「コマンドをコマンド計画に反映する事が必須ではない」ことが記述されているか否かに基づいて行われる。例えば、図３に示す、名称が「機器α観測」である運用要求データの例には、この旨が記載されているため、この運用要求データに記述されたコマンドは必須のコマンドではないことが分かる。
【００７５】
運用要求データに記述されたコマンドが必須のコマンドである場合、コマンド計画生成部１３は、生成中のコマンド計画ファイルを破棄し、コマンド計画を生成できなかった旨を示すエラー情報を処理優先度制御部１２に出力し、図７に示すメインフローに復帰する。
【００７６】
このように、コマンド計画生成部１３は、処理順に、運用要求データに人工天体のリソースを割り当てる。従って、後に処理される運用要求データ程、人工天体のリソースが枯渇し、コマンド計画に反映されない可能性が高くなる。そして、運用要求データに記述されたコマンドのうち、第何希望のコマンドがコマンド計画に反映されたかは、運用要求反映レポートに示される。第１希望から第ｎ希望までの全てのコマンドをコマンド計画に反映できない場合には、コマンド計画生成部１３は、その運用要求データをコマンド計画に反映できない。
【００７７】
以下、具体的に例を挙げて、図７及び図９に示す処理の結果について説明する。図１０に、処理優先度制御部１２による処理優先度の制御結果の一例を示す。この例は、図４に示す処理順定義テーブル１７に基づいて、３つの運用要求データについて処理を行った場合の結果を示す。図１０の各行に示される結果は、それぞれ、図４に示す処理順定義テーブル１７の同じ行に格納された処理順定義レコードに対応する。図４には６行の処理順定義レコードが示されているため、図１０にも、全部で６行の処理結果が示されている。
【００７８】
図４の１行目の処理順定義レコードには、最初に、運用要求データ「機器α観測」を処理し、次に、運用要求データ「バス機器βのＨＫ１」、最後に、運用要求データ「バス機器Θのメンテ」を処理することが記述されている。図１０の１行目の処理結果によれば、運用要求データ「機器α観測」については第１希望のコマンドが、運用要求データ「バス機器βのＨＫ１」及び「バス機器Θのメンテ」については共に第２希望のコマンドが、コマンド計画に反映された事が分かる。
【００７９】
また、図１０の４行目に示す処理結果によれば、運用要求データ「バス機器βのＨＫ１」に続いて、運用要求データ「バス機器Θのメンテ」についての処理を行い、その運用要求データに記述された第１希望から第５希望までの全てのコマンドをコマンド計画に反映できなかった後、処理が終了されたことが分かる。つまり、最後の運用要求データ「機器α観測」については処理が行われていない。これは、運用要求データ「バス機器Θのメンテ」に記述されたコマンドが必須のコマンドであり、それらのコマンドをコマンド計画に反映できなかったため、コマンド計画を生成できなかったことを意味する。同様に、図１０の６行目に示す処理結果も、コマンド計画を生成できなかったことを意味する。
【００８０】
図１０に示すような場合、６行の処理順定義レコードについて処理した結果、４つのコマンド計画ファイルが生成されたため、処理優先度の制御処理の結果として、処理優先度制御部１２は、４つの互いに異なるコマンド計画ファイルと、各コマンド計画ファイルに対応する運用要求反映レポートを得ることができる。
【００８１】
このように、同じ運用要求データが運用要求ファイル内に並べられている場合であっても、運用要求ファイル内の運用要求データの並び順が異なると、コマンド間のリソースの取り合いの関係上、それらの運用要求ファイルについて生成されるコマンド計画は互いに異なることが多い。
【００８２】
処理優先度の制御処理が終了すると、いくつかのコマンド計画ファイルが生成される。特に、運用要求データの数が膨大な場合、生成されるコマンド計画ファイルの数も多くなる。従って、コマンド計画立案者に、コマンド計画を評価するためのデータを提供することが必要になる。
【００８３】
そのために、コマンド計画ファイルに付随する運用要求反映レポートの各行にある「反映した希望順位」を評価点テーブル２０で定義された評価点に変換する、コマンド計画の評価処理が行われる。以下、図１１を用いて、コマンド計画の評価処理の手順について説明する。
【００８４】
まず、コマンド計画評価部１５は、運用要求反映レポート格納部１８に格納された運用要求反映レポートの全てについて処理を行ったか否か判定する（Ｓ４０）。まだ、全ての運用要求反映レポートについて処理を行っていない場合（Ｓ４０：Ｎｏ）、コマンド計画評価部１５は、運用要求反映レポート格納部１８からまだ処理されていない運用要求反映レポートを１つ取り出す。続いて、コマンド計画評価部１５は運用要求反映レポート及び評価点テーブル２０に基づいて、コマンド計画の評価を行う。以下、具体的に例を挙げてコマンド計画の評価方法について説明する。
【００８５】
図５に示す運用要求反映レポートによれば、あるコマンド計画において、運用要求データ「機器α観測」の第１希望、運用要求データ「バス機器βのＨＫ１」の第２希望及び運用要求データ「バス機器Θのメンテ」の第２希望が反映されている。図６に示す評価点テーブル２０の例１によれば、第１希望及び第２希望がコマンド計画に反映されると、それぞれ１０点及び６点がそのコマンド計画の評価点に加算される。従って、そのコマンド計画の評価点は、１０＋６＋６＝２２点となる。コマンド計画評価部１５は、評価結果を、評価順位テーブルの１行として出力する。
【００８６】
全ての運用要求反映レポートについて処理を行った場合（Ｓ４０：Ｙｅｓ）、コマンド計画評価部１５は、評価結果に基づいて、コマンド計画ファイルの評価順位テーブルを作成し（Ｓ４１）、処理を終了する。この評価順位テーブルは、コマンド計画立案者の端末、また、必要に応じて利用者の端末に出力される。
【００８７】
図１２に、評価順位テーブルの一例を示す。図１２に示す評価順位テーブルは、図１０に示す処理優先度の制御処理の結果についての評価結果を示す。図１２に示すように、評価順位テーブルには、評価結果に基づいて、生成された複数のコマンド計画がソートされて出力されている。
【００８８】
コマンド計画立案者は、最終的に人工天体に送信するコマンド計画を決定するために、この評価順位テーブルを利用する事ができる。また、人工天体の利用者は、運用要求反映レポートから、自分が出した運用要求データの内容がどのようにコマンド計画に反映されたのかを知り、出来上がったコマンド計画を迅速に検討することができる。
【００８９】
なお、実際の運用では、評価点として最高値をとったコマンド計画が絶対的に良いというものでは無く、他の利用者の運用要求データを見た時には、自身の運用要求データの優先度が変わることがある。
【００９０】
以下、上記実施形態の変形例について説明する。上記説明において、処理優先度制御部１２は、運用要求データを１つずつ順に並べる事により、処理順定義レコードを生成するとして説明した。しかし、以下のようにして処置順定義レコードを生成するとしてもよい。
【００９１】
例えば、上記説明において、各運用要求データには、予め定められた優先度は無いとして、順列の通りの総数だけの処理順定義レコードを生成するとして説明した。しかし、「この運用要求データが、ある運用要求データよりも優先されなければ、コマンド計画が成立し得ない」というような場合も実際はあり得る。このような場合、コマンド計画立案者が、予めある程度の処理順序を定めておくこととしてもよい。これにより、明らかにコマンド計画が成立し得ないような場合についてコマンド計画の生成処理を行うことを省くことが可能となる。
【００９２】
そのために、コマンド計画生成装置１０は、図１３に示すようなレベル定義テーブルを更に備えることとしてもよい。図１３に示すレベル定義テーブルには、「機器α観測」、「機器Γ観測」、「機器φ観測」、「バス機器βのＨＫ１」、「バス機器βのＨＫ２」及び「バス機器Θのメンテ」の５つの運用要求データが、３つのレベルに分けて示されている。このうち、「機器α観測」、「機器Γ観測」及び「機器φ観測」の３つの運用要求データは、図１３に示すレベル定義テーブルの１行目に、同じレベル内に定義されている。同様に、「バス機器βのＨＫ１」及び「バス機器βのＨＫ２」の２つの運用要求データも、図１３に示すレベル定義テーブルの２行目に、同じレベル内に定義されている。
【００９３】
１つのレベル内の運用要求データの処理順序は、レベル定義テーブルの１行に定義され、処理優先度制御部１２はその処理順序が変わらないように、順列を生成する。従って、５つの運用要求データは、２つの運用要求データの組と、１つの運用要求データとからなる３つのレベルに分けられ、処理優先度制御部１２は、３つのレベルの順列を生成する。より具体的には、図１３に示す例の場合、処理優先度制御部１２は、図１３に示すレベル定義テーブルに定義される３つのレベルの順列として、合計６つの処理順定義レコードを生成する。生成される６つの処理順定義レコードは、図４に示す処理順定義テーブル１７に示される処理順定義レコード中の運用要求データ「機器α観測」及び「バス機器βのＨＫ１」を、それぞれ、３つの運用要求データの組｛「機器α観測」、「機器Γ観測」、「機器φ観測」｝及び２つの運用要求データの組｛「バス機器βのＨＫ１」、「バス機器βのＨＫ２」｝に置き換えたものに相当する。
【００９４】
また、上述のレベル定義テーブルを用いる代わりに、予め並び方の処理順序を決めておきたい１以上の運用要求データを１つにまとめたファイルを複数用意し、処理優先度制御部１２は、これら複数のファイルの順列を生成することとしても良い。これによっても、レベル定義テーブルを用いる場合と同様の効果を得ることができる。
【００９５】
上記において説明したコマンド計画生成装置１０は、コンピュータを用いて構成することができる。以下、コンピュータの構成について、図１４を用いて説明する。
【００９６】
図１４に示すようにコンピュータ３０は、ＣＰＵ３１、メモリ３２、入力装置３３、出力装置３４、外部記憶装置３５、媒体駆動装置３６、及びネットワーク接続装置３７を備え、それらはバス３８により互いに接続されている。
【００９７】
メモリ３２は、例えば、ＲＯＭ（ReadOnly Memory）、ＲＡＭ（Random Access Memory）等を含み、処理に用いられるプログラムとデータを格納する。コマンド計画生成装置１０を構成する運用要求受付部１１、処理優先度制御部１２、コマンド計画生成部１３、天体シミュレータ１４及びコマンド計画評価部１５は、コンピュータ３０のメモリ３２の特定のプログラムコードセグメントにプログラムとして格納される。なお、コマンド計画生成装置１０によって行われる処理については、図を用いて既に説明した。
【００９８】
ＣＰＵ３１は、メモリ３２を利用して上述のプログラムを実行することにより、必要な処理を行う。
入力装置３３は、例えば、キーボード、ポインティングデバイス、タッチパネル等であり、ユーザからの指示や情報の入力に用いられる。出力装置３４は、例えば、ディスプレイやプリンタ等であり、コンピュータのユーザへの問い合わせ、処理結果等の出力に用いられる。
【００９９】
外部記憶装置３５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置等である。上述のプログラムをコンピュータ３０の外部記憶装置３５に保存しておき、必要に応じて、そのプログラムをメモリ３２にロードして使用することもできる。
【０１００】
媒体駆動装置３６は、可搬記録媒体３９を駆動し、その記録内容にアクセスする。可搬記録媒体３９としては、メモリカード、メモリスティック、フレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、光ディスク、光磁気ディスク、ＤＶＤ（Digital Versatile Disk）等、任意のコンピュータ読み取り可能な記録媒体が用いられる。この可搬記録媒体３９に上述のプログラムを格納しておき、必要に応じて、それをコンピュータ３０のメモリ３２にロードして使用することもできる。
【０１０１】
ネットワーク接続装置３７は、ＬＡＮ、ＷＡＮ等の任意のネットワークＮ（回線）を介して外部の装置を通信し、通信に伴うデータ変換を行う。また、必要に応じて、上述のプログラムを外部の装置から受け取り、それをコンピュータ３０のメモリ３２にロードして使用することもできる。
【０１０２】
図１５は、図１４のコンピュータにプログラムとデータを供給することのできるコンピュータで読み取り可能な記録媒体及び伝送信号を示している。
上述の実施形態において説明したコマンド計画生成装置１０に相当する機能を汎用的なコンピュータに行わせることも可能である。そのためには、上述のプログラムを、コンピュータで読み取り可能な記録媒体３９に予め記憶させておく。そして、図１５に示すようにしてその記録媒体３９からプログラムをコンピュータに読み出させて、そのコンピュータのメモリ３２や外部記憶装置３５に一旦格納させ、この格納されたプログラムをそのコンピュータの有するＣＰＵ３１に読み出させて実行させるように構成すればよい。なお、メモリ３２及び外部記憶装置３５も、コンピュータで読み取り可能な記録媒体である。
【０１０３】
また、プログラム（データ）提供者４０が有するＤＢから、通信回線（ネットワーク）３１を介して、プログラムをダウンロードすることとしてもよい。この場合、例えば、プログラム（データ）提供者４０が有する送信側コンピュータでは、プログラムを表現するプログラム・データをプログラム・データ・シグナルに変換し、モデムを用いて変換されたプログラム・データ・シグナルを変調することにより伝送信号を得て、得られた伝送信号を通信回線４１（伝送媒体）に出力する。プログラムを受信するコンピュータでは、モデムを用いて受信した伝送信号を復調することにより、プログラム・データ・シグナルを得て、得られたプログラム・データ・シグナルを変換することにより、プログラム・データを得る。なお、送信側のコンピュータと受信側のコンピュータの間を接続する通信回線４１（伝送媒体）がデジタル回線の場合、プログラム・データ・シグナルを通信することも可能である。また、プログラムを送信するコンピュータと、プログラムをダウンロードするコンピュータとの間に、電話局等のコンピュータが介在しても良い。
【０１０４】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態及び変形例に限定されるものではなく、その他の様々な変更が可能である。
（付記１）  人工天体の管制のためのコマンドによって構成されるコマンド計画を生成する制御をコンピュータに行わせるコンピュータ・プログラムであって、
実行させたい複数のコマンドとその希望順位を記述する複数の運用要求データを取得し、
順序をつけて並べられた前記複数の運用要求データからなる運用要求ファイルを複数作成し、
前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記複数の運用要求ファイル各々について前記コマンド計画を生成する、
ことを含む制御を前記コンピュータに行わせることを特徴とするコンピュータ・プログラム。
【０１０５】
（付記２）  前記複数の運用要求データの順列を生成することにより、前記複数の運用要求ファイルは生成される、
ことを特徴とする付記１に記載のコンピュータ・プログラム。
【０１０６】
（付記３）  前記複数の運用要求データを複数のレベルに分け、前記レベルの順列を生成することにより、前記複数の運用要求ファイルは生成される、
ことを特徴とする付記１に記載のコンピュータ・プログラム。
【０１０７】
（付記４）  前記複数の運用要求データについて生成された複数の前記コマンド計画のおのおのについて、前記コマンド計画に反映された各コマンドの希望順位に基づいて評価点を算出し、
前記評価点に基づいて、前記複数のコマンド計画をソートして出力させる、
ことを更に含む制御を前記コンピュータに行わせることを特徴とする付記１に記載のコンピュータ・プログラム。
【０１０８】
（付記５）  人工天体の管制のためのコマンドによって構成されるコマンド計画を生成する制御をコンピュータに行わせるプログラムを記録した記録媒体であって、
実行させたい複数のコマンドとその希望順位を記述する複数の運用要求データを取得し、
前記複数の運用要求データを順序づけて並べることにより運用要求ファイルを作成し、
前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記コマンド計画を生成する、
ことを含む制御を前記コンピュータに行わせるプログラムを記録した記録媒体。
【０１０９】
（付記６）  コンピュータが、人工天体の管制のためのコマンドによって構成されるコマンド計画を生成するコマンド計画生成方法であって、
実行させたい複数のコマンドとその希望順位を記述する複数の運用要求データを取得し、
前記複数の運用要求データを順序づけて並べることにより運用要求ファイルを作成し、
前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記コマンド計画を生成する、
ことを含むことを特徴とするコマンド計画生成方法。
【０１１０】
（付記７）  人工天体の管制のためのコマンドにより構成されるコマンド計画を生成するコマンド計画生成装置であって、
実行させたい複数のコマンドとその希望順位を記述する複数の運用要求データを取得する運用要求受付手段と、
前記複数の運用要求データを順序づけて並べることにより運用要求ファイルを作成する処理優先度制御手段と、
前記運用要求ファイル内において並べられた順序が先である運用要求データから順番に、運用要求データ内の希望順位が高いコマンドを優先して前記コマンド計画に反映させることにより、前記コマンド計画を生成するコマンド計画生成手段と、
を備えることを特徴とするコマンド計画生成装置。
【０１１１】
【発明の効果】
以上詳細に説明したように、本発明によれば、順序をつけて並べられた前記複数の運用要求データからなる運用要求ファイルを複数生成し、複数の運用要求ファイル各々についてコマンド計画を生成する。これにより、予め定められた優先度に従って特定のコマンドが偏重されるのではなく、全体が合理的にバランスしたコマンド計画の生成を支援することを可能とする。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】コマンド計画生成システムの構成図である。
【図３】運用要求データの一例を示す図である。
【図４】処理順定義テーブルの構造の一例を示す図である。
【図５】運用要求反映レポートの一例を示す図である。
【図６】評価点テーブルの一例を示す図である。
【図７】処理優先度の制御処理の手順を示すフローチャートである。
【図８】運用要求ファイルの構造の一例を示す図である。
【図９】コマンド計画の生成処理の手順を示すフローチャートである。
【図１０】処置優先度の制御処理の結果の例を示す図である。
【図１１】コマンド計画の評価処理の手順を示すフローチャートである。
【図１２】コマンド計画ファイルの評価順位テーブルの一例を示す図である。
【図１３】レベル定義テーブルの構造の一例を示す図である。
【図１４】コンピュータの構成図である。
【図１５】コンピュータにデータ及びプログラムを供給することが可能な記録媒体や伝送信号を説明する図である。
【符号の説明】
１  運用要求受付手段
２  処理優先度制御手段
３  コマンド計画生成手段
４  天体シミュレータ
５  コマンド計画評価手段
１０  コマンド計画生成装置
１１  運用要求受付部
１２  処理優先度制御部
１３  コマンド計画生成部
１４  人工天体シミュレータ
１５  コマンド計画評価部
１６  運用要求テーブル
１７  処理順定義テーブル
１８  運用要求反映レポート格納部
１９  コマンド計画ファイル格納部
２０  評価点テーブル
３０  コンピュータ
３１  ＣＰＵ
３２  メモリ
３３  入力装置
３４  出力装置
３５  外部記憶装置
３６  媒体駆動装置
３７  ネットワーク接続装置
３８  バス
３９  可搬記録媒体
４０  プログラム（データ）提供者
４１  回線
Ｓ  ステップ
【図１】
0003904958.tif 000002
【図２】
0003904958.tif 000003
【図３】
0003904958.tif 000004
【図４】
0003904958.tif 000005
【図５】
0003904958.tif 000006
【図６】
0003904958.tif 000007
【図７】
0003904958.tif 000008
【図８】
0003904958.tif 000009
【図９】
0003904958.tif 000010
【図１０】
0003904958.tif 000011
【図１１】
0003904958.tif 000012
【図１２】
0003904958.tif 000013
【図１３】
0003904958.tif 000014
【図１４】
0003904958.tif 000015
【図１５】
0003904958.tif 000016