(57)【特許請求の範囲】
【請求項１】
衛星に撮影させる撮影領域の情報を含む要求をスケジュール要求者から受け付け、記憶装置に格納する手段と、
前記衛星の軌道と視野範囲とに基づき前記撮影領域の少なくとも一部を観測可能なパスを算出し、算出された前記パスについて前記撮影領域の少なくとも一部を観測するためのロール角及び緯度引数を算出し、算出された前記パスと前記ロール角と前記緯度引数とにて特定される観測範囲を前記撮影領域の全体を含むように組み合わせることにより実現パターンを構成し、前記スケジュール要求者の要求の下位階層データとして前記実現パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該実現パターンの下位階層データとして当該実現パターンを構成する観測範囲をＡＮＤ関係にて前記記憶装置に格納する要求分析手段と、
前記衛星が保持する機器又は前記衛星により観測されたデータを受信する地上局を運用する上での制約と運用のスケジュール状態を保持する制約テーブルとを制約項目毎に管理する運用状態管理手段と、
前記記憶装置に格納された各前記観測範囲について、当該観測範囲を観測するための運用条件であって前記制約を満たす運用条件を、前記運用状態管理手段から各前記制約項目について１又は複数取得し、前記制約項目毎に１の前記運用条件を含むように、取得された前記運用条件を組み合わせて運用パターンを生成し、当該観測範囲の下位階層データとして当該運用パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該運用パターンの下位階層データとして当該運用パターンを構成する運用条件をＡＮＤ関係にて前記記憶装置に格納する運用パターン構成手段と、
前記記憶装置に格納されている特定の運用パターンを構成する運用条件を含む制約確認要求を前記運用状態管理手段に出力するスケジュール立案手段と、
を有し、
前記運用状態管理手段は、前記制約確認要求を受け取った場合、当該制約確認要求に含まれる運用条件が前記制約項目の運用のスケジュール状態との関係でスケジューリング可能か否かを前記制約テーブルを参照して判断し、判断結果を前記スケジュール立案手段に出力し、
前記スケジュール立案手段は、前記判断結果がスケジューリング可能を示している場合、前記特定の運用パターンを構成する運用条件を含む登録依頼を前記運用状態管理手段に出力し、
前記運用状態管理手段は、前記登録依頼を受け取った場合、当該登録依頼に含まれる前記運用条件に従って前記運用のスケジュール状態を更新する
ことを特徴とするコンピュータ・システム。
【請求項２】
要求受付部と、要求分析部と、衛星が保持する機器又は前記衛星により観測されたデータを受信する地上局を運用する上での制約と運用のスケジュール状態を保持する制約テーブルとを制約項目毎に管理する運用状態管理部と、運用パターン構成部と、スケジュール立案部と、記憶装置とを有するコンピュータにより実行されるスケジューリング方法であって、
前記要求受付部により、前記衛星に撮影させる撮影領域の情報を含む要求をスケジュール要求者から受け付け、前記記憶装置に格納するステップと、
前記要求分析部により、前記衛星の軌道と視野範囲とに基づき前記撮影領域の少なくとも一部を観測可能なパスを算出し、算出された前記パスについて前記撮影領域の少なくとも一部を観測するためのロール角及び緯度引数を算出し、算出された前記パスと前記ロール角と前記緯度引数とにて特定される観測範囲を前記撮影領域の全体を含むように組み合わせることにより実現パターンを構成し、前記スケジュール要求者の要求の下位階層データとして前記実現パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該実現パターンの下位階層データとして当該実現パターンを構成する観測範囲をＡＮＤ関係にて前記記憶装置に格納するステップと、
前記運用パターン構成部により、前記記憶装置に格納された各前記観測範囲について、当該観測範囲を観測するための運用条件であって前記制約を満たす運用条件を、前記運用状態管理部から各前記制約項目について１又は複数取得し、前記制約項目毎に１の前記運用条件を含むように、取得された前記運用条件を組み合わせて運用パターンを生成し、当該観測範囲の下位階層データとして当該運用パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該運用パターンの下位階層データとして当該運用パターンを構成する運用条件をＡＮＤ関係にて前記記憶装置に格納するステップと、
前記運用状態管理部により、前記記憶装置に格納されている特定の運用パターンを構成する運用条件が、各前記制約項目についての運用のスケジュール状態との関係でスケジューリング可能か否かを前記制約テーブルを参照して判断するステップと、
スケジューリング可能であると判断された場合、前記運用状態管理部により、前記特定の運用パターンを構成する運用条件に従って各前記制約項目についての運用のスケジュール状態を更新するステップと、
を含むスケジューリング方法。
【請求項３】
スケジュールのための要求解析プログラムであって、
コンピュータに、
衛星に撮影させる撮影領域の情報を含む要求をスケジュール要求者から受け付け、記憶装置に格納するステップと、
前記衛星の軌道と視野範囲とに基づき前記撮影領域の少なくとも一部を観測可能なパスを算出し、算出された前記パスについて前記撮影領域の少なくとも一部を観測するためのロール角及び緯度引数を算出し、算出された前記パスと前記ロール角と前記緯度引数とにて特定される観測範囲を前記撮影領域の全体を含むように組み合わせることにより実現パターンを構成し、前記スケジュール要求者の要求の下位階層データとして前記実現パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該実現パターンの下位階層データとして当該実現パターンを構成する観測範囲をＡＮＤ関係にて前記記憶装置に格納するステップと、
前記記憶装置に格納された各前記観測範囲について、当該観測範囲を観測するための運用条件であって前記制約を満たす運用条件を、前記衛星が保持する機器又は前記衛星により観測されたデータを受信する地上局を運用する上での制約と運用のスケジュール状態を保持する制約テーブルとを制約項目毎に管理する運用状態管理部から各前記制約項目について１又は複数取得し、前記制約項目毎に１の前記運用条件を含むように、取得された前記運用条件を組み合わせて運用パターンを生成し、当該観測範囲の下位階層データとして当該運用パターンのＩＤをＯＲ関係にて前記記憶装置に格納すると共に、当該運用パターンの下位階層データとして当該運用パターンを構成する運用条件をＡＮＤ関係にて前記記憶装置に格納するステップと、
前記記憶装置に格納されている特定の運用パターンを構成する運用条件が、各前記制約項目についての運用のスケジュール状態との関係でスケジューリング可能か否かを前記制約テーブルを参照して判断するステップと、
スケジューリング可能であると判断された場合、前記特定の運用パターンを構成する運用条件に従って各前記制約項目についての運用のスケジュール状態を更新するステップと、
を実行させるための要求解析プログラム。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、リソースのスケジューリング技術に関する。
【０００２】
【従来の技術】
地球観測衛星は、地球を所定の速度（例えば１周１００分（１５週／日）の速度）で、地上の所定の高度（例えば７００Ｋｍ上空）を飛び回っている。この衛星には、各種のセンサ（光学センサやレーダなど）を搭載可能で、地上のあらゆる場所を観測することができる。衛星が観測したデータは地上に設置された受信局に伝送され、所定の施設で取りまとめられた後、環境・資源の調査などに用いられる。また、図３２に示すように、衛星Ｘは、指定の観測域Ｙをセンサｘ１で観測し、観測結果のデータをアンテナｘ３にて地上の受信局Ｚに送るという動作を行うが、観測しながらリアルタイムにデータを地上に伝送するリアルタイム伝送という動作モードと、観測データを一旦一時記憶装置（テープレコーダ、半導体メモリなど）ｘ２に記録し後に観測データの再生を行って地上に伝送するデータ再生という動作モードとがある。リアルタイム伝送は、観測しながら直ぐに観測データを伝送するため、ロスの少ない衛星運用ではあるが、衛星Ｘが受信局Ｚの上空を飛んでいるときにしか使えない方法である。一時記憶装置（ｘ２）を用いた記録・再生は、任意の場所で観測ができる衛星運用であるが、一時記憶装置（ｘ２）の容量制限から多くのデータを蓄えておくことはできない。
【０００３】
【発明が解決しようとする課題】
このように衛星の運用スケジュール作成においては、衛星及び受信局などの多種多様な制約条件が存在し、制約条件の仕様変更も多い。しかし、従来のスケジュール立案プログラムにおいては、制約条件を条件式（ｉｆ文など）等で記述する方法であったため、仕様変更に伴うプログラムの改修に大きな手数がかかっていた。また、改修により他の条件や計画にどのような影響を及ぼすか特定が難しかった。また、衛星ごとに制約条件は大きく異なるので、衛星ごとにプログラムを作り直す必要もあった。
【０００４】
また、制約条件が多いため、わずかな制約違反でスケジューリングされない要求が発生する場合が多い。例えば、ある緊急性の高い要求をスケジュールに追加したい場合、制約違反となって採用されないこともある。この場合、従来のスケジューリングでは「なぜ採用されなかったのか」「スケジュールのどこを変更すると採用されるのか」「例え要求が半分しか満たされなくてもよいので、制約違反とならない部分はどこか」といったことが容易には分からなかった。従来のスケジューリングでこのような要望を実現するには、制約違反となるパターン毎に条件を分析して、計画を変更するアルゴリズムを記述する必要があった。但し、そのアルゴリズムは、制約の仕様が変更になるとそのままでは使用できなくなる恐れもある。
【０００５】
また、従来の最適化は、ある一定の条件・ロジックに従って立案方法をプログラムに記述する方法を採用していたが、制約条件が変更されたり、評価式が変わると、最適とならなくなり、ロジックの改修が必要であった。また、最適化ロジックの改修も立案プログラム内部まで入り組んでいて、改修が難しいという欠点があった。
【０００６】
さらに、各ユーザが観測したい地点の緯度経度と衛星の軌道から観測できる時間帯や観測時に衛星に与えるパラメタ情報を計算して要求を出さなければならない場合もあった。このような場合には衛星の軌道などの情報を有していないと要求を出すことができず、また多くの知識を有しないと衛星に与えるパラメタ情報を計算できない。もし、設定したパラメタ情報で観測できない場合には即座に要求は不採用になるため、多くの要求を出していずれかが採用されるようにするといった問題も生ずる。
【０００７】
また、「何日何時何分のこの軌道で観測する」という要求を出すユーザもいれば、「富士山を撮影する。時間はいつでもよい。」といった抽象的な要求を出すユーザもいるため、さまざまなレベルの要求に対処できる必要もある。
【０００８】
本発明は、以上のような問題を解決するものであって、ユーザによる様々な要求を一定の構造に変換することによりスケジューリングを容易にするための技術を提供することである。
【０００９】
また本発明の他の目的は、制約条件の管理とスケジュール立案処理とを分離することにより様々な要請及び状況に対し容易に対処可能なスケジューリング技術を提供することである。
【００１０】
【課題を解決するための手段】
本発明の第１の態様に係るコンピュータ・システムは、スケジュール対象に対する要求者（ユーザ）の要求情報を受け付け、記憶装置に格納する手段（例えば実施の形態における要求受付部１）と、スケジュール対象の性質に基づき、要求者の要求を満たし且つ実現可能性のある実現パターンを探索し、要求者の要求と実現パターンと当該実現パターンの内容（例えば実施の形態ではセグメント）とを階層構造データとして記憶装置に格納する要求分析手段（例えば実施の形態における要求分析部５）とを有する。
【００１１】
これにより要求者の要求は、要求者の要求と、スケジュール対象の性質に基づき探索された実現パターンと、当該実現パターンの内容とから構成される階層構造データに変換される。様々なレベルの要求をこのような一定の階層構造データに変換すれば、後のスケジュール立案処理の内容が簡単になる。また、データ管理もしやすくなる。
【００１２】
また、本発明の第１の態様は、スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段（例えば実施の形態におけるリソース・オブジェクト群１２４）と、階層構造データにおける実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を複数のスケジュール状態管理手段から取得し、各制約項目についてのスケジュール情報の組み合わせである運用パターンを実現パターンの内容の下位階層データとして構成し、記憶装置に格納する運用パターン構成手段（例えば実施の形態における前処理部１１０）とをさらに有するような構成であってもよい。
【００１３】
このように各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段を設けることにより、スケジュール立案処理と制約条件の管理とが分離される。よって、スケジュール立案処理ロジックの変更や、制約条件の管理・変更が簡単になる。
【００１４】
さらに、本発明の第１の態様は、複数のスケジュール状態管理手段に、階層構造データにおける運用パターンを、所定の順番（例えば実現パターンの内容の優先度又は運用パターンの優先度）で、当該スケジュール状態管理手段が管理する制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案手段（例えば実施の形態におけるスケジュール立案部（但し前処理部１１０を除く））をさらに有するような構成であってもよい。
【００１５】
本発明の第２の態様に係るコンピュータ・システムは、スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段（例えば実施の形態におけるリソース・オブジェクト群１２４）と、スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を複数のスケジュール状態管理手段から取得し、各制約項目についてのスケジュール情報の組み合わせである運用パターンを実現パターンの内容の下位階層データとして構成する運用パターン構成手段（例えば実施の形態における前処理部１１０）と、複数のスケジュール状態管理手段に、階層構造データにおける運用パターンを、所定の順番で、当該スケジュール状態管理手段が管理する制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案手段（例えば実施の形態における要素マネージャ１１４、立案マネージャ１１８及びリソース・マネージャ１２２）とを有する。
【００１６】
本発明の第２の態様においては、制約条件を管理する複数のスケジュール状態管理手段とスケジュール立案手段とが分離されている。よって、立案ロジックと制約条件とを別個に改修・変更等することが容易になる。
【００１７】
本発明の第３の態様に係るコンピュータ・システムは、スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段（例えば実施の形態におけるリソース・オブジェクト群１２４）と、複数のスケジュール状態管理手段に、スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける実現パターンの内容を、所定の順番で、当該スケジュール状態管理手段が管理する制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、複数のスケジュール状態管理手段に、スケジューリング可能な実現パターンの内容を設定させるスケジュール立案手段（例えば実施の形態におけるスケジュール立案部１１）とを有する。
【００１８】
スケジュール対象が実現パターンの内容をさらに展開する必要が無いような場合には、本発明の第３の態様のような構成で対処することができる。
【００１９】
なお、上述のコンピュータ・システムはコンピュータ・ハードウエアに専用のプログラムをインストールすることによっても実現可能である。この場合、このプログラムは、例えばフロッピーディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【００２０】
【発明の実施の形態】
図１に本発明の一実施の形態に係るシステム概要図を示す。本スケジュール立案システムは、ユーザからの要求を受け付ける要求受付部１と、要求受付部１により受け付けた要求情報を格納する要求格納部３と、要求格納部３に格納された要求情報を解析して要求階層構造データを生成する要求分析部５と、要求分析部５が要求階層構造データを管理する上で使用するデータを格納する要求階層構造管理データ格納部７と、要求分析部５により生成された要求階層構造データを格納する要求階層構造データ格納部９と、要求階層構造データとスケジュール対象の制約条件とに従ってスケジューリングを行うスケジュール立案部１１とを含む。
【００２１】
スケジュール立案部１１は、リソース・オブジェクト群１２４を参照して要求階層構造データから運用パターン（要求要素）を展開する前処理部１１０と、前処理部１１０により生成された要求要素を格納する要求要素格納部１１２と、要求要素格納部１１２に格納された要求要素を管理する要素マネージャ１１４と、要素マネージャ１１４が要求要素を管理する上で使用するデータを格納する要求要素管理データ格納部１１６と、要素マネージャ１１４に対して所定の順番で要求要素を要求し、リソース・マネージャ１２２に要求要素の採用の可否を問い合わせる立案マネージャ１１８と、採用が確定された要求要素のデータを立案マネージャ１１８から受け取って格納する立案結果格納部１２０と、リソース・オブジェクト群１２４と立案マネージャ１１８のインターフェースとなるリソース・マネージャ１２２と、各々管理する制約項目のスケジュール状態との関係で当該要求要素がスケジューリング可能か否かの判断を行い、スケジューリング可能で登録指示を受け取ると各々管理する制約項目のスケジュール状態を更新するリソース・オブジェクト群１２４とが含まれる。
【００２２】
例えば衛星の観測スケジュールを立案する場合には、図２のようなリソース・オブジェクト（一部）が設けられる。すなわち、ルート・オブジェクトであるリソースデータ・オブジェクト２０１と、ルート・オブジェクトより１階層下位の衛星制約オブジェクト２０３及び地上局制約オブジェクト２０５と、地上局制約オブジェクト２０５より１階層下位の可視情報オブジェクト２０７と、衛星制約オブジェクト２０３より１階層下位のセンサ制約オブジェクト２０９とパドル運用制約オブジェクト２１１と電力制約オブジェクト２１３と搭載メモリ運用制約オブジェクト２１９とダウンリンク可視情報オブジェクト２１７と熱制約オブジェクト２１５とを含む。
【００２３】
地上局制約オブジェクト２０５は、例えば衛星で観測されたデータを受信する地上局（受信局）についての制約を管理するオブジェクトであって、地上局に関する下位の制約に対応する下位のリソース・オブジェクトを管理する。ここでは、例えば衛星から観測データを受信できる範囲などを規定する可視情報オブジェクト２０７を下位リソース・オブジェクトとてして管理する。可視情報オブジェクト２０７は、さらに下位のリソース・オブジェクトを管理する場合もある。衛星制約オブジェクト２０３は、例えば衛星自体が保持する機器等から由来する制約を管理するオブジェクトであって、衛星自体が保持する機器等から由来する下位の制約に対応するリソース・オブジェクトを管理する。ここでは、衛星に設置されている各種センサを管理するセンサ制約オブジェクト２０９と、衛星のパドルに関する制約を管理するパドル運用制約オブジェクト２１１と、衛星の電源に関する制約を管理する電力制約オブジェクト２１３と、衛星の温度に関する制約を管理する熱制約オブジェクト２１５と、地上局との通信などに関する制約を管理するダウンリンク可視情報オブジェクト２１７と、搭載メモリの残容量などを管理する搭載メモリ運用制約オブジェクト２１９とを含む。これらの衛星制約オブジェクト２０３の下位のリソース・オブジェクトはさらに詳細な制約に関する下位のリソース・オブジェクトを管理する場合もある。
【００２４】
各リソース・オブジェクトは、当該リソース・オブジェクトが管理する制約の性質に応じて、スケジュール状態を制約テーブルとして管理している。搭載メモリ運用制約オブジェクト２１９の場合には、例えば時間軸に沿ったメモリ容量の残量が管理される。すなわち、ある時間に観測データを格納する場合には、観測時間以降観測データ分のメモリ容量が減少し、次に地上局（受信局）と通信する予定時間の後にはメモリ容量が増加するような管理がなされる。
【００２５】
なおこれらのリソース・オブジェクトは、例えば以下に示すようなＸＭＬ（eXtended Markup Language）データがオブジェクト化されることにより生成される。なお、表１の行番号は説明のためだけに付している。
【表１】
100  <?xml version="1.0" encoding="SHIFT-JIS"?>
102  <!DOCTYPE importdoc SYSTEM"../etc/dtd/PLANET.dtd">
104  <ResourceManager name="SPSResource">
106    <ResourceInformation name="SPSResource">-
108      <UnderResource name="Satell1" className="cosmo.planet.SatelliteResourceManager"/>
110      <UnderResource name="Satell2" className="cosmo.planet.SatelliteResourceManager"/>
112      <UnderResource name="Satell3" className="cosmo.planet.SatelliteResourceManager"/>
114      <UnderResource name="Satell4" className="cosmo.planet.SatelliteResourceManager"/>
116      <UnderResource name="Ground1"   className="cosmo.planet.AxisResourceManager"/>
118      <UnderResource name="Ground2"   className="cosmo.planet.AxisResourceManager"/>
120      <UnderResource name="Ground3"   className="cosmo.planet.AxisResourceManager"/>
122      <UnderResource name="Ground4"   className="cosmo.planet.AxisResourceManager"/>
124    </ResourceInformation>
126
128    <ResourceInformation name="Satell1">
130      <UnderResource name="Sensor" className="cosmo.planet.InstrumentResourceManager"/>
132      <UnderResource name="S1" className="cosmo.planet.InstrumentResourceManager"/>
134      <UnderResource name="S2" className="cosmo.planet.InstrumentResourceManager"/>
136      <UnderResource name="S3" className="cosmo.planet.InstrumentResourceManager"/>
138      <UnderResource name="S4" className="cosmo.planet.InstrumentResourceManager"/>
140      <UnderResource name="S5" className="cosmo.planet.InstrumentResourceManager"/>
142      <UnderResource name="S6" className="cosmo.planet.InstrumentResourceManager"/>
144
146      <ResourceProperty key="BasePower" value="100"/>
148      <ResourceProperty key="HKPower" value="50"/>
150      <ResourceProperty key="BatteyCapacity" value="10000"/>
152      <ResourceProperty key="PowerLimit1" value="10"/>
154      <ResourceProperty key="PowerLimit2" value="20"/>
156      <ResourceProperty key="CheckCycle1" value="2000"/>
158      <ResourceProperty key="CheckCycle2" value="1000"/>
160
162      <AxisInformation name="PowerAxis" className="cosmo.planet.model.IntegrateAxis" >
164      </AxisInformation>
166
168      <Constraint className="cosmo.planet.PowerConstraint">
170        <Property key="Power" index="0"/>
172        <Axis     name="PowerAxis" />
174      </Constraint>
176    </ResourceInformation>
178
180    <ResourceInformation name="Sensor">
182      <ResourceProperty key="BasePower" value="10"/>
184      <ResourceProperty key="HKPower"   value="5"/>
186
188      <AxisInformation name="Sensor" className="cosmo.planet.model.OnOffAxis" >
190      </AxisInformation>
192
194      <Constraint className="cosmo.planet.OnOffConstraint">
196        <Property key="Mode"          index="0"/>
198        <Property key="PointingAngle" index="1"/>
200        <Axis     name="Sensor" />
202      </Constraint>
204    </ResourceInformation>
206
208    <ResourceInformation name="S1">
210      <ResourceProperty key="BasePower" value="10"/>
212      <ResourceProperty key="HKPower"   value="5"/>
214
216      <AxisInformation name="S1" className="cosmo.planet.model.OnOffAxis" >
218      </AxisInformation>
220
222      <Constraint className="cosmo.planet.OnOffConstraint">
224        <Property key="Mode"          index="0"/>
226        <Axis     name="S1" />
228      </Constraint>
230    </ResourceInformation>
【００２６】
第１００行はＸＭＬ宣言文であり、第１０２行は外部のＤＴＤ（Document Type Definition）を参照する文である。第１０４行は最上位階層のリソースの定義であって、名前は「SPSResource」である。第１０６行乃至第１２４行は「SPSResource」の下位のリソースを定義する部分である。ここでは、衛星４基と地上受信アンテナ４基とが定義されている。すなわち、衛星リソース「Satell1」「Satell2」「Satell3」「Satell4」と地上受信アンテナ「Ground1」「Ground2」「Ground3」「Ground4」である。これらのリソースは、classname=で指定されるオブジェクトとして活性化される。すなわち、衛星の場合には、cosmo.planet.SatelliteResourceManagerであり、地上受信アンテナの場合には、cosmo.planet.AxisResourceManagerである。
【００２７】
第１２８行乃至第１７６行には、衛星「Satell1」の下位に属するリソースについての記述がなされている。ここでは第１３０行乃至第１４２行のUnderResourceタグ内に衛星「Satell1」の下位に属するリソースの種類が示されている。本例では、センサ（Sensor）、Ｓ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５、Ｓ６といったリソースが存在している。なお、これらのリソースは、cosmo.planet.InstrumentResourceManagerというオブジェクトとして活性化される。第１４６行乃至第１５８行のResourcePropertyタグ内には各リソースの属性に与える設定値が記述されている。BasePowerという属性には、１００という値が設定される。HKPowerという属性には、５０という値が設定される。BatteryCapacityという属性には、１００００という値が設定される。PowerLimit1という属性には、１０という値が設定される。PowerLimit2という属性には、２０という値が設定される。CheckCycle1という属性には、２０００という値が設定される。CheckCycle2という属性には、１０００という値が設定される。
【００２８】
第１６２行及び第１６４行は、リソースの残量を監視する軸を規定する部分である。ここで軸（縦軸）の名前はPowerAxisであり、cosmo.planet.model.IntegrateAxisというオブジェクトとして活性化される。IntegrateAxis部分は、軸の種類を示している。なお、横軸は通常時間軸である。第１６８行乃至第１７４行は制約を規定する部分である。ここではcosmo.planet.PowerConstraintというオブジェクトが制約を管理している。また、その属性Powerの制約条件値は０である。また、その属性の軸にはPowerAxisを用いる。
【００２９】
第１８０行乃至第２０４行はセンサ（Sensor）・リソースについて規定する部分である。第１８２行及び第１８４行は、このセンサ・リソースの属性に与える設定値を示す。ここでは、BasePowerという属性には、１０という値が設定される。HKPowerという属性には５という値が設定される。第１８８行及び第１９０行は、センサを管理する軸を規定する部分である。ここでは軸（縦軸）の名前はSensorであり、cosmo.planet.model.OnOffAxisというオブジェクトとして活性化される。OnOffAxis部分は、軸の種類を示している。第１９４行乃至第２０２行はセンサの制約を規定する部分である。ここではcosmo.planet.OnOffConstraintというオブジェクトが制約を管理している。このセンサの属性Modeの制約条件は０であり、属性PointingAngleの制約条件は１であり、軸の名前はSensorである。
【００３０】
第２０８行乃至第２３０行は、Ｓ１というリソースについて規定する部分である。第２１０行及び第２１２行は、このリソースの属性に与える設定値を規定している。ここでは、BasePowerという属性には１０という値が設定される。HKPowerという属性には５という値が設定される。ここでは軸（縦軸）の名前はS1であり、cosmo.planet.model.OnOffAxisというオブジェクトとして活性化される。OnOffAxis部分は、軸の種類を示している。第２２２行乃至第２２８行はセンサの制約を規定する部分である。ここではcosmo.planet.OnOffConstraintというオブジェクトが制約を管理している。このセンサの属性Modeの制約条件は０であり、軸の名前はS1である。
【００３１】
以下、衛星Satell1の全ての下位のリソースについて規定し、さらに衛星Satell1と同様の規定を衛星Satell2乃至Satell4、地上受信アンテナGround1乃至Ground4についても行うことにより、本実施の形態に必要なリソース・オブジェクトを用意することができる。なお、このような形で制約を管理するリソース・オブジェクトを管理しているため、スケジュール立案ロジックとは無関係に、リソースの内容を変更することも可能である。さらに、ＸＭＬを使用しているので、メンテナンスが非常に簡単である。
【００３２】
次に図１に示したスケジュール立案システムの処理フローを図３乃至図３１を用いて説明する。まず、要求受付部１が、ユーザから当該ユーザの要求情報を受け付ける（図３：ステップＳ１）。受け付けた要求情報は、要求格納部３に格納される。衛星の観測スケジュールを立案する場合には、観測したい領域、観測して欲しい時刻、観測の目的等を特定する必要がある。本実施の形態では、図４に示すような項目の情報が要求情報として設定される。なお、図４の設定可否の欄において情報が入力されていない項目についてはシステムで設定され、○が入力されている項目については必ずユーザが設定しなければならず、△が入力されている項目についてはユーザが設定することができ、また設定しなくとも良い。
【００３３】
管理情報としては、受け付けた時刻である受付日時、受付順に採番する管理番号である受付番号、要求者や目的に応じて算出される優先度、受付後の処理状態を管理するための処理状態、受付後に分析処理をした作業員がいる場合にはその者のＩＤである分析者ＩＤが含まれる。観測要求情報としては、要求者ＩＤ、観測目的、観測目的をカテゴリ分けする際の管理コードである観測目的カテゴリコード、観測期間開始時刻、観測期間終了時刻、観測回数、観測対象場所（例えば東京都）、観測対象物（区役所）、及び観測領域数（例えば２３）が含まれる。括弧内のより具体的な位置などについては、要求分析部５が分析する。なお、要求者ＩＤから要求者の所属やセキュリティレベルが判断される。また、衛星のロール角が指定される場合もある。
【００３４】
領域情報としては、１要求内に含まれる観測対象領域に付与する番号である領域番号と、撮像領域を地図上へ多角形でマッピングした場合の多角形の頂点の緯度及び経度である領域閉空間頂点緯度経度とが含まれる。また、衛星センサ情報としては、衛星に搭載され今回使用するセンサ名である観測センサ名、撮像時のセンサのモードであるセンサモード、衛星軌道の直下点からのセンサを傾ける角度であるポインティング角、観測したデータの画質を優先するか否かのフラグである画質優先フラグ、観測したデータの分解能を優先するか否かのフラグである分解能優先フラグとが含まれる。さらに、プロダクト情報としては、観測されたデータを受け取る希望日であるプロダクト配布希望日、配布されるデータを記録する媒体の種類を表すプロダクト配布媒体が含まれる。
【００３５】
図３の処理フローに戻って、次に要求分析部５は要求分析処理を実施する（ステップＳ３）。この要求分析処理には、上で述べたような東京都２３区全ての区役所を撮影するといった要求の場合には、東京都２３区全ての区役所の緯度及び経度の情報を取得するといった処理も含む。このような処理については、場所名と緯度及び経度のテーブルで簡単に行うことができるのでここではこれ以上述べない。ここでは、本実施の形態特有の処理を説明する。
【００３６】
図５に要求分析処理の一例を示す。最初に、ユーザからの要求に含まれる観測領域が点領域であるか判断する（ステップＳ１１）。例えば、図４の観測要求情報における観測対象場所が緯度経度の１つの組み合わせにて指定される又は要求分析処理において特定された場合には、点領域と判断される。この場合には、後に詳しく述べる、観測点についての実現パターン決定処理を実行する（ステップＳ１３）。一方、例えば図４の領域情報内の領域閉空間頂点緯度経度において複数の頂点の緯度経度が指定されている場合には、面の領域が観測領域として指定されていると判断して、観測領域についての実現パターン決定処理を実行する（ステップＳ１５）。
【００３７】
ステップＳ１３又はステップＳ１５の後に、全ての観測領域について処理したか判断する（ステップＳ１７）。これは、上で述べたように東京２３区の区役所といった２３箇所の観測領域が要求に含まれる場合があるからである。よって、全ての観測領域が処理されるまで、ステップＳ１１からステップＳ１５を繰り返す。一方、全ての観測領域が処理された場合には、要求、観測領域、実現パターン及びステップＳ１３又はステップＳ１５において生成されたセグメントにより構成される階層構造を表すＸＭＬデータを生成し、要求階層構造データ格納部９に格納する（ステップＳ１９）。また、管理のため上記階層構造に基づき、要求階層構造管理データ項目を作成して、要求階層構造管理データ格納部７に登録する（ステップＳ２１）。生成されるＸＭＬのデータについては後に述べる。階層構造データ及び要求階層構造管理データ格納部７に格納されるデータの一例については後に説明する。
【００３８】
次に、図６乃至図１３を用いて図５のステップＳ１３の処理を説明する。最初に、観測点を撮影可能な全てのパス（衛星の周回単位をパスと呼ぶ）についてロール角を算出する（ステップＳ２５）。ロール角とは、衛星軌道直下点から観測領域を観測するために衛星全体を振る角度である。図７に示すように、地球の中心７０４と衛星７００とを結ぶ直線の地球表面との交点が衛星直下点７０２である。衛星が通常の姿勢を保てばセンサは地球中心に向けてられており、衛星直下点７０２からセンサの視野の範囲のみが撮影できる。しかし、衛星を傾ければ、センサを観測点７０６に向けることができる。この衛星を傾けた角度がロール角である。ロール角だけ衛星を傾けた場合には、図７に示したようなセンサの視野角を地球表面に投影した範囲がセンサの観測幅（範囲）となる。なお、センサのみを振る場合にはポインティング角と呼ぶ。
【００３９】
なお、ロール角の刻み幅は衛星の仕様によって決まる。そのため計算結果は刻み幅で規格化して使用する。例えば、刻み幅が０．１°である場合には、ロール角がＡ１＝１０．０８９°と計算されると、Ａ１＝１０．１°として設定する。
【００４０】
図７で説明したように各パスについてロール角を計算するが、全く観測できないようなパスにてロール角を計算する必要は無い。ステップＳ２５の結果は、例えば図８に示すように、ｎ個のパス番号及びロール角の対として得られる。次に、使用可能なロール角の範囲に含まれるロール角及びそのときの衛星位置（パスと緯度引数のセットで指定される衛星軌道上の任意地点の座標）を決定する（ステップＳ２７）。衛星をあまりに傾けて観測するのは好ましくない。よって、使用可能なロール角の範囲は、ユーザにより指定されていない場合にはデフォルトで指定されている値、ユーザにより指定されている場合には当該指定された値で決定される。緯度引数は、図９に示すように、地球中心９０８からみた赤道面９０２と衛星９００の成す角９０４である。この緯度引数は、衛星９００の軌道上９１０のどのタイミングで観測するかを特定するために用いられる。
【００４１】
図１０に示すように、観測点がａ１であって、パスＰ２及びＰ３のロール角が使用可能なロール角の範囲に含まれているとする。そうすると、図１１に示すように、パスＰ２、ロール角Ａ２及び緯度引数Ｒ２のセットと、パスＰ３、ロール角Ａ３及び緯度引数Ｒ３のセットとが抽出される。
【００４２】
このようにして求められたパスと緯度引数の時に衛星をそのロール角だけ傾け、観測センサをオンにすれば目的の観測点が観測される。このとき、観測センサのオン／オフの制御も衛星の仕様により刻み幅が規定される。従って、この制御時間を考慮し、観測点が中心にくるように、各ロール角について、観測開始衛星位置と観測終了衛星位置とを算出して、セグメント（観測範囲）を決定する（ステップＳ２９）。
【００４３】
図１０の例の場合には、図１２に示すように、衛星がパスＰ３を移動する際にはロール角Ａ３でセグメントｓ３１を撮影する。また、衛星がパスＰ２を移動する際にはロール角Ａ２でセグメントｓ２１を撮影する。両パスにおいて衛星が下から上に移動する場合には、セグメントｓ３１及びｓ２１の下端から上端までが撮影時間（センサがオンになる時間）であり、下端における緯度引数が観測開始緯度引数で、上端における緯度引数が観測終了緯度引数である。
【００４４】
このように図１２の例では、２つのセグメントはいずれかが採用されればユーザの要求を満たすものであり、ＯＲ関係（排他関係）にある。よって、１つのセグメントにて１つの実現パターンが構成される。
【００４５】
次に、各セグメントの優先度を算出する（ステップＳ３１）。セグメントは、ユーザによる要求が受け付けられた時に要求者の所属や観測目的などにより付与された優先度を引き継ぐが、セグメント毎に再度、優先度を計算する。例えば本実施の形態では、以下の式にて計算される。
セグメント優先度
＝優先度×係数１×領域指定による係数×指定ロール角との差異
＋指定ロール角との差異×係数２                  （１）
式（１）の優先度は、要求受付時の優先度（例えば３）である。係数１は、優先度の数値幅の拡張用係数（例えば１００）である。領域指定による係数とは、観測点（観測領域が点指定）の場合の係数（例えば１０）、観測領域（観測領域が領域指定）の場合の係数（例えば１１）である。指定ロール角との差異は、要求において指定されたロール角とセグメントのロール角との差の絶対値である。なお、ロール角の指定が要求に含まれていない場合には、例えば以下の値を指定されたロール角として採用する。すなわち、観測領域が点指定の場合には観測点に最も近いパスに対するロール角、観測領域が領域指定の場合には領域の中心位置に対するロール角である。式（１）では、数値が低い場合に優先度が高くなる。
【００４６】
図１３に計算例を示す。図１３の例の場合、ケース１とケース２の差は、ケース１が観測領域が点指定の場合で、ケース２が観測領域が領域指定の場合である。このように式（１）により計算すると、領域指定の場合の方が優先度が低い。ケース３とケース４の差は、指定ロール角との差異（指定ロール角−セグメントのロール角）である。このように式（１）により計算すると、指定ロール角との差異が小さい方が優先度が高い。
【００４７】
図６に戻って、最後に、各セグメントをＯＲ関係の実現パターンとして決定する（ステップＳ３５）。観測点の場合には、１つのセグメントが１つの実現パターンの内容となる。
【００４８】
このように本実施の形態では、ユーザの要求を、スケジュール対象の性質に基づき実現パターンに変換する処理を行う。但し、この段階ではまだスケジュール対象の細かい制約条件との関係からスケジュール可能か否かといった判断は行わない。
【００４９】
次に図１４乃至図２４を用いて図５のステップＳ１５の説明を行う。最初に、要求において指定された観測領域を観測可能なパスを算出する（ステップＳ４１）。例えば図１５に示すように、頂点ａ１、ａ２、ａ３、ａ４、ａ５で指定される閉領域が観測領域である場合には、これらの各頂点を観測することができるパスを算出する。例えば、いずれかの頂点を観測できないようなパスは除去され、さらにいずれかの頂点が指定のロール角の範囲に入らないパスは除去される。なお、図１５において、上は北、下は南、右は東、左は西である。この時点で観測可能なパスについては、各頂点についてロール角及び緯度引数のセットを計算しておく。
【００５０】
そして、算出した全てのパスについて観測領域をセグメント化する（ステップＳ４３）。このセグメント化については図１６の処理フローを用いて説明する。ここでは一例として、図１５に示された観測領域をパスＰについてセグメント化する処理を説明する。図１６では最初に、観測領域に対してロール角の最大／最小値を計算し、センサの観測幅が重なりを持つように最大／最小値の間のロール角を計算する（ステップＳ５１）。図１５のパスＰの場合、図１７に示すように、頂点ａ３の場合が最大ロール角ｒmaxであり、頂点ａ５の場合が最小ロール角ｒminである。よって、最小ロール角から（センサの視野角（観測幅を表す）×（１−領域重複許容率））だけ傾けたところに、第１のロール角ｒｂ１を設ける。また、第１のロール角ｒｂ１から（センサの視野角（観測幅を表す）×（１−領域重複許容率））だけ傾けたところに、第２のロール角ｒｂ２を設ける。再度このような計算を実施すると、最大ロール角ｒmaxを超えてしまうので、計算はここで終了する。すなわち図１８に示すような状態が計算される。図１８では、最小ロール角ｒminから最大ロール角ｒmaxの間にロール角ｒｂ１及びｒｂ２が設定されている。
【００５１】
次に、計算されたロール角で定められる直線と観測領域の線分との交点及びその交点における緯度引数を計算する（ステップＳ５３）。図１９に示すように、ロール角ｒｂ１で定められる直線（点線）と頂点ａ１及びａ２間の線分との交点はｂ４であり、ロール角ｒｂ１で定められる直線（点線）と頂点ａ３及びａ４間の線分との交点はｂ３である。この交点ｂ３及びｂ４の緯度引数を計算する。また、ロール角ｒｂ２で定められる直線（点線）と頂点ａ１及びａ２間の線分との交点はｂ１であり、ロール角ｒｂ２で定められる直線（点線）と頂点ａ３及びａ４間の線分との交点はｂ２である。この交点ｂ１及びｂ２の緯度引数を計算する。最小ロール角にあたる頂点ａ５及び最大ロール角にあたる頂点ａ３における緯度引数と交点ｂ１乃至ｂ４の緯度引数を図２０に示す。
【００５２】
そして、最大ロール角及び最小ロール角にあたる頂点及び交点をロール角でソートし、同じロール角を持つ線分からセグメントを構成する（ステップＳ５５）。図２０をロール角ソートすると、図２１のようになる。すなわち、ロール角ｒminの頂点又は交点はａ５のみであり、このロール角ｒminでは頂点ａ５をカバーするセグメントＳＥＧ−１が構成される。また、ロール角ｒｂ１の頂点又は交点はｂ４及びｂ３であり、このロール角ｒｂ１では緯度引数Ａ１乃至Ａ５のセグメントＳＥＧ−２が構成される。ロール角ｒｂ２の頂点又は交点はｂ１及びｂ２であり、このロール角ｒｂ２では緯度引数Ａ２乃至Ａ４のセグメントＳＥＧ−３が構成される。ロール角ｒmaxの頂点又は交点はａ３のみであり、このロール角ｒmaxでは頂点ａ３をカバーするセグメントＳＥＧ−４が構成される。
【００５３】
図２１の状態を図形で示すと図２２のようになる。４つのセグメントが重なりをもってパスＰに平行に配置されていることがわかる。なお、ロール角ｒmin及びｒmaxについてのセグメントには高さが規定されていないが、図２２では分かりやすくするためにある程度の高さを有するように示している。図２２を見ると分かるように、ステップＳ５５で構成したセグメントでは観測領域を全てカバーできていない。例えば、サークルＰ１部分である。
【００５４】
よって観測領域を十分カバーするようにセグメントを補正する（ステップＳ５７）。補正の例を図２３及び図２４を用いて説明する。図２３は図２２のサークルＰ１内及び付近の拡大図である。セグメントＳＥＧ−３と隣接するＳＥＧ−２との観測幅の交点Ｘ３が観測領域内にある場合、ＳＥＧ−３の開始ライン（衛星が上から下に飛んでいる場合を想定している）をＳ１からＳ２まで延長する。セグメントＳＥＧ−２の４隅の座標と頂点ａ１及びａ２の座標からＸ２を算出し、Ｘ２に対する緯度引数を計算することにより開始ラインＳ１からＳ２までの延長が行われる。このＸ２が補正後のセグメント開始ラインとなる。このような処理を全てのセグメントについて実施すると、図２４に示すような状態となる。図２３で示したようにセグメントＳＥＧ−３は上方向に、ＳＥＧ−２及びＳＥＧ−１は上下に延長されている。このような補正を行うことにより、全セグメントにて観測領域を十分カバーすることができるようになる。なお、衛星は１本のパスにて１つのセグメントしか観測することはできない。よって、このようなセグメント化を行っても、単純に１本のパスに対応する全セグメントで実現パターンが構成できるわけではない。
【００５５】
なお、ステップＳ５７までに、セグメント毎にパス、開始及び終了緯度引数、ロール角及びセグメントの４隅の座標（緯度経度）が得られる。
【００５６】
図１４の説明に戻る。ステップＳ４３でセグメント化が完了すると、観測領域全てをカバーし且つパスが重ならないセグメントの組み合わせを全て探索する（ステップＳ４５）。これらのセグメントをＡＮＤ関係にて保持することにより観測領域を全て観測できる実現パターンを構成することができるようになる。簡単な例では、衛星は所定日数ごとに同じ軌道を通過するため、図２４のようなセグメント４本を観測するためには、４回パスＰの軌道を通過する毎に異なるセグメントを観測するといった組み合わせでも良い。より詳細に述べれば、ステップＳ５７（図１６）までにセグメント毎にパス、開始及び終了緯度引数、ロール角及びセグメントの４隅の座標（緯度経度）が得られているので、セグメントの４隅の座標（緯度経度）を用いて観測領域をカバーし且つパスが重ならないようにセグメントをピックアップする。このようにして選択されたセグメントの組み合わせは実現パターンを構成する。
【００５７】
そして、採用された各セグメントの優先度を、観測点についての処理で説明したのと同様の処理にて計算する（ステップＳ４７）。そして、各セグメントの組み合せをＯＲ関係を有する実現パターンとして決定する（ステップＳ４９）。
【００５８】
図２５に、各セグメントについて記憶装置に保持される、以上の処理にて得られたデータ項目及びユーザの要求から引き継がれるデータ項目等を示す。本実施の形態では、観測要求の緊急（ＵＲＧ）／通常（ＮＯＲ）の識別フラグ、観測要求承認時に付与されるオーダ番号、領域番号、観測領域が点指定か領域指定かの種別、領域別に付与するセグメントの識別番号（例えばセンサ名称＿シーケンシャル番号で構成）、撮像優先順位（受付時の優先度）、立案時のセグメント優先度（０−１００００）、セグメントの状態、衛星名称、マルチ（ＭＵＬ）／パンクロマルチ（ＰＡＭ）／開口合成レーダ（ＳＡＲ）のいずれかを示すセンサ種別、観測予定日、ステップＳ５７で得られたセグメントの開始衛星位置（パス番号＋緯度引数）、ステップＳ５７で得られたセグメントの終了衛星位置（パス番号＋緯度引数）、ステップＳ５７で得られた開始緯度／経度、並びに終了緯度／経度、実際にセンサをオン／オフする際の観測開始衛星位置（パス番号＋緯度引数）、並びに観測終了衛星位置、観測地点（緯度、経度、高度）、観測中心衛星位置（パス番号＋緯度引数）、センサの動作モード、分解能、画質／分解能優先フラグ（任意項目のフラグ設定も可能）、排他関係（ＯＲ関係）にあるセグメント識別番号（ＩＤ）、ロール角、偏波モード（電波観測のときに縦又は横を指定）等が含まれる。なお、図２５中最小チェックとあるのは、センサをオン及びオフできる最小の単位についての確認を意味する。
【００５９】
このように図６及び図１４の処理にてセグメントが生成されると、要求、観測領域（１つの要求には１又は複数の領域が指定される場合がある）、実現パターン、実現パターンの内容としてのセグメントという階層構造データを作成することができる（ステップＳ１９：図５）。すなわち、図２６に示すような階層構造データが生成される。
【００６０】
図２６の例では、観測要求２６００の下位に観測領域１（２６０２）及び観測領域２（２６０４）という階層が設けられる。これは一つの要求において複数の観測領域が指定される場合の例を示している。観測領域１（２６０２）及び観測領域２（２６０４）が観測されて初めて観測要求を満たすことになるので、観測領域１（２６０２）と観測領域２（２６０４）はＡＮＤ関係にあり、観測要求２６００の下には「ＡＮＤ」と示されている。観測領域１（２６０２）の実現パターンには２通りある。実現パターン１（２６０６）と実現パターン２（２６０８）である。実現パターン１（２６０６）と実現パターン２（２６０８）はいずれかが実現されれば観測領域１（２６０２）を観測したことになるため、実現パターン１（２６０６）と実現パターン２（２６０８）とはＯＲ関係にあり、観測領域１（２６０２）の下には「ＯＲ」が示されている。
【００６１】
実現パターン１（２６０６）を構成するのは、セグメント１（２６１４）及びセグメント２（２６１６）であり、これら２つのセグメントにて観測領域１（２６０２）を観測することになる。よって、セグメント１（２６１４）とセグメント２（２６１６）はＡＮＤ関係にあり、実現パターン１（２６０６）の下に「ＡＮＤ」が示されている。観測領域１（２６０２）の実現パターン２（２６０８）は、１つのセグメント３（２６１８）で構成される。このような構造が観測領域２（２６０４）についても構成される。図２６の例では、観測領域２（２６０４）の実現パターンには２通り（実現パターン３（２６１０）及び実現パターン４（２６１２））あることまでが示されている。
【００６２】
このような階層構造データは、本実施の形態ではＸＭＬにて記述される（ステップＳ１９：図５）。この例（一部）を以下に示す。なお、表２の左に示した行番号は説明のためだけに付されている。
【表２】
300  <?xml version="1.0" encoding="Shift_JIS" ?>
302  <!DOCTYPE Element (View Source for full doctype...)>
304  <Request id="xxx200103010001"/>
306    <RegistrationDate value="20010301125513"/>
308    <Priority value="9"/>
310    <Status value="reg">
312    <Operator id="sss940234"/>
314    同様に他の観測要求情報をタグ付きで表記する
316    <Area id="xxx200103010001-0">
318      <Polygon value="4">
320        <node>36.1235 139.9876</node>
322        <node>36.1240 139.9800</node>
324        <node>36.1004 139.9799</node>
326        <node>36.0999 139.9878</node>
328      </Polygon>
330      <ObservationTerm>20010402000000 20010501000000</ObservationTerm>
332      <Group>
334        <ElementID id="20001122003355888-2"/>
336        <ElementID id="20001122003355888-5"/>
338        <ElementID id="20001122003355888-6"/>
340      </Group>
342      <Element id="20001122003355888-2"/>
344        <Name value="XXXX"/>
346        <Priority value="90"/>
348        <Emergency value="false"/>
350        <Group>
352          <ElementID id="20001122003355888-5"/>
354          <ElementID id="20001122003355888-6"/>
356        </Group>
358        <AdoptionResult>
360          <ResultType value="YETADOPT"/>
362          <ResourceViolation/>
364        </AdoptionResult>
366        <Properties>
368          <Property key="testkey"value="testvalue"/>
370        </Properties>
372        <Factors>
374          <SPSFactor id="20001122003355888-2-0"/>
376            <Name value="XXXXXXX"/>
378            <ResourceName value="SATELL1"/>
380            <Mode value="MULT"/>
382            <RequiredPower value="0"/>
384            <CommandNumber value="0"/>
386            <RevicedValue value="0"/>
388            <RevicedFlag value="false"/>
390            <Properties>
392              <Property key="xx"value="xxxxxx"/>
394            </Properties>
396            <SPSTerm>
398              <Start value="0"/>
400              <End value="300">
402              <WishStart value="0"/>
404              <WishEnd value="330"/>
406              <StandardCount value="0"/>
408              <UsedCount value="300"/>
410            </SPSTerm>
412          </SPSFactor>
414          <SPSFactor id="20001122003355888-2-1"/>
416            次のセグメントについても同様に表記する
418          </SPSFactor>
420        </Factors>
422      </Element>
424      <Element id="20001122003355888-5"/>
426        上記の<Element>と同様に他のパターンも表記する
428      </Element>
430    </Area>
432    < Area id="xxx200103010001-1>
434      上記のフォーマットで要求に含まれる領域数繰り返す
436      Request内に含まれるAreaの情報はAndの関係となる
438    </Area>
440  </Request>
【００６３】
第３００行はＸＭＬの宣言文であり、第３０２行はＤＴＤの定義文であるが、ここでは省略されている。第３０４行乃至第４４０行で一つの観測要求を規定するようになっている。第３０４行では観測要求のＩＤがｘｘｘ２００１０３０１０００１とされている。第３０８行乃至第３１２行には、第３１４行にコメントとして記載されているように、観測要求情報がタグ付きで記載される。第３０６行には受付日（ResigtrationDate）が規定されており、第３０８行には観測要求の優先度（Priority）が規定されており、第３１０行には観測要求の状態（Status）が規定されており、第３１２行には関与したオペレータ（Operator）が規定されている。
【００６４】
また、第３１６行乃至第４３０行は、観測要求に含まれる第１の観測領域（ＩＤはｘｘｘ２００１０３０１０００１−０）を規定する。第４３２行乃至第４３８行は第２の観測領域（ＩＤはｘｘｘ２００１０３０１０００１−１）を規定する。第１の観測領域は、第３１８行で四角形（４つの頂点を有するポリゴン）であることが規定されている。第３２０行乃至第３２６行に各頂点の緯度・経度が指定されている。第３３０行は、観測要求の観測希望期間を示している。この例では、２００１年４月２日から２００１年５月１日までである。
【００６５】
第１の観測領域の実現パターンは第３３２行乃至第３４０行に規定される。第３３２行乃至第３４０行には、ＯＲ関係にある全ての実現パターンが列挙される。ここでは要素ＩＤ（ElementID）が２０００１１２２００３３５５８８８−２という実現パターン（第１実現パターン）と、要素ＩＤ（ElementID）が２０００１１２２００３３５５８８８−５という実現パターン（第２実現パターン）と、要素ＩＤ（ElementID）が２０００１１２２００３３５５８８８−６という実現パターン（第３実現パターン）と、がＯＲ関係で以下に列挙される。第１実現パターンは、第３４２行乃至第４２２行に規定される。第２及び第３実現パターンについては第４２４行乃至第４２８行に規定されるようになっている（ここでは省略されている）。
【００６６】
第１実現パターンの内容については第３４４行以降に規定される。第３４４行は第１実現パターンの名前、第３４６行は第１実現パターンの優先度、第３４８行は第１実現パターンの緊急度が規定されている。第３５０行乃至第３５６行は、当該第１実現パターンとＯＲ関係にある第２実現パターン及び第３実現パターンが規定されている。第３５８行乃至第３６４行には、当該第１実現パターンが採用されたか否かを規定する。第３６０行に規定されているように、現在はまだ採用されていないことが示されている。第３６６行乃至第３７０行には、第１実現パターンにおける属性値の設定が規定される。
【００６７】
第３７２行乃至第４２０行は、第１実現パターンの内容であるセグメントについて規定する部分である。第１実現パターンは、２つのＡＮＤ関係のセグメントにて構成される。第１のセグメントは第３７４行乃至第４１０行で規定される。第２のセグメントは第４１４行乃至第４１８行で規定されるようになっている（ここでは省略されている）。第１のセグメントの識別番号（ＩＤ）は第３７４行に記載されているように、２０００１１２２００３３５５８８８−２−０である。第３７６行には第１のセグメントの名前が、第３７８行には第１のセグメントのリソース名（SATELL1）が規定される。リソース名は、リソース・マネージャ１２２により取り扱われる名前である。第３８０行には観察モード（ここではＭＵＬＴ）、第３８２行には必要なパワーの値、第３８４行にはリソース使用時のコマンド数（CommandNumber）の値、第３８６行には期間修正値の値、第３８８行には期間修正を行ったか否かのフラグが規定されている。
【００６８】
第３９０行乃至第３９４行は、第１のセグメントの属性値を規定する部分である。また、第３９６行乃至第４１０行は、観測機器のオン・オフの期間などを規定する部分であって、開始値、終了値、希望開始値、希望終了値、標準カウント値（StandardCount）や使用カウント値などが規定される。このような第１のセグメントに対してＡＮＤ関係にある第２のセグメントの規定が、第４１４行以下になされる。
【００６９】
第４２４行乃至第４２８行は、上で述べたように第２実現パターン以降の実現パターンを規定する部分である。第４３２行乃至第４３６行では、第２の観測領域が規定される。第４３６行に記載されているように、観測要求内に含まれる観測領域は、ＡＮＤ関係となる。
【００７０】
要求分析部５は、表２で述べたようなユーザによる要求の階層構造データを管理するため図２７のような管理テーブルを要求階層構造管理データ格納部７に保持している。すなわち、要求分析部５は、表２のような１つの要求についてＸＭＬによる要求の階層構造データを生成すると、そのための項目を管理テーブルに作成する。図２７の例においては、ユーザによる要求ｉには観測領域ｉ0が含まれ、観測領域ｉ0には実現パターンｉ00及びｉ01が含まれる。そして、実現パターンｉ00にはセグメントｉ000及びセグメントｉ001が含まれる。実現パターンｉ01にはセグメントｉ010及びセグメントｉ011が含まれる。このような項目がテーブル上に追加される。なお、採否の欄については、スケジュール立案部１１によりセグメントの採否の結果が登録される。
【００７１】
ここまでで図３のステップＳ３までの処理が完了した。このように本実施の形態では要求者は、スケジュール対象の性質に基づき、一定の階層構造データに変換され、以下のスケジュール立案処理が簡単且つ高速化される。なお、ステップＳ３まででは詳細な制約条件との適合性までは判断しない。
【００７２】
次に、スケジュール立案部１１の前処理部１１０が、要求要素展開処理を実施する（ステップＳ５）。この処理については図２８及び図２９を用いて説明する。前処理部１１０は、要求階層構造データ格納部９から未処理のセグメントのデータを取得する（ステップＳ６１）。そして、取得したセグメントを観測するための各リソースの運用条件をリソース・オブジェクト群１２４の各リソース・オブジェクトに対して問い合わせる（ステップＳ６３）。要求分析部５の分析結果であるセグメントの情報は、各リソースをどのような態様で使用するのかという点までは展開されていない。これは、各リソースの制約条件などを参照することなく、衛星の軌道という点のみにおいて分析処理を行っていたためである。本実施の形態では、前処理部１１０が、このセグメントの観測を実現する上で、各リソース（制約）においてあり得る運用条件をリソース・オブジェクト群１２４の各リソース・オブジェクトに問い合わせる。但し、この段階では各リソース間におけるコンフリクトまでは考慮しない。
【００７３】
次に、この取得したセグメントについて、全リソースの運用条件から成る運用パターンを構成し、運用パターンの情報を要求要素格納部１１２に格納する（ステップＳ６５）。すなわち、各リソースについて得られた１又は複数の運用条件を組み合わせて、１又は複数の運用パターンを構成する。図２９に示すように、セグメント１（２９０１）には、セグメント１の観測を可能とする運用パターン１（２９０３）、運用パターン２（２９０５），，，，が下位の階層に設けられることになる。なお、運用パターン１（２９０３）及び運用パターン２（２９０５）は、いずれにてもセグメント１を観測できるためＯＲ関係となっている。図２９では示していないが、各運用パターンには、図２に示したリソースの階層構造と同じ構造のデータが含まれる。なお、この運用パターンの情報を要求要素と呼び、以下の処理ではこの要求要素が処理の単位となる。そして、ステップＳ６１乃至ステップＳ６５の処理を全てのセグメントについて実施する（ステップＳ６７）。このような処理を実施することにより、各セグメントは、各リソースの運用条件の組み合せである運用パターンに展開され、リソース・オブジェクト群１２４における処理に適した形になる。
【００７４】
運用パターンの一例（部分のみ）を以下に示す。なお、表３の左側に示された行番号は説明のためだけに付されている。
【表３】
500  <?xml version="1.0"encoding="Shift_JIS"?>
502  <!DOCTYPE Element SYSTEM"../etc/dtd/PLANET.dtd">
504  <Element id="20001231000000999-11">
506    <Name value="10-4"/>
508    <Priority value="90"/>
510    <Emergency value="false"/>
512    <Group>
514      <ElementID id="20001231000000999-l2"/>
516  </Group>
518  <AdoptionResult>
520    <ResultType value="YETADOPT"/>
522    <ResourceViolation/>
524  </AdoptionResult>
526  <Properties>
528    <Property key="testkey" value="testvalue"/>
530  </Properties>
532  <Factors>
534    <SPSFactor id="20001231000000999-11-0">
536      <Name value=SAR衛星1"/>
538      <ResoureName value="xxx-k1"/>
540      <Mode value="NOP"/>
542      <RequiredPower value="0"/>
544      <CommandNumber value="0"/>
546      <RevicedValue value="0"/>
548      <RevicedFlag value="false"/>
550      <Properties>
552      <Property key="subtestkey" value= "subtestvalue"/>
554      </Properties>
556      <SPSTerm>
558        <start value="O"/>
560        <End value="999"/>
562        <WishStart value="O"/>
564        <WishEnd value="0"/>
566        <StandardCount value="O"/>
568        <UsedCount value="999"/>
570        </SPSTerm>
572    <AttachedFactor/>
574    <UnderFactor>
576      <SPSFactor id="20001231000000999-11-0-0">
578       <Name value="センサ"/>
580       <ResourceName value="Sensor"/>
582       <Mode value=""/>
584       <Type value="UNDER"/>
586       <RequiredPower value="O"/>
588       <CommandNumber value="O"/>
590       <RevicedValue value="O"/>
592       <RevicedFlag value="false">
594       <Properties>
596         <Property/>
598       </Properties>
600       <SPSTerm>
602         <Start value="10"/>
604         <End value="100"/>
606         <WishStart value="O"/>
608         <WishEnd value="O"/>
610         <StandardCount value="O"/>
612         <UsedCount value="9O"/>
614       </SPSTerm>
616       <AttachedFactor/>
618       <UnderFactor/>
620      </SPSFactor>
622     </UnderFactor>
624    </SPSFactor >
626   </Factors>
628  </Element>
【００７５】
第５００行は宣言文であり、第５０２行はＤＴＤの定義文である。但し、ここではＤＴＤの外部参照を示している。第５０４行乃至第６２８行で、実現パターンの情報を規定している。第５０６行は、実現パターン識別番号（ＩＤ）２０００１２３１００００００９９９−１１の名前を規定し、第５０８行は実現パターンの優先度を規定し、第５１０行は緊急度を規定している。第５１２行乃至第５１６行は、当該実現パターンとＯＲ関係にある実現パターンを規定している。第５１８行乃至第５２４行は当該実現パターンの採否を規定する部分である。この実現パターンはまだ採用されていない。第５２６行乃至第５３０行は、当該実現パターンの属性を設定する部分である。第５３２行乃至第６２６行は、実現パターンを構成するセグメントを規定する部分である。この例では、１つのセグメントのみ規定されている。セグメント自身の規定については第５３４行乃至第５７０行になされている。ここでは、セグメント識別番号（ＩＤ）２０００１２３１００００００９９９−１１−０のセグメントの規定がなされる。
【００７６】
第５３６行ではセグメントの名前（ＳＡＲ衛星１）が規定され、第５３８行ではセグメントのリソース名（ｘｘｘ−Ｋ１。リソース・マネージャ１２２により取り扱われる名前）が規定され、第５４０行ではモードが規定され、第５４２行では必要な電力の値が規定され、第５４４行では観測時のコマンド数が規定され、第５４６行では修正値が規定され、第５４８行では修正フラグが規定される。第５５０行乃至５５４行では当該セグメントの属性値が規定される。第５５６行乃至第５７０行は、観測機器のオン・オフの期間などを規定する部分であって、開始値、終了値、希望開始値、希望終了値、標準カウント値（StandardCount）や使用カウント値などが規定される。
【００７７】
なお第５７２行ではAttachedFactorというタグが規定されているが、これは付帯的な構成因子を規定するものである。但し、本例では空となっている。
【００７８】
第５７４行乃至第６２２行は、セグメントの下位の階層である運用パターンの内容の一部である。すなわち、ＳＡＲ衛星１のセンサというリソースについての運用条件を規定する部分である。ここではセンサしか規定されていないが、実際には図２に示したような全てのリソース（制約）についての運用条件が運用パターンとして規定される。複数の運用パターンが存在する場合にはそれらも規定される。その際には、第５７４行及び第６２２行で使用されているUnderFactorタグが複数設けられる。また、これらはＯＲ関係にあるため、Groupタグを用いてＯＲ関係にある運用パターンが規定される。
【００７９】
第５７８行では運用条件の名前（センサ）が規定され、第５８０行ではリソース・マネージャ１２２が取り扱うリソース名が規定され、第５８２行ではモードが規定され、第５８４行では型（Type）が規定され、第５８６行では必要な電力値が規定され、第５８８行では観測時のコマンド数が規定され、第５９０行では修正値が規定され、第５９２行では修正フラグが規定される。第５９４行乃至第５９８行ではこのセンサというリソースの属性値が規定されるが、ここでは何も規定されていない。第６００行乃至第６１４行はセグメントの場合と同じように、センサのオン・オフの期間等を規定する部分である。
【００８０】
このセンサというリソースの付帯的な構成因子を規定する場合には第６１６行以下でAttachedFactorタグを使用して規定し、さらに下位のリソースを規定する場合には第６１８行以下でUnderFactorタグを使用して規定する。
【００８１】
第５７６行乃至第６２０行のような規定をＳＡＲ衛星１以下の全てのリソース（制約）について規定することにより１つの運用パターンが規定できる。
【００８２】
表３のような情報が前処理部１１０により生成されると、生成されたデータは要求要素格納部１１２に格納される。但し、この要求要素格納部１１２には図２及び図２９で示した階層構造データの全てを格納するようにしても良いし、以下の処理では図２９の部分のみが必要となるので、図２９の部分のデータのみを格納するようにしても良い。
【００８３】
ここまでで図３のステップＳ５まで説明した。このように前処理部１１０がリソース・オブジェクト群１２４に対応する要求要素を作成するので、リソース・オブジェクト群１２４における処理が簡単且つ高速化される。
【００８４】
次に、本スケジュール立案システムはリソースに対するスケジュール立案処理を実施する（ステップＳ７：図３）。このスケジュール立案処理について図３０及び図３１を用いて説明する。最初に要素マネージャ１１４は、要求要素（運用パターン）のデータを取得し、要求要素管理データ格納部１１６に設けられた管理テーブルに当該要求要素を登録する（ステップＳ７１）。この管理テーブルの一例を図３１に示す。図３１に示された管理テーブルの一例では、セグメントＩＤと当該セグメントの運用パターンのＩＤ（要素マネージャ１１４が付与する場合もある）と、当該運用パターンの優先度（例えばセグメントの優先度をそのまま使用する）、ＯＲ関係にある運用パターンのＩＤ、そして当該運用パターンが採用されたか否か（採否）が記録されるようになっている。なお、実現パターンのＩＤを保持するような構成の場合もある。この場合、セグメントと運用パターンの関係と同じように、１つの実現パターンに含まれ且つＯＲ関係にあるセグメントを管理し、さらにセグメントの採否をも管理する場合もある。
【００８５】
図３１の例では、セグメント１１−０の運用パターンが１１−０−１、１１−０−２、１１−０−３であり、セグメントの優先度９０がそのまま各運用パターンに引き継がれている。そして、運用パターン１１−０−１のＯＲ関係にある運用パターンＩＤは１１−０−２及び１１−０−３である。運用パターン１１−０−２のＯＲ関係にある運用パターンＩＤは１１−０−１及び１１−０−３である。運用パターン１１−０−３のＯＲ関係にある運用パターンＩＤは１１−０−１及び１１−０−２である。以下の説明でも述べるが、優先度の高い順に運用パターン（要求要素）は処理されるが、もしＯＲ関係にある運用パターンのいずれかが採用と判断されると、他のＯＲ関係にある運用パターンも採用という取り扱いになる。このセグメント１１−０の場合には、運用パターン１１−０−１が採用になると、運用パターン１１−０−２及び１１−０−３も採用されたことになる。このようにすれば、処理をする必要が無くなった運用パターン１１−０−２及び１１−０−３について二度と処理をすることがなくなる。もしＯＲ関係にある他の運用パターンを不採用としてしまうと、未処理の運用パターンが無くなったところで再度採用可能か判断するための処理を行ってしまう場合があるからである。また、ＯＲ関係にある他の運用パターンに何らのフラグも立てないと、無駄に処理を行ってしまうからである。
【００８６】
図３１のもう一つの例では、セグメント１１−１には運用パターン１１−１−１及び１１−１−２が設けられている。これらの優先度は９１である。運用パターン１１−１−１のＯＲ関係にある運用パターンは１１−１−２であり、運用パターン１１−１−２のＯＲ関係にある運用パターンは１１−１−１である。もし、運用パターン１１−１−１が不採用になった場合には、不採用（×）が登録されるが、もし運用パターン１１−１−２が採用になると、運用パターン１１−１−１も採用（○）に変更する必要がある。
【００８７】
図３０に戻って、立案マネージャ１１８は、次の優先度の要求要素（運用パターン）を要素マネージャ１１４に要求する（ステップＳ７３）。要素マネージャ１１４は、この要求を受けると、要求要素管理データ格納部１１６の管理テーブルを参照して、次の優先度の要求要素（運用パターン）を特定し、要求要素格納部１１２から当該要求要素を読み出して、立案マネージャ１１８に出力する（ステップＳ７５）。立案マネージャ１１８は、取得した要求要素（運用パターン）についての制約確認リクエストをリソース・マネージャ１２２に出力する（ステップＳ７７）。制約確認リクエストには要求要素（運用パターン）のデータが含まれる。なお、立案マネージャ１１８は、単純に各要求要素（運用パターン）の優先度に従って要素マネージャ１１４に要求要素（運用パターン）を要求するのではなく、独自に要求する順番を決定し、それに従って要求要素（運用パターン）の要求を要素マネージャ１１４に出力する場合もある。
【００８８】
リソース・マネージャ１２２は、立案マネージャ１１８から要求要素のデータを含む制約確認リクエストを受け取ると、リソース・オブジェクト群１２４にこの要求要素を登録可能かを問い合わせる（ステップＳ７９）。リソース・オブジェクト群１２４に対する問い合わせは、リソース・マネージャ１２２が各オブジェクトに問い合わせるようにしても良いし、リソース・オブジェクト群１２４がその階層構造に従ってルート・オブジェクトから配下のオブジェクトに順次問い合わせるように構成されているのであれば、リソース・マネージャ１２２はルート・オブジェクトに問い合わせを出力する。
【００８９】
リソース・オブジェクト群１２４は、個々のオブジェクトが保持する制約テーブル（スケジューリング状態を保持するテーブル）を参照して、受け取った要求要素のうち、当該オブジェクトに対応する部分について登録可能か（採用可能か）を確認し、その結果をリソース・マネージャ１２２に出力する（ステップＳ８１）。なお、リソース・オブジェクト群１２４は、単に登録可能か否かという事項のみならず、どの部分が登録できないのかについての情報を合わせて返すような構成であってもよい。なお、リソース・オブジェクト群１２４の各リソース・オブジェクトが直接リソース・マネージャ１２２に確認結果を返しても良いし、リソース・オブジェクトが階層構造に従って下位のオブジェクトから確認結果を取りまとめてゆき、ルート・オブジェクトが最終的な結果をリソース・マネージャ１２２に渡すような構成であってもよい。リソース・マネージャ１２２は、リソース・オブジェクト群１２４からの確認結果をまとめて立案マネージャ１１８に出力する（ステップＳ８３）。
【００９０】
立案マネージャ１１８は、リソース・マネージャ１２２からリソース・オブジェクト群１２４における確認結果を受け取ると、当該確認結果が登録可能を示しているかを確認する（ステップＳ８５）。もし、登録可能ということであれば、当該要求要素を含む登録依頼をリソース・マネージャ１２２に出力する（ステップＳ８７）。リソース・マネージャ１２２は、リソース・オブジェクト群１２４に、要求要素を含む登録依頼を出力する（ステップＳ８９）。登録可能かの問い合わせと同じように、リソース・マネージャ１２２は、各リソース・オブジェクト１２４に要求要素の当該オブジェクトに関係する部分を含む登録依頼を出力する場合もあれば、ルート・オブジェクトに要求要素のデータ全部を含む登録依頼を出力する場合もある。各リソース・オブジェクト１２４は、登録依頼に従って要求要素において当該リソース・オブジェクトに対応する部分のデータに従って登録を行う（ステップＳ９１）。すなわち、スケジュール状態を更新する。
【００９１】
立案マネージャ１１８は、登録依頼の出力と共に、採用となった要求要素を立案結果格納部１２０に登録する（ステップＳ９３）。このように立案結果格納部１２０には、採用となった要求要素が蓄積されるようになるので、この蓄積されたデータを元に衛星や地上の受信局等の運用情報を生成することができるようになる。また、立案マネージャ１１８は、採用されたことを要素マネージャ１１４に通知する（ステップＳ９５）。要素マネージャ１１４は、立案マネージャ１１８から採用の通知を受けると、当該要求要素について採用を要求要素管理データ格納部１１６の管理テーブルに登録する（ステップＳ９７）。また、この管理テーブルを参照して、ＯＲ関係にある要求要素（運用パターン）を特定し、その要求要素についても採用を登録する（ステップＳ９９）。ＯＲ関係にある要求要素はいずれか一つでも採用になれば、もう処理をする必要が無いので、採用として登録することにより以降の処理の対象から除外する。
【００９２】
一方、ステップＳ８５において登録不可という確認結果を受信した場合、立案マネージャ１１８は要素マネージャ１１４に、当該要求要素が採用できなかった旨の通知（その理由を含める場合もある）を行う（ステップＳ１０１）。要素マネージャ１１４は、要求要素管理データ格納部１１６の管理テーブルにおいて当該要求要素に対して不採用を登録する（ステップＳ１０３）。
【００９３】
また立案マネージャ１１８は、当該不採用となった要求要素とＯＲ関係にある要求要素を要素マネージャ１１４に要求する（ステップＳ１０５）。これに対して要素マネージャ１１４は、要求要素管理データ格納部１１６の管理テーブルを参照してＯＲ関係にある未処理の要求要素が存在しているかを確認する（ステップＳ１０７）。もし、ＯＲ関係にある未処理の要求要素が存在している場合には、当該要求要素のデータを要求要素格納部１１２から読み出して立案マネージャ１１８に出力する（ステップＳ１０９）。そして、端子Ａを介してステップＳ７７に移行する。
【００９４】
一方、不採用となった要求要素とＯＲ関係にある未処理の要求要素がない場合には、要素マネージャ１１４は、ＯＲ関係にある未処理の要求要素がない旨の通知を立案マネージャ１１８に出力する（ステップＳ１１１）。そして端子Ｂを介してステップＳ７３に移行する。なお、ステップＳ１０５乃至Ｓ１１１については実施せずに、ステップＳ１０１からステップＳ７３に移行するような構成であってもよい。
【００９５】
このように立案マネージャ１１８とリソース（制約）の管理を行うリソース・オブジェクト群１２４とは別個独立しており、立案マネージャ１１８の立案アルゴリズムを変更してもリソース・オブジェクト群１２４には影響は無い。また、リソース・オブジェクト群１２４の構成を変更しても、立案マネージャ１１８の立案ロジックには影響はない。よって、より多くのリソースを管理して、変更・修正などが頻繁に行われる状況においても立案マネージャ１１８を作り直す必要は無くなる。立案マネージャ１１８の立案ロジックについても変更・修正を加えてもリソース・オブジェクト群１２４には影響が無いので、立案対象の性質や立案効率など様々な観点で変更を加えることができるようになる。
【００９６】
なお、リソース・オブジェクト群１２４は、上でも述べたようにＸＭＬで記述されたデータを元に周知の方法によりオブジェクト化されるものであり、より記述の自由度が高く、変更・修正に適している。
【００９７】
最後に図３に戻って、このようにして得られた立案結果は、立案結果格納部１２０から読み出されて衛星管制部に出力され、実際の衛星制御に用いられる。また、地上の受信局にも出力され、観測データの受信制御などに用いられる。また、要求階層構造管理データ格納部７に格納された管理テーブルにも、セグメントの採否のデータを反映させる（ステップＳ９）。要求階層構造管理データ格納部７の管理テーブルでは、セグメントの採否を管理して、ＯＲ関係にある実現パターンで、他の実現パターンが採用になったため処理が不要となった実現パターンを検出することができる。
【００９８】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではなく、様々な変形が可能である。すなわち、要求受付部１は、例えばインターネット等のネットワークを介して要求を受け付けるような構成であってもよい。また、図１に示した本スケジュール立案システムは、１台のコンピュータで構成してもよいし、複数台のコンピュータで構成してもよい。
【００９９】
また、要求階層構造管理データ格納部７における管理テーブルの構成（図２７）、要求要素管理データ格納部１１６の管理テーブルの構成（図３１）は、一例であって同様の内容またはより多くのデータを含む他の形式のデータであってもよい。
【０１００】
さらに、本スケジュール立案システムは、衛星の観測スケジュールの立案だけでなく、他の様々なスケジュール立案にも適用可能である。
【０１０１】
さらに、図１に示したスケジュール立案システムにおいては前処理部１１０が要求要素への展開処理を実施するような構成を示したが、リソース（制約）の内容・性質によっては前処理部１１０における処理を無くすような構成であってもよい。
【０１０２】
なお、スケジュール立案システムに用いられるプログラムは、例えばフロッピーディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【０１０３】
（付記１）
スケジュール対象に対する要求者の要求情報を受け付け、記憶装置に格納する手段と、
前記スケジュール対象の性質に基づき、前記要求者の要求を満たし且つ実現可能性のある実現パターンを探索し、前記要求者の要求と前記実現パターンと当該実現パターンの内容とを階層構造データとして記憶装置に格納する要求分析手段と、
を有するコンピュータ・システム。
【０１０４】
（付記２）
前記スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段と、
前記階層構造データにおける前記実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を前記複数のスケジュール状態管理手段から取得し、前記各制約項目についてのスケジュール情報の組み合わせである運用パターンを前記実現パターンの内容の下位階層データとして構成する運用パターン構成手段と、
をさらに有する付記１記載のコンピュータ・システム。
【０１０５】
（付記３）
前記複数のスケジュール状態管理手段に、前記階層構造データにおける前記運用パターンを、所定の順番で、当該スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案手段
をさらに有する付記２記載のコンピュータ・システム。
【０１０６】
（付記４）
前記スケジュール立案手段が、
前記階層構造データにおける実現パターンの内容以下のデータ又は前記運用パターンのデータを、所定の規則に従って管理する管理手段と、
前記実現パターンの内容以下のデータ又は前記運用パターンのデータを、所定の順番に従って前記管理手段から取得し、前記複数のスケジュール状態管理手段により設定された運用パターンのデータを、記憶装置に格納する立案手段と、
前記複数のスケジュール状態管理手段に、前記立案手段から受け取った前記運用パターンのデータを、各前記スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させる手段と、
を含む付記３記載のコンピュータ・システム。
【０１０７】
（付記５）
前記スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段と、
前記複数のスケジュール状態管理手段に、前記階層構造データにおける前記実現パターンの内容を、所定の順番で、当該スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な実現パターンの内容を設定させるスケジュール立案手段と、
をさらに有する付記１記載のコンピュータ・システム。
【０１０８】
（付記６）
前記複数のスケジュール状態管理手段が、オブジェクトとして構成されることを特徴とする付記２乃至５のいずれか１つ記載のコンピュータ・システム。
【０１０９】
（付記７）
前記複数のスケジュール状態管理手段が、
制約項目の階層構造に応じた階層構造を有していることを特徴とする付記２乃至５のいずれか１つ記載のコンピュータ・システム。
【０１１０】
（付記８）
前記要求分析手段が、
少なくとも衛星の軌道に基づき、前記要求者の要求に含まれる撮影領域を撮影するための、軌道及び当該軌道における撮影セグメントの組み合わせにて実現パターンを構成し、前記要求者の要求と前記実現パターンと当該実現パターンを構成する前記軌道及び当該軌道における撮影セグメントの組み合わせとを階層構造データとして記憶装置に格納する
ことを特徴とする付記１記載のコンピュータ・システム。
【０１１１】
（付記９）
衛星のリソース及び衛星の運行上で必要となるリソースのいずれかについてのスケジュール状態を管理する複数のスケジュール状態管理手段と、
前記階層構造データにおける前記軌道及び当該軌道における撮影セグメントに適用可能な各リソースについてのスケジュール情報を前記複数のスケジュール状態管理手段から取得し、前記各リソースについてのスケジュール情報の組み合わせである運用パターンを前記軌道及び当該軌道における撮影セグメントの下位階層データとして構成する運用パターン構成手段と、
をさらに有する付記８記載のコンピュータ・システム。
【０１１２】
（付記１０）
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段と、
前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を前記複数のスケジュール状態管理手段から取得し、前記各制約項目についてのスケジュール情報の組み合わせである運用パターンを前記実現パターンの内容の下位階層データとして構成する運用パターン構成手段と、
前記複数のスケジュール状態管理手段に、前記階層構造データにおける前記運用パターンを、所定の順番で、当該スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案手段と、
を有するコンピュータ・システム。
【０１１３】
（付記１１）
前記スケジュール立案手段が、
前記階層構造データにおける実現パターンの内容以下のデータ又は前記運用パターンのデータを、所定の規則に従って管理する管理手段と、
前記実現パターンの内容以下のデータ又は前記運用パターンのデータを、所定の順番に従って前記管理手段から取得し、前記複数のスケジュール状態管理手段により設定された運用パターンのデータを、記憶装置に格納する立案手段と、
前記複数のスケジュール状態管理手段に、前記立案手段から受け取った前記運用パターンのデータを、各前記スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させる手段と、
を含む付記１０記載のコンピュータ・システム。
【０１１４】
（付記１２）
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段と、
前記複数のスケジュール状態管理手段に、前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける前記実現パターンの内容を、所定の順番で、当該スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な実現パターンの内容を設定させるスケジュール立案手段と、
を有するコンピュータ・システム。
【０１１５】
（付記１３）
スケジュールのための要求解析プログラムであって、
コンピュータに、
スケジュール対象に対する要求者の要求情報を受け付け、記憶装置に格納するステップと、
前記スケジュール対象の性質に基づき、前記要求者の要求を満たし且つ実現可能性のある実現パターンを探索し、前記要求者の要求と前記実現パターンと当該実現パターンの内容とを階層構造データとして記憶装置に格納するステップと、
を実行させるための要求解析プログラム。
【０１１６】
（付記１４）
スケジューリング・プログラムであって、
コンピュータに、
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理機能と、
前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を前記複数のスケジュール状態管理機能から取得し、各制約項目についてのスケジュール情報の組み合わせである運用パターンを前記実現パターンの内容の下位階層データとして構成する運用パターン構成機能と、
前記複数のスケジュール状態管理機能に、前記階層構造データにおける前記運用パターンを、所定の順番で、当該スケジュール状態管理機能が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理機能に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案機能と、
を実現させるためのスケジューリング・プログラム。
【０１１７】
（付記１５）
スケジューリング・プログラムであって、
コンピュータに、
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理機能と、
前記複数のスケジュール状態管理機能に、前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける前記実現パターンの内容を、所定の順番で、当該スケジュール状態管理機能が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理機能に、スケジューリング可能な実現パターンの内容を設定させるスケジュール立案機能と、
を実現させるためのスケジューリング・プログラム。
【０１１８】
（付記１６）
スケジュールのための要求解析プログラムを格納した記録媒体であって、
前記要求解析プログラムが、コンピュータに、
スケジュール対象に対する要求者の要求情報を受け付け、記憶装置に格納するステップと、
前記スケジュール対象の性質に基づき、前記要求者の要求を満たし且つ実現可能性のある実現パターンを探索し、前記要求者の要求と前記実現パターンと当該実現パターンの内容とを階層構造データとして記憶装置に格納するステップと、
を実行させるためのプログラムである、記録媒体。
【０１１９】
（付記１７）
スケジューリング・プログラムを格納した記録媒体であって、
前記スケジューリング・プログラムが、コンピュータに、
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理機能と、
前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を前記複数のスケジュール状態管理機能から取得し、前記各制約項目についてのスケジュール情報の組み合わせである運用パターンを前記実現パターンの内容の下位階層データとして構成する運用パターン構成機能と、
前記複数のスケジュール状態管理機能に、前記階層構造データにおける前記運用パターンを、所定の順番で、当該スケジュール状態管理機能が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理機能に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案機能と、
を実現させるためのプログラムである、記録媒体。
【０１２０】
（付記１８）
スケジューリング・プログラムを格納した記録媒体であって、
前記スケジューリング・プログラムが、コンピュータに、
スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理機能と、
前記複数のスケジュール状態管理機能に、前記スケジュール対象に対する要求者の要求と当該要求者の要求を満たし且つ実現可能性のある実現パターンと当該実現パターンの内容とから構成される階層構造データにおける前記実現パターンの内容を、所定の順番で、当該スケジュール状態管理機能が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理機能に、スケジューリング可能な実現パターンの内容を設定させるスケジュール立案機能と、
を実現させるためのプログラムである、記録媒体。
【０１２１】
（付記１９）
スケジュール対象に対する要求者の要求情報を受け付け、記憶装置に格納するステップと、
前記スケジュール対象の性質に基づき、前記要求者の要求を満たし且つ実現可能性のある実現パターンを探索し、前記要求者の要求と前記実現パターンと当該実現パターンの内容とを階層構造データとして記憶装置に格納するステップと、
を含むスケジューリング方法。
【０１２２】
（付記２０）
前記階層構造データにおける前記実現パターンの内容に適用可能な各制約項目についてのスケジュール情報を、前記スケジュール対象をスケジュールする上での各制約項目についてスケジュール状態を管理する複数のスケジュール状態管理手段から取得し、前記各制約項目についてのスケジュール情報の組み合わせである運用パターンを前記実現パターンの内容の下位階層データとして構成する運用パターン構成ステップ、
をさらに含む付記１９記載のスケジューリング方法。
【０１２３】
（付記２１）
前記複数のスケジュール状態管理手段に、前記階層構造データにおける前記運用パターンを、所定の順番で、当該スケジュール状態管理手段が管理する前記制約項目についてのスケジュール状態との関係でスケジューリング可能か否かの判断を行わせ、スケジューリング可能な場合には、前記複数のスケジュール状態管理手段に、スケジューリング可能な運用パターンのスケジュール情報を設定させるスケジュール立案ステップ
をさらに含む付記２０記載のスケジューリング方法。
【０１２４】
【発明の効果】
以上述べたように、ユーザによる様々な要求を一定の構造に変換することによりスケジューリングを容易にするための技術を提供することができた。
【０１２５】
また、制約条件の管理とスケジュール立案処理とを分離することにより様々な要請及び状況に対し容易に対処可能なスケジューリング技術を提供することができた。
【図面の簡単な説明】
【図１】  本発明の一実施の形態に係るシステムの概要を示す図である。
【図２】  リソース・オブジェクトの構造の一例を示す図である。
【図３】  本発明の一実施の形態に係るメイン処理フローを示す図である。
【図４】  観測要求項目の一例を示す図である。
【図５】  要求分析処理の処理フローを示す図である。
【図６】  観測領域が点指定の場合のセグメント化処理のフローを示す図である。
【図７】  ロール角などを説明するための模式図である。
【図８】  パスとロール角のテーブルを示す図である。
【図９】  緯度引数などを説明するための模式図である。
【図１０】  観測点とパスの関係を表す模式図である。
【図１１】  観測点を所定のロール角の範囲内で観測できるパスについてのロール角及び緯度引数のテーブルを示す図である。
【図１２】  観測点のためのセグメントを説明するための模式図である。
【図１３】  優先度の計算例を示す図である。
【図１４】  観測領域が領域指定の場合のセグメント化処理のフローを示す図である。
【図１５】  観測領域とパスの一例を示す模式図である。
【図１６】  領域セグメント化処理のフローを示す図である。
【図１７】  観測領域の頂点におけるロール角のテーブルを示す図である。
【図１８】  観測領域とロール角の関係を示す模式図である。
【図１９】  ロール角による線分と観測領域との交点を説明するための模式図である。
【図２０】  観測領域の点、ロール角及び緯度引数の関係を表すテーブルを示す図である。
【図２１】  観測領域の点、ロール角、緯度引数及びセグメントの関係を表すテーブルを示す図である。
【図２２】  初期セグメントを表す模式図である。
【図２３】  セグメントの補正を説明するための模式図である。
【図２４】  補正後のセグメントを表す模式図である。
【図２５】  セグメントのための情報テーブルを示す図である。
【図２６】  要求分析処理にて生成される階層構造データの一例である。
【図２７】  要求階層構造管理データ格納部における管理テーブルを示す図である。
【図２８】  前処理部における要求要素展開処理のフローを示す図である。
【図２９】  セグメントと運用パターンの関係を表す模式図である。
【図３０】  リソースに対するスケジュール立案処理のフローを示す図である。
【図３１】  要求要素管理データ格納部における管理テーブルの一例を示す図である。
【図３２】  衛星の観測処理の概要を示す図である。
【符号の説明】
１  要求受付部    ３  要求格納部    ５  要求分析部
７  要求階層構造管理データ格納部    ９  要求階層構造データ格納部
１１  スケジュール立案部
１１０  前処理部    １１２  要求要素格納部
１１４  要素マネージャ    １１６  要求要素管理データ格納部
１１８  立案マネージャ    １２０  立案結果格納部
１２２  リソース・マネージャ    １２４  リソース・オブジェクト群
【図１】
0004390399.tif 000002
【図２】
0004390399.tif 000003
【図３】
0004390399.tif 000004
【図４】
0004390399.tif 000005
【図５】
0004390399.tif 000006
【図６】
0004390399.tif 000007
【図７】
0004390399.tif 000008
【図８】
0004390399.tif 000009
【図９】
0004390399.tif 000010
【図１０】
0004390399.tif 000011
【図１１】
0004390399.tif 000012
【図１２】
0004390399.tif 000013
【図１３】
0004390399.tif 000014
【図１４】
0004390399.tif 000015
【図１５】
0004390399.tif 000016
【図１６】
0004390399.tif 000017
【図１７】
0004390399.tif 000018
【図１８】
0004390399.tif 000019
【図１９】
0004390399.tif 000020
【図２０】
0004390399.tif 000021
【図２１】
0004390399.tif 000022
【図２２】
0004390399.tif 000023
【図２３】
0004390399.tif 000024
【図２４】
0004390399.tif 000025
【図２５】
0004390399.tif 000026
【図２６】
0004390399.tif 000027
【図２７】
0004390399.tif 000028
【図２８】
0004390399.tif 000029
【図２９】
0004390399.tif 000030
【図３０】
0004390399.tif 000031
【図３１】
0004390399.tif 000032
【図３２】
0004390399.tif 000033