(57)【要約】【課題】  各制御端末が階層構成をとる分散システムにおいて、各制御端末が自らの判断で休止状態に移行可能とする。【解決手段】  各制御端末１〜４は休止状態に移行するときに、上位の制御端末５，６，７に「休止要求」を送信し、上記「休止要求」を受信した上位の制御端末５，６，７は、「休止要求」送信端末１〜４に依存する処理を実行中の場合「ＮＧ」を返信し、そうでない場合「ＯＫ」を返信する。【選択図】図１
2007287101.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数の制御端末が、階層構造を構成して動作するシステムの休止制御方法において、
上記複数の制御端末の各制御端末は休止状態に遷移するとき、自端末で実行する処理に依存する上位の処理を実行する他端末すべてに休止要求を送信し、
上記休止要求を受信した制御端末は、上記休止要求を送信した制御端末が実行する処理に依存する処理を、自端末で管理している処理の定義を記載した処理定義から検索し、
上記処理定義から上記休止要求を送信した制御端末が実行する処理に依存する処理に合致する処理が見つかった場合、上記処理のステータスを確認し、
上記ステータスが処理実行中以外のアイドル状態であれば休止許可を返信し、
上記ステータスが処理実行中のビジー状態であれば休止許否を返信する
ことを特徴とするシステムの休止制御方法。
【請求項２】
上記休止要求を送信した制御端末は、休止処理の実行中に上記休止要求を送信した他端末から休止許否を受信した場合に、上記休止処理をキャンセルし、
上記休止要求を送信したすべての他端末に休止キャンセル通知を送信することを特徴とする請求項１記載のシステムの休止制御方法。
【請求項３】
上記休止要求を送信した制御端末は、休止処理の実行中に他端末から処理要求を受信した場合に、上記休止処理をキャンセルし、
上記休止要求を送信したすべての他端末に休止キャンセル通知を送信することを特徴とする請求項１記載のシステムの休止制御方法。
【請求項４】
上記複数の制御端末の各制御端末が処理を実行するとき、上記処理が依存するすべての下位の処理を実行する他端末のステータスを確認し、
上記他端末のステータスが処理待機中の休止状態である端末が存在する場合に、上記端末を起動することを特徴とする請求項１記載のシステムの休止制御方法。
【請求項５】
上記複数の制御端末の各制御端末で収集したアクセスログから、上位の処理を実行する他端末であるクライアント端末から送信される処理要求のアクセスパターンを解析し、
あるクライアント端末から制御端末に第１の処理要求が送信された場合に、上記クライアント端末から続けて送信される可能性が高い第２の処理要求を上記解析結果に基づき予測し、
上記第２の処理要求の実行に必要な制御端末が休止中であれば上記休止中の制御端末を起動し、
上記第２の処理要求の実行に必要な制御端末が稼働中であれば上記稼働中の制御端末を休止状態に遷移しないように制御する
ことを特徴とする請求項１記載のシステムの休止制御方法。
【請求項６】
ネットワークに接続された階層構造を形成する複数の制御端末と、構成管理サーバとから構成される制御システムであって、
上記構成管理サーバは、上記複数の制御端末の階層構造の依存関係を解析するとともに、上記複数の制御端末で実行する処理内容の端末処理情報を管理する依存関係解析部を備え、
上記階層構造を形成する各制御端末は、自端末で実行する処理の定義を記載した処理定義と、上記自端末で実行する処理のステータスと、上記自端末で実行する処理が依存するすべての下位の処理を実行する他端末のアドレスと、上記自端末で実行する処理に依存する全ての上位の処理を実行する他端末のアドレスを管理する処理実行部を備えており、
上記処理実行部は、
自端末が休止状態に遷移するときは、該自端末で実行する処理に依存する上位処理を実行する他端末すべてに休止要求を送信し、該上位処理を実行する他端末から休止許可の返信を受けたときに、該自端末を休止状態にする機能を有するとともに、
他端末から休止要求を受信したときは、該他端末が実行する処理に依存する処理を、上記処理実行部が管理している処理定義から検索し、上記処理定義から休止要求を送信した上記他端末が実行する処理に依存する処理に合致する処理が見つかった場合に、上記処理のステータスを確認し、上記ステータスが処理実行中以外のアイドル状態であれば上記他端末に休止許可を返信し、自端末が処理実行中のビジー状態であれば上記他端末に休止許否を返信する休止判断機能を有する
ことを特徴とする制御システム。
【請求項７】
上記処理実行部は、休止処理の実行中に上記休止要求を送信した他端末から休止許否を受信した場合、上記休止処理をキャンセルし、上記休止要求を送信したすべての他端末に休止キャンセル通知を送信する休止キャンセル処理機能を有する
ことを特徴とする請求項６記載の制御システム。
【請求項８】
上記処理実行部は、休止処理の実行中に他端末から処理要求を受信した場合に、上記休止処理をキャンセルし、上記休止要求を送信したすべての他端末に休止キャンセル通知を送信する休止キャンセル処理機能を有する
ことを特徴とする請求項６記載の制御システム。
【請求項９】
上記階層構造に構成された各制御端末は、自端末で実行する処理が依存するすべての下位の処理を実行する他端末のステータスを管理する稼動情報管理部を備え、
上記各制御端末が処理を実行するとき、上記稼動情報管理部は、上記処理が依存するすべての下位の処理を実行する他端末のステータスを確認し、上記ステータスが処理待機中の休止状態である端末が存在する場合に、上記休止状態の端末を起動することを特徴とする請求項６記載の制御システム。
【請求項１０】
上記階層構造に構成された各制御端末は、アクセスログを収集するログ収集部を備え、
上記構成管理サーバは、上記複数の制御端末の各制御端末の上記ログ収集部で収集したアクセスログから、上位の処理を実行する他端末であるクライアント端末から送信される処理要求のアクセスパターンを解析するログ解析部を備え、
上記ログ解析部の解析結果に基づいて、上記構成管理サーバは、あるクライアント端末から第１の処理要求が送信された場合に、上記クライアント端末から続けて送信される可能性が高い第２の処理要求を上記解析結果に基づき予測し、上記第２の処理要求の実行に必要な制御端末が休止中であれば上記休止中の制御端末を起動し、上記第２の処理要求の実行に必要な制御端末が稼働中であれば上記稼働中の制御端末を休止状態に遷移しないように制御することを特徴とする請求項６記載の制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散システムの自動運転に関する技術であり、特にＲＦＩＤ（Radio Frequency Identification）システムのようにシステムを構成する機器の数が多いシステムの電力制御を行うシステムの休止制御方法及び制御システムに関する。
【背景技術】
【０００２】
分散システムの自動運転技術として、機器の依存関係に基づき各機器の起動／停止するスケジュールを作成する発明が提案されている（特許文献１参照）。上述した特許文献１に記載の発明では、ある機器を起動するときにあらかじめ起動しておく必要がある機器や、あらかじめ起動かつ初期化しておく必要がある機器を、機器間の依存関係として設定しておき、全ての依存関係からシステム全体の稼動スケジュールを自動的に作成するものであった。
【特許文献１】特許第３１８３３９８号
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、上述した特許文献１に記載の発明では、分散システムの規模が大きくなり、システムを構成する機器の数が膨大になると、実際に利用していない機器を一時的に休止し節電する要求が発生する。例えばＲＦＩＤを利用した自動倉庫では、ＲＦＩＤデバイスを制御するための機器が多数必要となるが、それら機器の多くは実際の処理に利用されていないアイドル状態となっていることが多いため、機器が消費する電力は無視できなくなる。
【０００４】
このような分散システムを節電するためには、各機器はアイドル状態になると自分の判断で待機状態を示す休止状態に遷移することが望ましい。しかし、休止状態と稼動状態間の状態遷移には一定の時間が必要であるので、休止状態になった機器を利用するためにはその機器を再起動（休止状態から稼動状態への遷移）する間、業務を一時停止する必要があり、システムの利便性が損なわれる。上記課題を解決するためには、休止しようとする機器が近い将来利用されないことを確認してから休止する必要がある。
【０００５】
上述した特許文献１に記載の方法では、各機器の稼動状態はあらかじめ決められたスケジュールに従って制御するため、各機器がアイドル状態になったときに各機器が自分の判断で休止状態に遷移する制御を行うことができないという不都合があった。また各機器が休止状態に遷移しようとしても、実際にその機器が近い将来利用されるかどうか判断することができないという不都合があった。
【０００６】
そこで、本発明は、分散システムで各機器が自分の判断で休止状態に遷移する制御を行うことができると共に、その機器が近い将来利用されるかどうか判断することができるシステムの休止制御方法及び制御システムを提供することを目的とするものである。
【課題を解決するための手段】
【０００７】
上記課題を解決し、本発明の目的を達成するため、本発明では、各制御端末は、自端末で実行する処理の定義を記載した処理定義と、上記自端末で実行する処理のステータスと、上記自端末で実行する処理が依存するすべての下位の処理及びその処理を実行する他端末のアドレスと、上記自端末で実行する処理に依存する全ての上位の処理及びその処理を実行する他端末のアドレスを管理する処理実行部を備えている。
【０００８】
各制御端末は休止状態に遷移するとき、自端末で実行する処理に依存する上位の処理を実行する他端末すべてに「休止要求」を送信し、上記「休止要求」を受信した制御端末は、上記「休止要求」を送信した制御端末が実行する処理に依存する処理を、上記処理実行部が管理している処理定義から検索し、上記条件に合致する処理が見つかった場合、その処理のステータスを確認し、上記ステータスが「アイドル」であれば「ＯＫ」を返信し、「ビジー」であれば「ＮＧ」を返信する。
【０００９】
また本発明では、「休止要求」を送信した制御端末は、休止処理実行中に上記「休止要求」を送信した他端末から「ＮＧ」を受信した場合、休止処理をキャンセルし、「休止要求」を送信したすべての他端末に「休止キャンセル通知」を送信する。
また本発明では、「休止要求」を送信した制御端末は、休止処理実行中に他端末から「処理要求」を受信した場合、休止処理をキャンセルし、「休止要求」を送信したすべての他端末に「休止キャンセル通知」を送信する。
【００１０】
また本発明では、各制御端末は、自端末で実行する処理が依存するすべての下位の処理を実行する他端末のステータスを管理する稼動情報管理部を備え、制御端末が処理を実行するとき、上記稼動情報管理部は、上記処理が依存するすべての下位の処理を実行する他端末のステータスを確認し、ステータスが「休止」である端末が存在する場合、その端末を起動する。
【００１１】
また本発明では、構成管理サーバは、各制御端末で収集したアクセスログから、クライアント端末から送信される「処理要求」のアクセスパターンを解析し、あるクライアント端末から制御端末に第１の「処理要求」が送信された場合に、上記クライアント端末から続けて送信される可能性が高い第２の「処理要求」を上記解析結果に基づき予測し、上記第２の「処理要求」の実行に必要な制御端末が休止中であれば上記休止中の制御端末を起動し、上記第２の「処理要求」の実行に必要な制御端末が稼働中であれば上記稼働中の制御端末を休止状態に遷移しないように制御する。
【発明の効果】
【００１２】
本発明によれば、各端末が実際に休止してもシステムの利便性に問題を起こさないときのみ、各端末を休止するので、分散システムの利便性を失うことなく節電効果を得ることができる。
【発明を実施するための最良の形態】
【００１３】
以下に、本発明の実施の形態について、適宜、図面を参照しながら説明する。
まず、本発明の第１の実施の形態を説明する。
図１は本発明の実施の形態例のシステム構成を示している。
ネットワーク１０１には、制御端末１〜７と、構成管理サーバ８と、クライアント端末ｔ１〜ｔｎ（ｎは端末の数）が接続されている。構成管理サーバ８に接続されている記憶装置（ハードディスクなど）には、制御端末１〜７で実行する処理内容を記述した端末処理情報が格納されている。制御端末１〜４はＲＳ−２３２Ｃケーブルを介してＲＦＩＤリーダ／ライタ１０−１〜１０−４を制御する。すなわち、制御端末１〜４はそれぞれ棚Ａ１、棚Ａ２、棚Ｂ１、棚Ｂ２に設置されたＲＦＩＤリーダ／ライタ１０−１〜１０−４の制御を受け持つ。
【００１４】
図４は制御端末間の階層構成を示す図である。
制御端末１〜７間の上下関係は図４に示すように階層構成となっており、図４において、制御端末１、制御端末２が読み取ったデータを制御端末５が集計する。つまり制御端末５は棚Ａ１と棚Ａ２から構成されるエリアＡを受け持つ。同様に、制御端末６は棚Ｂ１と棚Ｂ２から構成されるエリアＢを受け持ち、制御端末３、制御端末４が読み取ったデータを集計する。制御端末７はエリアＡとエリアＢからなるフロア全体を受け持ち、制御端末５、制御端末６が受信したデータを集計する。
【００１５】
図２は構成管理サーバの構成を示す図である。
図２に示すように構成管理サーバ８のソフトウェア構成は、制御端末１〜７の構成情報の依存関係を解析する依存関係解析部１１と、構成管理サーバ８の記憶装置に記憶されている端末処理情報Ｃの管理及び制御端末１〜７への配布を行う構成情報配布部１２からなる。
【００１６】
図３は制御端末の構成を示す図である。
図３に示すように、制御端末１〜７のソフトウェア構成は、端末処理情報Ｃに基づいて処理を実行する処理実行部２１と、自端末に依存する端末（逆依存関係端末）と自端末が依存する端末（依存関係端末）の稼動状態を管理する稼動状態管理部２２と、ＲＦＩＤリーダ／ライタ１０−１〜１０−４を制御するデバイス制御部２３からなる。ここで、稼動状態管理部２２は、制御端末１〜７の休止処理を行う休止処理実行機能と、制御端末１〜７の起動及び再起動処理を行う起動処理実行機能とを有している。
【００１７】
図５〜図７は、制御端末１〜７に格納される端末処理情報Ｃの具体例を示しており、図５、図６、図７はそれぞれ制御端末７、制御端末５、制御端末１に格納される端末処理情報Ｃ７、端末処理情報Ｃ５、端末処理情報Ｃ１に対応するものである。
端末処理情報Ｃ７、Ｃ５、Ｃ１は、依存処理リストＣ７１、Ｃ５１、Ｃ１１と、逆依存処理リストＣ７２、Ｃ５２、Ｃ１２と、処理定義Ｃ７３、Ｃ５３、Ｃ１３から構成される。処理定義Ｃ７３、Ｃ５３、Ｃ１３には、各端末で実行する処理の内容が記載されており、依存処理リストＣ７１、Ｃ５１、Ｃ１１には上記処理が依存する他端末の処理（他端末が実行する処理）が設定されており、逆依存処理リストＣ７２、Ｃ５２、Ｃ１２には上記処理に依存する他端末の処理が設定されている。
【００１８】
例えば、制御端末５の端末処理情報Ｃ５は図６のようになっており、処理定義Ｃ５３にはアドレス”192.168.0.2”を持つ端末（制御端末１）の「棚Ａ１確認」処理と、アドレス”192.168.0.3”を持つ端末（制御端末２）の「棚Ａ２確認」処理を実行する旨の動作が処理名「エリアＡ確認」として定義されている。処理定義Ｃ５３には制御端末５自身のアドレスも記載されているが、これは構成管理サーバ８が各制御端末１〜７に処理定義Ｃ５３を配布するときに利用する。
【００１９】
依存処理リストＣ５１には上記処理定義Ｃ５３に記述されている処理「棚Ａ１確認」、「棚Ａ２確認」とそれら処理を実行する制御端末１、２のアドレスが設定されている。また、制御端末５で定義された処理を利用する端末は制御端末７であるので、逆依存処理リストＣ５２には制御端末７のアドレス（192.168.0.8）と制御端末７の処理「フロア確認」が設定されている。
【００２０】
制御端末５の例では依存処理リストＣ５１、逆依存処理リストＣ５２の内容は、処理定義Ｃ５３が直接依存もしくは直接逆依存する処理定義に関する情報だけ設定しているが、実際には処理定義が間接的に依存もしくは逆依存するすべての処理定義に関する情報も含めて設定する。例えば、制御端末７の端末処理情報Ｃ７（図５）では、制御端末１〜６で定義されている処理を依存処理リストＣ７１に設定することになり、制御端末１の端末処理情報Ｃ１（図７）では、制御端末５と制御端末７で定義されている処理を逆依存処理リストＣ１２に設定することになる。
【００２１】
クライアント端末ｔ１〜ｔｎ上では、制御端末１〜７を利用するアプリケーションプログラムが稼動しており、例えばエリアＡの棚卸し処理を行う場合、クライアント端末ｔ１〜ｔｎは制御端末５に対して「エリアＡ確認」処理実行要求を送信する。上記要求を受け取った制御端末５は、制御端末１に「棚Ａ１確認」要求を、制御端末２に「棚Ａ２」確認要求を送信し、処理結果を集計後、クライアント端末ｔ１〜ｔｎに結果を返す。
【００２２】
本システムを構築するとき、システム開発者は図４のような階層構成の計画図に基づいて各端末に設定すべき端末処理情報Ｃ７、Ｃ５、Ｃ１の処理定義Ｃ７３、Ｃ５３、Ｃ１３を手作業もしくは、専用のツールを利用して構成管理サーバ８上に作成する。端末処理情報Ｃ７、Ｃ５、Ｃ１の依存処理リストＣ７１、Ｃ５１、Ｃ１１と逆依存処理リストＣ７２、Ｃ５２、Ｃ１２は、すべての処理定義Ｃ７３、Ｃ５３、Ｃ１３の作成完了後、構成管理サーバ８が端末処理情報Ｃ７、Ｃ５、Ｃ１の依存関係を解析することで自動的に作成する。
【００２３】
依存処理リストＣ７１、Ｃ５１、Ｃ１１と逆依存処理リストＣ７２、Ｃ５２、Ｃ１２の作成が完了すると、構成管理サーバ８は各端末に端末処理情報Ｃ７、Ｃ５、Ｃ１を配布し、システムが利用可能となる。なお、構成管理サーバ８は端末処理情報Ｃ７、Ｃ５、Ｃ１の配布先については、端末処理情報Ｃ７、Ｃ５、Ｃ１の処理定義Ｃ７３、Ｃ５３、Ｃ１３に記載されている処理を実行する端末アドレスから決定する。
【００２４】
〔端末処理情報の依存関係解析処理の手順〕
構成管理サーバ８が端末処理情報Ｃ７、Ｃ５、Ｃ１の処理定義Ｃ７３、Ｃ５３、Ｃ１３から依存処理リストＣ７１、Ｃ５１、Ｃ１１と逆依存処理リストＣ７２、Ｃ５２、Ｃ１２を作成する解析処理は、構成管理サーバ８が各端末処理情報Ｃ７、Ｃ５、Ｃ１の依存関係を再帰的に辿りながら実施する。図８に、上記依存関係解析処理の手順を表すフローチャートを示し、図９に上記依存関係解析処理の中で再帰処理を行う部分のフローチャートを示す。以下、上記依存関係解析処理の手順を説明する。
【００２５】
図８において、構成管理サーバ８の依存関係解析部１１は、端末処理情報を１つ選択し、その処理定義を解析し（ステップＳ１０１）、処理定義に依存する処理の処理名と上記処理を実行する制御端末のアドレスを依存処理リストに追加する（ステップＳ１０２）。例えば、構成管理サーバ８の依存関係解析部１１は、図５に示した端末処理情報Ｃ７を解析する場合、処理定義Ｃ７３を解析し、（処理名、アドレス）＝（エリアＡ確認、192.168.0.6）、（エリアＢ確認、192.168.0.7）という情報を取り出し、依存処理リストＣ７１に追加する。次に、依存関係解析部１１は、処理定義の解析を終了したか否かを判断する（ステップＳ１０３）。すなわち、ステップＳ１０１とステップ  Ｓ１０２の処理が全ての端末処理情報に対して行われたか否かを判断する。
【００２６】
判断ステップＳ１０３で全ての処理定義の解析が終了したと判断された場合は、続いて、依存関係解析部１１は他のどの端末処理情報の依存処理リストにも記載されていない処理定義（ルート処理）を１つ選択する（ステップＳ１０４）。ステップＳ１０４のルート処理が１つ選択できたら、構成管理サーバ８の依存関係解析部１１は、端末処理情報の依存関係を再帰的に辿ることで、処理定義間の依存関係を解析していく（ステップＳ１０６）。この依存処理定義解析についての詳細はサブルーチンとして図９に示されている。そして、全てのルート処理についてその解析が終了したかどうかを判断し（ステップＳ１０５）、全てのルート処理についてステップＳ１０６の処理が完了すると、解析処理は終了する。
【００２７】
上述したように、ステップＳ１０６の依存処理定義解析はサブルーチンとして実装されている。このサブルーチンの引数（入力情報）は、解析すべき処理の端末処理情報とその処理に逆依存する処理の情報（処理名とその処理を実行する制御端末のアドレス）のリストであり、サブルーチンの戻り値（出力情報）は、解析すべき処理とその処理が依存する処理の情報（処理名とその処理を実行する制御端末のアドレス）のリストである。
【００２８】
図９に示すように、サブルーチンの最初の処理では、構成管理サーバ８の依存関係解析部１１は、サブルーチンの引数に設定した逆依存処理を端末処理情報の逆依存処理リストへ設定する（ステップＳ１０７）。例えば、構成管理サーバ８の依存関係解析部１１が制御端末７の端末処理情報Ｃ７をルート処理として選択した場合、逆依存処理はないので、サブルーチンへ入力する情報はない。従って、この場合には、ステップＳ１０７で行う処理はない。
【００２９】
続いて、依存関係解析部１１は端末処理情報の依存処理リストに記載された処理を１つ選択し（ステップＳ１０８）、サブルーチンの引数を設定してステップＳ１０６のサブルーチンを呼び出す。このとき、解析すべき処理の端末処理情報は、選択した処理に関する端末処理情報となり、逆依存する処理の情報は、ステップＳ１０７で逆依存処理リストに追加した情報と現在解析中の端末処理情報に関する情報となる。
【００３０】
例えば、構成管理サーバ８の依存関係解析部１１が、端末処理情報Ｃ７を解析中に「エリアＡ確認」処理を選択した場合、解析すべき処理の端末処理情報は、「エリアＡ確認」（“192.168.0.6”）となり、また、逆依存する処理の情報は、「フロア確認」（“192.168.0.8”）となる。
【００３１】
ステップＳ１０８の処理では、構成管理サーバ８の依存関係解析部１１は、ステップＳ１０１、ステップＳ１０２で行なった処理定義解析処理で依存処理リストに追加した情報のみを選択する。なお、ステップＳ１０８以降の処理の途中では、依存処理リストに情報が追加されていくが、この情報についてはステップＳ１０８で選択しない。
【００３２】
構成管理サーバ８の依存関係解析部１１は、サブルーチンを再帰的に呼び出すので、続いて「エリアＡ確認」処理に関する端末処理情報、すなわち端末処理情報Ｃ５に関する依存関係解析処理をステップＳ１０７から行うことになる。つまり、このステップＳ１０７の逆依存リストの更新処理では、図８で説明した手順と同様の手順により、依存関係解析部１１は逆依存処理リストにサブルーチンの引数に設定されていた「フロア確認」処理に関する端末処理情報（「フロア確認」、”192.168.0.8”）を逆依存処理リストＣ５２に設定する処理を行うことになる。
【００３３】
次に、構成管理サーバ８の依存関係解析部１１は、依存端末リストＣ５から１つを選択し（ステップＳ１０８）、先ほどと同様に再帰的にサブルーチンを呼び出す。例えば「棚Ａ１確認」処理に関する処理を選択した場合は、構成管理サーバ８の依存関係解析部１１は、次のようにサブルーチンの引数を設定する。このとき、解析すべき処理の端末処理情報は、「棚Ａ１確認」（“192.168.0.2”）となり、逆依存する処理の情報は、「フロア確認」（“192.168.0.8”）と、「エリアＡ確認」（“192.168.0.6”）となる。
【００３４】
例えば、「棚Ａ１確認」処理に関する端末処理情報Ｃ１の解析では、構成管理サーバ８の依存関係解析部１１はサブルーチンの引数に設定されていた「フロア確認」（“192.168.0.8”）と、「エリアＡ確認」（“192.168.0.6”）を逆依存処理リストＣ１２に追加する（ステップＳ１０７）。そしてステップＳ１０６の依存処理定義解析のサブルーチンが実行される。ステップＳ１０６の依存処理定義解析が終了すると、これ以上依存する処理はないことになるので、このサブルーチンを抜ける。このとき、構成管理サーバ８の依存関係解析部１１は、戻り値として端末処理情報の依存処理リストに記載されている情報を設定する。端末処理情報Ｃ１を解析している場合は、依存処理リストＣ１１は空であるので、戻り値は空である。
【００３５】
判断ステップＳ１０９において、依存処理定義解析のサブルーチンを抜けると、構成管理サーバ８の依存関係解析部１１は、端末処理情報Ｃ５の解析処理に戻る。次のステップ（ステップＳ１１０）では、構成管理サーバ８の依存関係解析部１１は、サブルーチンの戻り値を依存処理リストＣ５１に追加することになるが、今回戻り値は空であるので、特に追加は行わない。構成管理サーバ８の依存関係解析部１１は、同様に制御端末２に関しても解析処理を行うと、端末処理情報Ｃ５の解析処理を終了しサブルーチンから戻るときには、端末処理情報Ｃ５の内容は図６に示すようになる。従ってサブルーチンの戻り値には、依存処理リストＣ５１に記載されている以下の情報を設定する。このとき、「処理名（“アドレス”）」は、「棚Ａ１確認（“192.168.0.2”）」及び「棚Ａ２確認（“192.168.0.3”）」となる。
【００３６】
続いて、構成管理サーバ８の依存関係解析部１１がサブルーチンから抜けると、端末処理情報Ｃ７の解析処理に戻る。次のステップ（ステップＳ１１０）では、サブルーチンの戻り値を依存処理リストＣ７１に設定する。続いて、構成管理サーバ８の依存関係解析部１１は、依存処理リストに記載された「エリアＢ確認」処理を選択し、以下のようにサブルーチンの引数を設定して、「エリアＢ確認」処理に関する端末処理情報の解析を行う。このとき、「解析すべき処理の端末処理情報」は、「エリアＢ確認」（“192.168.0.7”）となり、「逆依存する処理の情報」は、「フロア確認」（“192.168.0.8”）となる。
【００３７】
同様の手順で処理を行うと、「エリアＢ確認」処理に関する端末処理情報の解析を行なった結果、サブルーチンの戻り値は、「処理名（“アドレス”）」が「棚Ｂ１確認（“192.168.0.3”）」及び「棚Ｂ２確認（“192.168.0.4”）」となる。そして、依存関係解析部１１は、上記情報を依存処理リストＣ７１に追加する（ステップＳ１１０）。ステップＳ１０１、ステップＳ１０２で依存処理リストＣ７１に設定した処理はすべて解析処理を終了したので、サブルーチンを抜ける。これで端末処理情報Ｃ７の解析処理は終了するが、他のルート処理が存在すれば同様の手順で解析処理を行うことになる。
【００３８】
〔端末ステータスの説明〕
図８及び図９に示した端末処理情報の解析が終了すると、構成管理サーバ８は端末処理情報を各制御端末に配信し、本システムが稼動できるようになる。
ここで、制御端末の処理実行部２１は、図１０に示すように、動作情報テーブル２１２と、構成管理サーバ８から配布された端末処理情報Ｃ５から構成され、動作情報テーブル２１２には自端末で実行可能な処理とそのステータスをリストとして管理する。実際に処理が実行中のとき処理のステータスは「ビジー」となり、そうでないとき処理のステータスは「アイドル」となる。処理を行うために休止中の端末を起動している途中の場合も、その処理のステータスは「ビジー」である。
【００３９】
制御端末の稼動情報管理部２２は図１１に示すように、自端末のステータスを自端末ステータス情報２２１に設定し、他端末のアドレス、ステータス、およびステータスの状態が「休止」状態に変更した時刻（休止時刻）を他端末ステータス情報２２２のテーブルに設定する。自端末のステータスは、「起動中」、「ビジー」、「アイドル」、「休止途中」、「休止」のいずれかの値をとり、他端末のステータスは「稼働」、「休止」のいずれかの値をとる。
【００４０】
他端末ステータス情報２２２のテーブルには、端末処理情報の依存処理リスト及び逆依存処理リストに記載された全ての処理を担当する制御端末に関する情報が設定される。すなわち、自端末に依存する端末（逆依存関係端末）と、自端末が依存する端末（依存関係端末）に関する情報が設定される。
【００４１】
以下では自端末のステータスについて説明する。ステータスが「起動中」のときは、制御端末が起動中の状態であることを示し、各種ソフトウェアの初期化を行っている状態である。ステータスが「ビジー」のときは動作情報テーブル２１２に設定された処理のうち少なくとも１つのステータスが「ビジー」となっている状態である。ステータスが「アイドル」のときは動作情報テーブル２１２に設定されたすべての処理のステータスが「アイドル」となっている状態である。
【００４２】
ステータスが「休止途中」のときは制御端末が休止状態に入るための準備をしている状態であり、「休止」は制御端末が実際の休止処理を行なっている状態である。ステータスが「休止途中」状態の制御端末が一定条件（例えば、他端末から処理要求を受けた場合）を満たせば休止処理をキャンセルするが、「休止」状態の制御端末は休止処理をキャンセルすることはない。
【００４３】
続いて他端末のステータスについて説明する。他端末ステータス情報２２２のテーブルに設定される他端末のステータスが「稼働」の場合、他端末自身が自端末ステータス情報２２１で管理するステータスは「アイドル」、「ビジー」、「休止途中」のいずれかである。他端末ステータス情報２２２のテーブルに設定される他端末のステータスが「休止」の場合、他端末自身が自端末ステータス情報２２１で管理するステータスは「起動中」、「休止」、「休止途中」のいずれかである。
【００４４】
制御端末自身のステータスが「休止途中」状態のとき、制御端末は「休止要求」を他の制御端末に送信するが、この要求を受け取った他端末の稼動情報管理部２２は上記要求の送信端末のステータスを「休止」に設定する。従って、制御端末自身のステータスが「休止途中」であるが、その端末から「休止要求」を受信していない場合、他端末ステータス情報２２２のテーブルに設定する他端末のステータスは「稼働」となり、「休止要求」を受信した後他端末ステータス情報２２２のテーブルに設定する他端末のステータスは「休止」となる。
【００４５】
〔端末間通信メッセージの説明〕
稼動情報管理部２２は制御端末間でメッセージをやり取りしながら、各端末の稼動状態を管理する。図１７に稼動情報管理部２２がメッセージを受信したときどのような動作を行うかを、自端末のステータス（自端末ステータス情報２２１に設定するステータス）毎に表にしたものを示す。図１７には本実施の形態例で利用する主なメッセージを記載している。図１７では自端末のステータスが「休止」の場合について記載がないが、ステータスが「休止」の場合、稼動情報管理部２２は通信処理を停止するので他端末からメッセージを受信することはないため、省略している。
【００４６】
以下、各メッセージの意味を説明する。「ステータス確認」１７１は他端末が管理するステータスを確認するときに送信するメッセージであり、上記メッセージを受けた制御端末はステータスがアイドル１７８及びビジー１７９のとき「稼動」を返信し、もしくはステータスが起動中１７６及び休止途中１７７のとき「休止」を返信する。「ステータス確認」１７１を送信した稼動情報管理部２２は、上記返信に基づいて他端末ステータス情報２２２で管理している他端末のステータスを設定する。
【００４７】
「休止要求」１７２は制御端末が休止状態に移行してもよいかどうかを、他の制御端末に確認するメッセージである。「休止要求」１７２を受信した制御端末が、「休止要求」１７２の送信端末に依存する処理を実行中のビジー１７９の場合「ＮＧ」を返信し、それ以外の起動中１７６、休止途中１７７及びアイドル１７８の場合「ＯＫ」を返信する。「休止要求」１７２を受信した制御端末のステータスが「ビジー」１７９であっても、「休止要求」１７２の送信端末に依存する処理を実行中でない場合は、「ＯＫ」を返信する。
【００４８】
「休止キャンセル通知」１７３は制御端末のステータスが「休止途中」１７７状態に遷移して休止処理を開始したが、途中で休止処理をキャンセルする場合に、他端末に休止処理をキャンセルしたことを通知するメッセージである。稼動情報管理部２２は「休止キャンセル通知」１７３を受信すると、いずれのステータスの場合にも他端末ステータス情報２２２を更新し、対応する端末のステータスを「稼動」に設定する。
【００４９】
「起動通知」１７４は制御端末の起動処理が完了したことを通知するメッセージである。稼動情報管理部２２は「起動通知」１７４を受信すると、いずれのステータスの場合にも他端末ステータス情報２２２を更新し、対応する端末のステータスを「稼動」に設定する。
「起動パケット」１７５は、休止状態になっている制御端末を起動するためのパケットであり、例えばWake up On LANのマジックパケットを用いる。稼動情報管理部２２は「起動パケット」１７５を受信しても、上記メッセージに対する処理は特に行わない。
【００５０】
〔状態遷移の説明〕
図１２に、自端末ステータス情報２２１が管理する自端末のステータスの状態遷移を示す。制御端末が起動した直後は自端末のステータスは「起動中」１２５であるが、起動処理が完了するとステータスは「アイドル」１２２に遷移する（Ｔ７）。
ステータスが「アイドル」１２２の状態が一定時間続くなどの休止条件が成立すると、稼動情報管理部２２は自端末のステータスを「休止途中」１２１に遷移させて休止処理を開始する（Ｔ２）。休止処理では、制御端末は自端末に依存する端末（逆依存関係端末）に対して「休止要求」を送信する。
【００５１】
制御端末はもし１つでも「ＮＧ」返信を受信したら休止要求をキャンセルし「アイドル」１２２に遷移する（Ｔ１）。制御端末は全ての端末から「ＯＫ」返信を受信したら、実際に休止処理を行ってもよいと見なしステータスを「休止」１２４に遷移し、実際の休止処理を行う（Ｔ６）。また制御端末は休止処理中に他の端末から「処理要求」を受信した場合、休止処理をキャンセルし、制御端末の処理実行部２１は要求された処理を実行する。この場合、制御端末は自端末のステータスは「ビジー」１２３に遷移する（Ｔ３）。
【００５２】
アイドル中に他の端末から「処理要求」を受信した場合、制御端末の稼動情報管理部２２は自端末のステータスを「ビジー」１２３に遷移し、制御端末の処理実行部２１は要求された処理を実行する（Ｔ４）。制御端末は処理が終了したらステータスは「アイドル」１２２に遷移する（Ｔ５）。
【００５３】
〔起動処理の手順〕
制御端末１〜７を停止状態から起動した場合（コールドブート）や、制御端末１〜７が休止状態から再起動した場合（ウォームブート）、稼動情報管理部２２は制御端末１〜７の起動処理を行う。上記起動処理は、稼動情報管理部２２が管理する各種テーブルの設定などを行い、制御端末１〜７が正常に稼動できるようにするための処理である。
【００５４】
コールドブートの場合、稼動情報管理部２２が上記起動処理を稼動情報管理部２２の起動時に実行する。ウォームブートの場合、制御端末１〜７が休止状態になる直前のウォームブート時に、稼動情報管理部２２が上記起動処理を行う設定を行うことで、ウォームブート時に上記起動処理を行うようにする。
【００５５】
以下では、図１３に示した「起動処理」の詳細な処理を示すフローチャートを用いて、起動処理の手順を詳細に説明する。
起動処理が開始すると、稼動情報管理部２２は他端末ステータス情報２２２をいったんクリアし、処理実行部２１内の端末処理情報Ｃから他端末ステータス情報２２２を再作成する。すなわち、稼動情報管理部２２は端末処理情報Ｃの依存処理リストと逆依存処理リストに記載されている端末アドレスを、他端末ステータス情報２２２に格納して初期化処理をする（ステップＳ２０１）。このとき、初期化処理でのアドレスの重複がないようにする。
【００５６】
次に稼動情報管理部２２は自端末ステータス情報２２１に設定されている自端末のステータスを「起動中」に設定し（ステップＳ２０２）、通信処理を開始する。この状態で起動処理中の制御端末が自端末に依存する制御端末（依存関係端末）から「休止要求」を受信した場合、必ず「ＯＫ」を返信する。
【００５７】
次に稼動情報管理部２２は、他端末ステータス情報２２２に設定されるすべての制御端末に対して「ステータス確認」を送信する（ステップＳ２０３）。「ステータス確認」を受信した制御端末は、「休止」もしくは「稼動」を返信する。制御端末のステータスが「休止途中」もしくは「起動中」の場合には「休止」を返信し、制御端末のステータスが「アイドル」もしくは「ビジー」の場合には「稼動」を返信する。制御端末のステータスが「休止」の場合、制御端末は通信処理を行わないので返信しない。
【００５８】
稼動情報管理部２２は返信を受けると、その返信に従って他端末ステータス情報２２２のステータスを設定する。一定時間経過しても返信がない場合、稼動情報管理部２２はその制御端末のステータスは「休止」とする。このステップＳ２０３でステータスを「休止」に設定した他端末ステータス情報２２２のエントリについては、休止時刻を現在時刻に設定する。
【００５９】
次に稼動情報管理部２２は、他端末ステータス情報２２２に記載された端末でステータスが「稼動」であるすべての端末に「起動通知」を送信し（ステップＳ２０４）、自端末ステータス情報２２１に設定されている自端末のステータスを変更して「アイドル」に設定し（ステップＳ２０５）、起動処理を終了する。
上記ステップＳ２０４で「起動通知」を受信した制御端末の稼動情報管理部２２は、他端末ステータス情報２２２に設定されている、「起動通知」送信端末のステータスを「稼動」に変更する。
【００６０】
〔休止処理の手順〕
次に、図１４に示した「休止処理」の詳細な処理を示すフローチャートを用いて、休止処理の手順を詳細に説明する。
制御端末１〜７にあらかじめ設定した休止条件が満たされると稼動情報管理部２２は休止処理を開始し、自端末ステータス情報２２１に記載した自端末のステータスを「休止途中」に変更する（ステップＳ３０１）。
【００６１】
上記休止条件は、例えば自端末のステータスが１５分以上「アイドル」状態である状態が続いた場合、などの条件を設定することになるが、この休止条件の情報はシステム構築時に各制御端末１〜７の稼動情報管理部２２に予め設定されるようにしてもよいし、構成管理サーバ８で一元管理して構成変更時に構成管理サーバ８から配信してもよい。
【００６２】
続いて稼動情報管理部２２は、他端末ステータス情報２２２に設定されている制御端末１〜７のうちステータスが「稼動」のものに対して、「休止要求」を送信する（ステップＳ３０２）。他端末ステータス情報２２２には、自端末に依存する端末（逆依存関係端末）と、自端末が依存する端末（依存関係端末）のアドレスが設定されているので、稼動情報管理部２２は、この処理ではステータスが「稼動」であるすべての逆依存関係端末と依存関係端末に対して「休止要求」を送信することになる。
【００６３】
続いて、稼動情報管理部２２は上記ステップＳ３０２で「休止要求」を送信した端末からの返信があるまで返信待ちとなる（ステップＳ３０３）。このステップＳ３０３で返信待ち状態となっているときに、稼動情報管理部２２は他の端末から「処理要求」があったか否かを判断し（ステップＳ３０４）、判断ステップＳ３０４で他の端末から「処理要求」が送信されていないと判断された場合に、稼動情報管理部２２は「休止要求」を送信した端末から「ＮＧ」返信を受け取ったか否かを判断する（ステップＳ３０５）。
【００６４】
判断ステップＳ３０４で他の端末から「処理要求」が送信されてきた場合、及び判断ステップＳ３０５で「休止要求」を送信した端末から「ＮＧ」返信を受け取った場合には、稼動情報管理部２２は、ステップＳ３０２で「休止要求」を送信した全ての端末に対して「キャンセル通知」を送信し（ステップＳ３０６）、自端末のステータスを「アイドル」に変更して（ステップＳ３０７）、処理を終える。
【００６５】
そして、「キャンセル通知」を受け取った制御端末の稼動情報管理部２２は、他端末ステータス情報２２２から「キャンセル通知」送信端末のエントリを検索し、当該端末のステータスを「休止」から「稼動」に変更する。
次に、判断ステップＳ３０５で「休止要求」を送信した端末から「ＮＧ」返信を受け取らなかった場合には、稼動情報管理部２２は、すべての自端末に依存する端末（逆依存端末）から「ＯＫ」返信を受け取ったか否かを判断する（ステップＳ３０５）。そして、すべての逆依存端末から「ＯＫ」返信を受け取らない限り、ステップＳ３０３〜ステップＳ３０５までの処理及び判断をすべての自端末に依存する端末（逆依存端末）について繰り返す（ステップＳ３０８）。
【００６６】
ステップＳ３０２で「休止要求」を送信した制御端末１〜７のうち、ステップＳ３０８ですべての自端末に依存する端末（逆依存端末）から「ＯＫ」返信を受け取ったとき、ステップＳ３０８で「ＯＫ」返信を受け取った制御端末の稼動情報管理部２２は、実際に休止処理を行なってもよい。ステップＳ３０８で「ＯＫ」返信を受け取った制御端末の稼動情報管理部２２は自端末のステータスを「休止」に変更し（ステップＳ３０９）、通信処理を停止し、一定時間経過後（例：１５秒後）に起動処理を開始する設定を行なった後、制御端末のオペレーティングシステム（ＯＳ）に対してシステムを休止状態に移行するように指示する。これにより、稼動情報管理部２２は休止処理を実行する（ステップＳ３１０）。
【００６７】
上記起動処理の開始設定は、端末が休止状態から回復したときに、起動処理を適切に行うための設定である。端末が休止状態に以降するとき、オペレーティングシステム（ＯＳ）によってすべてのプログラムの状態が保存され、再起動時にすべてのプログラムが動作を再開する。よって端末が休止状態から回復すると、上記起動処理が起動する。本実施の形態例では、システム休止処理を行なっている途中で起動処理が開始されることを防止するために、稼動情報管理部２２は起動処理開始のタイムラグを設定している。
【００６８】
また、オペレーティングシステム（ＯＳ）が再起動したことを上位モジュールに通知する機能を備えている場合は、休止処理直前に起動処理の開始設定を行わず、オペレーティングシステム（ＯＳ）再起動時に起動処理を開始する構成としてもよい。
【００６９】
以上は休止処理を行う端末での処理の説明であるが、続いて図１５に示すフローチャートを用いて上記「休止要求」を受信した端末の処理を説明する。
稼動情報管理部２２が「休止要求」を受信すると、稼動情報管理部２２は処理実行部２１内の端末処理情報Ｃを参照し、端末処理情報Ｃの依存処理リスト内の端末アドレスに「休止通知」送信端末のアドレスが設定された端末処理情報Ｃを検索する（ステップＳ４０１）。
【００７０】
稼動情報管理部２２は上記ステップＳ４０１の検索条件に一致する端末処理情報Ｃが見つかったか否かを判断し（ステップＳ４０２）、判断ステップＳ４０２で上記ステップＳ４０１の検索条件に一致する端末処理情報が見つからなければ、本端末は「休止通知」送信端末に依存する端末ではないので、稼動情報管理部２２は他端末ステータス情報２２２から「休止要求」送信端末に対応するエントリを探し出し、そのエントリのステータスを休止に変更し（ステップＳ４０３）、休止時刻を更新した後、処理を終える。
【００７１】
判断ステップＳ４０２で上記ステップＳ４０１の検索条件に一致する端末処理情報Ｃが見つかったら、稼動情報管理部２２は自端末ステータス情報２２１を参照して自端末のステータスを確認する（ステップＳ４０４）。稼動情報管理部２２は自端末のステータスが「起動中」、「アイドル」又は「休止途中」のいずれかであるか否かを判断（ステップＳ４０５）する。
【００７２】
判断ステップＳ４０５で自端末のステータスが「起動中」、「アイドル」又は「休止途中」のいずれかの場合、「ビジー」状態の処理はないことが保障されるので、稼動情報管理部２２はステップＳ４０３と同様の手順で他端末ステータス情報２２２を更新し（ステップＳ４０８）、「休止要求」送信端末に「ＯＫ」を返信する（ステップＳ４０９）。
【００７３】
判断ステップＳ４０５で自端末のステータスが「ビジー」の場合は、以下の処理に進む。なお、自端末のステータスが「休止」の場合、稼動情報管理部２２は通信処理を停止しているので、本判断ステップＳ４０５で自端末のステータスが「休止」となることはありえない。
【００７４】
続いて稼動情報管理部２２は、処理実行部２１の動作情報テーブル２１２を参照し、ステップＳ４０１で見つかった端末処理情報Ｃのうち処理のステータスが「ビジー」であるものを検索する（ステップＳ４０６）。稼動情報管理部２２は上記ステップＳ４０６の検索条件に一致する端末処理情報Ｃが見つかったか否かを判断する（ステップＳ４０７）。
【００７５】
判断ステップＳ４０７でもしビジーである処理が１つでも見つかったら、稼動情報管理部２２は「休止要求」送信端末に「ＮＧ」を返信し（ステップＳ４１０）、処理を終える。判断ステップＳ４０７でもしビジーである処理が全く見つからなかったら、稼動情報管理部２２はステップＳ４０３と同様の手順で他端末ステータス情報２２２を更新し（ステップＳ４０８）、「休止要求」送信端末に「ＯＫ」を返信し（ステップＳ４０９）、処理を終える。
なお、判断ステップＳ４０５で自端末のステータスが「休止途中」の場合、稼動情報管理部２２は図１４に示す休止処理と上記処理を並列的に実行することになる。
【００７６】
〔実行準備処理の手順〕
動作中の制御端末１，２，３，４の稼動情報管理部２２が、上位の制御端末５，６，７やクライアント端末ｔ１〜ｔｎから「処理要求」を受信すると、稼動情報管理部２２は処理実行部２１内の端末処理情報から、上記「処理要求」で実行指示された処理が依存する処理を実行する他端末（依存関係端末）すべてのアドレスを取得する。
【００７７】
そして、稼動情報管理部２２は他端末ステータス情報２２２を参照して上記依存関係端末のステータスを確認し、もしステータスが「休止」である依存関係端末が存在する場合、その端末に「起動要求」を送信することで必要な全ての制御端末を起動する。稼動情報管理部２２は「起動要求」を送信したすべての制御端末の起動が確認できたら、稼動情報管理部２２は制御を処理実行部２１に移し、実際にＲＦＩＤリーダ／ライタ１０−１〜１０−４の制御を開始する。
【００７８】
本実施の形態例では稼動情報管理部２２が「処理要求」を受け付けてから、制御を処理実行部２１に移すまでの処理を「実行準備処理」と呼ぶ。以下では、図１６に示した「実行準備処理」の詳細な処理を示すフローチャートを用いて、実行準備処理の手順を詳細に説明する。
【００７９】
稼動情報管理部２２が「処理要求」を受信すると、「処理要求」に記載された処理名を処理実行部２１の動作情報テーブル２１２から検索し、見つかったエントリのステータスを「ビジー」に変更する（ステップＳ５０１）。そして、稼動情報管理部２２は自端末ステータス情報２２１に記載された自端末のステータスを「ビジー」に変更する。もし、既に他の処理を実行中であれば、自端末のステータスは既に「ビジー」であるので、改めて自端末のステータスを変更することは行わない。
【００８０】
続いて稼動情報管理部２２は、「処理要求」に記載された処理名を持つ処理定義を含む端末処理情報Ｃを、処理実行部２１内の端末処理情報Ｃから検索し、見つかった端末処理情報Ｃの依存端末リストに記載されている全端末のアドレスを取得する。これら端末は、「処理要求」で実行指示された処理が依存する処理を実行する制御端末（依存関係端末）であるので、「処理要求」で実行指示された処理を開始する前に起動しておく必要がある。次に、稼動情報管理部２２は他端末ステータス情報２２２を参照し、取得した依存関係端末の各アドレスに対応する端末のステータスを確認する（ステップＳ５０２）。
【００８１】
稼動情報管理部２２は上記依存関係端末のステータスが「休止」の端末があるか否かを判断する（ステップＳ５０３）。ステップＳ５０３で上記依存関係端末のステータスが「休止」の端末でないとき、つまり、上記依存関係端末のステータスがすべて「稼動」であれば、稼動情報管理部２２は実行準備処理を完了して制御を処理実行部２１に移す。
【００８２】
ステップＳ５０３で上記依存関係端末のステータスが「休止」である依存関係端末があれば、稼動情報管理部２２は他端末ステータス情報２２２を参照し、休止時刻から一定時間（例：３０秒）経過した端末を選択する（ステップＳ５０４）。
上記ステップＳ５０３での上記依存関係端末のステータスが「休止」である条件に合致する端末が見つかったとき、稼動情報管理部２２は制御端末を選択する際に、休止時刻から一定時間経過していることを条件としている（ステップＳ５０４）。
【００８３】
稼動情報管理部２２はステップＳ５０４の選択条件で制御端末を選択できたか否かを判断する（ステップＳ５０５）。ステップＳ５０５でステップＳ５０４の選択条件で制御端末を選択できたとき、稼動情報管理部２２はステップＳ５０４で見つかった端末に起動パケットを送信する（ステップＳ５０６）。
【００８４】
ステップＳ５０４の選択条件で休止時刻から一定時間経過していることを条件としているのは、制御端末が休止状態への以降が完了していなければ制御端末は起動パケットを受け付けないので、制御端末から「休止要求」を受信した後、その制御端末が休止状態への以降を完了するまでの時間を考慮しているためである。
【００８５】
稼動情報管理部２２は全端末に起動パケットを送信したか否かを判断する（ステップＳ５０７）。ステップＳ５０７で全端末に起動パケットを送信していないときは、全端末に起動パケットを送信するまで、ステップＳ５０４〜ステップＳ５０７までの処理及び判断を繰り返す（ステップＳ５０７）。ここでは、ステータスが「休止」の依存関係端末で起動パケットを送信していない端末が残っていれば、Ｓ５０４に戻る。そして、ステータスが「休止」のすべての依存関係端末への起動パケットの送信を完了すれば、次の処理に進む。
【００８６】
ステップＳ５０５でステップＳ５０４の選択条件に合致する端末が見つからなかったら、稼動情報管理部２２は一定時間（例：１０秒）待機した後（ステップＳ５０８）、他端末ステータス情報２２２を参照してステータスが「休止」である依存関係端末が存在するかどうか確認する（ステップＳ５０９）。
【００８７】
ここでステップＳ５０９で改めて依存関係端末のステータスを確認する理由は、ステップＳ５０８で待機中に依存関係端末が起動してその端末から「起動通知」を受信した場合、稼動情報管理部２２はその端末のステータスを「稼動」となるように他端末ステータス情報２２２を更新するからである。またステップＳ５０８の待機処理は、必ず一定時間待機するのではなく、他端末から「起動通知」を受信したら待機を終了して次のステップに進むようにしてもよい。これによって無駄な待機時間を削減することができる。
【００８８】
ステップＳ５０９で依存関係端末のステータスがすべて「稼動」であれば、稼動情報管理部２２は実行準備処理を完了して制御を処理実行部２１に移す。
稼動情報管理部２２は上記依存関係端末のステータスが「休止」の端末があるか否かを判断する（ステップＳ５１０）。ステップＳ５１０で上記依存関係端末のステータスが「休止」の端末でないとき、つまり、上記依存関係端末のステータスがすべて「稼動」であれば、稼動情報管理部２２は実行準備処理を完了して制御を処理実行部２１に移す。
【００８９】
ステップＳ５１０で上記依存関係端末のステータスが「休止」である依存関係端末があればステップＳ５０４に戻る。
ステップＳ５０７で、ステータスが「休止」のすべての依存関係端末への起動パケット送信を確認できたら、稼動情報管理部２２は他端末ステータス情報２２２を参照してステータスが「休止」である依存関係端末が存在するかどうか確認する（ステップＳ５１１）。
【００９０】
稼動情報管理部２２は上記依存関係端末のステータスが「休止」の端末があるか否かを判断する（ステップＳ５１２）。ステップＳ５１２で上記依存関係端末のステータスが「休止」の端末でないとき、つまり、上記依存関係端末のステータスがすべて「稼動」であれば、稼動情報管理部２２は実行準備処理を完了して制御を処理実行部２１に移す。
【００９１】
ステップＳ５１２で依存関係端末のステータスが「休止」である依存関係端末があれば、稼動情報管理部２２は一定時間（例：１０秒）待機した後（ステップＳ５１３）、ステップＳ５１１に戻る。このステップＳ５１３でも待機中に他端末から「起動通知」を受信したら待機を終了して直ちにステップＳ５１１に戻るようにしてもよい。
【００９２】
［他の実施の形態例］
クライアント端末ｔ１〜ｔｎから制御端末１〜７へ送信する「処理要求」のパターンは、エリアＡを確認してからエリアＢを確認する、といった一定のパターンを有する場合が多い。例えば上記例を先の実施の形態例の方法で行うと、エリアＡ確認処理を実行するために稼動情報管理部２２はその処理が依存する処理を実行する制御端末（１，２）を起動した後にエリアＡ確認処理を行い、エリアＢ確認処理を実行するためにその処理が依存する処理を実行する制御端末（３，４）を起動することになる。
【００９３】
しかし、制御端末１〜７のアクセスパターンが前もって分かっていれば、制御端末５がエリアＡ確認を指示した「処理要求」を受けた時点で、続けてエリアＢへのアクセス要求があることが予測できるので、稼動情報管理部２２はエリアＡ確認処理の完了を待たずに予めエリアＢ確認処理を実行するために必要な制御端末（３，４，６）に起動パケットを送信しておくことが可能である。
【００９４】
本実施の形態例では、各制御端末１〜７上でクライアント端末ｔ１〜ｔｎから送信されてきた「処理要求」のログを記録し、構成管理サーバ８で上記ログを集計する。構成管理サーバ８で、処理要求送信端末（クライアント端末）と時刻をもとにパターン分析を行ない、ある処理を実行したときに続けて実行する可能性が高い処理を決定するための、関連処理テーブルを作成する。
【００９５】
構成管理サーバ８は、上記関連処理テーブルと端末処理情報に基づいて、ある処理の実行後に続けて実行する可能性が高い処理の実行に必要な端末群を決定するために、関連処理解決テーブルを作成し、各制御端末に配布する。
各制御端末１〜７では、ある「処理要求」を受信したときに、上記関連処理解決テーブルを参照し、上記「処理要求」の実行後に続けて実行する可能性が高い処理の実行に必要な端末群を決定し、上記端末群に起動パケットを送信する。
【００９６】
以下、図面を用いて詳細に説明するが、本実施の形態例の多くの部分は先の実施の形態例と同じであるので、相違点を中心に説明する。図１８は他の実施の形態例における制御端末のソフトウェア構成を示す。先の実施の形態例と比較して、「処理要求」の受信ログを記録するログ収集部２４が追加されている。
【００９７】
図１９は他の実施の形態例における構成管理サーバのソフトウェア構成を示す。先の実施の形態例と比較して、ログ解析を行うログ解析部１３が追加されており、ログ解析部１３は動作ログテーブル１３１と関連処理テーブル１３２と関連処理解決テーブル１３３から構成される。動作ログテーブル１３１は図２１に示すように、要求端末アドレス（「処理要求」送信端末のアドレス）２１０１、処理名２１０２、処理端末アドレス（上記処理を実行する制御端末のアドレス）２１０３、時刻２１０４の４要素から構成されており、各制御端末のログ収集部２４から集計したログを記録する。
【００９８】
関連処理テーブル１３２は図２２に示すように、要求端末アドレス２２０１、処理名２２０２、処理端末アドレス２２０３の３要素から構成されており、実行される頻度が高い一連の処理のパターンを記録する。例えば図２２では、要求端末アドレス２２０１の（192.168.0.11）から処理端末アドレス２２０３の（192.168.0.3）に対して「棚Ａ２確認」を指示する「処理要求」が送信された後で、要求端末アドレス２２０１の（192.168.0.11）から処理端末アドレス２２０３の（192.168.0.5）に対して「棚Ｂ２確認」を指示する「処理要求」が送信される、パターンが記録されている。
【００９９】
関連処理解決テーブル１３３は図２３に示すように、要求端末アドレス２３０１、処理名２３０２、処理端末アドレス２３０３、依存端末アドレス２３０４の４要素から構成されており、ある処理の実行後に実行される可能性がある処理の実行に必要な制御端末のアドレスを依存端末アドレス２３０４に記録する。
【０１００】
例えば図２３の例では、要求端末アドレス２３０１の（192.168.0.11）を持つ端末から「棚Ａ２確認処理」を指示する「処理要求」が処理端末アドレス２３０３の（192.168.0.3）を持つ制御端末に送信されたら、上記処理の実行後に実行される可能性がある処理（「棚Ｂ２確認」）の実行に必要な制御端末の依存端末アドレス２３０４は（192.168.0.5）であることを示している。
【０１０１】
要求端末アドレス２３０１、処理名２３０２、処理端末アドレス２３０３には値を１つずつ設定するが、依存端末アドレス２３０４には複数個（２つ以上）のアドレスを設定する場合がある。例えば、関連処理テーブル１３２に３つ以上の処理が記載される場合や、ある処理の実行に必要な端末が複数存在する場合には依存端末アドレス２３０４に２つ以上のアドレスを設定することになる。
【０１０２】
図２０は他の実施の形態例における制御端末の処理実行部２１のソフトウェア構成を示す。処理実行部２１は関連処理解決テーブル２１３を持つが、このテーブルは構成管理サーバ８が保持する関連処理解決テーブル１３３とほぼ同様の内容である。但し、各制御端末は処理端末アドレスが自端末のアドレスと一致しないエントリは、保持しない。
以下では、本実施の形態例の動作を詳細に説明する。
【０１０３】
〔動作ログの収集〕
制御端末のログ収集部２４は、他端末から「処理要求」を受信する毎に、「処理要求」送信端末アドレス２１０１、処理名２１０２、時刻２１０４の３要素を記録する。ログはメンテナンス時に構成管理サーバ８に送信される。
【０１０４】
送信管理サーバ８のログ解析部１３は、制御端末から受信したログのエントリを動作ログテーブル１３１に記録する。このとき上記「処理要求」送信端末アドレス２１０１、処理名２１０２、時刻２１０４をそれぞれ、動作ログテーブル１３１の要求端末アドレス２１０１、処理名２１０２、時刻２１０４に格納する。動作ログテーブル１３１の処理端末アドレス２１０３は、ログを送信してきた制御端末のアドレスとする。
【０１０５】
また、ログ解析部１３は、構成管理サーバ８が保持する端末処理情報を参照し、要求端末アドレス２１０１がシステムを構成する制御端末のアドレスと合致するエントリは動作ログテーブル１３１に記録しない。つまり、「処理要求」がクライアント端末から送信されたログのみ記録する。
【０１０６】
〔ログの解析〕
ログ収集処理が完了したら、ログ解析部１３は動作ログテーブル１３から、要求端末アドレス２１０１が合致し、時刻２１０４が近い（例：３０秒以内）エントリを選び出し、それらを時系列に並べたパターン情報を作成する。選び出したパターン情報からは時刻２１０４を削除する。例えば動作ログテーブル１３が図２１のようになっている場合、エントリＬ１０１とＬ１０２は同一の要求端末アドレス２１０１を持ち時刻２１０４が近いので、以下のパターン情報を作成する。
【０１０７】
すなわち、エントリＬ１０１（要求端末アドレス２１０１、処理名２１０２、処理端末アドレス２１０３）として、（192.168.0.11、棚Ａ２確認、192.168.0.3）が作成され、Ｌ１０２として、（192.168.0.11，棚Ｂ２確認、192.168.0.5）が作成される。Ｌ１０３も同様である。
ログ解析部１３は上記のように作成したパターンのうち、頻度が高いものを関連処理テーブル１３２に記録する。図２２では関連処理テーブル１３２のテーブル数は１つだけであるが、実際にはパターンの数だけテーブルが作成される。
【０１０８】
続いてログ解析部１３は関連処理テーブル１３２から関連処理解決テーブル１３３を作成する。まず、関連処理テーブル１３２から１つのテーブルを選択し、そのテーブルに記録されている各エントリから、関連処理解決テーブル１３３に記録するエントリを１つずつ作成する。但し、関連処理テーブル１３２の最後のエントリからは、関連処理解決テーブル１３３のエントリは作成されない。
【０１０９】
例えば図２２の例では、エントリＬ１１１を最初に選択する。以下、ここで選択したエントリをベースエントリと呼ぶ。ログ解析部１３はベースエントリの要求端末アドレス２２０１、処理名２２０２、処理端末アドレス２２０３を関連処理解決テーブル１３３の新しいエントリとして複製する。
ログ解析部１３はベースエントリを選択したテーブルと同じテーブルで、ベースエントリの下位に記録されているエントリ（以下、サブエントリと呼ぶ）を１つ選択する。例えば図２２の例ではサブエントリはＬ１１２であるので、Ｌ１１２をサブエントリとして選択する。
【０１１０】
ログ解析部１３は、構成管理サーバ８に格納されている端末処理情報Ｃから、動作定義に選択したサブエントリの処理名および処理端末アドレスが記載されているものを検索する。上記例では、制御端末４の端末処理情報Ｃが条件に合致する。ログ解析部１３は、条件に合致した端末処理情報Ｃの依存処理リストに記載されている端末アドレスを取得し、上で作成した関連処理解決テーブル１３３の依存端末アドレス２３０４に追加する。
【０１１１】
また、ログ解析部１３はサブエントリの処理端末アドレス２２０３も、上で作成した関連処理解決テーブル１３３の依存端末アドレス２３０４に追加する。上の例では、制御端末４の端末処理情報Ｃの依存処理リストは空であるので、制御端末４のアドレス（192.168.0.5）のみを関連処理解決テーブル１３３の依存端末アドレス２３０４に追加する。
【０１１２】
上の例ではサブエントリは１つだけであるが、関連処理テーブル１３２に記録されているエントリ数が３個以上の場合には、サブエントリが２つ以上になる場合がある。サブエントリが複数の場合は、サブエントリ毎に上で説明した手順で、関連処理解決テーブル１３３の依存端末アドレス２３０４を更新していく。
【０１１３】
このようにして、関連処理テーブル１３２のエントリ１つから、関連処理解決テーブル１３３のエントリが１つ作成される。ログ解析部１３は上記処理を関連処理テーブル１３２の全てのテーブルに記録されている全てのエントリ（但し最後のエントリは除く）に対して、上記処理と同様の手順で、関連処理解決テーブル１３３のエントリを作成する。
【０１１４】
〔制御端末の処理〕
構成管理サーバ８のログ解析部８がログの解析処理を終了したら、構成管理サーバ８は関連処理解決テーブル１３３を各制御端末１〜７に配布する。このとき、制御端末１〜７には、関連処理解決テーブル１３３の処理端末アドレス２３０３に記載されたアドレスと配布しようとする制御端末１〜７のアドレスが一致するエントリのみ配布する。
【０１１５】
例えば図２３の例では、処理端末アドレス２３０３が（192.168.0.3）を持つ制御端末２にだけ、以下のエントリを配布する。
すなわち、関連処理解決テーブル１３３を構成する「要求端末アドレス２３０１、処理名２３０２、処理端末アドレス２３０３、依存端末アドレス２３０４」として、「192.168.0.11、棚Ａ２確認、192.168.0.3、192.168.0.5」が配布される。この関連処理解決テーブルが配布された制御端末２は、その処理実行部２１の関連処理解決テーブル２１３欄に上記配布された情報を記録する。
【０１１６】
制御端末２の稼動情報管理部２２は、他端末から「処理要求」を受信すると、先の実施の形態例で説明した実行準備処理を行う前に、以下で説明する処理を行う。稼動情報管理部２２は関連処理解決テーブル２１３を参照し、関連処理解決テーブル２１３の要求端末アドレスが「処理要求」の送信端末アドレスに合致し、かつ関連処理解決テーブル２１３の「処理名」が「処理要求」に指示されている処理名に合致するエントリを検索する。
【０１１７】
図２３の例では、制御端末２が要求端末アドレス２３０１の（192.168.0.11）を持つクライアント端末から処理名「棚Ａ２」確認を指示する「処理要求」を受け付けた場合、制御端末２の関連処理解決テーブル２１３から、以下のエントリが見つかる。
すなわち、「要求端末アドレス２３０１、処理名２３０２、処理端末アドレス２３０３、依存端末アドレス２３０４」として、「192.168.0.11、棚Ａ２確認、192.168.0.3、192.168.0.5」が見つかることになる。
【０１１８】
このエントリが見つかったら、稼動情報管理部２２は他端末ステータス情報２２２を参照し、上記エントリの依存端末アドレス２３０４に記載されている端末のステータスを確認する。稼動情報管理部２２はステータスが「休止」となっているすべての制御端末に起動パケットを送信し、ステータスが「稼動」となっているすべての端末に「実行準備」メッセージを送信する。
【０１１９】
「実行準備」メッセージを受けた制御端末は、端末内で実行中の処理の有無にかかわらす、一定時間（例：３０秒）だけ自端末ステータス情報２２１に設定されている自端末のステータスをビジーに設定する。これによって「実行準備」メッセージを受信した端末が、一定時間休止処理を行うことが防止できる。続いて、稼動情報管理部２２は先の実施の形態例で説明した実行準備処理を行う。
【０１２０】
本実施の形態例の変形例として、上記「実行準備」メッセージを関連処理テーブルに記載されたアドレスを持つ端末だけに送信する方法を用いてもよい。つまり、制御端末は休止状態に遷移するときに上位の制御端末に「休止要求」を送信するので、上位の制御端末が「ビジー状態」であれば下位の制御端末は「休止要求」を送信しても「ＮＧ」返信が返されるので、休止状態に遷移することができない。
【０１２１】
従って、ある処理を実行したときに続けて実行する可能性が高い処理を行う端末にのみ「実行準備」メッセージを送信し、その処理が依存する制御端末には「実行準備」メッセージは送信しない方式でもよく、この方式のほうが通信メッセージを削減できる。
これを行うためには、関連処理解決テーブル１３３、２１３の依存端末アドレスを以下の構造を持ったリストとして管理する。
（第１の依存処理実行端末アドレス、第１の依存処理が依存する処理を実行するすべての端末のアドレス（複数））
（第２の依存処理実行端末アドレス、第２の依存処理が依存する処理を実行するすべての端末のアドレス（複数））
【０１２２】
そして、構成管理サーバ８のログ解析部１３が、関連処理テーブル１３２から関連処理解決テーブル１３３を作成する処理を以下の手順で実行する。
ログ解析部１３は関連処理テーブル１３２からベースエントリを１つ選択し、上記選択したベースエントリの要求端末アドレス、処理名、処理端末アドレスを関連処理解決テーブル１３３の新しいエントリとして複製する。ただしテーブルの最後のエントリは、ベースエントリとして選択しない。
【０１２３】
ログ解析部１３は上記ベースエントリが格納されているテーブルで、ベースエントリの下位に記録されているエントリ（サブエントリ）を１つ選択し、そのエントリの処理端末アドレスを、上記依存端末アドレス構造の１つめのフィールド（第１の依存処理実行端末アドレス）に格納する。
【０１２４】
ログ解析部１３は上で説明した手順と同様の手順で、構成管理サーバ８に格納されている端末処理情報を利用して、サブエントリの処理に依存する処理を実行する制御端末のアドレスを決定し、上記依存端末アドレス構造の２つめのフィールド（第２の依存処理が依存する処理を実行するすべての端末のアドレス）に格納する。このようにして１個のサブエントリから、依存端末アドレスの構造を１つのエントリを作成する。すべてのサブエントリに対して同様の処理を行うと、依存端末アドレスの構造が完成する。
【０１２５】
このようにして関連処理テーブル１３２から選択した１つのベースエントリから、関連処理解決テーブル１３３のエントリが１つ作成される。
制御端末の稼動情報管理部２２は、クライアント端末から「処理要求」を受けると、関連処理解決テーブル２１３を参照し、関連処理解決テーブル２１３の要求端末アドレスが「処理要求」の送信端末アドレスに合致し、かつ関連処理解決テーブル２１３の「処理名」が「処理要求」に指示されている処理名に合致するエントリを検索する。
【０１２６】
エントリが見つかったら、稼動情報管理部２２は他端末ステータス情報２２２を参照し、上記エントリの依存端末アドレスに記載されている端末のステータスを確認する。ステータスが「休止」となっているすべての制御端末に起動パケットを送信する。ステータスが「稼動」となっている端末については、関連処理解決テーブル２１３の依存端末アドレスの１つ目のフィールド（第１の依存処理実行端末アドレス）に格納されている制御端末にのみ「実行準備」メッセージを送信する。
【産業上の利用可能性】
【０１２７】
本発明は分散システム一般に適用することができるが、特にＲＦＩＤシステムのように制御端末の数が多く、制御端末の節電効果が期待できる分策システムに有効である。
【図面の簡単な説明】
【０１２８】
【図１】システムの構成図である。
【図２】構成管理サーバの構成図である。
【図３】制御端末の構成図である。
【図４】制御端末が実行する処理の階層構成図である。
【図５】端末処理情報の一例を示す図である。
【図６】他の端末処理情報の一例を示す図である。
【図７】他の端末処理情報の一例を示す図である。
【図８】端末処理情報の依存関係解析処理の手順を示したフローチャートである。
【図９】端末処理情報の他の依存関係解析処理の手順を示したフローチャートである。
【図１０】処理実行部の内部構成図である。
【図１１】稼動情報管理部の内部構成図である。
【図１２】自端末ステータスの状態遷移図である。
【図１３】起動処理の手順を示したフローチャートである。
【図１４】休止処理の手順を示したフローチャートである。
【図１５】「休止要求」を受信した制御端末の処理を示したフローチャートである。
【図１６】実行準備処理の手順を示したフローチャートである。
【図１７】受信したメッセージに対して制御端末が行う処理を、自端末のステータス毎に纏めたマトリックス表である。
【図１８】他の制御端末のソフトウェア構成図である。
【図１９】他の構成管理サーバのソフトウェア構成図である。
【図２０】他の処理実行部の内部構成図である。
【図２１】動作ログテーブルである。
【図２２】関連処理テーブルである。
【図２３】関連処理解決テーブルである。
【符号の説明】
【０１２９】
１〜７…制御端末、８…構成管理サーバ、Ｃ，Ｃ５，Ｃ７，Ｃ１…端末構成情報、２１…処理実行部、２２…稼動情報管理部、２３…デバイス制御部、Ｃ１１，Ｃ５１、Ｃ７１  …依存処理リスト、Ｃ１２，Ｃ５２，Ｃ７２…逆依存処理リスト、Ｃ１３，Ｃ５３，Ｃ７３…処理定義、１３１…動作ログテーブル、１３２…関連処理テーブル、１３３…関連処理解決テーブル、２１２…動作情報テーブル、２１３…関連処理解決テーブル、２２１…自端末ステータス情報、２２２…他端末ステータス情報
【図１】
2007287101.tif 000003
【図２】
2007287101.tif 000004
【図３】
2007287101.tif 000005
【図４】
2007287101.tif 000006
【図５】
2007287101.tif 000007
【図６】
2007287101.tif 000008
【図７】
2007287101.tif 000009
【図８】
2007287101.tif 000010
【図９】
2007287101.tif 000011
【図１０】
2007287101.tif 000012
【図１１】
2007287101.tif 000013
【図１２】
2007287101.tif 000014
【図１３】
2007287101.tif 000015
【図１４】
2007287101.tif 000016
【図１５】
2007287101.tif 000017
【図１６】
2007287101.tif 000018
【図１７】
2007287101.tif 000019
【図１８】
2007287101.tif 000020
【図１９】
2007287101.tif 000021
【図２０】
2007287101.tif 000022
【図２１】
2007287101.tif 000023
【図２２】
2007287101.tif 000024
【図２３】
2007287101.tif 000025