JP2006260549A - モバイルエージェント移動の高速化方法、モバイルエージェントの移動の高速化システム及び移動高速化モバイルエージェントによる事故区間分離処理方法 - Google Patents

Abstract

【課題】需要地系統の監視制御にて求められる高速な処理を実現するべく、モバイルエージェントの移動及び処理速度を高速化する。
【解決手段】スレッドを有する複数の緊急処理用待機エージェントを受信側装置３内に予め待機させておき、緊急処理モバイルエージェントが緊急処理用受信部３ａへと移動し、復元したら緊急処理用待機エージェントの中の一つを抽出し、復元後の緊急処理モバイルエージェントの処理内容オブジェクトを抽出された緊急処理用被抽出エージェントに関連づけ、その後、この緊急処理用被抽出エージェントに対して処理再開指令を出し、この処理内容オブジェクトの実行終了後、処理内容オブジェクトを廃棄するが当該緊急処理用被抽出エージェントが有しているスレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用する。
【選択図】図３

Description

本発明は、モバイルエージェント移動の高速化方法、モバイルエージェントの移動の高速化システム及び移動高速化モバイルエージェントによる事故区間分離処理方法に関する。さらに詳述すると、本発明は、例えば需要地系統の監視制御にて求められる高速な処理を実現するための情報通信処理手法の改良に関する。

数多くの分散型電源が連系することを可能とし、かつ、電気の品質を維持できるような次世代の配電系統として需要地系統の開発が取り組まれている。ここでいう需要地系統とは、電力需要地に近い場所で発電を実施し電力を供給するためのシステムのことで、この需要地系統を監視制御するにあたっては、少ない計算資源で多様な処理の実現を可能とするためにモバイルエージェントをベースとしたシステムの適用の検討がなされている。

ところが、モバイルエージェントはプログラムとデータが一体となって移動するものであるため、使い方によっては通常の分散システムよりも処理時間が長くなる場合がある。また、需要地系統の監視制御システムにおいては多種多様な機能を実現することから、それぞれの機能が要求する通信及び処理の品質（ＱｏＳ：Quality of Service）を実現する必要がある。例えばこれまでに、多様な機能をその要求に応じて三種類のエージェントにて実現し、異なるＱｏＳを実現するという方法が提案されている（例えば非特許文献１参照）。尚、本明細書中において「移動」とは、エージェントが送信側装置において移動を命令した直後から受信側装置においてエージェントが有する具体的な処理を開始する直前までを指す。

また、具体的には、従来、需要地系統の監視制御向けに開発が進められているモバイルエージェント（Mobile Agents For Demand Area Power System、略してＭＡＦＤＡＰＳという）におけるＱｏＳ制御においては、移動後復元されたエージェントが受信側装置１０１において起動されることによって処理を開始するようになっており、この際、エージェントのためのスレッドを実現するThreadオブジェクトの生成がＪａｖａ（登録商標）仮想機械において自動的に行われるようになっている（図３２参照）。

大谷哲夫、「次世代配電系統監視制御用モバイルエージェントの構成とＱｏＳ制御方式」、電気学会電子・情報・システム部門誌、2004年、Vol.124-C、No.3、pp.921-928

しかしながら、最も高いＱｏＳが求められるモバイルエージェントは地絡事故時の区間分離などに用いられることから現状よりもさらに高速な処理の実現が求められており、この高速処理の実現が課題となっている。

すなわち、一般に、分散システムのサーバにおいては、複数の処理を並行して行うためにソフトウェアの実行単位であるスレッドを複数設定することになる。ところが、スレッドの生成及び消去には時間的なコストがかかるため、例えばＷｅｂサーバのようにどのタイミングでどのような要求が来るか予測がつきにくいシステムにおいては、処理が終了したスレッドを消去せずに保持しておき、次の処理要求が発生した段階で再利用する「スレッドプーリング」によって処理時間を短縮する方法が採用される場合がある。しかしながら、Ｗｅｂサーバであればプログラムはサーバ自体に予めインストールされているので、元々サーバにインストールされたプログラムをスレッドプーリングに用いれば良いのに対し、モバイルエージェントシステムはプログラムとデータが一体となって移動するものであるので、受信側装置はプログラムを有しておらず、Ｗｅｂサーバにスレッドプーリングを適用するのと同様にスレッドプーリングを適用することはできないという問題がある。

また、モバイルエージェント技術においても、処理の途中に移動し、中断した状態から移動後に再開することが可能なストロングマイグレーション(strong migration)と呼ばれる手法においてはスレッドの扱い方に関する研究が進められている。しかし、移動後に改めて処理を開始するというもう一方のウィークマイグレーション(weak migration)と呼ばれる手法は、例えばAgletsをはじめとして様々なモバイルエージェントシステムにおいて採用されてはいるが、一般にモバイルエージェント技術では移動経路の最適化に研究の重点が置かれており、モバイルエージェントの１回の移動時間をミリ秒単位で削減し処理の高速化を図るようなシステム設計は困難である。このため、スレッドプーリングを用いた処理の高速化の試みは見当たらないというのが現状であり、この手法の分野における高速処理の実現が望まれている。

そこで、本発明は、需要地系統の監視制御にて求められる高速な処理を実現するべく、モバイルエージェントの移動及び処理速度を高速化することが可能なモバイルエージェント移動の高速化方法、モバイルエージェントの移動の高速化システム及び移動高速化モバイルエージェントによる事故区間分離処理方法を提供することを目的とする。

かかる目的を達成するため、請求項１に記載のモバイルエージェント移動の高速化方法は、送信側装置と受信側装置が通信網を介して相互に接続されたモバイルエージェントシステムにおけるモバイルエージェントの移動方法において、スレッドを有し、かつ処理内容オブジェクトを有しない待機エージェントを受信側装置に予め生成して待機させておき、受信側装置は、送信側装置からモバイルエージェントを受信したときに、待機エージェントとモバイルエージェントが有する処理内容オブジェクトを関連づけ、当該処理内容オブジェクトを関連づけられた待機エージェントを起動するようにしている。

また、請求項６に記載のモバイルエージェント移動の高速化システムは、送信側装置と受信側装置が通信網を介して相互に接続されたモバイルエージェントシステムにおいて、受信側装置は、待機エージェント設定部、エージェント復元部、エージェント抽出部、エージェント関連づけ部、実行開始部とを有し、待機エージェント設定部は、スレッドを有し、かつ処理内容オブジェクトを有しない待機エージェントを生成して主記憶装置上に待機させ、エージェント復元部は、送信側装置から受信したモバイルエージェントを復元し、エージェント抽出部は、待機中の待機エージェントを抽出し、エージェント関連づけ部は、待機エージェントと復元されたモバイルエージェントが有する処理内容オブジェクトを関連づけ、実行開始部は、処理内容オブジェクトを関連づけられた待機エージェントを起動するものである。

したがって、具体的な処理内容オブジェクトを有しないがスレッドを有する待機エージェントを予めインスタンス化して待機させておき、移動してきたモバイルエージェントが有する具体的な処理内容オブジェクトを、待機エージェントに関連づけて実行している。したがって、エージェントごとにスレッドを作成する必要がないため、処理の高速化を図ることができる。

また、請求項２に記載の発明は、請求項１に記載のモバイルエージェント移動の高速化方法において、更に待機エージェントを実行後、当該待機エージェントに関連づけられた処理内容オブジェクトを廃棄し、待機エージェントを生成時の状態に戻すようにしている。

また、請求項７に記載の発明は、請求項６に記載のモバイルエージェント移動の高速化システムにおいて、更に受信側装置は、処理終了通知部、スレッド再利用部とを有し、処理終了通知部は、待機エージェントを実行後、当該待機エージェントに関連づけられた処理内容オブジェクトを廃棄し、スレッド再利用部は、待機エージェントを生成時の状態に戻すものである。

したがって、待機エージェントは、具体的な処理内容の実行終了後、処理内容オブジェクトを廃棄し、具体的な処理内容オブジェクトを有しないがスレッドを有する生成時の状態に戻り、再び待機状態となる。よって、次のエージェントの移動時にも同様に処理を行うことが可能となる、即ち待機エージェントが有するスレッドは繰り返し利用される。

また、請求項３に記載の発明は、請求項１または２のいずれかに記載のモバイルエージェント移動の高速化方法において、待機エージェントを複数生成し、受信側装置に待機させておくようにしている。したがって、複数の待機エージェントを待機させることにより、モバイルエージェントが複数移動した場合においても、エージェントごとにスレッドを作成する必要がないため、処理の高速化を図ることができる。

また、請求項４に記載の発明は、緊急処理モバイルエージェントを受信側装置の緊急処理用受信部にて受信後、当該緊急処理モバイルエージェントの処理内容オブジェクトに基づき緊急処理を進める際、この緊急処理モバイルエージェントの移動速度を高速化することによって緊急処理に要する時間を短縮するためのモバイルエージェント移動の高速化方法において、スレッドを有する複数の緊急処理用待機エージェントを受信側装置内に予め待機させておき、緊急処理モバイルエージェントが緊急処理用受信部へと移動したらこの緊急処理モバイルエージェントを復元させ、緊急処理用受信部によって複数の緊急処理用待機エージェントの中の一つを抽出し、さらに緊急処理用受信部によって復元後の緊急処理モバイルエージェントの処理内容オブジェクトを抽出された緊急処理用被抽出エージェントに関連づけ、その後、緊急処理用受信部からこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始し、この処理内容オブジェクトの実行終了後、緊急処理用被抽出エージェントに関連づけられた処理内容オブジェクトを廃棄させてから緊急処理用受信部に対して処理終了を通知させ、当該緊急処理用被抽出エージェントが有しているスレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用することを特徴とするものである。

このモバイルエージェント移動の高速化方法においては、処理が終了したスレッド（ソフトウェアの実行単位）を消去せずに保持しておき、次の処理要求が発生した段階で再利用するというスレッドプーリングを利用しており、迅速処理エージェント及び平常処理エージェントに対しては従来と同様に移動したエージェントごとに受信側装置にてスレッドを生成することによって対応・処理する一方で、緊急処理エージェントに対してはこのスレッドプーリングを利用した高速処理を実行する。すなわち、各種スレッドを有する複数の緊急処理用待機エージェントを予め待機させておき、緊急処理モバイルエージェントが移動してきたならば、復元させた後、緊急処理用待機エージェントの中から一つを抽出し、抽出したエージェントに復元後のモバイルエージェントの処理内容オブジェクトを関連づける。その後、関連づけられた処理内容オブジェクトに対して処理再開指令を出して当該処理を実行する。実行を終えた緊急処理用被抽出エージェントは、処理内容オブジェクトは廃棄するが、もともと保有していたスレッドは廃棄することなく保持したままで元の待機状態に戻る。したがって、緊急処理モバイルエージェントが何時移動してくるかにかかわらず、複数の緊急処理用待機エージェントが常にスタンバイしていることにより複数のスレッドが準備されているということができる。従来のモバイルエージェントシステムやその処理手法であれば緊急処理エージェントごとにスレッドを作成しなければならず、ＣＰＵで計算を行ったり、メモリ空間を使ったりして処理に時間を要していたが、スレッドプーリングによってスレッド作成を省略できる本発明の手法によれば処理に要する時間を短縮することが可能となる。また、例えば従来のエージェントシステムならばモバイルエージェントが移動先にてインスタンス生成、即ち、Ｊａｖａ（登録商標）仮想機械（Ｊａｖａ（登録商標）ＶＭ）上に呼び出されてインスタンス化される必要があったが、本発明ではスレッドに関して予めインスタンスが生成されている点で従来システムないし処理方法とは異なる。

また、請求項５に記載の発明は、電力需要地に近い場所で発電を実施し電力を供給するための需要地系統にて、事故情報を通知する緊急処理モバイルエージェントを当該事故区間を担当する運用管理サブシステムにて受信後、当該緊急処理モバイルエージェントの処理内容オブジェクトに基づき緊急処理を進める際、この緊急処理モバイルエージェントの移動速度を高速化することによって緊急処理に要する時間を短縮する移動高速化モバイルエージェントによる事故区間分離処理方法において、スレッドを有する複数の緊急処理用待機エージェントを運用管理サブシステム及びこれに隣接する運用管理サブシステム内に予め待機させておき、緊急処理モバイルエージェントが運用管理サブシステムへと移動したらこの緊急処理モバイルエージェントを復元させ、運用管理サブシステムによって複数の緊急処理用待機エージェントの中の一つを抽出し、さらに運用管理サブシステムによって復元後の緊急処理モバイルエージェントの処理内容オブジェクトを抽出された緊急処理用被抽出エージェントに関連づけ、その後、運用管理サブシステムからこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始し、当該事故が発生した区間の運用管理サブシステムに集結した二つ以上の緊急処理用被抽出モバイルエージェントあるいはそれに関連づけられた処理内容オブジェクトの間で情報交換を行うことによって事故区間を判定し、事故区間を当該需要地系統から分離し、この処理内容オブジェクトの実行終了後、緊急処理用被抽出エージェントに関連づけられた処理内容オブジェクトを廃棄させてから運用管理サブシステムに対して処理終了を通知させ、当該緊急処理用被抽出エージェントが有しているスレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用することを特徴とするものである。

以上説明したように、本発明にかかるモバイルエージェント移動の高速化方法及びモバイルエージェント移動の高速化システムによれば、スレッドをインスタンス化した状態で待機させておくことにより、エージェントごとにスレッドを作成する必要がないため、スレッドの生成及び消去にかかる時間的なコストを削減することができ、モバイルエージェントの高速処理ひいては高速移動が可能となる。

更に、請求項２に記載のモバイルエージェント移動の高速化方法及び請求項７に記載のモバイルエージェント移動の高速化システムによれば、待機エージェントが有するスレッドは再利用することができ、スレッドの生成及び消去にかかる時間的なコストを削減することができる。したがって、モバイルエージェントの高速処理ひいては高速移動が可能となる。

更に、請求項３に記載のモバイルエージェント移動の高速化方法よれば、モバイルエージェントが複数移動した場合においても、エージェントごとにスレッドを作成する必要がないため、スレッドの生成及び消去にかかる時間的なコストを削減することができ、モバイルエージェントの高速処理ひいては高速移動が可能となる。

また、請求項４に記載のモバイルエージェントの移動の高速化方法によると、ウィークマイグレーションと呼ばれる手法においてスレッドプーリングを用いた高速化が実現し、これによってスレッドの生成及び消去にかかる時間的なコストを削減することができるためモバイルエージェントの高速処理ひいては高速移動が可能となる。

また、請求項５に記載の移動高速化モバイルエージェントによる事故区間分離処理方法によれば事故区間を迅速に分離するという処理が可能となる。例えば、需要地系統における事故（特に地絡事故）が起こった場合、事故区間を当該系統から１秒以内に分離することが求められているために情報通信処理に割り当てられる時間は数百ミリ秒（例えば３００ミリ秒）といった程度に過ぎないが、スレッドプーリングの技術を応用した本発明によれば短時間のうちに処理することが可能となる。したがって、従来の事故区間分離処理手法よりも短時間で事故区間を判定し、当該判定した事故区間を需要地系統から迅速に分離することができる。

また、この事故区間分離処理方法においては、緊急処理エージェントに関しては上述したように短時間で処理するが、迅速処理エージェント及び平常処理エージェントに対しては従来と同様に移動したエージェントごとに受信側装置にてスレッドを生成することによって対応・処理する。こうした場合、ハードウェアのメモリ空間使用量はできるだけ少なく抑えて省資源化を図りつつ、緊急処理は短時間で行うことにより需要地系統の健全性を保つことが可能になるという点で有益である。特に、分散システムが構築されていくと系統が複雑になり尚かつ多様性を帯びることとなるが、本処理方法によれば各種系統においてリアルタイムに対応することが可能であり、省資源化と健全性維持という両課題を両立することができるようになる。

以下、本発明の構成を図面に示す実施の形態に基づいて詳細に説明する。

図１〜図１４に本発明の一実施形態を示す。本発明にかかるモバイルエージェント移動の高速化方法は、送信側装置１と受信側装置３が通信網２を介して相互に接続されたモバイルエージェントシステムにおけるモバイルエージェントの移動方法において、スレッドを有し、かつ処理内容オブジェクトを有しない待機エージェントを受信側装置に予め生成して待機させておき、受信側装置は、送信側装置からモバイルエージェントを受信したときに、待機エージェントとモバイルエージェントが有する処理内容オブジェクトを関連づけ、当該処理内容オブジェクトを関連づけられた待機エージェントを起動するようにしている。即ち、アプリケーションが有する処理はエージェント本体とは異なるオブジェクトとして記述し、モバイルエージェントが受信側装置３に移動した後、待機中の待機エージェントにその処理内容を関連づけ、待機中であったエージェントを起動することにより、見かけ上はモバイルエージェントが、移動後そのまま処理を開始するように動作するものである。尚、待機エージェントは一つであっても良いが、複数の処理内容を連続して実行することができるので、予め複数待機させておくことが好ましい。

以下、本発明の実施形態として、需要地系統向けモバイルエージェントシステムに適用した場合の概要と、スレッドプーリングの実現方法について説明する。以下、待機エージェントのうち、緊急処理用受信部３ａによって抽出される前の待機中のものを待機中のエージェントといい、抽出され実行状態のものを被抽出エージェントという。

まず、本実施形態におけるモバイルエージェントシステムの概要についてであるが、ここでは、需要地系統の監視制御向けに開発が進められているモバイルエージェント（ＭＡＦＤＡＰＳ）におけるＱｏＳ制御の概要を述べた上で、ＭＡＦＤＡＰＳに対するスレッドプーリングの組み込みの内容について示す。尚、本発明のモバイルエージェント移動の高速化方法はＭＡＦＤＡＰＳに限らず、他のモバイルエージェントシステムに適用することが可能であることは勿論である。

本実施形態において、モバイルエージェント移動の高速化方法は、緊急処理モバイルエージェント（以下に示す実施形態においては緊急処理エージェントとも呼ぶことがある）を受信側装置３の緊急処理用受信部（図中では「受信部（緊急処理用）」と表示している）３ａにて受信後、当該緊急処理モバイルエージェントの処理内容オブジェクトに基づき緊急処理を進める際、この緊急処理モバイルエージェントの移動速度を高速化することによって緊急処理に要する時間を短縮するための手法であり、本実施形態では、スレッドを有する複数の緊急処理用待機エージェントを受信側装置３内に予め待機させておき、緊急処理モバイルエージェントが緊急処理用受信部３ａへと移動したらこの緊急処理モバイルエージェントを復元させ、緊急処理用受信部３ａによって複数の緊急処理用待機エージェントの中の一つを抽出し、さらに緊急処理用受信部３ａによって復元後の緊急処理モバイルエージェントの処理内容オブジェクトを抽出された緊急処理用被抽出エージェントに関連づけ、その後、緊急処理用受信部３ａからこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始し、この処理内容オブジェクトの実行終了後、緊急処理用被抽出エージェントに関連づけられた処理内容オブジェクトを廃棄させてから緊急処理用受信部３ａに対して処理終了を通知させ、当該緊急処理用被抽出エージェントが有しているスレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用することとしている。

ＭＡＦＤＡＰＳでは、モバイルエージェントを優先度に応じて以下の三種類に分類する。
（１）緊急処理エージェント：優先度高
（２）迅速処理エージェント：優先度中
（３）平常処理エージェント：優先度低
あわせて、エージェントが移動後最初に到着する受信部についても、緊急処理用と通常処理用とを用意し、それぞれ高優先度及び中優先度を割り当てる（なお、図１中では符号３ｂで通常処理用の受信部を示している）。尚、本実施形態では、緊急処理用受信部３ａの優先度は緊急処理エージェントと同一に、通常処理用受信部３ｂの優先度は迅速処理エージェントと同一に設定することとしているが、これに限られるものではなく、任意に優先度を設定しても良い。

本実施形態では、最も優先度の高い緊急処理エージェントのみにスレッドプーリングを適用している。この理由は、例えば緊急処理エージェントが処理を行う地絡発生時の事故区間分離処理や事故復旧処理においては、一つの装置上で同時に存在するエージェント数の予測が可能であり、かつその数は少ない点にある。これに対し、迅速処理エージェントや平常処理エージェントは様々な処理を行うものであり、一つの装置上で同時に存在するエージェントの数を予測することが困難である。例えば、一つの装置上に多数のスレッドを待機させる場合、使用するメモリ量が大きくなってしまい処理の迅速化を図れない場合が存在する。したがって、本実施形態では、迅速処理エージェントと平常処理エージェントについては、エージェント到着時にスレッドを生成している。しかしながら、本発明のモバイルエージェント移動の高速化方法を適用するのは、緊急処理エージェントに限られるものではない。例えば、実行する処理の内容が限られているような状況においては、迅速処理エージェント、平常処理エージェントに本発明のモバイルエージェント移動の高速化方法を適用しても良い。

まず、ＭＡＦＤＡＰＳにおけるＱｏＳ制御の様子を図１に示す。符号１は送信側装置、２は通信網、３は受信側装置をそれぞれ示している。

図１２に受信側装置３の構成の一例を示す。受信側装置３は、ディスプレイ等の出力装置４と、キーボード、マウス等の入力装置５と、ＣＰＵ６と、主記憶装置（ＲＡＭ）７と、ハードディスク等の補助記憶装置８等により構成される。

さらに、受信側装置３は、緊急処理用受信部３ａ及び通常処理用受信部３ｂと、スレッドを有する複数の緊急処理用待機エージェントを受信側装置内に予め待機させておく待機エージェント設定部１１と、緊急処理モバイルエージェントを緊急処理用受信部に受信したらこの緊急処理モバイルエージェントを復元させるエージェント復元部１２と、緊急処理用受信部３ａによって複数の緊急処理用待機エージェントの中の一つを抽出するエージェント抽出部１３と、エージェント復元部１２により復元された復元後の緊急処理モバイルエージェントの処理内容オブジェクトをエージェント抽出部１３により抽出された緊急処理用被抽出エージェントに関連づけるエージェント関連づけ部１４と、緊急処理用受信部３ａからこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始する実行開始部１５と、この処理内容オブジェクトの実行終了後、緊急処理用被抽出エージェントに関連づけられた処理内容オブジェクトを廃棄させてから緊急処理用受信部３ａに対して処理終了を通知させる処理終了通知部１６と、当該緊急処理用被抽出エージェントが有しているスレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用するスレッド再利用部１７を有するものである。

上記待機エージェント設定部１１、エージェント復元部１２、エージェント抽出部１３、エージェント関連づけ部１４、実行開始部１５、処理終了通知部１６及びスレッド再利用部１７は、ＣＰＵ６で実行されるソフトウェアとして構成でき、その実行の際に必要なデータは、ＲＡＭ７にロードされる。尚、受信側装置３の構成はこれに限られるものではない。また、送信側装置１も受信側装置３と同様のハードウェア構成を備えるものである。また、受信側装置３が送信側装置１に、送信側装置１が受信側装置３にそれぞれなりうるのは勿論である。

上記のハードウェア資源は例えばバス９を通じて電気的に接続され、ネットワークＩ／Ｆ１０を通じてＷＡＮ等の通信網２との通信を行うものである。尚、通信網２は一般的には有線通信網であるが、一部又は全部を無線通信網としても構わない。また、通信網２は、特に限られるものではなく、例えばインターネット等を利用しても良い。尚、本実施形態ではセション層プロトコルにＪａｖａ（登録商標）ＲＭＩ（Ｊａｖａ Remote Method Invocation)、トランスポート層プロトコルにＴＣＰを用いて通信を行うこととしているがこれに限られるものではない。

次に、Ｊａｖａ（登録商標）ＲＭＩによるコネクションの設定について説明する。尚、コネクションとはＪａｖａ（登録商標）ＲＭＩによる仮想的な回線のことをいうものとする。Ｊａｖａ（登録商標）ＲＭＩでは、図１３に示すように、クライアントとサーバの間に予めコネクションを設定した上でメソッドの呼出し（Ｓ５１）とそれに対応する応答（Ｓ５２）が行われる。ＭＡＦＤＡＰＳにおいては、ＲＭＩクライアントは送信側装置１、ＲＭＩサーバは受信部にそれぞれ相当しているといえる。

ＭＡＦＤＡＰＳにおいては、緊急処理エージェント用のコネクションと、その他のエージェント用のコネクションについて以下のように設定する。本実施形態では、緊急処理エージェントは事故区間分離処理など用途が限定されているため受信側装置３はある程度特定されている場合が多い。したがって、送信側装置１にコネクション保持部１８を設け、受信側装置３の緊急処理用受信部３ａに対して、コネクションを常設する設定としている。

図１４にＭＡＦＤＡＰＳにおけるコネクション設定の一例を示す。図１４（ａ）は、緊急処理エージェントのコネクション設定例を示している。緊急処理エージェントが処理を開始し、移動する場合には、先ず受信側装置３のＵＲＬをコネクション保持部１８に送り(Ｓ５３)、緊急処理用受信部３ａへのコネクションを管理するオブジェクトを得る(Ｓ５４)。次に、緊急処理エージェントはこのオブジェクトを利用して受信側装置３へと移動する(Ｓ５５)

図１４（ｂ）は、迅速処理エージェントと平常処理エージェントのコネクション設定例を示している。迅速処理エージェント及び平常処理エージェントが移動する場合には、迅速処理エージェント及び平常処理エージェントは、移動先である受信側装置３のＵＲＬに基づいてrmiregistryと呼ばれるディレクトリサービスに対して問い合わせを行い(Ｓ５６)、移動先となる通常処理用受信部３ｂの識別子を取得する(Ｓ５７)。その後、取得した識別子に基づいて通常処理用受信部３ｂに対してコネクションを設定し(Ｓ５８)、移動する(Ｓ５９)。尚、rmiregistryはサーバの情報を登録するためのネームサーバであって、通常は送信側装置１及び受信側装置３とは別に構成される。したがって、rmiregistryへの問い合わせ処理（Ｓ５６〜Ｓ５７）の処理時間が増加する傾向にある上、コネクションをその都度設定する時間（Ｓ５８）も増加する。これに対し、緊急処理エージェントにおいては、これらの処理を省略することで高速に処理する仕組みが備わっている。

尚、到着したエージェントが上記いずれのエージェントであるのかの判断は、エージェントを実現するオブジェクトクラスの型をみて判断される。これは、例えば緊急処理エージェントを実現するオブジェクトクラスと、より優先度の低いエージェントを実現するオブジェクトクラスは、それぞれ異なる型を持っていることから判断される。

また、処理を実行中の（つまり活性化されている）エージェント及び受信部は、独自に処理を行うためのスレッドを有する。本実施形態ではＪａｖａ（登録商標）ＶＭにより優先度に基づいたスレッド処理が実現されている（図２参照）。例えば、優先度の最大値を１０、最小値を１、通常値を５とし、値が大きいほど優先される仕組みとしたような場合、優先度の高いエージェントまたは受信部の処理は、優先度の低いエージェントまたは受信部の処理が行われている最中でも割り込んで開始される（図２参照）。また、同じ優先度のものに対してはＣＰＵの占有時間を均等に割り当てる。例えば図２に示すスレッド処理の場合には、最も優先度の高いスレッドＡの処理が最優先される一方で、優先度の低いスレッドＣとスレッドＤは処理は途中で割り込まれることによって適宜中断される。また、優先度が同じであるスレッドＣとスレッドＤは、ＣＰＵの占有時間が均等に割り当てられる結果、均等な時間ごとに区切られることとなる（図２参照）。

次に、スレッドプーリングの組み込みの内容について説明する。スレッドプーリングは、短い時間での処理完了を必要とする緊急処理エージェント及び緊急処理用受信部３ａが関わるモバイルエージェントの移動に適用するものである。スレッドプーリングを用いた移動の概要を図３に示す。ここでは、スレッドを有する複数の緊急処理用待機エージェントが待機しており、これら緊急処理用待機エージェントの中の一つを使って処理内容オブジェクトに従った処理を進める。この際、緊急処理用待機エージェントのそれぞれが予め有しているスレッドを利用して処理を進めることができることから、処理の実行にあたってスレッドを作成する必要がないという点が特徴的である。

一方、既述のように、従来のＭＡＦＤＡＰＳにおいては移動後に復元されたエージェントが受信側装置３において起動されることによって処理を開始するようになっており、この復元の際、エージェントのためのスレッドを実現するThreadオブジェクトの生成がＪａｖａ（登録商標）ＶＭにおいて自動的に行われる。つまり、緊急処理用のインスタンスを作り出すたびにスレッドを作成する必要があったわけだが、これに対し、スレッドプーリングを組み込んだ本実施形態のＭＡＦＤＡＰＳにおいては、上述したようにスレッドを有する緊急処理エージェントが複数待機状態で待機している（図３参照）。ここで、ある緊急処理エージェント（図３ではエージェントＡ）が緊急処理用受信部３ａまで移動し（ステップＡ）、緊急処理用受信部３ａにて復元されると（ステップＢ）、当該緊急処理用受信部３ａが待機中の緊急処理エージェントの中から一つ例えば図３でいえばエージェントＢを選び出す（ステップＣの抽出）。次に緊急処理用受信部３ａが、エージェントＡの処理内容（処理内容を表すオブジェクト）をエージェントＢに関連づけ（ステップＤ）、その後、エージェントＢに対して処理再開指令を出すことにより（ステップＥ）、移動してきた処理内容の実行が開始される。また、エージェントＢは、処理内容がすべて終了すると、処理内容を表すオブジェクトを廃棄した後、緊急処理用受信部３ａに処理終了を通知して待機状態に戻る。

以上の処理内容をフローチャートを用いてより詳しく説明すると以下のとおりである。すなわち、待機エージェントを準備する処理の流れは（図４参照）、待機エージェントの準備する処理の開始（ステップ１）後、具体的処理内容を持たない緊急処理エージェントを複数生成する（ステップ２）。本実施形態では具体的処理内容を持たない緊急処理エージェントとは、例えば監視制御機能を実現するためのオブジェクトを持たないこと、即ち監視制御のための変数や手順を定めたプログラムを持たないエージェントをいう。尚、監視制御機能とは、例えば事故区間分離処理において、どの電源を系統から切り離す（解列する）かを判断し、解列信号を送信する処理等をいう。また、待機エージェントの数は、２個ないしは３個とすることが移動高速化の観点から最適であるが、エージェントの生成数は使用可能なメモリ量、実行する処理内容等に応じて予め設定しておけばよく、特に限られるものではない。

続いて、生成された複数の緊急処理エージェントを緊急処理用受信部３ａ上のキューに待機エージェントとして格納する（ステップ３）。尚、本実施形態では待機エージェントは一意の識別子を有する点を除いては同一の構造としている。以上で、待機エージェントを準備する処理を終了する（ステップ４）。

また、緊急処理用受信部３ａにおいて、移動してきたエージェントの受信／処理関連づけ／待機エージェント起動までの処理の流れを示すと以下のとおりである（図５参照）。すなわち、処理開始（ステップ１１）後、移動してきた緊急処理エージェント（上述したステップＡ）のオブジェクトを受信し、復元（上述したステップＢ）する（ステップ１２）。尚、モバイルエージェントシステムでは、一般的にエージェントは複数のデータユニットに分割された状態で移動がなされる。ここでいう復元とは、データユニットを結合してエージェントを復元する処理をいう。次に、緊急処理用受信部３ａのスレッド優先度を予め設定された値、例えば最高位である値に設定する（ステップ１３）。次に、緊急処理用受信部３ａが有するキューの先頭から待機エージェント（図５における待機中の緊急処理エージェント）を取り出す（ステップ１４）。尚、キューは先入れ先出しのデータ構造であるので最も待機時間の長い緊急処理エージェントが抽出される。このとき、キューにおける登録は削除する。取り出した待機エージェントを緊急処理用受信部３ａに作業中エージェントとして登録し（ステップ１５）、移動してきた緊急処理エージェントが有する処理内容オブジェクトを待機エージェントに渡して関連づける（ステップ１６、上述したステップＤ）。続いて、待機エージェントのスレッドを起動し（ステップ１７）、起動までの処理を終了する（ステップ１８）。ステップ１７でスレッドを起動したら図６に示す処理に移行する。

図６には、待機エージェントの起動から再度待機状態となるまでの処理の流れを示している。ここでは、起動（ステップ２１）の後、緊急処理エージェントが生成直後のものかどうかを判断し（ステップ２２）、生成直後のものであれば生成時の処理を実行する（ステップ２３）。尚、本実施形態では、生成直後かどうかの判断は緊急処理エージェントの有するフラグにより判断している。例えば緊急処理エージェントは、生成直後は真の値のフラグを有し、生成時の処理を行った後にフラグの値を偽としている。続いて、移動直後用の処理が存在するかどうかを判断し（ステップ２４）、移動直後用の処理が存在する場合には、移動直後用の処理を実行し（ステップ２５）、移動直後用の処理を削除する（ステップ２６）。ステップ２４で移動直後用の処理が存在しない場合には以上のステップ２４，２５の処理は実行しない（図６参照）。その後、緊急処理用受信部３ａに処理終了を通知し（ステップ２７）、待機モードに移行して（ステップ２８）、待機モードに戻る（ステップ２９）。ステップ２７で緊急処理用受信部３ａに処理終了を通知したら図７に示す処理に移行する。

ここで生成時の処理と移動直後用の処理の一例を説明する。例えば緊急処理エージェントの処理内容が事故区間分離処理である場合において、生成時の処理とは、検知された事故電流の向きに応じて移動先の受信側装置３を判断し、移動するまでの処理をいう。また、移動直後用の処理とは、移動先の受信側装置３において他のエージェントの存在を確認し、他のエージェントが存在する場合には、他のエージェントと事故電流に関するデータの交換をし、事故区間を判定する処理を行う。さらに事故区間が自区間である場合には、隣接する区間の装置への移動や、区間内の分散型電源を管理する装置への移動を行う処理をいう。尚、生成時の処理と移動直後用の処理は、予め設定しておくものとする。また、上記生成時の処理と移動直後用の処理は一例であって、これに限られるものではない。

図７には、緊急処理用受信部３ａにおけるエージェントの待機モード移行についての流れを示している。ここでは、処理開始（ステップ３１）の後、ステップ１５で登録した当該エージェントを作業中エージェントとしての緊急処理用受信部３ａの登録から抹消する（ステップ３２）。抹消したら、当該エージェントを待機エージェントとしてキューに登録し（ステップ３３）、待機モード移行を終了する（ステップ３４）。

以上説明した処理を実現するためのオブジェクトクラス構成の一例を図１０に示す。図１０はオブジェクト指向分析設計の標準的な記述法の一つであるＵＭＬ（Unified Modeling Language）により表したものである。以下、図１０について説明する。四角で囲まれたものがオブジェクトクラス又はインタフェースを表す。尚、インタフェースについては特に<<interface>>と記載されている。また、オブジェクトクラス間の関連は線を用いて表されている。このうち三角形の矢印と実線にて結ばれた関係（一例を符号１９で示す）は、継承関係（インヘリタンス）を示し、三角形の矢印と破線にて結ばれた関係（一例を符号２０で示す）は、実装関係を示している。また、線に付随した数は多重度を示している。例えばMobileAgentクラスは０から５個までのStrategyクラスに対する関連を保持できることを意味する。また、すべてのモバイルエージェントに共通する属性及びメソッドはMobileAgentクラスにて定義される。例えば監視制御機能を実現するStrategyクラスに対する参照は、MobileAgentクラスで定めている。MobileAgentクラスはＪａｖａ言語にて用意されているRunnableインタフェースを実装することによりＪａｖａにおけるThreadオブジェクトにて独立した制御の下、処理を実行できるようになる。また抽象クラス(図１０における<<abstract>>)とすることにより、MobileAgentクラスを直接オブジェクトとして生成することがないように定めている。

本実施形態において、実際にオブジェクトとして生成されるのはMobileAgentクラスから派生した３つのオブジェクトクラスであり、Emergency Agent、Rapid Agent、Best Effort Agentはそれぞれ緊急処理エージェント、迅速処理エージェント、平常処理エージェントに対応している。また、受信部に相当するクラス(MafdapsRootImplとEmergencyGate)は共に、遠隔装置からモバイルエージェントが移動するためのメソッドを提供するためＪａｖａＲＭＩのサーバオブジェクトであるUnicastRemoteObjectクラスを継承している。加えてモバイルエージェントが移動する際のメソッドの書式を規定しているMafdapsRootインタフェースを実装している。また緊急処理用受信部３ａに対応するEmergencyGateクラスには、処理を実行中の緊急処理エージェントと待機状態にある緊急処理エージェントを管理するためEmergencyAgentオブジェクトに対する２種類の参照を設定する。このうち作業中の緊急処理エージェントの管理には、ハッシュキーにて高速な検索が可能なHashSetクラスを利用する。待機中の緊急処理エージェントの管理には、先頭に位置するものから順に処理を再開させることから、リスト構造を持つArrayListクラスを利用している。

またjava.lang.ThreadにおいてThreadオブジェクトが生成される。またモバイルエージェントにおけるアプリケーションプログラムであるストラテジー(Strategy)によりエージェントによる処理内容が表現される。本実施形態の場合であれば、事故区間の判定や開閉器の開放操作などのアプリケーションにおける処理がこのストラテジーによって表現されている。なお、緊急処理エージェントの復元や処理内容オブジェクトの関連づけ、処理再開といった処理の内容は、Emergency Gateによって表現されている。ちなみに、処理再開指令は、例えばＪａｖａのThreadオブジェクトに対するnotify()メソッドの起動による。また、待機モードへの移行は、例えばThreadオブジェクトに対するwait()メソッドの起動による。

また、処理内容を表すオブジェクトだけを送信する方法を採用することもできるが、本実施形態ではこれを採用していない。本実施形態で採用していないのは、緊急処理エージェントが他の種類のモバイルエージェントと同じ移動形式を採用することによりプログラム構成の簡潔さを維持できることに加え、モバイルエージェントを構成するオブジェクトの大きさが、通信の遅延時間を大幅に増大させる恐れが非常に低いことによる。また、処理内容を表すオブジェクトクラスを設計する際に、異なる優先度でも同一のプログラミング方法を採用できるため、柔軟性を確保できることも、すべてのモバイルエージェントが同じ移動方法を採用する要因の一つとなっている。

本実施形態に係るシステム及びこれについて実験した実施例１の結果内容（後段参照）を参酌すると、例えば需要地系統の監視制御を行う場合において本発明のエージェントシステムによれば大きな効果が得られるということができる。すなわち、需要地系統の監視制御を行うにあたって現在考えられている最もリアルタイム性の高い処理は、地絡事故が発生した区間を分離するというものである。この処理においては、図１１に示すように、配電線上に設置された開閉器（例えば開閉器Ｂ，Ｃ）において、例えば事故電流など予め設定された条件を満たす状態が検出されると（ステップ４１）、開閉器Ｂ（またはＣ）が属する区間を担当する運用管理サブシステムＢ（またはＣ）ヘエージェントが移動して事故情報を通知する（ステップ４２）。運用管理サブシステムＢ（またはＣ）に移動したエージェントは、事故電流の向きなどに基づき、隣接する運用管理サブシステムに自らのクローンを移動させて事故情報を通知する（ステップ４３）。事故が発生した区間の運用管理サブシステム（例えば図１１における運用管理サブシステムＢ）上には二つ以上のモバイルエージェントが集結し、相互に事故情報に関するデータを交換することによって事故区間を判定する（ステップ４４）。判定後、モバイルエージェントは隣接する運用管理サブシステムＡまたはＣに移動して事故区間を通知し（ステップ４５）、さらには開閉器Ｂ（またはＣ）へと移動して開放指示を出す（ステップ４６）。これによって開閉器Ｂ，Ｃが開放されると（ステップ４７）、各開閉器Ｂ，Ｃを管理している運用管理サブシステムＢ，Ｃヘ開放通知を行う（ステップ４８）。また、自らが管理する区間にて事故が発生したと判定した運用管理サブシステム（例えばＢ）から、区間内に存在する需給インタフェース（需給ＩＦ）に、分散型電源の解列指示を行うためのエージェントが移動して指示をする（ステップ４９）。電源を解列した需給インタフェースは運用管理サブシステム（例えばＢ）へ解列通知を行う（ステップ５０）。

また、需要地系統での処理の流れを示すと以下のとおりである（図８、図９参照）。すなわち、需要地系統における事故区間を分離する処理を開始したら（ステップ４０１）、まず事故電流を検出し（ステップ４０２）、当該区間の運用管理サブシステムに移動したら（ステップ４０３）、自分以外の事故処理エージェントがいるかどうかを判断する（ステップ４０４）。いる場合には図９に示す処理のステップ４１１に移行し、いない場合には、隣接区間の運用管理サブシステムに移動する（ステップ４０５）。運用管理サブシステムに移動したらそこで待機し（ステップ４０６）、予め設定された待機時間に基づいて時間切れかどうかを判断する（ステップ４０７）。時間切れでない限りは待機し続け、時間切れとなったら事故区間ではないと判定し（ステップ４０８）、終了する（ステップ４０９）。

また、上述のステップ４０４から図９に示す処理のステップ４１１に移行した後の処理は以下のとおりである（図９参照）。すなわち、処理開始（ステップ４１１）の後、他の事故処理エージェントと情報交換を行い（ステップ４１２）、事故区間かどうかを判断する（ステップ４１３）。事故区間ではないと判定した場合には（ステップ４１４）、そのまま事故区間分離処理を終了する（ステップ４１５）。一方、事故区間だと判断した場合には、隣接区間の運用管理サブシステムに事故を通知し（ステップ４１６）、開閉器に複製を移動させる（ステップ４１７）。その後、区間内の分散型電源を解列し（ステップ４１８）、処理を終了する（ステップ４２０）。一方、開閉器に移動したエージェントは開閉器を開放し（ステップ４１９）、処理を終了する（ステップ４２１）。

以上の手順は、いくつか考えられる事故区間分離処理の中でエージェントの移動回数が最も多いものの一つである。この手順の場合、事故発生から開閉器を開放するまでにエージェントは最大で４回の移動を行う。また、分散型電源の解列については、区間内に設置されている需給インタフェース（需給ＩＦ）の台数分だけエージェントの移動が発生することとなる。ところで、現在設計あるいは運用されている分散システムの構成であれば、一つまたは少数の分散型電源に対して一つの需給ＩＦが設置されるため、一区間内、すなわち一つの運用管理サブシステムの配下に数十から百程度の需給ＩＦが存在する可能性がある。一方で、地絡事故が発生してから区間を分離するまでの時間は１秒以内であることが求められている。この時間には、事故情報の検出時間や開閉器の動作時間も含まれるため、情報通信処理に割り当てられる時間は数百ミリ秒である。このような状況下、上述した実施形態におけるようなエージェントシステムならば開閉器の開放までの処理時間に貢献するのはもちろん、分散型電源の解列に関してより大きな効率化をもたらすことが期待できる。

なお、上述の実施形態は本発明の好適な実施の一例ではあるがこれに限定されるものではなく本発明の要旨を逸脱しない範囲において種々変形実施可能である。

上述の実施形態にて説明したモバイルエージェントシステムの実際の処理時間を測定すべく実験を実施した。以下に実験システムの概要を述べるとともに、その処理時間に関する測定結果を示す。

まず、実験システムの構成を図１５に示す。実験における計算機には、ＣＰＵがCeleron（登録商標） 2.0GHz、メモリが１ＧＢのものを一台用いた。ＯＳには、Microsoft Windows(登録商標) XP Professional Editionを利用した。ここに、ＪＤＫ1.4.2に対応したＪａｖａ（登録商標）ＶＭによって、モバイルエージェントシステムであるＭＡＦＤＡＰＳを二つ立ち上げ、この間でモバイルエージェントが往復するように設定した。ＭＡＦＤＡＰＳにおける通信には、Ｊａｖａ（登録商標）ＲＭＩを利用した。今回の実験では、通信網の影響を除外するため、通信網を介さずモバイルエージェントが移動する構成とした。

また、今回の実験システムにおける処理内容は
（１）到着後、時刻を取得する。
（２）時刻を表示する。
（３）遠隔のＪａｖａ（登録商標）ＶＭに移動する。
といった簡潔なものとしたことから、エージェントは短時間のうちに待機状態へと復旧するために多数の待機エージェントを用意する必要がない。また、想定している事故区間分離処理において、事故区間を判定するために一つの装置上で協調するエージェント（つまり集結して相互に情報を交換するモバイルエージェント）がほとんどの場合二つないしは三つであることから、予備の一つを加え、今回の実験では待機中の緊急処理エージェントを四つ用意することとした。ちなみに、これら複数の緊急処理用待機エージェントは、いずれも同じ優先度のスレッドを有しているものであり、いずれが抽出されても同じ処理が可能な同一のものである。なお、一つの装置上で協調するにあたっては、その区間を含む開閉器及びＬＰＣの台数分のエージェントが協調することになる。例えば図１１の場合であれば二つのエージェントが協調する。つまり、ある区間に着目した場合、二つの区間と接していれば二つのエージェントが、三つの区間と接していれば三つのエージェントが協調することになる。

また、実験は、１００回の往復を連続して実行し、それを一つの試行セットとして扱った。１００回の往復を一つの試行セットとして扱うのは、Windows(登録商標) XPの時間分解能が１０ミリ秒程度であり、測定データ内に一往復に要する時間が０秒となってしまうことがある程度の確率で含まれてしまうため、複数回の平均に主眼をおく必要があることによる。例えば、スレッドプーリングを用いた方法の試行番号１の場合、往復時間が０秒と計測されるものが２６％含まれていたが、上記のように往復数を１００回程度に設定することによって往復に要する平均時間を取得することができるようになる。

続いて、上記のような構成の実験システムにおける測定結果を示す。表１には、従来方式による移動と、スレッドプーリングを用いた本発明に係る方式（ないしは方法）による移動のそれぞれについて、エージェントが一往復する平均時間と改善率を示す。今回行った実験全般について、本方式（本発明に係る方法）を用いることにより一往復あたり約10ミリ秒、11.6％の改善が見られた。なお、待機中のモバイルエージェントが枯渇する（つまり待機数が０になる）事象は発生しなかった。

図１６に、エージェントが一往復するのに要する移動時間を、１０ミリ秒ごとに区切って発生頻度を表したグラフとその回数を示す。従来方式において最も発生頻度の高かったのは一往復に１０〜２０ミリ秒を要する場合であったが、本方式によればそれらの一部が１０ミリ秒以下で実行可能になり、この結果、全体として移動の高速化がもたらされていることがわかる。なお、最も移動に時間を要する事象は従来方式ではなく本方式のときに発生しており、したがって本方式の方が発生頻度のレンジが広いこととなったが、全体としてみれば本方式の方が高速処理が可能であるとの結果が得られた。

また、図１７に、実験システムに設置した二つのＭＡＦＤＡＰＳ間で、緊急処理エージェントが１００回往復する実験を、従来の移動とスレッドプーリングを用いた移動のそれぞれについて合計１０回行った際の、一往復に要する移動時間の推移を示す。さらに、図１８には試行ケースごとの改善率を示す。いずれの試行ケースにおいても、本方式の場合には、従来方式を用いる場合と同じかあるいはそれよりも短い時間で処理を終了した。

また、図１７と図１８に示すように、試行番号３以降のケースにおいて移動時間が短縮する現象が見られている。この現象が一般的特徴なのか本方式に特有の特徴なのか断定することは難しいが、一つの要因としては、繰り返し同じ動作をさせることによってＣＰＵ（中央演算装置）におけるキャッシュのヒット率が高まったことが挙げられる。

なお、本実施例においては待機中とした緊急処理エージェントの数を四つとしたが、これは一つの装置上で協調するエージェントがほとんどの場合二つないしは三つであることを考慮して設定したプール数であり、固定数とするのではなく、状況に応じて動的に待機エージェントのプール数を変動する、または待機エージェントの数がしきい値よりも少なくなった場合に、一時的に増加させるなどの手法を採用することも可能である。

以下に第二の実施例を示す。尚、特に記載のない限りは第一の実施例と同様の条件下による。

本実験では、エージェントは次の処理を実行した。
（１）時刻記録側のエージェントシステム（以下、エージェントシステム１ともいう）であれば、到着直後に時刻を取得する。
（２）往復回数が１０００回に到達していなければ、遠隔のエージェントシステム（以下、エージェントシステム２ともいう）に移動する。
（３）往復回数が１０００回に到達していれば、処理を停止する。

これによりモバイルエージェントが頻繁に移動する場合を測定することが可能となる。また、移動以外の処理を簡素化することができるため、移動以外に要する処理時間が測定結果に与える影響は小さくなる。尚、上記のようなアルゴリズムのため一つの緊急処理エージェントを往復させた場合、一つのエージェントシステム上に複数の緊急処理エージェントが存在することはない。

本実験では、モバイルエージェントの移動に際しては、常に同じ数のオブジェクトが付随することとした。これは移動に付随するオブジェクトの数や大きさによってオブジェクト復元時間が変動することを排除するためである。具体的には、一往復あたりの移動時間を測定するために生成するオブジェクト(JavaにおけるDateオブジェクト)を、予め往復回数に必要な個数生成し、その後、到着時刻を記録したオブジェクトに順次置き換えた。

処理時間に関する実験ケース１から実験ケース６までの実験ケースの目的と設定条件を表２に示す。尚、表２において、ＥＡは緊急処理エージェント、ＲＡは迅速処理エージェント、ＢＥＡは平常処理エージェントをそれぞれ示す。

表２に示すように、本実験では実験ケースを６種類を用意した。このうち実験ケース１から３については同一計算機上(すなわち通信網を経由しない場合)で二つのモバイルエージェントシステムを起動し、その間をエージェントが移動する実験とした。これにより通信網及び通信装置における処理の影響を排除したデータを測定した。これに対し、実験ケース４から６については通信網を経由した実験とし、通信手順が含まれる場合の移動時間を測定した。さらに通信手順を含む場合及び含まない場合のそれぞれにおいて、緊急処理エージェントのみが移動する場合と、低優先度エージェントも移動している場合を設定し、低優先度エージェントが緊急処理エージェントの移動時間に対して持つ影響についても調べた。

また、メモリ使用量の測定には実験ケース１を用いた。これは以下に示す二つの理由による。
（１）迅速処理エージェントや平常処理エージェントといった低優先度エージェントが存在すると本発明の移動方式によって増加するメモリ量を特定することが困難になること。
（２）１台の計算機上であれば２つのモバイルエージェントシステムのメモリ使用量を同時に測定できること。

尚、すべての実験ケースにおいて本発明のモバイルエージェント移動の高速化方法を用いたプログラム（以下、提案方式という）３種類と、エージェントを待機させずに、エージェント到着時にスレッドを生成する従来方式の合計４種類の実験を行った。提案方式の設定条件の違いは、待機しているエージェントの数(以下、プール数ともいう)だけとし、それぞれ４個、１０個、２０個のエージェントが存在するように設定したものを用いた。

本実験にはＣＰＵがIntel Pentium（登録商標）II３３３MHz、メモリが１９６MBの計算機を使用した。ここで需要地系統の運用管理システムに採用される計算機は低コストであることが求められるため限定された計算資源であることが想定される。このため比較的低スペックの計算機を用いて実験を行った。

尚、計算機にはデスクトップＯＳを搭載した。これはＭＡＦＤＡＰＳがＪａｖａＲＭＩを利用していること、リアルタイムＯＳの機能を利用できるＪａｖａＶＭにＪａｖａＲＭＩを利用できるものがないことによる。

実験ケース１は緊急処理エージェントだけが移動を繰り返し、他の種類のエージェントは存在しない場合である。本実験では一つの緊急処理エージェントが二つのエージェントシステム間を往復する試行を３回(３０００往復分)行った。一往復に要する平均時間のグラフを図１９に示す。

図１９から、待機しているエージェントの数により所要時間が変化することが分かった。即ちエージェントの待機数が最も少ない４個の場合では、従来方式よりも約４ミリ秒短縮できるのに対し、２０個のエージェントが待機している場合には、従来方式と比べ効果は小さくなった。

図２０に、実験ケース１の結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを示す。尚、図２０に示すグラフは、往復所要時間ごとの各方式の発生頻度を示しており、左から提案方式（プール数４）、提案方式（プール数１０）、提案方式（プール数２０）、従来方式である。以下、図２２、図２４、図２６、図２８、図３０において同様である。ここで、移動に要する時間のばらつきや特徴に着目すると、いずれの方式においても５０ミリ秒未満で完了した往復は存在しなかった。エージェント待機数が４個の提案方式については、５０ミリ秒以上６０ミリ秒未満で移動した場合が全体の約６パーセント測定されたのに対し、従来方式についてはこの時間内に完了した往復は存在しなかった。また、いずれの方式においても９０ミリ秒以上要する往復は非常に少なく、かつ同程度の発生頻度であった４個のエージェントがプールされている提案方式と従来方式に着目すると７０ミリ秒以上８０ミリ秒未満での往復の発生頻度はほぼ同数であるが、６０ミリ秒未満の往復時間帯では提案方式のみで１７９回であり、６０ミリ秒以上７０ミリ秒未満の時間帯では提案方式の方が２８３回多かった。一方で８０ミリ秒以上９０ミリ秒未満での往復は、提案方式の発生頻度が従来方式に比べて４３６回少なかった。これらの時間帯に発生する往復の結果が平均所要時間に与える影響は(３０×１７９＋２０×２８３)÷３０００＝３．６７となり、図１９に示した平均所要時間における提案方式と従来方式の差に近い数字となる。加えて９０ミリ秒以上要する往復の発生頻度が同程度であり、かつ長時間を要する往復が発生していないことから上記の時間帯の違いが主に平均時間の違いとなって現れていると考えられる。

次に、優先度の異なるエージェント（迅速処理エージェント及び平常処理エージェント）が存在する場合における緊急処理エージェントの移動時間について測定を行った。これらのエージェントにおいてはエージェントシステムに到着後、時刻の取得と画面表示用のオブジェクト生成を１０００回繰り返した後、対向するエージェントシステムへ移動することを無限に繰り返すようにプログラムを設定した。尚、平常処理エージェントについては直前の平常処理エージェントが移動してから一定時間経過していることを確認してから移動するようにした。本実験では、待機時間を２秒に設定した。また、本実験では、迅速処理エージェント又は平常処理エージェントが１０個同時に処理を行っている状況を発生させた。

まず、迅速処理エージェントが１０個動作している場合(実験ケース２)における緊急処理エージェントの平均往復時間を図２１に示す。この結果によると、待機している緊急処理エージェントの数が増加するに連れて往復に要する時間が増加している傾向は、迅速処理エージェント存在しない場合と同様だが、待機エージェントが２０個存在する場合には、従来方式よりも往復に時間を要する結果となった。一方で待機エージェントを４とした提案方式と従来方式を比較すると、その差はやや小さくなっているものの提案方式の方が短い時間で往復を完了する結果となった。

実験ケース２の結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを図２２に示す。ここで移動に要する時間のばらつきや特徴に着目する。平均時間で見た場合には、プール数を２０とした提案方式が従来方式よりも往復に時間を要することが分かったが、８０ミリ秒未満の往復発生頻度ではプール数を２０とした提案方式の方が従来方式よりも多く発生し、逆に８０ミリ秒以上９０ミリ秒未満の往復については従来方式の方が多く発生した。このことから９０ミリ秒以上を要する往復においてプール数を２０とした提案方式の平均往復時間を増大させる要因が含まれると考えられる。そこで長時間を要する往復について分析するとプール数を２０とした提案方式では１５０ミリ秒以上要する往復が４３回発生しているのに対して、従来方式では２５回であることが分かった。このことからプール数を２０とした提案方式でも多くの場合では従来方式よりも早く移動完了する効果を有することがわかった。

次に、平常処理エージェントが１０個動作している場合(実験ケース３)における緊急処理エージェントの平均往復時間を図２３に示す。提案方式及び従来方式のいずれにおいても緊急処理エージェントが単独で往復している場合よりも往復時間が増加した。さらにプール数を４とした提案方式と従来方式の時間差は、迅速処理エージェントが移動している場合(実験ケース２)とほぼ同程度であった。

実験ケース３の測定結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを図２４に示す。ここで移動に要する時間のばらつきや特徴に着目する。ここで見られる傾向は、緊急処理エージェントのみが往復している場合とほぼ同様であった。

さらにＣＰＵがIntelモバイルPentium（登録商標）III４５０MHz、メモリが２５６MBの計算機を一台追加し、これらを１０ＢＡＳＥ−Ｔのスイッチング機能を有するハブに接続した。それぞれの計算機上で、モバイルエージェントシステムを一つずつ実行させた。

実験ケース４では、緊急処理エージェントだけが移動を繰り返し、他の種類のエージェントは存在していない。実験ケース４における緊急処理エージェントの平均往復時間を図２５に示す。

待機エージェントの数及び従来方式に対する往復所要時間の短縮傾向に関しては、同一計算機上での試験結果とほぼ同じであった。しかし、往復時間そのものについては、全体的に短縮されていることがわかった。これは本実験ケースに用いた計算機の一つが、同一計算機での実験に用いたものよりも高速に処理が可能であることによる。この結果、待機エージェントの数が４の場合、従来方式に比べて往復で約２ミリ秒の短縮となった。

実験ケース４の測定結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを図２６に示す。ここで、移動時間に要する時間のばらつきや特徴に着目する。プール数を４とした提案方式と従来方式に着目して比較すると、６０ミリ秒以上７０ミリ秒未満を要する往復の発生回数は従来方式よりも提案方式の方が少なく、６０ミリ秒未満で往復する回数は提案方式の方が多く発生している。また７０ミリ秒以上を要する往復の発生回数に差がないこと、また長時間を要する往復が発生していないことから、一台の計算機上での結果と同じように、６０ミリ秒未満で往復する回数の増加が、平均時間に対して大きな影響を持っているといえる。

更に、イーサネット（登録商標）を経由した場合における低優先エージェントの影響を測定するために、一台の計算機で行った環境と同様に迅速処理又は平常処理のいずれかのエージェントが１０個動作している中で緊急処理エージェントを往復させ、その移動時間を測定した。

まず迅速処理エージェントが１０個動作している場合(実験ケース５)における緊急処理エージェントの平均往復時間を図２７に示す。この結果が示す傾向は、１台の計算機上で往復を繰り返した場合と同様であった。すなわち提案方式は他の結果と同様に待機している緊急処理エージェントの数に応じて平均移動時間が増加している。緊急処理エージェントのみが移動している場合に比べると、すべての方式において往復時間が増加していることがわかった。プール数を４とした提案方式と従来方式の差は、迅速処理エージェントが存在しない場合(実験ケース４)に比べて拡大している一方、プール数を２０とした提案方式と従来方式を比較すると所要時間が逆転した結果となった。

実験ケース５の測定結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを図２８に示す。同様に移動時間に要する時間のばらつきや特徴に着目する。最も大きな平均移動時間となった提案方式(プール数２０)について、所要時間の発生頻度を見ると、むしろ短い時間で移動を完了する試行が多いことが分かった。これは長時間を要する移動の測定結果が図２８に示した平均時間に影響を与えていることを意味している。その他の方式については短い時間の発生頻度が高くなれば、平均時間が短くなる傾向を示している。

更に、平常処理エージェントが１０個動作している場合(実験ケース６)における緊処理エージェントの平均往復時間を図２９に示す。この結果によると、いずれのプール数においても提案方式の方が従来方式よりも短い時間で往復したことが分かった。また、迅速処理エージェントが存在する場合(実験ケース５)に比べて、プール数の増加により平均往復時間が増加する割合が小さくなる結果となった。

実験ケース６の測定結果について移動に要した時間を横軸に、発生頻度を縦軸にとったグラフを図３０に示す。ここで、移動に要する時間のばらつきや特徴に着目する。ここで見られる傾向は、他の実験ケースと同様に平均往復時間が短い方式ほど短い時間で往復を完了する頻度が高いものであった。

最後に、提案方式及び従来方式に基づいたプログラムが使用するメモリ量を起動直後(移動実験前)と移動実験を行った後について測定した。移動実験後の測定では,エージェントの往復を１０００回実行した後に使用しているメモリ量が安定した段階でデータを取得した。提案方式については移動時間の実験と同様に、待機しているエージェントの数を４個、１０個、２０個に設定し、それぞれについて測定を行った。この結果を図３１に表す。

起動直後に使用するメモリ量は、いずれの方式及びプール数においてもほぼ同じ大きさであった。具体的にはプール数を４に設定した提案方式と従来方式の差は２８kB、プール数を２０に設定した提案方式と従来方式の差は４８kBであった。この差が待機エージェントを用意しておくために必要となるメモリ量である。この程度のメモリ使用量は全体からすると無視できる大きさといえる。一方、実際に移動した後のメモリ使用量については従来方式及び提案方式のプール数を変化させた場合の傾向は、起動直後の場合よりも差が大きくなった。具体的には、プール数を４に設定した提案方式と従来方式の差は１７６kB、プール数を２０に設定した提案方式と従来方式の差は５００kBであった。このように起動直後よりも差が広がるのは、以下に示す要因が影響するためである。
（１）提案方式においては、実行中エージェントの集合と待機中エージェントの集合を管理している。
（２）集合の要素数が多くなるに連れ、必要とするメモリ領域も増大する。
（３）要素の追加や削除に伴い、新たなメモリ領域の設定を行う場合がある。
（４）ガーベージコレクションが実行されるまでは、不要となったメモリ領域も確保されたまま残る。
（５）ヒープ領域は、ある程度余裕をもって確保される。
尚、エージェントの移動が終了し、ガーベージコレクションを実行した後に存在するインスタンス数の差は起動直後と同程度となった。また、ログを出力するエージェントシステムとその処理を行わないエージェントシステム２においてメモリ使用量が異なるが、これはログを出力するためのオブジェクトを生成し実行するために必要なメモリ量の差である。

本発明にかかるモバイルエージェント移動の高速化方法及び移動高速化モバイルエージェントによる事故区間分離処理方法の実施形態において、ＭＡＦＤＡＰＳにおけるＱｏＳ制御の様子を示す図である。 ＭＡＦＤＡＰＳにおける優先度に基づいたスレッドの処理内容を示す図である。 スレッドプーリングを組み込んだＭＡＦＤＡＰＳにおけるエージェントの移動の様子を示す図である。 待機エージェントを準備する際の流れを示すフローチャートである。 受信部（緊急処理用）において、移動してきたエージェントの受信／処理関連づけ／待機エージェント起動までの流れを示すフローチャートである。 待機している緊急処理エージェントの起動から再度待機するまでの流れを示すフローチャートである。 受信部（緊急処理用）におけるエージェントの待機モード移行に関するフローチャートである。 需要地系統における事故区間分離の流れを示すフローチャート（その１）である。 需要地系統における事故区間分離の流れを示すフローチャート（その２）である。 スレッドプーリングを組み込んだ場合のＭＡＦＤＡＰＳにおけるオブジェクトクラス構成の一例を示す図である。 モバイルエージェントを用いる際の事故区間分離処理の一例を示す図である。 受信側装置のハードウェア構成の一例を示す図である。 ＪａｖａＲＭＩにおけるコネクション設定の一例を示す図である。 ＭＡＦＤＡＰＳにおけるコネクション設定の一例を示す図であり、（ａ）は緊急処理エージェント用のコネクション、（ｂ）は迅速処理エージェント用のコネクションの設定の一例を示す図である。 実施例１における実験システムの構成を示す図である。 エージェントが一往復するのに要する移動時間を１０ミリ秒ごとに区切って発生頻度を表したグラフとその回数を示す図である。 実験システムに設置した二つのＭＡＦＤＡＰＳ間で、緊急処理エージェントが１００回往復する実験を、従来の移動とスレッドプーリングを用いた移動のそれぞれについて合計１０回行った際の一往復に要する移動時間の推移を示すグラフである。 実験システムに設置した二つのＭＡＦＤＡＰＳ間で、緊急処理エージェントが１００回往復する実験を、従来の移動とスレッドプーリングを用いた移動のそれぞれについて合計１０回行った際の試行ケースごとの改善率を示すグラフである。 実施例２の実験ケース１における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース１における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２の実験ケース２における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース２における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２の実験ケース３における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース３における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２の実験ケース４における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース４における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２の実験ケース５における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース５における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２の実験ケース６における緊急処置エージェントの平均往復時間を示すグラフである。 実施例２の実験ケース６における緊急処置エージェントの往復の所要時間の発生頻度を示すグラフである。 実施例２におけるメモリ使用量を示すグラフである。 従来のモバイルエージェントの移動方法におけるエージェントの移動の様子を示す図である。

符号の説明

１ 送信側装置
２ 通信網
３ 受信側装置
３ａ 緊急処理用受信部
１１ 待機エージェント設定部
１２ エージェント復元部
１３ エージェント抽出部
１４ エージェント関連づけ部
１５ 実行開始部
１６ 処理終了通知部
１７ スレッド再利用部

Claims (7)

1. 送信側装置と受信側装置が通信網を介して相互に接続されたモバイルエージェントシステムにおけるモバイルエージェントの移動方法において、スレッドを有し、かつ処理内容オブジェクトを有しない待機エージェントを前記受信側装置に予め生成して待機させておき、前記受信側装置は、前記送信側装置からモバイルエージェントを受信したときに、前記待機エージェントと前記モバイルエージェントが有する処理内容オブジェクトを関連づけ、該処理内容オブジェクトを関連づけられた待機エージェントを起動することを特徴とするモバイルエージェント移動の高速化方法。
2. 更に前記待機エージェントを実行後、該待機エージェントに関連づけられた前記処理内容オブジェクトを廃棄し、前記待機エージェントを生成時の状態に戻すことを特徴とする請求項１に記載のモバイルエージェント移動の高速化方法。
3. 前記待機エージェントを複数生成し、前記受信側装置に待機させておくことを特徴とする請求項１または２のいずれかに記載のモバイルエージェント移動の高速化方法。
4. 緊急処理モバイルエージェントを受信側装置の緊急処理用受信部にて受信後、当該緊急処理モバイルエージェントの処理内容オブジェクトに基づき緊急処理を進める際、この緊急処理モバイルエージェントの移動速度を高速化することによって緊急処理に要する時間を短縮するためのモバイルエージェント移動の高速化方法において、スレッドを有する複数の緊急処理用待機エージェントを前記受信側装置内に予め待機させておき、前記緊急処理モバイルエージェントが前記緊急処理用受信部へと移動したらこの緊急処理モバイルエージェントを復元させ、前記緊急処理用受信部によって前記複数の緊急処理用待機エージェントの中の一つを抽出し、さらに前記緊急処理用受信部によって前記復元後の緊急処理モバイルエージェントの処理内容オブジェクトを前記抽出された緊急処理用被抽出エージェントに関連づけ、その後、前記緊急処理用受信部からこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより前記緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始し、この処理内容オブジェクトの実行終了後、前記緊急処理用被抽出エージェントに前記関連づけられた処理内容オブジェクトを廃棄させてから前記緊急処理用受信部に対して処理終了を通知させ、当該緊急処理用被抽出エージェントが有している前記スレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用することを特徴とするモバイルエージェント移動の高速化方法。
5. 電力需要地に近い場所で発電を実施し電力を供給するための需要地系統にて、事故情報を通知する緊急処理モバイルエージェントを当該事故区間を担当する運用管理サブシステムにて受信後、当該緊急処理モバイルエージェントの処理内容オブジェクトに基づき緊急処理を進める際、この緊急処理モバイルエージェントの移動速度を高速化することによって緊急処理に要する時間を短縮する移動高速化モバイルエージェントによる事故区間分離処理方法において、スレッドを有する複数の緊急処理用待機エージェントを前記運用管理サブシステム及びこれに隣接する運用管理サブシステム内に予め待機させておき、前記緊急処理モバイルエージェントが前記運用管理サブシステムへと移動したらこの緊急処理モバイルエージェントを復元させ、前記運用管理サブシステムによって前記複数の緊急処理用待機エージェントの中の一つを抽出し、さらに前記運用管理サブシステムによって前記復元後の緊急処理モバイルエージェントの処理内容オブジェクトを前記抽出された緊急処理用被抽出エージェントに関連づけ、前記運用管理サブシステムからこの緊急処理用被抽出エージェントに対して処理再開指令を出すことにより前記緊急処理モバイルエージェントの処理内容オブジェクトの実行を開始し、当該事故が発生した区間の運用管理サブシステムに集結した二つ以上の前記緊急処理用被抽出モバイルエージェントあるいはそれに関連づけられた処理内容オブジェクトの間で情報交換を行うことによって事故区間を判定し、前記事故区間を当該需要地系統から分離し、この処理内容オブジェクトの実行終了後、前記緊急処理用被抽出エージェントに前記関連づけられた処理内容オブジェクトを廃棄させてから前記運用管理サブシステムに対して処理終了を通知させ、当該緊急処理用被抽出エージェントが有している前記スレッドは消去せず保持させたまま当初の待機状態に戻らせて次の処理要求が発生した段階で当該スレッドを再利用することを特徴とする移動高速化モバイルエージェントによる事故区間分離処理方法。
6. 送信側装置と受信側装置が通信網を介して相互に接続されたモバイルエージェントシステムにおいて、前記受信側装置は、待機エージェント設定部、エージェント復元部、エージェント抽出部、エージェント関連づけ部、実行開始部とを有し、前記待機エージェント設定部は、スレッドを有し、かつ処理内容オブジェクトを有しない待機エージェントを生成して待機させ、前記エージェント復元部は、前記送信側装置から受信したモバイルエージェントを復元し、前記エージェント抽出部は、待機中の前記待機エージェントを抽出し、前記エージェント関連づけ部は、前記待機エージェントと復元されたモバイルエージェントが有する処理内容オブジェクトを関連づけ、前記実行開始部は、前記処理内容オブジェクトを関連づけられた待機エージェントを起動することを特徴とするモバイルエージェント移動の高速化システム。
7. 更に前記受信側装置は、処理終了通知部、スレッド再利用部とを有し、前記処理終了通知部は、前記待機エージェントを実行後、該待機エージェントに関連づけられた前記処理内容オブジェクトを廃棄し、前記スレッド再利用部は、前記待機エージェントを生成時の状態に戻すことを特徴とする請求項６に記載のモバイルエージェント移動の高速化システム。

Images