データ処理システム及び方法
【課題】 多様な機器の中から特定の機器を迅速に検索するとともに、その機器を管理する上で必要な詳細データを取得する。
【解決手段】 装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の保護制御装置の中から保護制御機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ取得要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データをラッパーオブジェクト形式で取得するデータ取得実行手段として機能する情報モデル変換部４０とを備える。
【解決手段】 装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の保護制御装置の中から保護制御機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ取得要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データをラッパーオブジェクト形式で取得するデータ取得実行手段として機能する情報モデル変換部４０とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システム及び方法に関し、さらに詳しくは、複数の異なる種類の機器がネットワークを介して接続されている環境下において、エージェントと、このエージェントが指定した機器との間でデータの授受を行なわせるためのデータ処理システム及び方法に関する。
【背景技術】
【０００２】
現在、電力会社では、業務の効率化、保守・運用コストの低廉化を図るために、発電所、変電所、給電所などの電力系統で使用されている様々な機器を自立的な分散処理が可能なモバイルエージェントを用いて統一的に管理することが検討されている。モバイルエージェントは、処理プログラムと処理に必要なデータとが一体化し、ネットワーク内を移動するソフトウェアであり、移動先のノードにおいて所定の処理を実行する。このモバイルエージェントをネットワークを介してノード間を巡回させることにより各ノードに対応した情報の集配信が可能となる。
【０００３】
ところで、上記の電力系統では、メーカや設定内容などの属性が互いに異なる多数の機器が使用されている。属性が異なると機器について入出力されるデータ形式にも差異が生じる。このような多様な機器をモバイルエージェントを用いて遠隔管理する場合、モバイルエージェントが各機器のデータを集配信するにあたって、各機器に対応したデータ形式に変換することが必要となる。そこで、データ形式を統一することにより各機器へのデータ集配信を可能にする技術が提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１には、各機器が所有しているデータのうち、全ての機器に共通しているデータのみを取得し、それ以外の冗長データを排除するといった技術が開示されている。
【特許文献１】特開２０００−９９４７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、共通データ以外のデータを冗長データとして排除するといった方法では、機器を管理する上で必要な詳細データも失われてしまうため、個々の機器に対して十分な管理が行なえなくなってしまうといった問題が生じる。
【０００６】
そこで、本発明は、多様な機器の中から特定の機器を迅速に検索するとともに、その機器を管理する上で必要な詳細データを取得することができるデータ処理システム及び方法を提供することを目的とする。加えて、多様な機器の中から特定の機器を迅速に検索するとともに、その機器に対して的確なデータ設定を行なうことができるデータ処理システム及び方法を提供することも本発明のもう１つの目的とする。
【課題を解決するための手段】
【０００７】
かかる目的を達成するために、請求項１記載の発明にかかるデータ処理システムは、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データをラッパーオブジェクト形式で取得するデータ取得手段とを設けたことを特徴としている。
【０００８】
また、請求項３記載の発明にかかるデータ処理方法は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データをラッパオブジェクト形式でデータ取得手段によって取得するステップとを設けたことを特徴としている。
【０００９】
したがって、入出力されるデータ形式が異なる複数の機器に関するデータを各機器固有のデータとともにツリー構造を用いて体系的に管理することができるので、特定の機器に関するデータを取得する場合、そのデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができる。
【００１０】
上記目的を達成するために請求項２の発明にかかるデータ処理システムは、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうものであり、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定を行なうデータ設定実行手段とを設けたことを特徴としている。
【００１１】
また、請求項４記載の発明にかかるデータ処理方法は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうものであり、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定実行手段によってデータ設定を行なうステップとを設けたことを特徴とするデータ処理方法。
【００１２】
したがって、入出力されるデータ形式が異なる複数の機器に関するデータをツリー構造を用いて体系的に管理することが可能となり、特定の機器に対してデータ設定を行なう場合、そのデータ設定を迅速且つ的確に行なうことができる。
【発明の効果】
【００１３】
以上のように、請求項１記載のデータ処理システム、請求項３記載のデータ処理方法によれば、複数の機器に関するデータをツリー構造を用いて体系的に管理することにより、必要なデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができるので、業務の効率化、管理コストの低廉化を図ることができる。
【００１４】
また、請求項２記載のデータ処理システム、請求項４記載のデータ処理方法によれば、複数の機器に関するデータをツリー構造を用いて体系的に管理することにより、特定の機器に対してのデータ設定を迅速且つ的確に行なうことができるので、業務の効率化、管理コストの低廉化を図ることができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の構成を図面に示す最良の形態に基づいて詳細に説明する。
【００１６】
図１〜１４に本発明のデータ処理システム及び方法の一実施形態を示す。本発明のデータ処理システムである装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の保護制御装置の中から保護制御機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ取得要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データをラッパーオブジェクト形式で取得するデータ取得実行手段として機能する情報モデル変換部４０とを設けたことを特徴としている。
【００１７】
また、装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ設定要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データを用いて、このデータに対応した保護制御装置に対してデータ設定を行なうデータ設定実行手段として機能する情報モデル変換部４０及び独自アクセス部４１とを設けたことを特徴としている。
【００１８】
図１に示すように、制御システム１は、ネットワークを介して相互に接続されている電気所２、運転所３、保守所４、及びデータセンター５から構成されている。電気所２、運転所３、保守所４、及びデータセンター５はＩＰベースのＷＡＮ６を介して相互に接続されている。電気所２は、いわゆる変電所や発電所と呼ばれているものである。電気所２にはＩＰベースのＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。ＬＡＮ７には、多数の保守用ＣＰＵの他に、これらの保守用ＣＰＵや運転所３、保守所４、及びデータセンター５のノードに対して各種サービスを提供するための電気所サーバ９が接続されている。
【００１９】
電気所２に設置されている各保守用ＣＰＵには、例えば、変圧器（図示省略）を構成している部品の状態を監視するためのセンサ、電流計、電圧計などの機器（図示省略）が接続されている。例えば、保守用ＣＰＵ１０には変圧器（図示省略）で使用されているゴム部材の温度を監視するための温度センサ１１が接続されている。この温度センサ１１での検知結果は保守用ＣＰＵ１０に入力される。保守用ＣＰＵ１０は、温度センサ１１から入力された検知結果に基づいて、例えば、ゴム部材の劣化状態を判断し、その判断結果を後述するモバイルエージェントを用いて保守所４の設備保全サーバ１２などに通知する。
【００２０】
リレー１３は、ＶＣＴ１４、電流計、電圧計、変圧器、遮断器（図示省略）などの機器の状態を監視するものであり、保守用ＣＰＵ１５とリレー用ＣＰＵ１６とから構成されている。保守用ＣＰＵ１５にはリレー用ＣＰＵ１６を介して上記の機器が接続されている。ＶＣＴ１４とは、変圧器（VT：Voltage Transformer）及び変流器（CT：Current Transfer）の総称である。リレー用ＣＰＵ１６は、例えば、ＶＣＴ１４で測定された測定値が予め定められた閾値を超えたか否かを識別し、その識別結果を保守用ＣＰＵ１５に入力する。また、遮断器の場合には、遮断器が作動したか否かを識別し、その識別結果を保守用ＣＰＵ１５に入力する。
【００２１】
運転所３は、いわゆる給電所や制御所と呼ばれるものであり、電気所２に設置されている各機器の開閉状態を制御する。運転所３には電気所２と同様にＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。運転所３のＬＡＮ７に接続されている監視制御サーバ１７は、電気所２に設定されている各機器に対して開閉状態を制御しており、各機器が接続している系統の潮流状態の状態変化に応じて潮流を制御する。
【００２２】
保守所４は、いわゆる電力所と呼ばれるものであり、電気所２に設置されている各機器の保守を行なう。保守所４には電気所２や運転所３と同様にＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。保守所４のＬＡＮ７に接続されている設備保全サーバ１２は、例えば、電気所２に設置されている複数の機器の状態変化を示す情報（例えば、各機器の劣化や故障などの不具合を示す情報）を取得して、その情報を解析することにより不具合が生じている機器を選定する。つまり、電気所２に設置されている各機器の状態変化は設備保全サーバ１２によって監視されている。電気所２に設置されている機器に不具合が生じた場合には、例えば、保守所４に所属している者が電気所２に行き、その機器に対して点検や修理などを行なう。あるいは、設備保全サーバ１２が不具合の生じた機器に接続されている保守用ＣＰＵに向けてその不具合に対しての処置プログラムなどを搭載したモバイルエージェントを送る。
【００２３】
データセンター５は、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃを備えている。図２に示すように、位置管理装置５ａは、管理対象となるエージェントプラットフォーム（以下、「エージェントＰＦ」と称する）１８からの情報を基に、モバイルエージェントの位置や処理進捗状況を管理する。この位置管理装置５ａにより、モバイルエージェントの状態（例えば、移動中、処理中、停止中、アラーム状態など）の取得やモバイルエージェントの動作（例えば、使用、ロック動作など）の変更指示が可能となる。なお、図３に示す「エージェントＣＰＵ」とは、サーバ９、１２、１７、及び電気所２内の保守用ＣＰＵの総称である。
【００２４】
装置情報データベース５ｂは、モバイルエージェントが収集した情報を蓄積する。系統データベース５ｃは、系統情報（例えば、電気所２の一覧など）や電気所２で使用されているリレー１３の特性に関する情報などを蓄積する。
【００２５】
図３に示すように、保守用ＣＰＵ１５は、モバイルエージェントＡ、Ｂと、このモバイルエージェントＡ、Ｂの実行環境であるエージェントＰＦ１８と、モバイルエージェントＡの要求に応じてリレー用ＣＰＵ１６やこのリレー用ＣＰＵ１６に接続されているＶＣＴ１４、電流計、電圧計、変圧器、遮断器などの機器（以下、リレー用ＣＰＵ１６、及びこのリレー用ＣＰＵ１６に接続されている上記機器の総称を「保護制御装置」とする）からその機器に関するデータ（以下、保護制御装置に関するデータを「装置データ」と称する）を取得したり、モバイルエージェントＡの要求に応じて保護制御装置に対してデータ設定を行なう装置アクセスソフトウェア１９とから構成されている。なお、電気所２に設定されている保守用ＣＰＵ１５以外の各保守用ＣＰＵも保守用ＣＰＵ１５と同様に構成されている。また、各サーバは、モバイルエージェントとエージェントＰＦ１８を備えている。
【００２６】
リレー用ＣＰＵ１６と装置アクセスソフトウェア１９との間の信号の授受はバスあるいはイーサネット（登録商標）ケーブル２０を介して行なわれる。詳しくは後述するが、リレー用ＣＰＵ１６から装置アクセスソフトウェア１９に入力される装置データは、装置アクセスソフトウェア１９によってツリー構造を用いたラッパオブジェクト形式で体系的に管理されている。なお、本実施形態では、モバイルエージェントＡ、Ｂを、エージェントＰＦ１８で生成されたものか、あるいは保守用ＣＰＵ１５以外の保守用ＣＰＵや各種サーバからエージェントＰＦ１８に送り込まれたものであるとする。また、本実施形態では説明の便宜上モバイルエージェントＡ、Ｂを用いているが、モバイルエージェントの数は適宜に変更可能である。
【００２７】
モバイルエージェントＡ、Ｂは、プログラムとデータが一体化し、ＬＡＮ７やＷＡＮ６などのネットワーク内を移動するソフトウェアである。このモバイルエージェントＡ、Ｂは、例えば、電気所２内の複数の保守用ＣＰＵを巡回して、事故や故障などの障害に関する情報を集配信する。また、電気所２内で収集したデータをサーバ１２、１７、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃに配信する。また、サーバ１２、１７、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃから得たデータを電気所２内の各保守用ＣＰＵに配信する。また、場合によっては、データ加工などの付加的な処理も行なう。このようにモバイルエージェントＡ、Ｂが各ノード間を巡回することにより、運転所３や保守所４のサーバ１２、１７から電気所２内の保護制御装置に対して遠隔監視、遠隔設定、遠隔調整を行なうことが可能となる。
【００２８】
保守用ＣＰＵ１５のエージェントＰＦ１８は、保護制御装置の状態変化（例えば、ＶＣＴ１４での測定値が予め定められた閾値を超えたということ）、モバイルエージェントＡ、Ｂの状態変化（例えば、モバイルエージェントＡ、Ｂの少なくともいずれか１つが保守用ＣＰＵ１５以外の保守用ＣＰＵや各種サーバ、データセンター５などに移動したり、モバイルエージェントＡ、Ｂの少なくともいずれか１つがエラー処理を行なったりしたということ）をイベントとして取得し、そして、そのイベントの内容に応じてモバイルエージェントＡ、Ｂ以外に新たにモバイルエージェントを生成したり、その生成したモバイルエージェントを保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７などのエージェントＰＦ１８に転送したり、保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７から送られてきたモバイルエージェントを起動させたりするなどといった機能を有している。また、モバイルエージェントには、処理期限や優先度などが付与されており、これに基づいてエージェントＰＦ１８はモバイルエージェントの制御を行い、個々のモバイルエージェントに必要な性能や信頼性を満足するように運用者用プロファイル３６やエージェント用プロファイル３７に基づいて処理を実行する。イベントとしては、外部イベントと内部イベントとがある。外部イベントとは、保護制御装置の状態変化を示す。この状態変化は、装置アクセスソフトウェア１９によって検知され、外部イベントとして外部サービスインターフェース２０で受信される。その具体的な内容は、例えば、イベントの種別、イベントを発した装置の名称、後述するツリー構造のラッパオブジェクトとの関連付けで使用される識別子、イベントの送信希望先などとなっており、これらのデータは装置アクセスソフトウェア１９によってツリー構造４５（図８及び図９参照）を用いて管理されている。内部イベントとは、モバイルエージェントＡ、Ｂの状態変化を示し、その具体的な内容は、例えば、イベントの種別、イベントを発したモバイルエージェントに関するデータ、補足データ、イベントの送信希望先などとなっている。
【００２９】
以下、エージェントＰＦ１８の具体的な構成について説明する。エージェントＰＦ１８は、ハードディスクなどの大容量記憶手段に格納されたプログラムを実行することによって外部サービスインターフェース２０、イベント処理手段２１、位置管理部２２、リソース管理部２３、エージェント生成部２４、エージェント削除部２５、処理ロジック管理部２６、エージェント処理管理部２７、及び通信制御部２８として機能する。
【００３０】
外部サービスインターフェース２０は、装置アクセスソフトウェア１９とイベント処理手段２１とを仲介するものである。装置アクセスソフトウェア１９がモバイルエージェントＡ、Ｂに対して外部イベントを送る際には、外部サービスインターフェース２０が呼び出される。これにより、イベントがモバイルエージェントＡ、Ｂに送られる。外部サービスインターフェース２０によって受信された外部イベントは、その内容に応じて、イベント処理手段２１または保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７におけるエージェントＰＦ１８の外部サービスインターフェース２０に転送される。なお、保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバの外部サービスインターフェース２０との通信は通信制御部２８によって実現される。具体的には、外部サービスインターフェース２０が外部イベントを受け取り、それを保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバの外部サービスインターフェース２０に転送する場合、図４に示す通信プロトコルを用いて転送処理を実行する。
【００３１】
イベント処理手段２１は、イベントの内容に応じてイベントの転送処理を行うものであり、外部イベント受信部２９、内部イベント受信部３０、フィルター部３１、運用者用ルーチング部３２、エージェント用ルーチング部３３、記憶部３４、及び履歴作成部３５から構成されている。
【００３２】
外部イベント受信部２９は、外部サービスインターフェース２０から転送された外部イベントを受信し、それをフィルター部３１に転送する。内部イベント受信部３０は、内部イベントを受信し、それをフィルター部３１に転送する。このように外部イベント受信部２９及び内部イベント受信部３０は、モバイルエージェントＡ、Ｂと保守用ＣＰＵ１５によって監視されている保護制御装置との少なくともいずれか一方からのイベントを受信する状態変化データ受信手段として機能する。
【００３３】
フィルター部３１は、内部イベント受信部３０または外部イベント受信部２９からイベントが入力されたことを契機に、記憶部３４に予め格納されている運用者用プロファイル３６及びエージェント用プロファイル３７を読み出す。これらのプロファイルにはイベントの種類に対応した転送可否条件３６ａ、３７ａが記載されており、フィルター部３１は、その転送可否条件３６ａ、３７ａに基づいて転送処理の必要性を判断する。そして、転送が必要であると判断した場合、そのイベントを運用者用ルーチング部３２に転送する。転送が必要でないと判断した場合、そのイベントを廃棄する。なお、転送可否条件とは、例えば、イベントの種別、イベントの送信元、イベントの送信先エージェントなどのことを示し、フィルター部３１は、これらの条件を満足したイベントのみを運用者用ルーチング部３２に転送する。
【００３４】
このように記憶部３４は、外部イベント受信部２９や内部イベント受信部３０で受信したイベントの転送可否条件３６ａ、３７ａを記憶した転送可否条件記憶手段として機能する。また、フィルター部３１は、内部イベント受信部３０や外部イベント受信部２９からイベントが入力されたことを契機に、記憶部３４から転送可否条件３６ａ、３７ａを読み出す転送可否条件読み出し手段として機能する。また、フィルター部３１は、その読み出された転送可否条件３６ａ、３７ａに基づいてイベントの転送の可否を判定する転送可否判定手段として機能する。
【００３５】
運用者用ルーチング部３２は、フィルター部３１からイベントが入力されたことを契機に、記憶部３４の運用者用プロファイル３６を読み出す。この運用者用プロファイル３６には、イベントの種類ごとの転送先が示された転送先テーブル３６ｂが記載されており、運用者用ルーチング部３２は、その転送先テーブル３６ｂを参照してフィルター部３１から入力されたイベントをエージェント用ルーチング部３３に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントを廃棄し、転送の必要があると判断した場合、次に、運用者用プロファイル３６の転送先テーブル３６ｂに基づいてイベントを履歴作成部３５に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントをそのままエージェント用ルーチング部３３に転送し、転送の必要があると判断した場合（障害履歴を作成してイベントを履歴情報として保存する必要がある場合）、イベントを複製して一方のイベントをエージェント用ルーチング部３３に、他方のイベントを履歴作成部３５に転送する。運用者用プロファイル３６とは、例えば、運転所３、保守所４、電気所２、データセンター５などの運用者がイベントごとの処理の仕方を記録したデータファイルのことであり、これはキーボード等の入力装置によって作成される。このように運用者用ルーチング部３２では、運用者の要求に基づいてイベントが処理される。なお、本実施形態では、転送先として履歴作成部３５とエージェント用ルーチング部３３との２つを設定したが、転送先は上記の２つとは限らず転送先が３つ以上ある場合も考えられる。この場合、イベントは転送先の数だけ複製される。
【００３６】
以上のように、記憶部３４は、イベントの種類に対応した転送先が保持されている転送先テーブル３６ｂを記憶した転送先テーブル記憶手段として機能する。また、運用者用ルーチング部３２は、フィルター部３１で転送許可の判定を受けたイベントが入力されたことを契機に、記憶部３４から転送先テーブル３６ｂを読み出す転送先テーブル読み出し手段として機能する。また、運用者用ルーチング部３２は、その読み出された転送先テーブル３６ｂに基づいてイベントの転送先を決定する転送先決定手段として機能する。また、運用者用ルーチング部３２は、その決定された転送先にイベントを転送する状態変化データ転送手段として機能する。
【００３７】
履歴作成部３５は、モバイルエージェントＡ、Ｂの振る舞いやリレー用ＣＰＵ１６からの信号などによりイベントが発生したときにその日時やイベントを発した箇所の名称やその詳細情報を自身のメモリ（図示省略）に記録し、その記録を入力装置からの入力操作に応答して液晶パネル等の表示器（図示省略）に表示する。
【００３８】
エージェント用ルーチング部３３は、運用者用ルーチング部３２からイベントが入力されたことを契機に、記憶部３４のエージェント用プロファイル３７を読み出す。このエージェント用プロファイル３７には、イベントの種類ごとの転送先が示された転送先テーブル３７ｂが記載されており、エージェント用ルーチング部３３は、その転送先テーブル３７ｂを参照して運用者用ルーチング部３２から入力されたイベントをモバイルエージェントＢに転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントを廃棄し、転送の必要があると判断した場合、次に、エージェント用プロファイル３７に基づいてイベントを履歴作成部３５に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントをそのままモバイルエージェントＢに転送し、転送の必要があると判断した場合、イベントを複製して一方のイベントをモバイルエージェントＢに、他方のイベントを履歴作成部３５に転送する。エージェント用プロファイル３７とは、保守用ＣＰＵやサーバなどでエージェントを使用している者（以下、「エージェント使用者」と称する）がイベントごとの処理の仕方を記録したデータファイルのことであり、これはキーボード等の入力装置によって作成される。このようにエージェント用ルーチング部３３では、エージェント使用者の要求に基づいてイベントが処理される。なお、本実施形態では、転送先として履歴作成部３５とモバイルエージェントＢとの２つを設定したが、転送先は上記の２つとは限らず転送先が３つ以上ある場合も考えられる。この場合、イベントは転送先の数だけ複製される。
【００３９】
以上のように、記憶部３４は、イベントの種類に対応した転送先が保持されている転送先テーブル３７ｂを記憶した転送先テーブル記憶手段として機能する。また、エージェント用ルーチング部３３は、フィルター部３１で転送許可の判定を受けたイベントが入力されたことを契機に、記憶部３４から転送先テーブル３７ｂを読み出す転送先テーブル読み出し手段として機能する。また、エージェント用ルーチング部３３は、その読み出された転送先テーブル３７ｂに基づいてイベントの転送先を決定する転送先決定手段として機能する。また、エージェント用ルーチング部３３は、その決定された転送先にイベントを転送する状態変化データ転送手段として機能する。
【００４０】
エージェント用ルーチング３３がモバイルエージェントＢにイベントを転送した場合、そのモバイルエージェントＢは、エージェント用ルーチング３３から転送されたイベントに対応した処理プログラムに基づいた処理を実行する。例えば、モバイルエージェントＢは、エージェント用ルーチング３３からイベントが入力されたことを契機に、保守用ＣＰＵ１５以外の保守用ＣＰＵへの移動を依頼することを示す移動依頼信号を通信制御部２８に入力する。この他にも、エージェント用ルーチング３３から入力されたイベントの内容によってはリソース管理部２３、エージェント生成部２４、エージェント削除部２５などにイベントを転送するといった処理も実行する。このようにエージェント用ルーチング３３からイベントが入力されたときのモバイルエージェントＢの振る舞いはモバイルエージェントＢに設定されている処理プログラムの内容によって決定する。
【００４１】
エージェント生成部２４は、モバイルエージェントＡ、Ｂの少なくともいずれか１つが新たなモバイルエージェントを生成する必要があると判断した場合に、その要求に基づいてモバイルエージェントの生成を行なう。エージェント削除部２５は、モバイルエージェントＡ、Ｂの少なくともいずれか１つが既存のエージェントを削除する必要があると判断した場合に、その要求に基づいてモバイルエージェントの削除を行なう。
【００４２】
処理ロジック管理部２６は、エージェント生成部２４によってモバイルエージェントが生成された場合、あるいは他の保守用ＣＰＵやサーバなどから通信制御部２８を介してモバイルエージェントがエージェントＰＦ１８内に送り込まれてきた場合、そのモバイルエージェントに対して予め定められた処理ロジックを実行させる。
【００４３】
エージェント処理管理部２７は、処理ロジック管理部２６を制御しており、エージェントＰＦ１８上のモバイルエージェントＡ、Ｂの処理の管理を行なう。つまり、モバイルエージェントの状態変化を管理し、その状態変化を内部イベントとして内部イベント受信部３０に入力する。また、モバイルエージェントの起動や演算処理に失敗した場合にもそれを内部イベントとして内部イベント受信部３０に入力する。
【００４４】
位置管理部２２は、モバイルエージェントＡ、Ｂが移動した場合に、その移動を開始した時間や移動先などを管理するものである。具体的には、管理対象となるエージェントＰＦ１８からの情報を基に、モバイルエージェントＡ、Ｂの位置や処理進捗状況を管理する。この位置管理部２２によりモバイルエージェントＡ、Ｂの動作状況（移動中・処理中・停止中・アラーム等）の取得や、モバイルエージェントＡ、Ｂの動作（使用・ロック）の変更指示を可能とする。例えば、モバイルエージェントＡが移動した場合に、その移動を開始した時間や移動先などを自身のメモリ（図示省略）に記録するとともに、その記録内容を表示器（図示省略）に表示する。
【００４５】
リソース管理部２３は、エージェントＰＦ１８に動作環境を提供している保守用ＣＰＵ１５のメモリ量や負荷、エージェントＰＦ１８上のモバイルエージェントの数を監視しており、リソース不足を防止するための処理を行なう。具体的な処理としては、メモリ量や負荷が上限値を超過した場合には、ガーベッジコレクションを実行する。また、他のエージェントＰＦ１８からのモバイルエージェントの転送を拒否するように通信制御部２８を制御する。さらに、リソース不足が発生した場合、それを内部イベントとして内部イベント受信部３０に入力する。イベント処理手段２１は、リソース不足を示す内部イベントが入力されたことを契機に、モバイルエージェントＡ、Ｂの停止、削除、エージェントＰＦ１８の再起動などの処理を実行する。
【００４６】
通信制御部２８は、保守用ＣＰＵ１５上のエージェントＰＦ１８と保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ上のエージェントＰＦ１８（例えば、保守用ＣＰＵ１０のエージェントＰＦ１８やサーバ９のエージェントＰＦ１８）との間の通信、具体的には、モバイルエージェントＡ、Ｂの他のエージェントＰＦ１８への移動（図５参照）、エージェントＰＦ１８内のモバイルエージェントと他のエージェントＰＦ１８のモバイルエージェントとの通信（図６参照）を実現させるためのインターフェースとして機能する。このようなエージェントＰＦ１８間の通信は、図４に示す通信プロトコルによって実現される。また、通信制御部２８は、エージェントＰＦ１８内のモバイルエージェント間での通信を実現させるためのインターフェースとしても機能する。さらに、イベントを転送する際のインターフェース（例えば、エージェントＰＦ１８内のモバイルエージェントの振る舞いを内部イベントとして内部イベント受信部３０に入力するためのインターフェース）としても機能する。
【００４７】
図５に示すように、モバイルエージェントを他のエージェントＰＦ１８に移動させる場合、エージェントＰＦ１８の通信制御部２８は、モバイルエージェントから入力された移動依頼信号に応答してモバイルエージェントの処理動作を停止させ、モバイルエージェントが指定したエージェントＰＦ１８にモバイルエージェントを移動させる。ネットワークの障害などによりモバイルエージェントの移動が失敗した場合には、再送を行なう。そして、その移動が完了すると、モバイルエージェントは移動先のエージェントＰＦ１８上で起動する。また、通信制御部２８は、移動が成功したか失敗したかを示す情報を内部イベントとして内部イベント受信部３０に入力する。
【００４８】
図６に示すように、エージェントＰＦ１８内のモバイルエージェントと他のエージェントＰＦ１８のモバイルエージェントとで通信を行なう場合、通信制御部２８は、タイムアウト機能、リトライ機能を提供する。タイムアウト時間およびリトライ回数は、プロファイルで指定する。通信方法としては、個別に通信する方法、つまり、１対１で通信する方法とマルチキャストで通信する方法をサポートする。また、通信方法としては、「応答ありの同期通信」「応答ありの非同期通信」「応答なしの片方向通信」の３種類をサポートする。エージェント間通信で授受する情報としては、文字列情報や装置アクセスソフトウェア１９から得たオブジェクトなどがある。授受する情報の形式は、シリアライザブルとする。メッセージの送信・応答結果の受信については、オブジェクトクラスＰｒｏｘｙを用いる。この方法により、外部から直接モバイルエージェントを操作することを防止する。
【００４９】
以上のように、通信制御部２８は、保守用ＣＰＵ１５上のモバイルエージェントから入力された移動依頼信号に応答してそのモバイルエージェントを保守用ＣＰＵ以外の保守用ＣＰＵやサーバなどのノードに移動させる移動制御手段として機能する。
【００５０】
図７に示すように、装置アクセスソフトウェア１９は、モバイルエージェントＡからの要求に応じてリレー用ＣＰＵ１６やそのリレー用ＣＰＵ１６に接続されているＶＣＴ１４などの機器に関するデータを取得する。また、モバイルエージェントＡからの要求に応じてリレー用ＣＰＵ１６やそのリレー用ＣＰＵ１６に接続されているＶＣＴ１４などの機器に対してデータ設定を行なう。さらに、外部イベントをエージェントＰＦ１８に送るといった機能も有している。保護制御装置に関する装置データは、ハードディスクなどの記憶手段に記憶されており、後述するデータ収容部４４によりオブジェクトとしてツリー構造を用いて体系的に管理されている。
【００５１】
装置アクセスソフトウェア１９は、装置アクセス機能３８、イベント監視部３９、情報モデル変換部４０、及び独自アクセス部４１から構成されている。装置アクセス機能３８は、エージェントＡやエージェントＰＦ１８とのインタフェースとして機能を有する装置アクセスＡＰＩ４２（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）４２と、モバイルエージェントＡあるいはイベント監視部３９から入力されるデータ取得の要求を示すデータ取得要求信号またはデータ設定の要求を示すデータ設定要求信号に応じてツリー構造の中からオブジェクト群（図８参照）を指定する機能を有するツリー検索部４３と、ツリー検索部４３で指定したオブジェクト群をさらに絞り込む機能を有するデータ収容部４４とを備えている。
【００５２】
モバイルエージェントＡと装置アクセスソフトウェア１９との間でのデータの授受は、装置アクセスＡＰＩ４２を介して行なわれる。装置アクセスＡＰＩ４２は、モバイルエージェントＡからのデータ取得要求信号またはデータ設定要求信号を受信してそれを装置アクセスソフトウェア１９に送るとともに、モバイルエージェントＡへその要求信号に対しての結果を送る。また、装置アクセスＡＰＩ４２は、装置アクセスソフトウェア１９からの外部イベントを受信してエージェントＰＦ１８に送る。なお、上記の「データ取得」とは、モバイルエージェントＡが指示した保護制御装置に関する装置データの取得を示し、上記の「データ設定」とは、モバイルエージェントＡが指示した保護制御装置に対して行なうデータ設定を示す。
【００５３】
データ収容部４４は、装置データをメモリ４４ａ上でツリー構造４５を用いてラッパオブジェクト形式で保持する。なお、ツリー構造を用いて管理されている装置データをオブジェクトと称する。
【００５４】
データ収容部４４は、例えば、図８に示すように、ＸＭＬのＤＢ（データベース）やＪａｖａ（登録商標）形式でデータを入出力するソフトウェアを備えており、ツリー構造を構成している多数のオブジェクトをＸＭＬに属するオブジェクトとＪａｖａ形式に属するオブジェクトとに分割した状態で管理している。
【００５５】
ツリー検索部４３は、モバイルエージェントＡから装置アクセスＡＰＩ４２を介して入力されたデータ取得要求信号またはデータ設定要求信号に含まれるスコープ情報に基づいてツリー構造４５のオブジェクトを指定する。スコープ情報とは、ツリー構造４５上で指定したオブジェクトを起点として、例えば、その起点のオブジェクトのみを指定したり、第１階層（起点の１つ下の階層）のオブジェクトを指定したり、起点以下の全ての階層のオブジェクトを指定したり、起点から数えて第Ｎ番目の階層のオブジェクトを指定したり、または、第Ｎ番目の階層までのオブジェクトを指定したりすることを示す情報のことである。
【００５６】
データ収容部４４は、モバイルエージェントＡから装置アクセスＡＰＩ４２、ツリー検索部４３を介して入力されたデータ取得要求信号またはデータ設定要求信号に含まれるフィルター情報に基づいてツリー検索部４３で選択されたオブジェクト群をさらに絞り込む。フィルター情報とは、スコープ情報に基づいて選択されたオブジェクト群に対してさらに指定した条件を満足するオブジェクトだけに絞り込むための情報であり、具体的には、指定した属性値の大小、属性値の一致などを示す情報である。なお、独自アクセス部４１がデータ収容部４４と同様のフィルター情報による絞り込み機能を有している場合、モバイルエージェントＡからのフィルター情報は独自アクセス部４１に送られて、独自アクセス部４１でフィルター情報による絞り込みが行なわれる。
【００５７】
このようにツリー検索部４３及びデータ収容部４４の検索機能を用いることにより容易にモバイルエージェントＡが指定するオブジェクトを検索することができる。例えば、図８に示すように、スコープ情報がＸＭＬ形式のオブジェクトを全て指定するといったものであった場合には、ツリー検索部４３によってツリー構造４５の中のＸＭＬのＤＢ、つまり、ＸＭＬ形式のオブジェクト群が全て選択される。また、スコープ情報がＪａｖａ形式のラッパオブジェクトを全て指定するといったものであった場合には、ツリー構造４５の中のＪａｖａ形式データ入出力ソフトウェア、つまり、Ｊａｖａ形式のオブジェクト群が選択される。そして、スコープ情報によりＸＭＬのＤＢが選択された場合、データ収容部４４は、ＸＭＬのソフトウェア上でフィルター情報に基づいてオブジェクトをさらに絞り込む。また、スコープ情報によりＪａｖａ形式データ入出力ソフトウェアが選択された場合、データ収容部４４は、Ｊａｖａ形式データ入出力ソフトウェア上でフィルター情報に基づいてオブジェクトをさらに絞り込む（図９参照）。
【００５８】
データ収容部４４は、上記のようにして絞り込まれたオブジェクトを情報モデル変換部４０に入力するとともに、モバイルエージェントＡから入力されたデータ取得要求信号またはデータ設定要求信号を情報モデル変換部４０に転送する。
【００５９】
情報モデル変換部４０のメモリ４０ａには、独自アクセス部４１でのデータ入出力で使用されるシーケンシャルファイル４６とツリー構造４５上の各オブジェクトとを対応付けた対照テーブル４７が格納されている（図１０参照）。独自アクセス部４１で使用されるシーケンシャルファイル４６は、複数のデータ記録領域に区切られており、予め各領域ごとに識別子が付されている。他方、ツリー構造４５の各オブジェクトにも識別子が付されており、このオブジェクトの識別子とシーケンシャルファイル４６の各領域ごとの識別子とは対照テーブル４７において１対１で対応付けられている。
【００６０】
情報モデル変換部４０は、オブジェクトの識別子とシーケンシャルファイル４６の各データ記録領域ごとに付されている識別子との対応関係が記録されている対照テーブル４７を参照しながらシーケンシャルファイル４６に記録されている各データをツリー構造４５のオブジェクトに変換したり、逆に、ツリー構造４５のオブジェクトをシーケンシャルファイル４６に変換したりする。
【００６１】
独自アクセス部４１は、ベンダ固有のインターフェースであり、ネットワークに接続されている複数の保守用ＣＰＵの中には保守用ＣＰＵ１５の独自アクセス部４１とはベンダの異なる独自アクセス部４１を使用しているものも存在している。独自アクセス部４１は、データ収容部４４で指定されたオブジェクトの内容に基づいて保護制御装置から装置データの読み出し、または、保護制御装置に対して装置データの書き込みを行なう。
【００６２】
モバイルエージェントＡからのデータ取得要求信号に対応したオブジェクトがデータ収容部４４で選択され、そのオブジェクトに対応した装置データを取得する場合で、例えば、データ収容部４４で選択されたオブジェクトが、保護制御装置の名称、データ種別、時刻、型形式やメーカ名などといったものであった場合、情報モデル変換部４０は、これらのオブジェクトを対照テーブル４７に基づいてシーケンシャルファイル４６の各データ記録領域に振り分ける。
【００６３】
以下、その振り分け方法を具体的に説明する。シーケンシャルファイル４６の各データ記録領域には識別子Ａ〜Ｄが付されており、例えば、識別子Ａのデータ記録領域には、保護制御装置の名称（例えば、ＶＣＴ１４など）に関するデータが記録され、識別子Ｂのデータ記録領域にはデータ種別（例えば、ＸＭＬ形式なのか、それともＪａｖａ形式なのかを識別するもの）に関するデータが記録され、識別子Ｃのデータ記録領域には時刻（例えば、保護制御装置が起動した時刻など）に関するデータが記録され、識別子Ｄのデータ記録領域には型形式やメーカ名などに関するデータが記録されるように構成されている。他方、ツリー構造４５の各オブジェクトにも識別子ａ〜ｄが付されており、識別子ａのオブジェクトは保護制御装置の名称を示し、識別子ｂのオブジェクトはデータ種別を示し、識別子ｃのオブジェクトは時刻を示し、識別子ｄのオブジェクトは型形式やメーカ名などを示す。情報モデル変換部４０は、対照テーブル４７を参照しながらａ〜ｄのオブジェクトをシーケンシャルファイル４６のＡ〜Ｄの領域に振り分ける。そして、独自アクセス部４１は、そのシーケンシャルファイル４６に従って保護制御装置から装置データを取得し、それをシーケンシャルファイル４６に記録する。情報モデル変換部４０は、独自アクセス部４１のシーケンシャルファイル４６に記録されている装置データを対照テーブル４７を用いてツリー構造４５のオブジェクトに振り分ける。そして、情報モデル変換部４０は、それをラッパオブジェクト形式で、データ収容部４４、ツリー検索部４３、装置アクセスＡＰＩ４２を介してモバイルエージェントＡに送る。
【００６４】
ツリー検索部４３及びデータ収容部４４がモバイルエージェントＡから入力されたデータ設定要求信号に基づいてオブジェクトを指定した場合、その指定されたオブジェクトは情報モデル変換部４０によってシーケンシャルファイル４６に振り分けられる。つまり、情報モデル変換部４０は、対照テーブル４７に基づいてデータ収容部４４によって選択された保護制御装置やその保護制御装置に対して付与するデータ設定値などを示すオブジェクトを独自アクセス部４１で読み取り可能なシーケンシャルファイル４６に変換する。そして、独自アクセス部４１は、そのシーケンシャルファイル４６に基づいて所定の保護制御装置に対してデータ設定を行なう。独自アクセス部４１はデータ設定が成功したか否かを示す設定実行結果信号を装置アクセスＡＰＩ４２を介してモバイルエージェントＡに入力する。
【００６５】
イベント監視部３９は、外部イベントをエージェントＰＦ１８に送るために予め定められているイベント監視プロパティ情報に従って所定のデータを監視するものであり、タイマー機能を用いて定期的にツリー検索部４３に対してデータ取得要求信号を入力する。イベント監視プロパティには、保護制御装置の状態変化が外部イベントとしてエージェントＰＦ１８に通知するべきものであるか否かを判断するためのイベント通知条件（例えば、保護制御装置のある部位の温度が閾値を超えるという条件）が含まれており、イベント監視部３９は、保護制御装置の状態変化がイベント通知条件を満足したか否かを判断し、条件を満足した場合にはエージェントＰＦ１８に通知を行なう。なお、上記の「所定のデータ」とは、例えば、予め定められた保護制御装置に関するデータのことを示す。
【００６６】
次に、イベントの処理の流れについて図１１のフローチャートを参照しながら説明する。エージェントＰＦ１８を起動させると、エージェントＰＦ１８はイベント発生を監視する（Ｓ１）。内部イベント受信部３０や外部イベント受信部２９は、イベントを受信すると、そのイベントをフィルター部３１に転送する（Ｓ２）。フィルター部３１は、内部イベント受信部３０や外部イベント受信部２９から送られたイベントを転送可否条件３６ａ、３７ａを用いて運用者用ルーチング部３２に転送するか否かを判断するためのフィルタリングを行ない、そこで転送する必要があると判断されたイベントを運用者用ルーチング部３２に転送する（Ｓ３）。フィルター部３１で転送する必要がないと判断されたイベントはフィルター部３１にて廃棄される（Ｓ４）。運用者用ルーチング部３２は、フィルター部３１から送られてきたイベントを転送先テーブル３６ｂに基づいてエージェント用ルーチング部３３に転送する必要があるか否かを判断する（Ｓ５）。ここで転送する必要がないと判断されたイベントは廃棄される（Ｓ６）。運用者用ルーチング部３２は、イベントをエージェント用ルーチング部３３に転送する必要があると判断した場合、次に、そのイベントを履歴作成部３５に転送する必要があるか否かを転送先テーブル３６ｂに基づいて判断し、「転送の必要なし」と判断した場合、イベントをそのままエージェント用ルーチング部３３に転送する（Ｓ７）。履歴作成部３５への「転送の必要が有り」と判断した場合、イベントを複製してそれらを履歴作成部３５とエージェント用ルーチング部３３に転送する（Ｓ８）。エージェント用ルーチング部３３は、転送先テーブル３７ｂに基づいて運用者用ルーチング部３２から送られてきたイベントをモバイルエージェントＢに転送する必要があるか否かを判断する（Ｓ９）。ここで転送する必要がないと判断されたイベントは廃棄される（Ｓ１０）。エージェント用ルーチング部３３は、イベントをモバイルエージェントＢに転送する必要があると判断した場合、次に、そのイベントを履歴作成部３５に転送する必要があるか否かを転送先テーブル３７ｂに基づいて判断し、「転送の必要なし」と判断した場合、イベントをそのままモバイルエージェントＢに転送する（Ｓ１１）。履歴作成部３５への「転送の必要が有り」と判断した場合、イベントを複製してそれらを履歴作成部３５とモバイルエージェントＢに転送する（Ｓ１２）。モバイルエージェントＢは、エージェント用ルーチング部３３からのイベントを内部イベントであるか否かを判断し（Ｓ１３）、それが内部イベントであればモバイルエージェントＢに対してそのイベントに対応して振る舞いを実行させ（Ｓ１４）、内部イベントでなければ、つまり、外部イベントであった場合、それを廃棄する（Ｓ１５）。Ｓ１〜Ｓ１５までの処理は、エージェントＰＦ１８の動作が停止するまで繰り返して実行される（Ｓ１６）。
【００６７】
次に、装置アクセスソフトウェア１９を用いてデータ取得を行なう際の処理の流れについて図１２を参照しながら説明する。モバイルエージェントＡが装置アクセス機能３８に対してデータ取得要求信号を入力すると、その信号をツリー検索部４３が受信する（Ｓ１０１）。ツリー検索部４３は、データ取得要求信号に含まれるスコープ情報からデータ収容部４４を指定する（Ｓ１０２）。データ収容部４４は、データ取得要求信号に含まれるフィルター情報を用いてスコープ情報で指定したオブジェクト群からさらにオブジェクトを絞り込む（Ｓ１０３）。情報モデル変換部４０は、対照テーブル４７を用いてデータ収容部４４で絞り込まれたオブジェクトを独自アクセス部４１で使用可能なデータ形式に変換する（Ｓ１０４）。独自アクセス部４１は、データ取得要求信号によって指定された保護制御装置の装置データをその装置固有のデータ形式で取得する（Ｓ１０５）。情報モデル変換部４０は、対照テーブルを用いて独自アクセス部４１で取得した装置データを装置アクセスソフトウェア１９で使用可能なデータ形式に変換し（Ｓ１０６）、その変換した装置データをオブジェクトに収容する（Ｓ１０７）。情報モデル変換部４０は、そのオブジェクトに収容した装置データをラッパーオブジェクト形式で装置アクセスＡＰＩ４２を介してモバイルエージェントＡに送る（Ｓ１０８）。
【００６８】
次に、モバイルエージェントＡが指定した機器に対して装置アクセスソフトウェア１９を用いてデータ設定を行なう際の処理の流れについて図１３を参照しながら説明する。モバイルエージェントＡが装置アクセス機能３８に対してデータ設定要求信号を入力すると、その信号をツリー検索部４３が受信する（Ｓ２０１）。ツリー検索部４３は、データ設定要求信号に含まれるスコープ情報からデータ収容部４４を指定する（Ｓ２０２）。データ収容部４４は、データ設定要求信号に含まれるフィルター情報を用いてオブジェクト、すなわち、データ設定範囲を絞り込む（Ｓ２０３）。そして、情報モデル変換部４０は、データ収容部４４で絞り込まれたオブジェクトからモバイルエージェントＡが指定した設定値を抽出し（Ｓ２０４）、その設定値を対照テーブル（図１０参照）を用いて独自アクセス部４１で使用可能なデータ形式に変換して、独自アクセス部４１に送る（Ｓ２０５）。独自アクセス部４１は、モバイルエージェントＡが指定した保護制御装置に対してデータ設定を行なう（Ｓ２０６）。そして、データ設定が終了すると、独自アクセス部４１は、装置アクセスＡＰＩ４２を介してモバイルエージェントＡに設定実行結果を送る（Ｓ２０７）。
【００６９】
次に、イベント監視部３９による処理の流れについて図１４を参照しながら説明する。イベント監視部３９は、自身のタイマー機能が予め定められた監視時刻を計時したことを契機に（Ｓ３０１）、図１２のフローチャートで示す処理に従って、イベント監視プロパティで指定した監視対象から装置データを取得する（Ｓ３０２）。イベント監視部３９は、タイマー機能が予め定められた監視時刻を計時しない場合には、タイマー機能が監視時刻を計時するまで装置データを取得する処理を実行せずに待機する（Ｓ３０３）。取得した装置データがイベント通知条件を満足した場合（Ｓ３０４）、その旨をエージェントＰＦ１８に通知する（Ｓ３０５）。この通知が終了した場合（Ｓ３０５）、あるいは取得した装置データがイベント通知条件を満足しなかった場合（Ｓ３０４）、イベント監視部３９は、イベント監視プロパティで予め定められている全ての監視対象に対してのデータ取得が終了しているか否かを判断し、予め定められている全ての監視対象に対してのデータ取得が終了していなければ、イベント監視プロパティで定められている全ての監視対象に対してのデータ取得が終了するまで上記の処理を繰り返し行なう（Ｓ３０６）。予め定められている全ての監視対象に対してのデータ取得が終了した後、装置アクセスソフトウェア１９の動作が終了するまでＳ３０１〜Ｓ３０６までの処理が繰り返して実行される（Ｓ３０７）。
【００７０】
以上のように、本発明のデータ処理システムである装置アクセスソフトウェア１９によれば、入出力されるデータ形式が異なる複数の機器に関するデータを各機器固有のデータとともにツリー構造４５を用いて体系的に管理することができるので、特定の機器に関するデータを取得する場合、そのデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができる。また、入出力されるデータ形式が異なる複数の機器に関するデータをツリー構造４５を用いて体系的に管理することが可能となり、特定の機器に対してデータ設定を行なう場合、そのデータ設定を迅速且つ的確に行なうことができる。
【００７１】
また、制御システム１は、運用者やエージェント使用者によって予め設定されたプロファイルに従ってエージェントＰＦ１８上で処理を実行するようにしたので、広域にわたって複数のノードやそれらのノードに接続されている機器を統一的に管理することが可能となり、遠隔管理の高信頼化を図ることができる。また、保護制御装置で発生した不具合を遠隔地にてリアルタイムで把握することができるので、その不具合に対して迅速且つ的確な処置を施すことが可能となる。
【００７２】
なお、上述の形態は本発明の好適な形態の一例ではあるがこれに限定されるものではなく本発明の要旨を逸脱しない範囲において種々変形実施可能である。例えば上記実施形態では、運用者用ルーチング部３２におけるイベントの転送先をエージェント用ルーチング部３３及び履歴作成部３５とし、エージェント用ルーチング部３３におけるイベントの転送先を履歴作成部３５及びモバイルエージェントＢとしたが、これに限ることなく、転送先をエージェント生成部２４やエージェント削除部２５にしても良い。これは転送先テーブル３６ｂや転送先テーブル３７ｂの内容を書き換えることによって実現される。
【実施例】
【００７３】
以下に本発明のモバイルエージェントシステムを電力送電系統における保護・制御システムの遠隔運用保守などに適用する例について説明する。
【００７４】
自律的な分散処理が可能なモバイルエージェント技術やIP（Internet Protocol）ネットワーク技術は、広域での情報集配信の自動化や低コスト化に適していると考えられる。しかし、現状のモバイルエージェント技術はベンダ（メーカーあるいは販売会社）固有の方式であり、ベンダー間での相互接続性確保や仕様共通化は実現されていない。このため、マルチベンダーによって運用され尚且つ広域において多様な機器に対応せざるを得ない変電所の保護機能の運用保守を主な対象とする送電系統の保護・制御システムにおいては、モバイルエージェント技術を用いた保護リレー装置などの遠隔運用保守のためのシステムを構築することができなかった。このことは、系統監視制御機能においても同様である。
【００７５】
送電系統の保護・制御システムは、例えば図１に示すように、多数の変電所等の電気所２とこれらを監視して運転を制御する運転所３及び電気所２の保守を行う保守所４並びに位置管理サーバ５ａ、装置情報ＤＢ５ｂ、系統ＤＢ５ｃなどがワイドエリアネットワーク（ＷＡＮ）６で相互に接続されている。電気所２では、電気所サーバ９あるいは保守用CPU１０，１５に保護リレー装置１３・センサ１１等の装置が接続されている。また、系統DB５ｃは、系統構成や保護リレーに関する情報を蓄積する。装置情報DB５ｂは、エージェントが収集した情報を蓄積する。さらに、保守所４と電気所２のCPUは、IPベースのWAN６を介して接続される。電気所構内の保守用CPU１０，１５は、IPベースのLAN７を介して接続される。そのため、システムはIPネットワークのQoS・信頼性にかかわる機能と連携することで、通信の遅延や可用性などの性能を担保することができる。さらに、運転所３の監視制御サーバ１７及び保守所４の保守サーバ１２とＷＡＮ６を介して接続されている電気所・変電所２の保守用ＣＰＵ（ネットワーク端末）１０，１５には保護制御装置としての保護リレー装置（ＲｙＣＰＵ）１６が接続されている。そして、保守用ＣＰＵ１０，１５には、「エージェントPF１８」、「装置アクセスソフトウェア１９」および「エージェント」の３要素が保守用CPU１５上に主記憶装置（図示省略）に格納されているソフトウェアによって構成されている。また、保護制御装置１６を接続していない運転所３の監視制御サーバ１７及び保守所４の保守サーバ１２のCPUには、「エージェントPF１８」と「エージェント」の２要素がCPU上に構成されている。本実施例のエージェントシステムは、この3要素をソフトウェアの構成要素とするものであり、各要素は、保護制御装置とIP網との仲介役となる保守用CPU（保守用CPU）やサーバ等の上で動作する。保護リレー装置と接続する場合、保守用CPU１５は、保護機能を実行するCPU(RyCPU)１６と接続される。ここでは、保守用CPUやサーバなどエージェントが動作するCPUを総称して、「エージェントCPU」と呼ぶこととする。なお、本明細書では、基板やサーバ、PCなどの情報処理装置をCPUと呼ぶものとしている。
【００７６】
ここで、エージェントPF１８は、エージェントを動作させるためのミドルウェアであり、エージェントの生成、移動、状態管理などエージェント実行に必要な機能をエージェントやその利用者に提供するものである。また、装置アクセスソフトウェア１９は、エージェントが保護制御装置１６に対して情報取得設定する際に、そのインタフェースとなるソフトウェアである。また、エージェントは、処理プログラムと処理に必要なデータを一体化したソフトウェアである『オブジェクト』を拡張したソフトウェア」であり、通信網内を装置から装置へと移動して、移動先の装置で、自律的に必要とするデータを自律的に収集やその他の適切な処理の選択、実施が可能である。ここで、エージェントの移動は、プログラムとデータが一体化した処理であることから、ソフトウェアのインストールや更新の手段としても利用できる。このような使い方の移動の後、そのエージェントは特定の装置に常駐しても良い。
【００７７】
本実施例のエージェント技術を用いた遠隔運用保守システム（以下、エージェントシステム）におけるエージェントは、電気所や保守所４などを巡回して情報集配信するだけではなく、要求によってはデータ加工等の付加的な処理を行うことが可能である。これら処理の組み合わせによって、エージェントシステムは、電気所機器の遠隔監視、電気所機器の遠隔設定（遠隔整定など）、電気所側での自動処理（自動監視など）、保守や運用担当者との対話などの機能を提供する。
【００７８】
このエージェント技術を用いて保護リレーなどの装置情報を収集・配信・処理するためには、図１６に示すエージェントシステムモデルのように、「エージェントPF１８」、「装置アクセスソフトウェア１９」および「エージェント」の３要素が必要である。そして、現実に運用されている送電系統の保護・制御システムは、シングルベンダーによって構成されておらず、様々なメーカーが製造しかつ仕様が定められたベンダー固有の保護制御装置、エージェントPF、エージェントCPUが混在するマルチベンダー方式で運用されている。したがって、異なるベンダーが作成したエージェントが全てのメーカーのエージェントPF、エージェントCPU上で動作し、かつ他メーカーの保護制御装置の情報を取得・設定できる必要がある。これを実現するには、エージェントシステムの3要素について標準化を行う必要がある。特に「エージェントPF」並びに「装置アクセスソフトウェア」が具備するAPI(Application Programming Interface)とそれらの機能の標準化が重要である。エージェントプラットフォームの仕様に違いがある場合、A社製のエージェントは、B社製のエージェントプラットフォームへの移動はできない。また、装置アクセスインタフェースに違いがある場合、ベンダの数だけエージェントを開発し、かつエージェント間の協調方法を決める必要がある。しかも、様々なアプリケーションを段階的に導入する場合、導入する度に、これらの作業が発生する。
【００７９】
このように、装置アクセスインタフェースとエージェントプラットフォーム１８が提供するインタフェースと、両インタフェースを用いて利用する機能を標準化することで、エージェントはベンダの差異の影響を受けずに、保護制御システム全体に対して、装置の設定や情報取得を行うことが可能となる。そして、エージェントについては、エージェントPFと装置アクセスソフトウェアが提供するAPIを利用し、作成すればよい。なお、本実施例においては、1個のエージェントCPUにつき、１個のエージェントPFのみが動作する場合を想定したものとして説明しているが、当然これに限られるものではなく、電力送電系統に接続される膨大な数のエージェントCPUとエージェントPFとを対象とし得ることは言うまでもない。図１７に標準化（仕様化）するエージェントCPUで実装する各種機能等を示す。
【００８０】
具体的には、図１５に示す基本概念図のように、エージェントプラットフォーム１８は、(1)エージェントを生成・削除する、(2)エージェントの移動が要求されると、移動先のエージェントプラットフォームにエージェントを転送する、(3)エージェントが転送されてくると、そのエージェントを起動するといった基本的機能の他に、(4)エージェントに対する追跡・停止などの遠隔管理を行うプラットフォーム間通信機能、(5)異常検出機能や故障対応機能(イベント通知、履歴、装置アクセスソフトウェア連携)を追加することで、障害発生時に移動経路を変更するなどの自律的な処理を可能としたエージェント処理機能を備え、電力用としてエージェント管理の詳細化や耐障害性の向上を図るようにしている。また、装置アクセスソフトウェア１９は、(1)エージェントからの保護制御装置の情報取得、設定処理要求に基づき処理を実行し、結果をエージェントに返すエージェントとのインタフェース、並びに(2)：保護制御装置の状態変化（保護制御装置からの通知）を、エージェントプラットフォームを介してエージェントに通知する保護制御装置１６とのインタフェースを備えるようにしている。
【００８１】
尚、保護制御装置と接続する保守用CPUには、アナログ・ディジタル入出力のための物理的なインタフェースが必要である。制御装置は装置アクセスソフトウェアを持つ保守用CPUと接続されることによって、他のエージェントCPUである保守用CPUや各種サーバからはエージェントPFで規定した論理的なインタフェースを介して、装置情報の遠隔取得設定が可能とされる。また、エージェントCPUには、保護制御装置とIP網を接続するために、ネットワーク端末機能を備えている。
【００８２】
また、エージェントシステムを構成するソフトウェアは様々なベンダが提供する装置上で動作可能とするために、Java（登録商標）言語を用いた実装が好ましい。Java言語は、Windows（登録商標）やLinuxなど多様なOSが対応しており、今後のさらなる普及が期待でき、かつ保守用CPUでの実装事例がある。Java言語を用いて実装する場合、タイマー機能などスレッド処理の高度化とTCP/IPの高度な利用に当たっては、Java Standard Edition (SE)1.4以上が、CPU資源の詳細情報取得のために、Java SE 1.5以上が必要となる点から、Java SE 1.5以上の使用が好ましい。通信プロトコルについては、図４に示した通信プロトコルの階層のように、Javaの層では、通信インフラAPIを通じてプロトコル上位を利用できる必要がある。通信インフラAPIとしては、Java RMIや高度通信RPCを挙げることがある。なお、直列可能な情報とは、Java言語のjava. io. Serializable形式の情報である。
【００８３】
しかして、本実施例のエジェントシステムは、エージェントを異なるベンダーのエージェントCPU、エージェントPF間へ移動して、処理を行うことが可能となる。また、マルチベンダの保護制御装置の情報を統一した形式で利用可能となり、メーカ独自形式情報も集配信できる。
【００８４】
ここで、送電系統の保護・制御システムを実行するエージェントシステムには、以下に示す(1)〜(5)の基本機能と、(6)〜(8)の高信頼化のための機能を備えることが望まれる。
【００８５】
(1)情報収集の自動的開始
イベント（保護リレー装置動作、遮断器動作、リレー装置障害、一定時刻経過、スケジュールによる起動命令）を処理の起点として、エージェントは、情報の収集を自動的に開始することができる。尚、ある箇所（中給、給電制御所、保守所４）から自所および遠隔(例えば電気所)のエージェントプラットフォームに対してエージェントの起動要請をかけることができる。
【００８６】
(2)情報収集箇所の自律的選択
事前に用意された系統などの条件とその対応シナリオに従い、情報収集箇所を決定し情報収集することができる。
【００８７】
(3)エージェント(プログラム)の配信
保護リレー装置が発するイベント情報により、処理するエージェント（事故解析など）を選択することができる。得られた情報より自律的に処理するエージェントを選定し、配信することができる。
【００８８】
(4)処理結果配信箇所の自律的選択
系統の運転所、設備の保守所４、解析箇所など電圧階級や設備により情報を配信すべき箇所は異なる。これらを条件に基づいて判断し、情報を必要とする箇所に適切に配信することができる。
監視制御を行なっている箇所への事故速報の配信のように、同一電気所の事故においても、事故設備によって配信箇所を選択することが出来る。
【００８９】
(5)エージェントの状態の把握
エージェントの現在位置、処理状況を運用保守担当者などが把握できる。
【００９０】
(6)エージェントの詳細管理
エージェントシステムでは、エージェントによる確実な処理を実現するために、「エージェントPF」、「エージェントの種類」、「エージェント」のそれぞれの単位で状態を管理する。これにより、保守担当者などは状況に応じてエージェントに対して停止などの命令を効率的伝えることが可能となる。
【００９１】
(7)情報収集・配信失敗時の処理
(i)「情報収集・データ処理異常時への対応」
エージェントによる収集必要箇所となる保護制御装置のうち情報収集・データ処理が不可能なものがある場合、システムは以下の処理を行う。
1)情報収集・データ処理が不可能であることを認識し、その箇所を回避して情報を収集する。
2)情報収集・データ処理が不可能であった箇所およびどの情報が収集・処理できなかったかを保守担当者などへ通知する。
なお、収集不可能とは、装置アクセスソフトウェアがエラーあるいは例外を発している状況とする。
これにより、情報収集の実行が不可能な保護制御装置やデータ処理が不可能なエージェントCPUからの影響を抑えることが可能となる。
(ii)「移動の異常時の対応」
エージェントがコネクション断などの伝送路障害によって移動中に異常となったと判断された場合、システムは、以下の処理を行う。
1)エージェントが移動中に通信異常に陥った場合、移動のリトライを移動先となるエージェントPFにかける。
2)リトライをかけてもだめな場合はあきらめ、違う箇所へ情報を収集に回る。
これにより、処理実行不可能なエージェントCPUの影響を抑えることが可能となる。
(iii)「エージェント間通信の異常時の対応」
エージェントがエージェント間通信中に異常となった場合、システムは、通信のリトライを通信相手となるエージェントPFにかける。リトライに失敗した場合は、異常終了とする。
これにより、エージェント間連携における障害の影響を抑えることが可能となる。
(iv)「消失への対応」
エージェントが消失してしまった場合、システムはそれをシステム管理者へ通知すると共に、保守担当者などに通知する。異常終了によりエージェントが消失した等の場合は、消失の自動検出・通知が困難と考えられる。その場合は、担当者が位置管理機能やログ機能によりエージェントの追跡を行う。
これにより、消失箇所が限定でき、消失したエージェントの問題点の分析が容易となる。
(v)「エージェントの処理起動・中止・再開」
保守担当者は、エージェントに対して以下の起動・中止・再開に関する指令を発することが可能である。中止の指令が発されると、エージェントは中断状態、中止状態の順に移行する。
1) エージェント生成後、エージェントPFがエージェントに処理を開始させる指令。
2) エージェント中止後に保守担当者などが行う処理再開指令。
3) エージェントが移動先で、そこのエージェントCPU上のエージェントPFが、エージェントの処理を開始させる指令。
(vi)「起動失敗時の対応」
事故などの発生により、エージェントの起動が失敗した場合、以下の手順で処理を行うことができる。
1)エージェントが起動すべきときに起動しなかったことを検出し、通知する。
2)起動しなかったエージェントを外部から起動する。
これにより、保守担当者による強制的な起動が可能となり、緊急時においても必要な情報を取得できる可能性が高まる。
【００９２】
(8)リレー装置のリソースが不足しそうな場合の処理
(i)「リソース不足への対応」
エージェントCPUのリソース(メモリなど)が不足しそうな場合、対応処理を行う。
(a)リソース不足を回避する処理
1)エージェントの移動などによりエージェントCPUのリソースが不足するかどうかを判定する。
2)リソース不足に陥る場合は、リソース不足とならない状態になるまで待つ。あるいは、そのエージェントCPUでの処理を実行せずに、次のエージェントCPUへ移動する。
(b)占有状態対策
ここで、CPU資源が占有された状態は、以下の何れかの状態を想定する。
1)一定時間(処理期限)を越えた。
2)エージェントPFからの中止命令に応答しない。
エージェントPFがCPU占有状態を検出した際には、システムは以下の手順で処理を実行する。
1)エージェントの停止・削除
2)エージェントPFの再起動（保守用CPUではなく、サーバの場合、可能であれば、再起動前に占有しているエージェントの処理優先度を変更することで、占有状態の解消を図る。）
これらの機能により、リソース不足への一時的な対応が可能となり、可用性が向上する。
(ii)「優先処理」
優先すべきエージェントがあった場合は、現在処理中のエージェントを停止させ、優先すべきエージェントを先に処理する。これにより、緊急性を要するエージェントが迅速に処理を実行することができる。エージェントに、処理期限や優先度を付与することにより、エージェントPFは処理期限や優先度を用いて、エージェントを制御することができるので、個々のエージェントに必要な性能・信頼性を満足することができる。
【００９３】
また、上述の送電系統の保護・制御システムを実行するエージェントシステムに要望される機能を実現するため、エージェントPFは、エージェントの生成・移動などを実現するための基本機能だけでなく、高信頼化等の観点からその他多数の機能を具備する。基本機能については、MASIF規格やAglets で提供する機能を備えることで、一般的なモバイルエージェント機能を提供でき、将来の他のエージェントPFとの接続の容易さが期待できる。高信頼化については、独自のイベント処理機能やログ機能、処理管理機能などを設けることで対応している。図１８に全体構成を示し、各種機能の動作と対応するAPIであるオブジェクトクラスを以下に示す。
(1)エージェント生成／削除機能(Agent Create Delete) ５１
(2)移動機能 (Migration)５２
(3)エージェント間通信機能 (Agent Communication)５３
(4)処理ロジック管理機能 (Process Logic Manager)５４
(5)プラットフォームインタフェース (PFIF)５５
(6)プラットフォーム間通信機能 (PF Communication Infrastructure)５６
(7)ログ機能（Log）５７
(8)イベント処理機能 (Event Processor)５８
(9)外部サービスインタフェース (External Service Interface)５９
(10)リソース管理機能 (Resource Manager)６０
(11)エージェント処理管理機能 (Agent Process Manager)６１
(12)位置管理機能 (Location Manager)６２
(13)セキュリティ機能(Security Manager)６３
尚、図中の符号の後の()の中の符号は上述の機能を実現する手段を示している。
【００９４】
図２９にエージェントPFが提供する主な機能対応表を示す。この表が示すように、ほとんどの機能は高信頼化のために必須の機能である。1)エージェントPFと運用・保守担当者との連携のために、プラットフォームインタフェースとプラットフォーム間通信機能を、2)異常状態に対応するために、イベント処理機能とエージェント処理管理機能を利用する。尚、各種機能の詳細を指定する設定をプロファイルと呼ぶ。
【００９５】
（生成・削除機能）
アプリケーションや起動中のエージェントからの要求に基づき、エージェントの生成や削除などを行う。関連するオブジェクトクラスは、PFIF５５および、Agent Process Manager６１である。
【００９６】
（移動機能）
エージェント自らなどの要求に基づき、指定されたエージェントPFへそのエージェントを転送する。転送完了後、エージェントを起動する。通信網の障害などにより移動が失敗した場合、再送を行う。
図５(a)に示すように移動時には、エージェントPF間でエージェントPFのget_resourceメソッド、receive_agentメソッドの順で処理を行う。そして、移動先でのリソース不足に対して、エージェントには以下の1)〜3)の対応モードを指定することが出来る。
1) 中断（送信元に戻り、担当者への通知などの対応処理を行う。）
2) スキップ（何も処理を行わず、次のエージェントPFへ移動する。）
3) 待機
図５(b)に示すように、エージェントPFの移動機能は、通信網の障害などによりエージェントの移動が失敗した場合、再送を行う。また、ログ機能が移動などの処理失敗などをログとして記録する。図２６にエージェントの状態遷移を示す。担当者は、位置管理機能を用いてエージェントの管理モードを変更することで、遠隔地に移動したエージェントが可能である。関連するオブジェクトクラスは、PFIF５５とEvent Processor５８である。
【００９７】
（エージェント間通信）
図１９に示すように、エージェント間通信は、異なるエージェント間で情報交換するための機能である。授受する情報には、文字列情報や装置情報アクセスソフトウェアから得たオブジェクトなどを収容できる。エージェント間通信機能は、タイムアウト機能およびリトライ機能を提供する。タイムアウト時間およびリトライ回数は、プロファイルで指定する。
通信方法（トポロジ）としては、個別に通信する方法（1:1）とマルチキャストで通信する方法(1:m)をサポートする。
通信方法（応答の有無と手順）としては、次の1)〜3)の3種類をサポートする。
1) 応答ありの同期通信
2) 応答ありの非同期通信
3) 応答なしの片方向通信
授受する情報の形式は、シリアライザブルとする。
エージェント間通信機能は、タイムアウト機能を提供する。メッセージの送信・応答結果の受信については、オブジェクトクラスProxyを用いる。この方法により、外部から直接エージェントを操作することを防止する。関連するオブジェクトクラスは、PF Communication Infrastructure５６である。
【００９８】
（処理ロジック管理機能）
処理ロジック管理機能は、エージェントが生成あるいは到着した場合、処理ロジックを実行させる。処理ロジック管理機能は、エージェントPFのエージェント処理実行管理機能に含まれる。例えば、図１９（ｂ）に示すような、経路番号とエージェントCPU、ロジックID、ロジックがそれぞれ対応するテーブルをエージェント処理実行管理機能のメモりに有し、このテーブルに従って、図１９（ａ）に示すように所定のエージェントが所定の経路を通って所定のエージェントCPUで所定のロジックを実行する。関連するオブジェクトクラスは、Agent Process Manager６１である。
【００９９】
（プラットフォームインタフェース）
プラットフォームインタフェースは、保守担当者や他のエージェントPFと連携するためのインタフェースである。保守担当者からのエージェントの生成・起動・中止指令やエージェントPF間でのエージェント移動などの際に、利用する。
この機能はエージェント起動を承認・拒否の結果通知として、Boolean（True or False）など戻り値で結果を返す。詳細情報などその他の情報を呼び出し元のエージェントPFに通知する手段には、例外を用いる。
プラットフォームインタフェースは、エージェントPFを構成する他の機能と連携と保守担当者や他のエージェントCPUとの連携を可能とする。関連するオブジェクトクラスは、 Agent Process Manager６１、PF Communication Infrastructure５６である。
【０１００】
（プラットフォーム間通信機能）
プラットフォーム間通信機能は、通信ミドルウェアとエージェントPFを接続する役割を有する通信インフラストラクチャであり、以下の1)〜3)の機能に対して通信機能を提供する。
1) 移動機能
2) エージェント間通信
3) 外部サービスインタフェース
関連するオブジェクトクラスは、PF Communication Infrastructure５６、External Service Interface５９である。
【０１０１】
（ログ機能）
ログ機能は、エージェントの振る舞いや装置からのトリップ信号などによりイベントが発生した場合など、プロファイルに従い、日時やイベントを発した機能名や詳細情報を記録する。関連するオブジェクトクラスは、Log５７である。
【０１０２】
（イベント処理機能）
イベント処理機能は、イベントを受信すると、その内容に応じた処理を行う。プロファイルを用いて、ログ機能やエージェントなどに転送するイベントの種別を指定可能とする。
以下に示す1)〜4)のエージェントの基本的な振る舞い時に発生するイベントを処理する。
1) 生成／削除
2) 移動
3) エージェント間通信
4) 処理ロジックの実行
エージェントPFは、上記の処理の実行前後に、イベントを発することが出来る。プロファイルによりイベントの発生の有無を指定する。
図 ２０(a)に示すように、イベント処理機能は、イベントを受信すると、その内容に応じた処理を行う。イベントへの対応方法は、プロファイルによって指定することが出来る。例えば、プロファイルで指定されたログ機能やエージェントなどにイベントを転送する。イベントの転送については、以下の1)〜2)の機能を提供する。
1) 常駐エージェントへの通知
2) 移動しているエージェントへの通知（中止や中断等を想定）
移動しているエージェントへの通知は、位置管理機能との連携が必要となる。位置管理サーバへの負荷を考慮し、以下の1)〜3)の方法を利用することができる。
1)位置管理機能で検索し、エージェントPFから該当エージェントへ通知：
位置管理サーバの負荷：大
2)位置管理機能が検索・通知までを実施：位置管理サーバの負荷：中
3)ブロードキャスト通知：位置管理サーバの負荷：小
関連するオブジェクトクラスは、Event Processor５８である。
【０１０３】
（外部サービスインタフェース）
外部サービスには、装置アクセスソフトウェアと既存システムが含まれる。図 ２０(b)に示すように、外部サービスインタフェース (インターフェース)は、外部サービスからのイベントを受信することができる。また、イベントの内容に応じて、イベントを他APFへ転送することができる。
外部サービスがエージェントに対してイベントを発するために、外部サービスインターフェースを呼び出す。受信されたイベントは、イベント処理機能あるいは他のエージェントPFの外部サービスインターフェースへ転送される。他のエージェントPFとの通信には、プラットフォーム間通信機能を用いる。関連するクラスは、External Service Interface５９である。
【０１０４】
（リソース管理機能）
エージェントPFが動作するハードウェアのメモリ量や負荷、エージェント数を監視し、リソース不足を防止するための処理を行う。リソース不足を防止する処理としては、例えば、メモリ量が上限値を超過した場合には、ガーベッジコレクションを実行したり、エージェントの転送を拒否するように、移動機能に依頼するなどである。そして、リソース不足が発生すると、イベントを発する。このとき、イベント処理機能を利用して、エージェントの停止・削除、エージェントPFの再起動を実現することが出来る。関連するオブジェクトクラスは、Resource Manager６０である。
【０１０５】
（エージェント処理管理機能）
エージェント処理管理機能は、エージェントの生成あるいは到着後の処理の管理を行う。すなわち、起動処理も管理する。エージェント処理管理機能は、エージェントの状態遷移を管理し、状態遷移前後にイベントを発生することができる。エージェントの起動および演算異常に失敗した場合にもイベントを発生できる。
エージェントPFおよびエージェントは、保守担当者などが指定するモード例えば管理モード (Administrative State)と、システム側が発するモード例えば運用モード (Operational State)と使用モード (Usage State)、アラームモード (Alarm Status)の都合4種類のモードをそれぞれ具備する。このモードは、以下の単位でそれぞれ有する。
1) エージェントPF
2) エージェントの種類
3) 個々のエージェント
関連するオブジェクトクラスは、PFIFあるいは、Agent Create Deleteである。
エージェントの処理スケジューリングには、エージェントに割り当てられた処理期限や優先度などの情報を用いる。エージェントPF上に複数のエージェントが混在する場合、逐次処理を行うスケジューリングをベースとし、複数の常駐エージェント動作の実現や単一エージェントによる処理占有などを防止するために並行処理を行うスケジューリングを併用する。関連するオブジェクトクラスは、Resource Manager６０、 Event Processor５８である。
【０１０６】
（位置管理機能）
システム全体管理のために、管理対象となるエージェントPFからの情報を基に、エージェントの位置や処理進捗状況を管理する。位置管理機能を用いることで、エージェントの状態(移動中・処理中・停止中・アラーム等)の取得や、エージェントの動作（使用・ロック）の変更指示を可能とする。図２に位置管理機能の動作概要を示す。ログ機能と同様に、エージェントの移動開始時と到着時に位置管理機能に対して、通知を発することができる。関連するオブジェクトクラスは、Event Processor５８、Migration５２である。
【０１０７】
尚、本エージェントシステムは、通信網レベルで外部に対してクローズなシステムを構成し、新規なセキュリティ対策あるいはJavaレベルなど既存技術で実現容易なセキュリティ対策を施すことでセキュリティのレベルが高い状況を構築するものとしている。
例えば、処理の実行制御に対しては、プロファイルの内容により、エージェントが行う処理の許可と制約を設定可能とする。エージェントの種類毎に、あるいはエージェント単位で指定できるものとする。許可（permission）が与えられた処理（ex. 生成（子エージェント）や移動など）は、エージェントは、その処理を実行可能とする。逆に、制約（protection）が設定された処理は、エージェントは、その処理が実行できない。
また、通信に対しては、プロファイルによりエージェント移動に伴うプログラム(ダウンロード)に関する設定を可能とする。これにより、指定したユーザやノードからのみエージェントプログラムをダウンロード可能とする。さらに、通信機能 (ex. VLAN)と連携し、他のシステムと分離することも可能である。これにより、エージェントプログラムを盗聴されないようにできる。
【０１０８】
さらに、新規のアプリケーショの追加は、エージェントの追加およびエージェントPF用プロファイルの変更により、容易に可能である。本エージェントシステムは、保護制御に要求される高信頼化処理や異機種接続性を実現し、かつ拡張性が優れたものとなる。
【０１０９】
次に、装置アクセスソフトウェアについて説明する。装置アクセスソフトウェアは、エージェントが保護リレー装置や制御装置、センサなどの機器に対して情報取得や設定を行うために、その仲介機能として利用する。エージェントは、装置アクセスソフトウェアが提供するAPIを利用することで、装置情報を取得設定する。また、装置アクセスソフトウェアは、エージェントPFに対してイベントを発することができる。そのイベントを、エージェントはエージェントPFを介して受信することができる。これにより、保護リレー装置動作を起点とした事故解析処理などが可能となる。
【０１１０】
図２１に示すように、装置アクセスソフトウェア１９は、装置アクセス機能３８、情報モデルへの変換機能４０、メーカ独自の装置アクセス機能４１を含む。装置アクセス機能３８は、情報モデルを保持し、検索機能を提供する。情報モデル変換機能４０は、必要に応じてEquipmetData形式と装置固有データ形式の変換を行うものであり、エージェントからのEquipmetData形式の要求を独自アクセス機能に適した形式に変換して独自アクセス機能４１へ渡したり、あるいは独自アクセス機能４１を介して保護機能を実行するCPU(RyCPU)１６から取得した保護制御装置のデータ４６をEquipmetDataに変換してから該当情報収容部４４へ格納される。そのために、情報モデルは、個々の情報をオブジェクトとしてツリー構成４５で収容する(図２２(a))。個々の情報をオブジェクトとしてカプセル化することで、エージェントは様々な情報を集配信することが出来る。例えば、オブジェクトには、独自規定のものだけに限らず、電気所装置の情報を示すIEC61850などのオブジェクトも収容可能である。そして、オブジェクトの定義には、Java言語による規定だけではなく、データ表記方法であるXML（Extensible Mark-up Language）を適用可能とする。
【０１１１】
装置アクセスソフトウェアのAPIでは、エージェントとの連携をとるため、以下のメソッドを提供する。整定の処理ステップなどに対応するために、 情報取得（getData）や情報設定 (setData)命令を使う際には、“仮設定”や“運用”などのパラメータを指定可能である。
1) getData( オブジェクトのID、検索範囲、パラメータ）
2) getData( オブジェクトのID、検索範囲、検索条件パラメータ）
3) setData( オブジェクトのID、検索範囲、設定値、パラメータ）
4) setData( オブジェクトのID、検索範囲、検索条件、設定値、パラメータ）
【０１１２】
装置アクセスソフトウェア１９では、エージェントと授受するデータ形式としてラッパーオブジェクト形式（EquipmetData）を採用している。ラッパオブジェクトは、保護制御装置が入出力するデータの生データ（保守運用に必要な詳細情報を含む）、データ種別・形式、アクセス日時を保持する。同時に、装置アクセスソフトウェアでは、保護制御装置毎に保守用 CPUが接続されるだけではなく、電気所サーバなどが多数の保護制御装置と接続されることが想定されるため、装置アクセスソフトウェアには、装置情報をツリー構造でオブジェクトとして保持することにより、ツリー検索を可能としている。これを実現するためには、以下の項目を規定する必要がある。
1) ツリー階層構成：オブジェクトの読み書き方法が明確となる。
2) オブジェクトの基本定義（設備番号などを属性とする。）：オブジェクトに共通して必須となる属性が明らかとなる。
3) オブジェクトの定義(継承)：実保護制御装置を接続する際に必須である。
また、オブジェクト（EquipmetData）は、データを設定したタイムスタンプ（ Date timestamp）並びにデータのタイプ（String datatype）例えば、“XMLやPlain Old Java形式の種別“＋オブジェクトクラスIDを設定した属性と、装置から取得したデータ本体（Serializable Data）あるいは装置に入力するためのデータ本体（Serializable Data）を具備する。Euqipmentクラスは、これらの属性を具備することで、各種形式のJavaオブジェクトを収容するラッパークラスとして機能する。例えば、図２８に示すように、装置アクセスソフトウェアは3種類のオブジェクトを統一した方法で収容することで、エージェントは様々なデータ形式の集配信が可能となる。尚、オブジェクトの定義は、Java言語あるいはXMLで規定する。
【０１１３】
この実施例のアクセスソフトウェアにおいては、設備モデルと運用モデルの2種類の情報モデルを収容することを想定している。設備モデルは、各装置の型番などの設備情報を収容する。運用モデルは、整定値や動作状態などの情報を収容する。ツリーの階層の上位部は、両モデルとも共通とし、その下位にモデル毎にオブジェクトを配置する。上位部の階層を以下の通りである。下記は、ツリー構成を構成するための仮想のオブジェクトである。
・ Top
・ 電気所識別子(ex. 変電所A)
・ 設備識別子（ex. 送電線、変圧器）
・ 装置識別子（ex. 保護リレー装置、事故波形記録装置）
・ 回線識別子（ex. xxx線3L）
【０１１４】
オブジェクトの定義は、以下の通りである。
(1)設備モデル
図２３(a)にPCM保護リレー装置の例を示す。保護リレー装置に関する各種オブジェクトは、回線識別子となる仮想オブジェクトxxx3Lの下位に配置する。各オブジェクトは、以下の属性を持つ。
・ 名称：例えば、MainPCM001
・ データ種別：例えば、主保護各端各相判定PCM
・ 起動時刻
・ データ(複数)：型形式、メーカ名など
オブジェクトの定義において、属性として、メーカ固有形式のデータを追加することも可能である。
【０１１５】
(2)運用モデル
図２３(b)に運用モデルのオブジェクトの構成を示す。オブジェクトは、回線識別子となる仮想オブジェクトxxx3Lの下位に配置されている。下位部の構成は以下の通りとした。
第1層：整定、動作内容、異常状態、運用状態
第2層a（整定の下位）： 整定
第3層a：整定（リレー1）、整定（リレー2）、運用設定（リレー3）
第2層b（動作内容の下位）：最新動作内容、動作履歴
第2層c1（異常内容の下位）:最新異常内容、異常一覧、詳細情報
第2層c2（異常内容の下位）:異常履歴、詳細情報
第2層d（運用状態の下位）運用状態:リレー動作、入力電気量
例えば、整定の第3層のメインリレーは、要素1タップ、要素1倍率、要素1大電流域、要素2タップの値を属性として持つ。
【０１１６】
このように、ツリー構造を用いることで、設備情報と運用情報を体系的に収容することが可能となる。エージェントは、これらの情報モデルを装置アクセスソフトウェアのAPIを介して利用することが出来る。階層の段数や装置の名称や整定値などを検索条件(範囲)とすることで、遠隔運用保守に必要な情報を取得できる。直接階層上の位置を指定し、各オブジェクトを取得することも可能である。
ただし、情報ツリーを構成するオブジェクトとエージェントの移動先となるエージェントCPUは関連があり、エージェントCPUの種別に応じた検索条件の指定が必要となる。
【０１１７】
以下に移動先と検索内容の組み合わせの例を示す。
(1)変電所には変電所サーバのみが配置される場合
移動先：電気所サーバ（Top.変電所A）相当のIPアドレス
検索例1：送電線．保護Ry．ｘｘｘ3L.PCMCa以下を検索
検索例2：PCMCaという名称のオブジェクトを検索
検索例3：送電線．保護Ry．ｘｘｘ3L.PCMCa．MainPCM001の情報取得
(2)PCMCaに保守用CPUが接続される場合
移動先：PCMCaの保守用CPU（ Top.変電所A.保護Ry．ｘｘｘ3L.PCMCa）相当のIPアドレス
検索例1：全オブジェクトを検索
検索例2：PCMCaという名称のオブジェクトを検索
検索例3：MainPCM001の情報取得
【０１１８】
図２２(b)に示すように、装置アクセス機能３８は、情報ツリー検索部（名前検索部とも呼ぶ）４３と情報収容部４４から構成されている。情報収容部４４は、例えばXMLのDBやJava形式でデータを入出力するソフトウェアの組み合わせで構成される。名前検索部４３は、情報ツリーとDBの対応付けを管理する。
エージェントが装置アクセスAPIを呼び出すと、名前検索部４３は、装置アクセスの情報取得設定APIの引数に含まれる検索範囲を基に、該当する情報収容部４４を選択し、データ形式に応じたツリー検索機能を用いて検索する。即ち、装置アクセス機能３８の情報ツリー検索機能によって、スコープ情報から情報収容部を特定し、さらにフィルター情報を用いてデータ検索を行う。
このように、名前検索部４３がオブジェクトの形式を隠蔽することで、様々なデータ形式を統一的に利用することが可能となる。ただし、エージェントは、それぞれのデータ形式を処理できる必要がある。
装置アクセスソフトウェア１９は、リレー装置のトリップ動作や故障通知の状態変化を検出すると、エージェントPFの外部サービスインタフェースに対して通知を行う。この動作によって、この内容に応じて、エージェントPFはエージェントの生成やエージェントへの通知を行うことができる。
以上のように、装置アクセスソフトウェアを介することで、装置情報を標準形式に変換、あるいはベンダ固有形情報をXML形式でオブジェクトに収容した形で、集配信することができる。
【０１１９】
さらに、エージェントについて説明する。エージェントは、エージェントPFにより次に実行すべき振る舞いが指定される。振る舞いの内容は、エージェントパッケージのエージェントクラスから派生することで、エージェント毎に規定された属性とメソッド・処理ロジックに基づいて決定される。本実施例のエージェントは以下の機能を提供する。
（ａ） 生成／削除
（ｂ） 保存（永続化）
（ｃ） 移動
（ｄ） エージェント間通信
（ｅ） 処理ロジックの実行
（ｆ） エージェントの振る舞い指定の詳細化（再送回数などのパラメータや異常時処理ロジック）
（ｇ） 優先度、処理期限を用いたエージェントの制御
（ｈ） 複数の処理ロジックの組み合わせ
（ｉ） エージェント間通信への対応
（ｊ） 使用・ロックなどへの状態遷移の対応
（ｋ） 移動経路
（ｌ） 処理ロジックの振る舞い
（ｍ） 処理結果
（ｎ） 例外処理発生時対応
（ｏ） 状態
（ｐ） 優先度
（ｑ） 処理期限
尚、エージェントに与えられる優先度は、１から999までの整数値であり、値が大きい程、優先度が高いものとみなす。
【０１２０】
（状態遷移）
また、エージェントは「起動」、「活性（実行）中」、「中断」、「中止」、「停止」及び「ロック」の状態を遷移する。エージェントクラスにおいてこの状態遷移が、関連する属性statusである。DetailedStatusのクラスの型の属性であり、以下の情報を参照できる。
・ 管理モード（Administrative State）
・ 運用モード（Oprational State）
・ 使用モード（Usage State）
・ アラームモード（AlarmStatus）
・ 移動モード（Migration Behavior Mode={Hop、 Wait、 Return}）
・ 処理モード（Process Time={逐次、並行}）
【０１２１】
（保持するデータ）
エージェントは、以下のデータを保持し、外部からアクセス（読み書き）する機能を提供する。
・ Javaオブジェクト
・ XMLデータ
・ ファイル
ただし、データへのアクセスを制御することが可能である。
外部からアクセス可能なデータは、エージェントクラスのprogram Data属性に保持する。
【０１２２】
（生成／削除）
ａ）エージェントが生成される処理手順は以下の通りである。
1. エージェントPFへのエージェントの生成要求としてcreateエージェントメソッドが呼び出される。
2. エージェントのコンストラクタが呼び出される。
3. エージェントのonCreationメソッドが呼び出される。
4. イベントリスナに登録された処理が呼び出される。
5. 処理ロジック管理機能により処理ロジックが実行される。
【０１２３】
ｂ）エージェントが削除される処理手順は以下の通りである。
1. エージェントPFへのエージェントの削除要求としてterminateエージェントメソッドが呼び出される。
2. イベントリスナに登録された処理が呼び出される。
3. エージェントのonDisposingメソッドが呼び出される。
【０１２４】
（移動）
エージェントは、滞在しているノードでの処理が完了すると、指定された移動先のエージェント CPUに移動する。エージェントは、移動元での処理ロジックの進捗結果を保持し、移動先では、その次のロジックを実行する。また、migrateメソッドを呼び出すことでも移動するが可能である。
エージェントには、移動処理失敗への対策として、移動時間のタイムアウト値と再送回数を設定できる。タイムアウト値に達した場合、移動失敗となる。移動に一度失敗した場合、指定された回数の再送をエージェントPFが試行する。タイムアウト値や再送回数は、エージェントに指定が無い場合、エージェントPFが保持するデフォルト値を利用する。
エージェントの移動において、IP網上の他の通信の影響を回避するために、エージェントPFのプラットフォーム間通信機能がルータなどのQoS制御機能と連携するための通信制御を行う。また、移動先において、他のエージェントと競合した際には、エージェントPFのエージェント処理管理機能が、優先度や処理期限を参照して、事故解析エージェントを優先する。
【０１２５】
（保存 (永続化)）
エージェントがロック状態になった際に、そのエージェントは保存される。
【０１２６】
（イベント）
エージェントは、エージェントPFのイベント処理機能と連携し、以下のイベントを受信する。そして、Delegation-Based Event Modelに基づいて、イベント毎にそれに対応する処理を実行。
・ 生成
onCreationメソッド、あるいはCreation Event Listenerが処理を行う。
・ 削除
onDisposeメソッドがあるいはイベントリスナが処理を行う。
・ クローン
onClonningメソッドがあるいはイベントリスナが処理を行う。
・ 移動(送信)
onMigratingメソッドがあるいはイベントリスナが処理を行う。
・ 移動(受信)
onMigratedメソッドがあるいはイベントリスナが処理を行う。
・ 永続化(ファイルなどに保存)
onPeresitenceメソッドがあるいはイベントリスナが処理を行う。
・ 移動失敗（1回目）
onMigrationFailedメソッドがあるいはイベントリスナが処理を行う。
・ 移動再送失敗（最大回数、タイムアウト）
onRetryMigrationFailedメソッドがあるいはイベントリスナが処理を行う。
・ エージェント間通信失敗（1回目）
onエージェントCommunicationFailedメソッドがあるいはイベントリスナが処理を行う。
・ エージェント間通信再送失敗（最大回数、タイムアウト）
onRetryエージェントCommunicationFailedメソッドがあるいはイベントリスナが処理を行う。
・ 処理異常
onProcessFailedメソッドがあるいはイベントリスナが処理を行う。
・ 外部イベント受信
onExternalServiceEventRecivedメソッドあるいはイベントリスナが処理を行う。
【０１２７】
（処理ロジックの実行）
図１９（ｂ）に示すように、エージェントが行う処理内容は、複数のロジックの組み合わせで構成できる。そのために、エージェントは、処理ロジックの一覧を保持し、経路番号とロジック番号の組み合わせで構成される。図１９（ａ）に示すように、エージェントは、エージェントCPU毎に異なる処理を実行することができる。また、エージェントは、同一のエージェントCPUに対して複数の経路番号を割り当てることが出来る。これにより、処理内容の変更や処理割り込み（次のロジックを開始前に割り込む）が容易となる。
エージェントが実行する処理は、Logicクラスから派生したクラスに処理内容を記述する。処理ロジック管理機能が、これを実行する。
【０１２８】
以上のように構成された本実施例のエージェントシステムによれば、事故解析情報集配信機能に必要な機能を有しており、高信頼化、異機種接続性に対して有効である。このことを、以下に遠隔整定アプリケーションソフト、事故波形データ配信アプリケーションソフト並びに事故解析情報集配信アプリケーションソフトを実行する場合を例に挙げて説明する。
【０１２９】
（実施例１）
以下、本発明を遠隔整定を実行するアプリケーションソフトを例として、保守所４にいる担当者が遠隔の保護リレー装置の情報を取得設定する場合の動作について説明する。尚、保守所の担当者（当該エージェント所有者）が、保守サーバへ遠隔整定の開始を要求することで、システムが遠隔整定を行う場合を考える。
ここで、利用する遠隔整定エージェントは、以下の構成とする。
（１） エージェントの処理ロジック（保守サーバ）：アプリケーションを通じて、担当者と連携しつつ、現在値確認と仮設定、運用設定処理を行う。
（２） エージェントの処理ロジック（保守用CPU）：装置アクセスソフトウェアと情報の授受を行う。
（３） エージェントが保持するデータ：情報集配信を可能とするために、保守サーバからの情報取得設定要求と装置アクセスソフトウェアからの情報をデータとして収容する。
尚、保守所の担当者（当該エージェント所有者）が、保守サーバへ遠隔整定の開始を要求することで、システムが遠隔整定を行う場合を考える。本システムでは、以下の動作を行う。図２４に処理の流れを示す。
【０１３０】
まず、担当者は、端末を通じて保守サーバ１２の遠隔整定アプリケーション６４を起動する（ステップ1）。保守サーバ１２では、遠隔整定アプリケーション６４がエージェントPF１８のプラットフォームインタフェース５５を用いて、エージェントPF１８のエージェント生成削除機能５１にエージェント生成要求を行い（ステップ2-1）、遠隔整定エージェント(以下、整定エージェント)を生成する（ステップ2-2）。遠隔整定エージェントは、現在値確認のために、エージェントPF１８の移動機能５２に対して、移動を要求する（ステップ3）。移動機能５２は、エージェントPF間通信機能５６を利用して、保守用CPU１５のエージェントPF１８へエージェントを転送する（ステップ4）。保守用CPU１５は整定エージェントを受け取った後、エージェントを起動する（ステップ5）。起動されたエージェントは、装置アクセスソフトウェア１９を介して保護リレー装置１３の運用モデルの情報を取得し（ステップ6-1）、保守用ＣＰＵ１５のエージェントPF１８の移動機能５２に対して移動を要求し（ステップ6-2）、保守サーバ１２へエージェントを転送する（ステップ6-3）。保守サーバ１２では、転送されてきた遠隔制定エージェントをエージェント処理管理機能６１で起動させて（ステップ6-4）、保護リレー装置１３の状況を遠隔整定アプリケーションに通知し（ステップ7-1）、さらにエージェント担当者に対して保護リレー装置１３の状況を通知し（ステップ7-2）、整定値を書き込むための入力を待機する（ステップ7-3）。以後、保守担当者の指示に基づいて、ステップ1〜7と同様の処理の流れで、仮設定、保護リレー装置１３への整定値書き込み、運用開始の指示の順に行い（ステップ8）、整定を完了する。
以上のようにして、本エージェントシステムでは、遠隔整定に必要な起動、情報取得・設定を行う。
【０１３１】
（実施例２）
事故波形データ配信を例として、保護リレー装置の動作を起点として、保守所４にいる担当者へ事故波形データを配信する場合の動作を説明する。
ここで、保守用CPUのエージェントPFのプロファイルには、以下の指定を行う。
（１） 保護リレー装置の状態変化発生時、事故波形データ配信エージェントを生成し、保護リレー装置状態変化のイベントをログとして記録する。
利用する事故波形データ配信エージェントは、以下の構成とする。
（２） エージェントの処理ロジック（保守用CPU）：エージェント生成後、時刻と波形データを検索キーとして、事故波形データを取得する。検索終了後、プロファイルに指定されたサーバへ移動する。
（３） エージェントの処理ロジック（保全サーバ）：事故解析アプリケーションへ保護リレー装置動作を通知し、データをファイルとして保存する。
・ エージェントが保持するデータ：エージェントは、情報配信のために事故波形データを収容する。
尚、エージェントシステムは、保護リレー装置の動作を検出し、保護リレー装置が保持する事故波形データを取得し、保守サーバにデータを配信する場合を考える。本システムは、以下の動作を行う。図２５に処理の流れを示す。
【０１３２】
保護リレー装置１３が動作すると（ステップ1-1）、装置アクセスソフトウェア１９は、保護リレー装置１３に動作に伴う信号を検出する（ステップ1-2）。装置アクセスソフトウェア１９は、エージェントPF１８の外部サービスインタフェース５９の状変通知用APIを呼び出し状態変化を通知する（ステップ2-1）。また、保護リレー装置１３の動作情報を情報モデルの中に記録する（ステップ2-2）。外部サービスインタフェース５９は、イベント処理機能５８にその情報を伝える（ステップ3）。イベント処理機能５８は、ログ機能５７に対して履歴記録を要求する（ステップ4）。イベント処理機能５８は、エージェント生成機能５１に対して事故波形データ配信エージェントの生成を要求し（ステップ5）、エージェントを生成、あるいは起動する。事故波形データ配信エージェントは、装置アクセスソフトウェア１９に対して、事故に関する情報を取得するために、時刻と波形データを検索キーとして検索を要求する（ステップ6）。装置アクセスソフトウェア１９は、情報ツリー４５に対して検索を行い、運用モデルから取得した事故波形データをエージェントに要求の戻り値として与える（ステップ7）。事故波形データ配信エージエントは、生成時に指定された移動先である保守所４に対して移動するために、エージエントPF１８の移動機能５２に対して移動要求を出す（ステップ8-1）。エージェントPF１８はエージェントPF間通信機能５６を用いてエージェントを保守サーバ１２へ転送する（ステップ8-2）。保守サーバ１２へ転送された事故波形データ配信エージエントは起動され（ステップ8-3）、事故情報監視アプリケーション６５に状態通知し（ステップ9-1）、事故情報監視アプリケーション６５を通して保守担当者へ状態通知される（ステップ9-2）と共に、波形データが保守サーバ１２に記録される（ステップ9-3）。
このようにして、本エージェントシステムでは、保守対象の状態変化が起きたときに、そのことを検出して状態変化を示すデータ例えば事故波形データなどを自律的に収集して指定された箇所に配信することができる。なお、本実施例ではリレー装置の動作を起点とした基本的な処理について説明したが、その他の機器の動作並びにデータを処理させ得ることは言うまでもない。
【０１３３】
（実施例３）
事故解析情報集配信を例として、保守所４と電気所２だけではなく、関係する複数の電気所、系統の運転所までをエージェントの動作範囲として、エージェントによるシステムの広域集配信機能の動作を説明する。
ここで、保守用CPUのエージェントPFのプロファイルは、以下の指定を行う。
（１） 保護リレー装置の状態変化発生時には、事故解析情報集配信エージェントを生成し、かつ保護リレー装置状態変化のイベントをログとして記録する。
利用する事故解析情報集配信エージェントは、以下の構成とする。
（２） エージェントの処理ロジック（イベントが発生した保守用CPU）エージェント生成後、時刻と波形データを検索キーとして、事故波形データを取得する。検索終了後、構内の保守用CPUと電気所サーバを巡回する。
（３） エージェントの処理ロジック（構内の他の保守用CPUと電気所サーバ）装置アクセス内のイベント発生時前後の情報を検索し、取得する。巡回終了後、系統DBに移動する。
（４） エージェントの処理ロジック（系統DB）：関連する電気所の一覧を取得し、その電気所に移動する。
（５） エージェントの処理ロジック（装置情報DB）：エージェントの処理ロジック（系統DB）：装置情報DBに収集した情報を蓄積する。保守サーバへ移動する。
（６） エージェントの処理ロジック（保全サーバ）保全サーバのアプリケーションに収集した情報を伝え、待機する。保守所４の担当者が事故解析を行い、その結果がアプリケーションを通じて、エージェントへ渡されると、エージェントは他の保守所４および運転所を巡回する。
（７） エージェントの処理ロジック（他の保守所４と運転所）：解析結果から必要な情報を通知し、巡回する。巡回が完了すると、処理を終了する。
（８） エージェントが保持するデータ：エージェントは、情報集配信のために装置情報、系統情報（電気所一覧）、解析結果を収容する。
（９） エージェントの状態遷移：図２６に示すように、管理モードの変更によりエージェントを停止、終了できる。また、軽故障時には、処理を継続するが、重故障時には、エージェントの処理は終了する。
システムの振る舞いは以下の通りである。図２７に処理の流れを示す。
【０１３４】
保護リレー用CPU１６を介して保護リレー動作等の状態変化を、保守用CPU１５あるいは電気所サーバ９内の装置アクセスソフトウェア１９は検出し（ステップ1-1）、その情報をイベントとしてエージェントPF１８に送信する（ステップ1-2）。エージェントPF１８は、イベント内容に応じた事故解析エージェント生成（ステップ2-1）、やログ記録を行う（ステップ2-2）。生成された事故解析エージェントは、エージェントPF１８に移動を要求し（ステップ3-1）、装置アクセスソフトウェア１９を介して構内の関係する保守用CPU１０や電気所サーバ９を巡回し、事故に関連する情報を収集する（ステップ2-3）。保守用CPUや電気所サーバ内では、装置アクセスソフトウェア１９の検索機能を用いて、情報収容部４４の設備モデルおよび運用モデルから、必要な情報を収容したオブジェクトを保持する（ステップ3-2）。事故解析エージェントは、構内情報を収集後、系統DB５ｃに移動し、関連する電気所２を把握し（ステップ4-1）、その電気所２に移動して情報収集を行う（ステップ4-2）。事故解析エージェントは、収集した情報を装置情報DB５ｂに蓄積すると共に（ステップ5-1）、保守サーバ１２に収集した情報を伝える（ステップ5-2）。保守所４の担当者が事故解析を行い（ステップ5-3）、他の保守所４および運転所３に必要な分の解析結果の情報を通知し（ステップ5-4）、処理を終了する。
【図面の簡単な説明】
【０１３５】
【図１】本発明のモバイルエージェントによる制御システムの構成を示す図である。
【図２】位置管理装置の機能を示す機能ブロック図である。
【図３】本発明のモバイルエージェントによる制御システムの要部を示す機能ブロック図である。
【図４】ネットワーク端末で利用する通信プロトコルの構成を示す図である。
【図５】モバイルエージェントの移動処理を示す図であり、（ａ）はリソース不足への対応についての処理態様を示し、（ｂ）は通信障害への対応についての処理態様を示す。
【図６】エージェントＰＦ間での通信機能を示す図である。
【図７】装置アクセスソフトウェアの構成を示す機能ブロック図である。
【図８】ツリー構造とオブジェクトの構成を示す構成図である。
【図９】シーケンシャルファイルとオブジェクトとの対応関係を示す図である。
【図１０】対照テーブルの構成を示す図である。
【図１１】エージェントＰＦでの処理の流れを示すフローチャートである。
【図１２】保護制御装置からデータを取得する場合の処理の流れを示すフローチャートである。
【図１３】保護制御装置に対してデータ設定を行なう場合の処理の流れを示すフローチャートである。
【図１４】イベント監視部によるデータ取得の処理の流れを示すフローチャートである。
【図１５】エージェント技術を適用したシステムの基本アーキテクチャを示す図である。
【図１６】エージェントシステムモデルを示す図であり、（ａ）はハードウェア構成を示し、（ｂ）はソフトウェア構成を示す。
【図１７】仕様化する部位を示す図である。
【図１８】エージェントＰＦの構成を示す機能ブロック図である。
【図１９】異なるエージェント間で情報交換するための機能を示す図であり、（Ａ）はエージェントによる移動と処理ロジックの実行とを示し、（Ｂ）は処理ロジックの一例を示す。
【図２０】イベント処理機能と外部インターフェースの構成を示す図であり、（ａ）はイベント処理機能を示し、（ｂ）は外部インターフェースとの連携を示す。
【図２１】装置アクセスソフトウェアの構成を示す図である。
【図２２】装置アクセスソフト機能が収容するデータと処理内容を示すであり、（ａ）は検索ツリーとオブジェクトを示し、（ｂ）は情報取得時の処理内容を示す。
【図２３】情報モデルのツリー構成を示す図であり、（ａ）は設備モデルを示し、（ｂ）は運用モデルを示す。
【図２４】遠隔整定の処理態様を示す機能ブロック図である。
【図２５】事故情報配信の処理態様を示す機能ブロック図である。
【図２６】エージェントの状態遷移の処理態様を示す図である。
【図２７】モバイルエージェントが事故解析情報を集配信する態様を示す図である。
【図２８】装置アクセスソフトウェアにおける異なるデータの収容形態を示す図である。
【図２９】エージェントＰＦを構成している機能とその機能が対応する事柄との対応関係を示す図である。
【符号の説明】
【０１３６】
１ 制御システム
２ 電気所
３ 運転所
４ 保守所
５ データセンター
６ ＷＡＮ
７ ＬＡＮ
９ 電気所サーバ
１２ 設備保全サーバ
１５ 保守用ＣＰＵ
１６ リレー用ＣＰＵ
１７ 監視制御サーバ
１８ エージェントＰＦ
１９ 装置アクセスソフトウェア
２０ 外部サービスＩ／Ｆ
２１ イベント処理手段
２９ 外部イベント受信部
３０ 内部イベント受信部
３１ フィルター部
３２ 運用者用ルーチング部
３３ エージェント用ルーチング部
３４ 記憶部
３５ 履歴作成部
３６ 運用者用プロファイル
３６ａ、３７ａ 転送可否条件
３６ｂ、３７ｂ 転送先テーブル
３７ エージェント用プロファイル
３８ 装置アクセス機能
３９ イベント監視部
４０ 情報モデル変換部
４０ａ、４４ａ メモリ
４１ 独自アクセス部
４３ ツリー検索部
４４ データ収容部
４５ ツリー構造
【技術分野】
【０００１】
本発明は、データ処理システム及び方法に関し、さらに詳しくは、複数の異なる種類の機器がネットワークを介して接続されている環境下において、エージェントと、このエージェントが指定した機器との間でデータの授受を行なわせるためのデータ処理システム及び方法に関する。
【背景技術】
【０００２】
現在、電力会社では、業務の効率化、保守・運用コストの低廉化を図るために、発電所、変電所、給電所などの電力系統で使用されている様々な機器を自立的な分散処理が可能なモバイルエージェントを用いて統一的に管理することが検討されている。モバイルエージェントは、処理プログラムと処理に必要なデータとが一体化し、ネットワーク内を移動するソフトウェアであり、移動先のノードにおいて所定の処理を実行する。このモバイルエージェントをネットワークを介してノード間を巡回させることにより各ノードに対応した情報の集配信が可能となる。
【０００３】
ところで、上記の電力系統では、メーカや設定内容などの属性が互いに異なる多数の機器が使用されている。属性が異なると機器について入出力されるデータ形式にも差異が生じる。このような多様な機器をモバイルエージェントを用いて遠隔管理する場合、モバイルエージェントが各機器のデータを集配信するにあたって、各機器に対応したデータ形式に変換することが必要となる。そこで、データ形式を統一することにより各機器へのデータ集配信を可能にする技術が提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１には、各機器が所有しているデータのうち、全ての機器に共通しているデータのみを取得し、それ以外の冗長データを排除するといった技術が開示されている。
【特許文献１】特開２０００−９９４７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、共通データ以外のデータを冗長データとして排除するといった方法では、機器を管理する上で必要な詳細データも失われてしまうため、個々の機器に対して十分な管理が行なえなくなってしまうといった問題が生じる。
【０００６】
そこで、本発明は、多様な機器の中から特定の機器を迅速に検索するとともに、その機器を管理する上で必要な詳細データを取得することができるデータ処理システム及び方法を提供することを目的とする。加えて、多様な機器の中から特定の機器を迅速に検索するとともに、その機器に対して的確なデータ設定を行なうことができるデータ処理システム及び方法を提供することも本発明のもう１つの目的とする。
【課題を解決するための手段】
【０００７】
かかる目的を達成するために、請求項１記載の発明にかかるデータ処理システムは、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データをラッパーオブジェクト形式で取得するデータ取得手段とを設けたことを特徴としている。
【０００８】
また、請求項３記載の発明にかかるデータ処理方法は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データをラッパオブジェクト形式でデータ取得手段によって取得するステップとを設けたことを特徴としている。
【０００９】
したがって、入出力されるデータ形式が異なる複数の機器に関するデータを各機器固有のデータとともにツリー構造を用いて体系的に管理することができるので、特定の機器に関するデータを取得する場合、そのデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができる。
【００１０】
上記目的を達成するために請求項２の発明にかかるデータ処理システムは、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうものであり、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定を行なうデータ設定実行手段とを設けたことを特徴としている。
【００１１】
また、請求項４記載の発明にかかるデータ処理方法は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうものであり、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定実行手段によってデータ設定を行なうステップとを設けたことを特徴とするデータ処理方法。
【００１２】
したがって、入出力されるデータ形式が異なる複数の機器に関するデータをツリー構造を用いて体系的に管理することが可能となり、特定の機器に対してデータ設定を行なう場合、そのデータ設定を迅速且つ的確に行なうことができる。
【発明の効果】
【００１３】
以上のように、請求項１記載のデータ処理システム、請求項３記載のデータ処理方法によれば、複数の機器に関するデータをツリー構造を用いて体系的に管理することにより、必要なデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができるので、業務の効率化、管理コストの低廉化を図ることができる。
【００１４】
また、請求項２記載のデータ処理システム、請求項４記載のデータ処理方法によれば、複数の機器に関するデータをツリー構造を用いて体系的に管理することにより、特定の機器に対してのデータ設定を迅速且つ的確に行なうことができるので、業務の効率化、管理コストの低廉化を図ることができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の構成を図面に示す最良の形態に基づいて詳細に説明する。
【００１６】
図１〜１４に本発明のデータ処理システム及び方法の一実施形態を示す。本発明のデータ処理システムである装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の保護制御装置の中から保護制御機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ取得要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データをラッパーオブジェクト形式で取得するデータ取得実行手段として機能する情報モデル変換部４０とを設けたことを特徴としている。
【００１７】
また、装置アクセスソフトウェア１９は、入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するものであり、複数の保護制御装置に関する装置データをツリー構造４５を用いてラッパーオブジェクト形式で保持するデータ保持手段として機能するデータ収容部４４と、入力されたデータ設定要求信号に基づいてツリー構造４５から装置データを指定するデータ指定手段として機能するツリー検索部４３及びデータ収容部４４と、ツリー検索部４３及びデータ収容部４４によって指定された装置データを用いて、このデータに対応した保護制御装置に対してデータ設定を行なうデータ設定実行手段として機能する情報モデル変換部４０及び独自アクセス部４１とを設けたことを特徴としている。
【００１８】
図１に示すように、制御システム１は、ネットワークを介して相互に接続されている電気所２、運転所３、保守所４、及びデータセンター５から構成されている。電気所２、運転所３、保守所４、及びデータセンター５はＩＰベースのＷＡＮ６を介して相互に接続されている。電気所２は、いわゆる変電所や発電所と呼ばれているものである。電気所２にはＩＰベースのＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。ＬＡＮ７には、多数の保守用ＣＰＵの他に、これらの保守用ＣＰＵや運転所３、保守所４、及びデータセンター５のノードに対して各種サービスを提供するための電気所サーバ９が接続されている。
【００１９】
電気所２に設置されている各保守用ＣＰＵには、例えば、変圧器（図示省略）を構成している部品の状態を監視するためのセンサ、電流計、電圧計などの機器（図示省略）が接続されている。例えば、保守用ＣＰＵ１０には変圧器（図示省略）で使用されているゴム部材の温度を監視するための温度センサ１１が接続されている。この温度センサ１１での検知結果は保守用ＣＰＵ１０に入力される。保守用ＣＰＵ１０は、温度センサ１１から入力された検知結果に基づいて、例えば、ゴム部材の劣化状態を判断し、その判断結果を後述するモバイルエージェントを用いて保守所４の設備保全サーバ１２などに通知する。
【００２０】
リレー１３は、ＶＣＴ１４、電流計、電圧計、変圧器、遮断器（図示省略）などの機器の状態を監視するものであり、保守用ＣＰＵ１５とリレー用ＣＰＵ１６とから構成されている。保守用ＣＰＵ１５にはリレー用ＣＰＵ１６を介して上記の機器が接続されている。ＶＣＴ１４とは、変圧器（VT：Voltage Transformer）及び変流器（CT：Current Transfer）の総称である。リレー用ＣＰＵ１６は、例えば、ＶＣＴ１４で測定された測定値が予め定められた閾値を超えたか否かを識別し、その識別結果を保守用ＣＰＵ１５に入力する。また、遮断器の場合には、遮断器が作動したか否かを識別し、その識別結果を保守用ＣＰＵ１５に入力する。
【００２１】
運転所３は、いわゆる給電所や制御所と呼ばれるものであり、電気所２に設置されている各機器の開閉状態を制御する。運転所３には電気所２と同様にＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。運転所３のＬＡＮ７に接続されている監視制御サーバ１７は、電気所２に設定されている各機器に対して開閉状態を制御しており、各機器が接続している系統の潮流状態の状態変化に応じて潮流を制御する。
【００２２】
保守所４は、いわゆる電力所と呼ばれるものであり、電気所２に設置されている各機器の保守を行なう。保守所４には電気所２や運転所３と同様にＬＡＮ７が構築されており、このＬＡＮ７はルータ８を介してＷＡＮ６に接続されている。保守所４のＬＡＮ７に接続されている設備保全サーバ１２は、例えば、電気所２に設置されている複数の機器の状態変化を示す情報（例えば、各機器の劣化や故障などの不具合を示す情報）を取得して、その情報を解析することにより不具合が生じている機器を選定する。つまり、電気所２に設置されている各機器の状態変化は設備保全サーバ１２によって監視されている。電気所２に設置されている機器に不具合が生じた場合には、例えば、保守所４に所属している者が電気所２に行き、その機器に対して点検や修理などを行なう。あるいは、設備保全サーバ１２が不具合の生じた機器に接続されている保守用ＣＰＵに向けてその不具合に対しての処置プログラムなどを搭載したモバイルエージェントを送る。
【００２３】
データセンター５は、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃを備えている。図２に示すように、位置管理装置５ａは、管理対象となるエージェントプラットフォーム（以下、「エージェントＰＦ」と称する）１８からの情報を基に、モバイルエージェントの位置や処理進捗状況を管理する。この位置管理装置５ａにより、モバイルエージェントの状態（例えば、移動中、処理中、停止中、アラーム状態など）の取得やモバイルエージェントの動作（例えば、使用、ロック動作など）の変更指示が可能となる。なお、図３に示す「エージェントＣＰＵ」とは、サーバ９、１２、１７、及び電気所２内の保守用ＣＰＵの総称である。
【００２４】
装置情報データベース５ｂは、モバイルエージェントが収集した情報を蓄積する。系統データベース５ｃは、系統情報（例えば、電気所２の一覧など）や電気所２で使用されているリレー１３の特性に関する情報などを蓄積する。
【００２５】
図３に示すように、保守用ＣＰＵ１５は、モバイルエージェントＡ、Ｂと、このモバイルエージェントＡ、Ｂの実行環境であるエージェントＰＦ１８と、モバイルエージェントＡの要求に応じてリレー用ＣＰＵ１６やこのリレー用ＣＰＵ１６に接続されているＶＣＴ１４、電流計、電圧計、変圧器、遮断器などの機器（以下、リレー用ＣＰＵ１６、及びこのリレー用ＣＰＵ１６に接続されている上記機器の総称を「保護制御装置」とする）からその機器に関するデータ（以下、保護制御装置に関するデータを「装置データ」と称する）を取得したり、モバイルエージェントＡの要求に応じて保護制御装置に対してデータ設定を行なう装置アクセスソフトウェア１９とから構成されている。なお、電気所２に設定されている保守用ＣＰＵ１５以外の各保守用ＣＰＵも保守用ＣＰＵ１５と同様に構成されている。また、各サーバは、モバイルエージェントとエージェントＰＦ１８を備えている。
【００２６】
リレー用ＣＰＵ１６と装置アクセスソフトウェア１９との間の信号の授受はバスあるいはイーサネット（登録商標）ケーブル２０を介して行なわれる。詳しくは後述するが、リレー用ＣＰＵ１６から装置アクセスソフトウェア１９に入力される装置データは、装置アクセスソフトウェア１９によってツリー構造を用いたラッパオブジェクト形式で体系的に管理されている。なお、本実施形態では、モバイルエージェントＡ、Ｂを、エージェントＰＦ１８で生成されたものか、あるいは保守用ＣＰＵ１５以外の保守用ＣＰＵや各種サーバからエージェントＰＦ１８に送り込まれたものであるとする。また、本実施形態では説明の便宜上モバイルエージェントＡ、Ｂを用いているが、モバイルエージェントの数は適宜に変更可能である。
【００２７】
モバイルエージェントＡ、Ｂは、プログラムとデータが一体化し、ＬＡＮ７やＷＡＮ６などのネットワーク内を移動するソフトウェアである。このモバイルエージェントＡ、Ｂは、例えば、電気所２内の複数の保守用ＣＰＵを巡回して、事故や故障などの障害に関する情報を集配信する。また、電気所２内で収集したデータをサーバ１２、１７、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃに配信する。また、サーバ１２、１７、位置管理装置５ａ、装置情報データベース５ｂ、及び系統データベース５ｃから得たデータを電気所２内の各保守用ＣＰＵに配信する。また、場合によっては、データ加工などの付加的な処理も行なう。このようにモバイルエージェントＡ、Ｂが各ノード間を巡回することにより、運転所３や保守所４のサーバ１２、１７から電気所２内の保護制御装置に対して遠隔監視、遠隔設定、遠隔調整を行なうことが可能となる。
【００２８】
保守用ＣＰＵ１５のエージェントＰＦ１８は、保護制御装置の状態変化（例えば、ＶＣＴ１４での測定値が予め定められた閾値を超えたということ）、モバイルエージェントＡ、Ｂの状態変化（例えば、モバイルエージェントＡ、Ｂの少なくともいずれか１つが保守用ＣＰＵ１５以外の保守用ＣＰＵや各種サーバ、データセンター５などに移動したり、モバイルエージェントＡ、Ｂの少なくともいずれか１つがエラー処理を行なったりしたということ）をイベントとして取得し、そして、そのイベントの内容に応じてモバイルエージェントＡ、Ｂ以外に新たにモバイルエージェントを生成したり、その生成したモバイルエージェントを保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７などのエージェントＰＦ１８に転送したり、保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７から送られてきたモバイルエージェントを起動させたりするなどといった機能を有している。また、モバイルエージェントには、処理期限や優先度などが付与されており、これに基づいてエージェントＰＦ１８はモバイルエージェントの制御を行い、個々のモバイルエージェントに必要な性能や信頼性を満足するように運用者用プロファイル３６やエージェント用プロファイル３７に基づいて処理を実行する。イベントとしては、外部イベントと内部イベントとがある。外部イベントとは、保護制御装置の状態変化を示す。この状態変化は、装置アクセスソフトウェア１９によって検知され、外部イベントとして外部サービスインターフェース２０で受信される。その具体的な内容は、例えば、イベントの種別、イベントを発した装置の名称、後述するツリー構造のラッパオブジェクトとの関連付けで使用される識別子、イベントの送信希望先などとなっており、これらのデータは装置アクセスソフトウェア１９によってツリー構造４５（図８及び図９参照）を用いて管理されている。内部イベントとは、モバイルエージェントＡ、Ｂの状態変化を示し、その具体的な内容は、例えば、イベントの種別、イベントを発したモバイルエージェントに関するデータ、補足データ、イベントの送信希望先などとなっている。
【００２９】
以下、エージェントＰＦ１８の具体的な構成について説明する。エージェントＰＦ１８は、ハードディスクなどの大容量記憶手段に格納されたプログラムを実行することによって外部サービスインターフェース２０、イベント処理手段２１、位置管理部２２、リソース管理部２３、エージェント生成部２４、エージェント削除部２５、処理ロジック管理部２６、エージェント処理管理部２７、及び通信制御部２８として機能する。
【００３０】
外部サービスインターフェース２０は、装置アクセスソフトウェア１９とイベント処理手段２１とを仲介するものである。装置アクセスソフトウェア１９がモバイルエージェントＡ、Ｂに対して外部イベントを送る際には、外部サービスインターフェース２０が呼び出される。これにより、イベントがモバイルエージェントＡ、Ｂに送られる。外部サービスインターフェース２０によって受信された外部イベントは、その内容に応じて、イベント処理手段２１または保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ９、１２、１７におけるエージェントＰＦ１８の外部サービスインターフェース２０に転送される。なお、保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバの外部サービスインターフェース２０との通信は通信制御部２８によって実現される。具体的には、外部サービスインターフェース２０が外部イベントを受け取り、それを保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバの外部サービスインターフェース２０に転送する場合、図４に示す通信プロトコルを用いて転送処理を実行する。
【００３１】
イベント処理手段２１は、イベントの内容に応じてイベントの転送処理を行うものであり、外部イベント受信部２９、内部イベント受信部３０、フィルター部３１、運用者用ルーチング部３２、エージェント用ルーチング部３３、記憶部３４、及び履歴作成部３５から構成されている。
【００３２】
外部イベント受信部２９は、外部サービスインターフェース２０から転送された外部イベントを受信し、それをフィルター部３１に転送する。内部イベント受信部３０は、内部イベントを受信し、それをフィルター部３１に転送する。このように外部イベント受信部２９及び内部イベント受信部３０は、モバイルエージェントＡ、Ｂと保守用ＣＰＵ１５によって監視されている保護制御装置との少なくともいずれか一方からのイベントを受信する状態変化データ受信手段として機能する。
【００３３】
フィルター部３１は、内部イベント受信部３０または外部イベント受信部２９からイベントが入力されたことを契機に、記憶部３４に予め格納されている運用者用プロファイル３６及びエージェント用プロファイル３７を読み出す。これらのプロファイルにはイベントの種類に対応した転送可否条件３６ａ、３７ａが記載されており、フィルター部３１は、その転送可否条件３６ａ、３７ａに基づいて転送処理の必要性を判断する。そして、転送が必要であると判断した場合、そのイベントを運用者用ルーチング部３２に転送する。転送が必要でないと判断した場合、そのイベントを廃棄する。なお、転送可否条件とは、例えば、イベントの種別、イベントの送信元、イベントの送信先エージェントなどのことを示し、フィルター部３１は、これらの条件を満足したイベントのみを運用者用ルーチング部３２に転送する。
【００３４】
このように記憶部３４は、外部イベント受信部２９や内部イベント受信部３０で受信したイベントの転送可否条件３６ａ、３７ａを記憶した転送可否条件記憶手段として機能する。また、フィルター部３１は、内部イベント受信部３０や外部イベント受信部２９からイベントが入力されたことを契機に、記憶部３４から転送可否条件３６ａ、３７ａを読み出す転送可否条件読み出し手段として機能する。また、フィルター部３１は、その読み出された転送可否条件３６ａ、３７ａに基づいてイベントの転送の可否を判定する転送可否判定手段として機能する。
【００３５】
運用者用ルーチング部３２は、フィルター部３１からイベントが入力されたことを契機に、記憶部３４の運用者用プロファイル３６を読み出す。この運用者用プロファイル３６には、イベントの種類ごとの転送先が示された転送先テーブル３６ｂが記載されており、運用者用ルーチング部３２は、その転送先テーブル３６ｂを参照してフィルター部３１から入力されたイベントをエージェント用ルーチング部３３に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントを廃棄し、転送の必要があると判断した場合、次に、運用者用プロファイル３６の転送先テーブル３６ｂに基づいてイベントを履歴作成部３５に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントをそのままエージェント用ルーチング部３３に転送し、転送の必要があると判断した場合（障害履歴を作成してイベントを履歴情報として保存する必要がある場合）、イベントを複製して一方のイベントをエージェント用ルーチング部３３に、他方のイベントを履歴作成部３５に転送する。運用者用プロファイル３６とは、例えば、運転所３、保守所４、電気所２、データセンター５などの運用者がイベントごとの処理の仕方を記録したデータファイルのことであり、これはキーボード等の入力装置によって作成される。このように運用者用ルーチング部３２では、運用者の要求に基づいてイベントが処理される。なお、本実施形態では、転送先として履歴作成部３５とエージェント用ルーチング部３３との２つを設定したが、転送先は上記の２つとは限らず転送先が３つ以上ある場合も考えられる。この場合、イベントは転送先の数だけ複製される。
【００３６】
以上のように、記憶部３４は、イベントの種類に対応した転送先が保持されている転送先テーブル３６ｂを記憶した転送先テーブル記憶手段として機能する。また、運用者用ルーチング部３２は、フィルター部３１で転送許可の判定を受けたイベントが入力されたことを契機に、記憶部３４から転送先テーブル３６ｂを読み出す転送先テーブル読み出し手段として機能する。また、運用者用ルーチング部３２は、その読み出された転送先テーブル３６ｂに基づいてイベントの転送先を決定する転送先決定手段として機能する。また、運用者用ルーチング部３２は、その決定された転送先にイベントを転送する状態変化データ転送手段として機能する。
【００３７】
履歴作成部３５は、モバイルエージェントＡ、Ｂの振る舞いやリレー用ＣＰＵ１６からの信号などによりイベントが発生したときにその日時やイベントを発した箇所の名称やその詳細情報を自身のメモリ（図示省略）に記録し、その記録を入力装置からの入力操作に応答して液晶パネル等の表示器（図示省略）に表示する。
【００３８】
エージェント用ルーチング部３３は、運用者用ルーチング部３２からイベントが入力されたことを契機に、記憶部３４のエージェント用プロファイル３７を読み出す。このエージェント用プロファイル３７には、イベントの種類ごとの転送先が示された転送先テーブル３７ｂが記載されており、エージェント用ルーチング部３３は、その転送先テーブル３７ｂを参照して運用者用ルーチング部３２から入力されたイベントをモバイルエージェントＢに転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントを廃棄し、転送の必要があると判断した場合、次に、エージェント用プロファイル３７に基づいてイベントを履歴作成部３５に転送するか否かの必要性を判断する。そして、転送の必要がないと判断した場合、イベントをそのままモバイルエージェントＢに転送し、転送の必要があると判断した場合、イベントを複製して一方のイベントをモバイルエージェントＢに、他方のイベントを履歴作成部３５に転送する。エージェント用プロファイル３７とは、保守用ＣＰＵやサーバなどでエージェントを使用している者（以下、「エージェント使用者」と称する）がイベントごとの処理の仕方を記録したデータファイルのことであり、これはキーボード等の入力装置によって作成される。このようにエージェント用ルーチング部３３では、エージェント使用者の要求に基づいてイベントが処理される。なお、本実施形態では、転送先として履歴作成部３５とモバイルエージェントＢとの２つを設定したが、転送先は上記の２つとは限らず転送先が３つ以上ある場合も考えられる。この場合、イベントは転送先の数だけ複製される。
【００３９】
以上のように、記憶部３４は、イベントの種類に対応した転送先が保持されている転送先テーブル３７ｂを記憶した転送先テーブル記憶手段として機能する。また、エージェント用ルーチング部３３は、フィルター部３１で転送許可の判定を受けたイベントが入力されたことを契機に、記憶部３４から転送先テーブル３７ｂを読み出す転送先テーブル読み出し手段として機能する。また、エージェント用ルーチング部３３は、その読み出された転送先テーブル３７ｂに基づいてイベントの転送先を決定する転送先決定手段として機能する。また、エージェント用ルーチング部３３は、その決定された転送先にイベントを転送する状態変化データ転送手段として機能する。
【００４０】
エージェント用ルーチング３３がモバイルエージェントＢにイベントを転送した場合、そのモバイルエージェントＢは、エージェント用ルーチング３３から転送されたイベントに対応した処理プログラムに基づいた処理を実行する。例えば、モバイルエージェントＢは、エージェント用ルーチング３３からイベントが入力されたことを契機に、保守用ＣＰＵ１５以外の保守用ＣＰＵへの移動を依頼することを示す移動依頼信号を通信制御部２８に入力する。この他にも、エージェント用ルーチング３３から入力されたイベントの内容によってはリソース管理部２３、エージェント生成部２４、エージェント削除部２５などにイベントを転送するといった処理も実行する。このようにエージェント用ルーチング３３からイベントが入力されたときのモバイルエージェントＢの振る舞いはモバイルエージェントＢに設定されている処理プログラムの内容によって決定する。
【００４１】
エージェント生成部２４は、モバイルエージェントＡ、Ｂの少なくともいずれか１つが新たなモバイルエージェントを生成する必要があると判断した場合に、その要求に基づいてモバイルエージェントの生成を行なう。エージェント削除部２５は、モバイルエージェントＡ、Ｂの少なくともいずれか１つが既存のエージェントを削除する必要があると判断した場合に、その要求に基づいてモバイルエージェントの削除を行なう。
【００４２】
処理ロジック管理部２６は、エージェント生成部２４によってモバイルエージェントが生成された場合、あるいは他の保守用ＣＰＵやサーバなどから通信制御部２８を介してモバイルエージェントがエージェントＰＦ１８内に送り込まれてきた場合、そのモバイルエージェントに対して予め定められた処理ロジックを実行させる。
【００４３】
エージェント処理管理部２７は、処理ロジック管理部２６を制御しており、エージェントＰＦ１８上のモバイルエージェントＡ、Ｂの処理の管理を行なう。つまり、モバイルエージェントの状態変化を管理し、その状態変化を内部イベントとして内部イベント受信部３０に入力する。また、モバイルエージェントの起動や演算処理に失敗した場合にもそれを内部イベントとして内部イベント受信部３０に入力する。
【００４４】
位置管理部２２は、モバイルエージェントＡ、Ｂが移動した場合に、その移動を開始した時間や移動先などを管理するものである。具体的には、管理対象となるエージェントＰＦ１８からの情報を基に、モバイルエージェントＡ、Ｂの位置や処理進捗状況を管理する。この位置管理部２２によりモバイルエージェントＡ、Ｂの動作状況（移動中・処理中・停止中・アラーム等）の取得や、モバイルエージェントＡ、Ｂの動作（使用・ロック）の変更指示を可能とする。例えば、モバイルエージェントＡが移動した場合に、その移動を開始した時間や移動先などを自身のメモリ（図示省略）に記録するとともに、その記録内容を表示器（図示省略）に表示する。
【００４５】
リソース管理部２３は、エージェントＰＦ１８に動作環境を提供している保守用ＣＰＵ１５のメモリ量や負荷、エージェントＰＦ１８上のモバイルエージェントの数を監視しており、リソース不足を防止するための処理を行なう。具体的な処理としては、メモリ量や負荷が上限値を超過した場合には、ガーベッジコレクションを実行する。また、他のエージェントＰＦ１８からのモバイルエージェントの転送を拒否するように通信制御部２８を制御する。さらに、リソース不足が発生した場合、それを内部イベントとして内部イベント受信部３０に入力する。イベント処理手段２１は、リソース不足を示す内部イベントが入力されたことを契機に、モバイルエージェントＡ、Ｂの停止、削除、エージェントＰＦ１８の再起動などの処理を実行する。
【００４６】
通信制御部２８は、保守用ＣＰＵ１５上のエージェントＰＦ１８と保守用ＣＰＵ１５以外の保守用ＣＰＵやサーバ上のエージェントＰＦ１８（例えば、保守用ＣＰＵ１０のエージェントＰＦ１８やサーバ９のエージェントＰＦ１８）との間の通信、具体的には、モバイルエージェントＡ、Ｂの他のエージェントＰＦ１８への移動（図５参照）、エージェントＰＦ１８内のモバイルエージェントと他のエージェントＰＦ１８のモバイルエージェントとの通信（図６参照）を実現させるためのインターフェースとして機能する。このようなエージェントＰＦ１８間の通信は、図４に示す通信プロトコルによって実現される。また、通信制御部２８は、エージェントＰＦ１８内のモバイルエージェント間での通信を実現させるためのインターフェースとしても機能する。さらに、イベントを転送する際のインターフェース（例えば、エージェントＰＦ１８内のモバイルエージェントの振る舞いを内部イベントとして内部イベント受信部３０に入力するためのインターフェース）としても機能する。
【００４７】
図５に示すように、モバイルエージェントを他のエージェントＰＦ１８に移動させる場合、エージェントＰＦ１８の通信制御部２８は、モバイルエージェントから入力された移動依頼信号に応答してモバイルエージェントの処理動作を停止させ、モバイルエージェントが指定したエージェントＰＦ１８にモバイルエージェントを移動させる。ネットワークの障害などによりモバイルエージェントの移動が失敗した場合には、再送を行なう。そして、その移動が完了すると、モバイルエージェントは移動先のエージェントＰＦ１８上で起動する。また、通信制御部２８は、移動が成功したか失敗したかを示す情報を内部イベントとして内部イベント受信部３０に入力する。
【００４８】
図６に示すように、エージェントＰＦ１８内のモバイルエージェントと他のエージェントＰＦ１８のモバイルエージェントとで通信を行なう場合、通信制御部２８は、タイムアウト機能、リトライ機能を提供する。タイムアウト時間およびリトライ回数は、プロファイルで指定する。通信方法としては、個別に通信する方法、つまり、１対１で通信する方法とマルチキャストで通信する方法をサポートする。また、通信方法としては、「応答ありの同期通信」「応答ありの非同期通信」「応答なしの片方向通信」の３種類をサポートする。エージェント間通信で授受する情報としては、文字列情報や装置アクセスソフトウェア１９から得たオブジェクトなどがある。授受する情報の形式は、シリアライザブルとする。メッセージの送信・応答結果の受信については、オブジェクトクラスＰｒｏｘｙを用いる。この方法により、外部から直接モバイルエージェントを操作することを防止する。
【００４９】
以上のように、通信制御部２８は、保守用ＣＰＵ１５上のモバイルエージェントから入力された移動依頼信号に応答してそのモバイルエージェントを保守用ＣＰＵ以外の保守用ＣＰＵやサーバなどのノードに移動させる移動制御手段として機能する。
【００５０】
図７に示すように、装置アクセスソフトウェア１９は、モバイルエージェントＡからの要求に応じてリレー用ＣＰＵ１６やそのリレー用ＣＰＵ１６に接続されているＶＣＴ１４などの機器に関するデータを取得する。また、モバイルエージェントＡからの要求に応じてリレー用ＣＰＵ１６やそのリレー用ＣＰＵ１６に接続されているＶＣＴ１４などの機器に対してデータ設定を行なう。さらに、外部イベントをエージェントＰＦ１８に送るといった機能も有している。保護制御装置に関する装置データは、ハードディスクなどの記憶手段に記憶されており、後述するデータ収容部４４によりオブジェクトとしてツリー構造を用いて体系的に管理されている。
【００５１】
装置アクセスソフトウェア１９は、装置アクセス機能３８、イベント監視部３９、情報モデル変換部４０、及び独自アクセス部４１から構成されている。装置アクセス機能３８は、エージェントＡやエージェントＰＦ１８とのインタフェースとして機能を有する装置アクセスＡＰＩ４２（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）４２と、モバイルエージェントＡあるいはイベント監視部３９から入力されるデータ取得の要求を示すデータ取得要求信号またはデータ設定の要求を示すデータ設定要求信号に応じてツリー構造の中からオブジェクト群（図８参照）を指定する機能を有するツリー検索部４３と、ツリー検索部４３で指定したオブジェクト群をさらに絞り込む機能を有するデータ収容部４４とを備えている。
【００５２】
モバイルエージェントＡと装置アクセスソフトウェア１９との間でのデータの授受は、装置アクセスＡＰＩ４２を介して行なわれる。装置アクセスＡＰＩ４２は、モバイルエージェントＡからのデータ取得要求信号またはデータ設定要求信号を受信してそれを装置アクセスソフトウェア１９に送るとともに、モバイルエージェントＡへその要求信号に対しての結果を送る。また、装置アクセスＡＰＩ４２は、装置アクセスソフトウェア１９からの外部イベントを受信してエージェントＰＦ１８に送る。なお、上記の「データ取得」とは、モバイルエージェントＡが指示した保護制御装置に関する装置データの取得を示し、上記の「データ設定」とは、モバイルエージェントＡが指示した保護制御装置に対して行なうデータ設定を示す。
【００５３】
データ収容部４４は、装置データをメモリ４４ａ上でツリー構造４５を用いてラッパオブジェクト形式で保持する。なお、ツリー構造を用いて管理されている装置データをオブジェクトと称する。
【００５４】
データ収容部４４は、例えば、図８に示すように、ＸＭＬのＤＢ（データベース）やＪａｖａ（登録商標）形式でデータを入出力するソフトウェアを備えており、ツリー構造を構成している多数のオブジェクトをＸＭＬに属するオブジェクトとＪａｖａ形式に属するオブジェクトとに分割した状態で管理している。
【００５５】
ツリー検索部４３は、モバイルエージェントＡから装置アクセスＡＰＩ４２を介して入力されたデータ取得要求信号またはデータ設定要求信号に含まれるスコープ情報に基づいてツリー構造４５のオブジェクトを指定する。スコープ情報とは、ツリー構造４５上で指定したオブジェクトを起点として、例えば、その起点のオブジェクトのみを指定したり、第１階層（起点の１つ下の階層）のオブジェクトを指定したり、起点以下の全ての階層のオブジェクトを指定したり、起点から数えて第Ｎ番目の階層のオブジェクトを指定したり、または、第Ｎ番目の階層までのオブジェクトを指定したりすることを示す情報のことである。
【００５６】
データ収容部４４は、モバイルエージェントＡから装置アクセスＡＰＩ４２、ツリー検索部４３を介して入力されたデータ取得要求信号またはデータ設定要求信号に含まれるフィルター情報に基づいてツリー検索部４３で選択されたオブジェクト群をさらに絞り込む。フィルター情報とは、スコープ情報に基づいて選択されたオブジェクト群に対してさらに指定した条件を満足するオブジェクトだけに絞り込むための情報であり、具体的には、指定した属性値の大小、属性値の一致などを示す情報である。なお、独自アクセス部４１がデータ収容部４４と同様のフィルター情報による絞り込み機能を有している場合、モバイルエージェントＡからのフィルター情報は独自アクセス部４１に送られて、独自アクセス部４１でフィルター情報による絞り込みが行なわれる。
【００５７】
このようにツリー検索部４３及びデータ収容部４４の検索機能を用いることにより容易にモバイルエージェントＡが指定するオブジェクトを検索することができる。例えば、図８に示すように、スコープ情報がＸＭＬ形式のオブジェクトを全て指定するといったものであった場合には、ツリー検索部４３によってツリー構造４５の中のＸＭＬのＤＢ、つまり、ＸＭＬ形式のオブジェクト群が全て選択される。また、スコープ情報がＪａｖａ形式のラッパオブジェクトを全て指定するといったものであった場合には、ツリー構造４５の中のＪａｖａ形式データ入出力ソフトウェア、つまり、Ｊａｖａ形式のオブジェクト群が選択される。そして、スコープ情報によりＸＭＬのＤＢが選択された場合、データ収容部４４は、ＸＭＬのソフトウェア上でフィルター情報に基づいてオブジェクトをさらに絞り込む。また、スコープ情報によりＪａｖａ形式データ入出力ソフトウェアが選択された場合、データ収容部４４は、Ｊａｖａ形式データ入出力ソフトウェア上でフィルター情報に基づいてオブジェクトをさらに絞り込む（図９参照）。
【００５８】
データ収容部４４は、上記のようにして絞り込まれたオブジェクトを情報モデル変換部４０に入力するとともに、モバイルエージェントＡから入力されたデータ取得要求信号またはデータ設定要求信号を情報モデル変換部４０に転送する。
【００５９】
情報モデル変換部４０のメモリ４０ａには、独自アクセス部４１でのデータ入出力で使用されるシーケンシャルファイル４６とツリー構造４５上の各オブジェクトとを対応付けた対照テーブル４７が格納されている（図１０参照）。独自アクセス部４１で使用されるシーケンシャルファイル４６は、複数のデータ記録領域に区切られており、予め各領域ごとに識別子が付されている。他方、ツリー構造４５の各オブジェクトにも識別子が付されており、このオブジェクトの識別子とシーケンシャルファイル４６の各領域ごとの識別子とは対照テーブル４７において１対１で対応付けられている。
【００６０】
情報モデル変換部４０は、オブジェクトの識別子とシーケンシャルファイル４６の各データ記録領域ごとに付されている識別子との対応関係が記録されている対照テーブル４７を参照しながらシーケンシャルファイル４６に記録されている各データをツリー構造４５のオブジェクトに変換したり、逆に、ツリー構造４５のオブジェクトをシーケンシャルファイル４６に変換したりする。
【００６１】
独自アクセス部４１は、ベンダ固有のインターフェースであり、ネットワークに接続されている複数の保守用ＣＰＵの中には保守用ＣＰＵ１５の独自アクセス部４１とはベンダの異なる独自アクセス部４１を使用しているものも存在している。独自アクセス部４１は、データ収容部４４で指定されたオブジェクトの内容に基づいて保護制御装置から装置データの読み出し、または、保護制御装置に対して装置データの書き込みを行なう。
【００６２】
モバイルエージェントＡからのデータ取得要求信号に対応したオブジェクトがデータ収容部４４で選択され、そのオブジェクトに対応した装置データを取得する場合で、例えば、データ収容部４４で選択されたオブジェクトが、保護制御装置の名称、データ種別、時刻、型形式やメーカ名などといったものであった場合、情報モデル変換部４０は、これらのオブジェクトを対照テーブル４７に基づいてシーケンシャルファイル４６の各データ記録領域に振り分ける。
【００６３】
以下、その振り分け方法を具体的に説明する。シーケンシャルファイル４６の各データ記録領域には識別子Ａ〜Ｄが付されており、例えば、識別子Ａのデータ記録領域には、保護制御装置の名称（例えば、ＶＣＴ１４など）に関するデータが記録され、識別子Ｂのデータ記録領域にはデータ種別（例えば、ＸＭＬ形式なのか、それともＪａｖａ形式なのかを識別するもの）に関するデータが記録され、識別子Ｃのデータ記録領域には時刻（例えば、保護制御装置が起動した時刻など）に関するデータが記録され、識別子Ｄのデータ記録領域には型形式やメーカ名などに関するデータが記録されるように構成されている。他方、ツリー構造４５の各オブジェクトにも識別子ａ〜ｄが付されており、識別子ａのオブジェクトは保護制御装置の名称を示し、識別子ｂのオブジェクトはデータ種別を示し、識別子ｃのオブジェクトは時刻を示し、識別子ｄのオブジェクトは型形式やメーカ名などを示す。情報モデル変換部４０は、対照テーブル４７を参照しながらａ〜ｄのオブジェクトをシーケンシャルファイル４６のＡ〜Ｄの領域に振り分ける。そして、独自アクセス部４１は、そのシーケンシャルファイル４６に従って保護制御装置から装置データを取得し、それをシーケンシャルファイル４６に記録する。情報モデル変換部４０は、独自アクセス部４１のシーケンシャルファイル４６に記録されている装置データを対照テーブル４７を用いてツリー構造４５のオブジェクトに振り分ける。そして、情報モデル変換部４０は、それをラッパオブジェクト形式で、データ収容部４４、ツリー検索部４３、装置アクセスＡＰＩ４２を介してモバイルエージェントＡに送る。
【００６４】
ツリー検索部４３及びデータ収容部４４がモバイルエージェントＡから入力されたデータ設定要求信号に基づいてオブジェクトを指定した場合、その指定されたオブジェクトは情報モデル変換部４０によってシーケンシャルファイル４６に振り分けられる。つまり、情報モデル変換部４０は、対照テーブル４７に基づいてデータ収容部４４によって選択された保護制御装置やその保護制御装置に対して付与するデータ設定値などを示すオブジェクトを独自アクセス部４１で読み取り可能なシーケンシャルファイル４６に変換する。そして、独自アクセス部４１は、そのシーケンシャルファイル４６に基づいて所定の保護制御装置に対してデータ設定を行なう。独自アクセス部４１はデータ設定が成功したか否かを示す設定実行結果信号を装置アクセスＡＰＩ４２を介してモバイルエージェントＡに入力する。
【００６５】
イベント監視部３９は、外部イベントをエージェントＰＦ１８に送るために予め定められているイベント監視プロパティ情報に従って所定のデータを監視するものであり、タイマー機能を用いて定期的にツリー検索部４３に対してデータ取得要求信号を入力する。イベント監視プロパティには、保護制御装置の状態変化が外部イベントとしてエージェントＰＦ１８に通知するべきものであるか否かを判断するためのイベント通知条件（例えば、保護制御装置のある部位の温度が閾値を超えるという条件）が含まれており、イベント監視部３９は、保護制御装置の状態変化がイベント通知条件を満足したか否かを判断し、条件を満足した場合にはエージェントＰＦ１８に通知を行なう。なお、上記の「所定のデータ」とは、例えば、予め定められた保護制御装置に関するデータのことを示す。
【００６６】
次に、イベントの処理の流れについて図１１のフローチャートを参照しながら説明する。エージェントＰＦ１８を起動させると、エージェントＰＦ１８はイベント発生を監視する（Ｓ１）。内部イベント受信部３０や外部イベント受信部２９は、イベントを受信すると、そのイベントをフィルター部３１に転送する（Ｓ２）。フィルター部３１は、内部イベント受信部３０や外部イベント受信部２９から送られたイベントを転送可否条件３６ａ、３７ａを用いて運用者用ルーチング部３２に転送するか否かを判断するためのフィルタリングを行ない、そこで転送する必要があると判断されたイベントを運用者用ルーチング部３２に転送する（Ｓ３）。フィルター部３１で転送する必要がないと判断されたイベントはフィルター部３１にて廃棄される（Ｓ４）。運用者用ルーチング部３２は、フィルター部３１から送られてきたイベントを転送先テーブル３６ｂに基づいてエージェント用ルーチング部３３に転送する必要があるか否かを判断する（Ｓ５）。ここで転送する必要がないと判断されたイベントは廃棄される（Ｓ６）。運用者用ルーチング部３２は、イベントをエージェント用ルーチング部３３に転送する必要があると判断した場合、次に、そのイベントを履歴作成部３５に転送する必要があるか否かを転送先テーブル３６ｂに基づいて判断し、「転送の必要なし」と判断した場合、イベントをそのままエージェント用ルーチング部３３に転送する（Ｓ７）。履歴作成部３５への「転送の必要が有り」と判断した場合、イベントを複製してそれらを履歴作成部３５とエージェント用ルーチング部３３に転送する（Ｓ８）。エージェント用ルーチング部３３は、転送先テーブル３７ｂに基づいて運用者用ルーチング部３２から送られてきたイベントをモバイルエージェントＢに転送する必要があるか否かを判断する（Ｓ９）。ここで転送する必要がないと判断されたイベントは廃棄される（Ｓ１０）。エージェント用ルーチング部３３は、イベントをモバイルエージェントＢに転送する必要があると判断した場合、次に、そのイベントを履歴作成部３５に転送する必要があるか否かを転送先テーブル３７ｂに基づいて判断し、「転送の必要なし」と判断した場合、イベントをそのままモバイルエージェントＢに転送する（Ｓ１１）。履歴作成部３５への「転送の必要が有り」と判断した場合、イベントを複製してそれらを履歴作成部３５とモバイルエージェントＢに転送する（Ｓ１２）。モバイルエージェントＢは、エージェント用ルーチング部３３からのイベントを内部イベントであるか否かを判断し（Ｓ１３）、それが内部イベントであればモバイルエージェントＢに対してそのイベントに対応して振る舞いを実行させ（Ｓ１４）、内部イベントでなければ、つまり、外部イベントであった場合、それを廃棄する（Ｓ１５）。Ｓ１〜Ｓ１５までの処理は、エージェントＰＦ１８の動作が停止するまで繰り返して実行される（Ｓ１６）。
【００６７】
次に、装置アクセスソフトウェア１９を用いてデータ取得を行なう際の処理の流れについて図１２を参照しながら説明する。モバイルエージェントＡが装置アクセス機能３８に対してデータ取得要求信号を入力すると、その信号をツリー検索部４３が受信する（Ｓ１０１）。ツリー検索部４３は、データ取得要求信号に含まれるスコープ情報からデータ収容部４４を指定する（Ｓ１０２）。データ収容部４４は、データ取得要求信号に含まれるフィルター情報を用いてスコープ情報で指定したオブジェクト群からさらにオブジェクトを絞り込む（Ｓ１０３）。情報モデル変換部４０は、対照テーブル４７を用いてデータ収容部４４で絞り込まれたオブジェクトを独自アクセス部４１で使用可能なデータ形式に変換する（Ｓ１０４）。独自アクセス部４１は、データ取得要求信号によって指定された保護制御装置の装置データをその装置固有のデータ形式で取得する（Ｓ１０５）。情報モデル変換部４０は、対照テーブルを用いて独自アクセス部４１で取得した装置データを装置アクセスソフトウェア１９で使用可能なデータ形式に変換し（Ｓ１０６）、その変換した装置データをオブジェクトに収容する（Ｓ１０７）。情報モデル変換部４０は、そのオブジェクトに収容した装置データをラッパーオブジェクト形式で装置アクセスＡＰＩ４２を介してモバイルエージェントＡに送る（Ｓ１０８）。
【００６８】
次に、モバイルエージェントＡが指定した機器に対して装置アクセスソフトウェア１９を用いてデータ設定を行なう際の処理の流れについて図１３を参照しながら説明する。モバイルエージェントＡが装置アクセス機能３８に対してデータ設定要求信号を入力すると、その信号をツリー検索部４３が受信する（Ｓ２０１）。ツリー検索部４３は、データ設定要求信号に含まれるスコープ情報からデータ収容部４４を指定する（Ｓ２０２）。データ収容部４４は、データ設定要求信号に含まれるフィルター情報を用いてオブジェクト、すなわち、データ設定範囲を絞り込む（Ｓ２０３）。そして、情報モデル変換部４０は、データ収容部４４で絞り込まれたオブジェクトからモバイルエージェントＡが指定した設定値を抽出し（Ｓ２０４）、その設定値を対照テーブル（図１０参照）を用いて独自アクセス部４１で使用可能なデータ形式に変換して、独自アクセス部４１に送る（Ｓ２０５）。独自アクセス部４１は、モバイルエージェントＡが指定した保護制御装置に対してデータ設定を行なう（Ｓ２０６）。そして、データ設定が終了すると、独自アクセス部４１は、装置アクセスＡＰＩ４２を介してモバイルエージェントＡに設定実行結果を送る（Ｓ２０７）。
【００６９】
次に、イベント監視部３９による処理の流れについて図１４を参照しながら説明する。イベント監視部３９は、自身のタイマー機能が予め定められた監視時刻を計時したことを契機に（Ｓ３０１）、図１２のフローチャートで示す処理に従って、イベント監視プロパティで指定した監視対象から装置データを取得する（Ｓ３０２）。イベント監視部３９は、タイマー機能が予め定められた監視時刻を計時しない場合には、タイマー機能が監視時刻を計時するまで装置データを取得する処理を実行せずに待機する（Ｓ３０３）。取得した装置データがイベント通知条件を満足した場合（Ｓ３０４）、その旨をエージェントＰＦ１８に通知する（Ｓ３０５）。この通知が終了した場合（Ｓ３０５）、あるいは取得した装置データがイベント通知条件を満足しなかった場合（Ｓ３０４）、イベント監視部３９は、イベント監視プロパティで予め定められている全ての監視対象に対してのデータ取得が終了しているか否かを判断し、予め定められている全ての監視対象に対してのデータ取得が終了していなければ、イベント監視プロパティで定められている全ての監視対象に対してのデータ取得が終了するまで上記の処理を繰り返し行なう（Ｓ３０６）。予め定められている全ての監視対象に対してのデータ取得が終了した後、装置アクセスソフトウェア１９の動作が終了するまでＳ３０１〜Ｓ３０６までの処理が繰り返して実行される（Ｓ３０７）。
【００７０】
以上のように、本発明のデータ処理システムである装置アクセスソフトウェア１９によれば、入出力されるデータ形式が異なる複数の機器に関するデータを各機器固有のデータとともにツリー構造４５を用いて体系的に管理することができるので、特定の機器に関するデータを取得する場合、そのデータを迅速に取得することができ、また、機器を管理する上で必要となる詳細なデータも取得することができる。また、入出力されるデータ形式が異なる複数の機器に関するデータをツリー構造４５を用いて体系的に管理することが可能となり、特定の機器に対してデータ設定を行なう場合、そのデータ設定を迅速且つ的確に行なうことができる。
【００７１】
また、制御システム１は、運用者やエージェント使用者によって予め設定されたプロファイルに従ってエージェントＰＦ１８上で処理を実行するようにしたので、広域にわたって複数のノードやそれらのノードに接続されている機器を統一的に管理することが可能となり、遠隔管理の高信頼化を図ることができる。また、保護制御装置で発生した不具合を遠隔地にてリアルタイムで把握することができるので、その不具合に対して迅速且つ的確な処置を施すことが可能となる。
【００７２】
なお、上述の形態は本発明の好適な形態の一例ではあるがこれに限定されるものではなく本発明の要旨を逸脱しない範囲において種々変形実施可能である。例えば上記実施形態では、運用者用ルーチング部３２におけるイベントの転送先をエージェント用ルーチング部３３及び履歴作成部３５とし、エージェント用ルーチング部３３におけるイベントの転送先を履歴作成部３５及びモバイルエージェントＢとしたが、これに限ることなく、転送先をエージェント生成部２４やエージェント削除部２５にしても良い。これは転送先テーブル３６ｂや転送先テーブル３７ｂの内容を書き換えることによって実現される。
【実施例】
【００７３】
以下に本発明のモバイルエージェントシステムを電力送電系統における保護・制御システムの遠隔運用保守などに適用する例について説明する。
【００７４】
自律的な分散処理が可能なモバイルエージェント技術やIP（Internet Protocol）ネットワーク技術は、広域での情報集配信の自動化や低コスト化に適していると考えられる。しかし、現状のモバイルエージェント技術はベンダ（メーカーあるいは販売会社）固有の方式であり、ベンダー間での相互接続性確保や仕様共通化は実現されていない。このため、マルチベンダーによって運用され尚且つ広域において多様な機器に対応せざるを得ない変電所の保護機能の運用保守を主な対象とする送電系統の保護・制御システムにおいては、モバイルエージェント技術を用いた保護リレー装置などの遠隔運用保守のためのシステムを構築することができなかった。このことは、系統監視制御機能においても同様である。
【００７５】
送電系統の保護・制御システムは、例えば図１に示すように、多数の変電所等の電気所２とこれらを監視して運転を制御する運転所３及び電気所２の保守を行う保守所４並びに位置管理サーバ５ａ、装置情報ＤＢ５ｂ、系統ＤＢ５ｃなどがワイドエリアネットワーク（ＷＡＮ）６で相互に接続されている。電気所２では、電気所サーバ９あるいは保守用CPU１０，１５に保護リレー装置１３・センサ１１等の装置が接続されている。また、系統DB５ｃは、系統構成や保護リレーに関する情報を蓄積する。装置情報DB５ｂは、エージェントが収集した情報を蓄積する。さらに、保守所４と電気所２のCPUは、IPベースのWAN６を介して接続される。電気所構内の保守用CPU１０，１５は、IPベースのLAN７を介して接続される。そのため、システムはIPネットワークのQoS・信頼性にかかわる機能と連携することで、通信の遅延や可用性などの性能を担保することができる。さらに、運転所３の監視制御サーバ１７及び保守所４の保守サーバ１２とＷＡＮ６を介して接続されている電気所・変電所２の保守用ＣＰＵ（ネットワーク端末）１０，１５には保護制御装置としての保護リレー装置（ＲｙＣＰＵ）１６が接続されている。そして、保守用ＣＰＵ１０，１５には、「エージェントPF１８」、「装置アクセスソフトウェア１９」および「エージェント」の３要素が保守用CPU１５上に主記憶装置（図示省略）に格納されているソフトウェアによって構成されている。また、保護制御装置１６を接続していない運転所３の監視制御サーバ１７及び保守所４の保守サーバ１２のCPUには、「エージェントPF１８」と「エージェント」の２要素がCPU上に構成されている。本実施例のエージェントシステムは、この3要素をソフトウェアの構成要素とするものであり、各要素は、保護制御装置とIP網との仲介役となる保守用CPU（保守用CPU）やサーバ等の上で動作する。保護リレー装置と接続する場合、保守用CPU１５は、保護機能を実行するCPU(RyCPU)１６と接続される。ここでは、保守用CPUやサーバなどエージェントが動作するCPUを総称して、「エージェントCPU」と呼ぶこととする。なお、本明細書では、基板やサーバ、PCなどの情報処理装置をCPUと呼ぶものとしている。
【００７６】
ここで、エージェントPF１８は、エージェントを動作させるためのミドルウェアであり、エージェントの生成、移動、状態管理などエージェント実行に必要な機能をエージェントやその利用者に提供するものである。また、装置アクセスソフトウェア１９は、エージェントが保護制御装置１６に対して情報取得設定する際に、そのインタフェースとなるソフトウェアである。また、エージェントは、処理プログラムと処理に必要なデータを一体化したソフトウェアである『オブジェクト』を拡張したソフトウェア」であり、通信網内を装置から装置へと移動して、移動先の装置で、自律的に必要とするデータを自律的に収集やその他の適切な処理の選択、実施が可能である。ここで、エージェントの移動は、プログラムとデータが一体化した処理であることから、ソフトウェアのインストールや更新の手段としても利用できる。このような使い方の移動の後、そのエージェントは特定の装置に常駐しても良い。
【００７７】
本実施例のエージェント技術を用いた遠隔運用保守システム（以下、エージェントシステム）におけるエージェントは、電気所や保守所４などを巡回して情報集配信するだけではなく、要求によってはデータ加工等の付加的な処理を行うことが可能である。これら処理の組み合わせによって、エージェントシステムは、電気所機器の遠隔監視、電気所機器の遠隔設定（遠隔整定など）、電気所側での自動処理（自動監視など）、保守や運用担当者との対話などの機能を提供する。
【００７８】
このエージェント技術を用いて保護リレーなどの装置情報を収集・配信・処理するためには、図１６に示すエージェントシステムモデルのように、「エージェントPF１８」、「装置アクセスソフトウェア１９」および「エージェント」の３要素が必要である。そして、現実に運用されている送電系統の保護・制御システムは、シングルベンダーによって構成されておらず、様々なメーカーが製造しかつ仕様が定められたベンダー固有の保護制御装置、エージェントPF、エージェントCPUが混在するマルチベンダー方式で運用されている。したがって、異なるベンダーが作成したエージェントが全てのメーカーのエージェントPF、エージェントCPU上で動作し、かつ他メーカーの保護制御装置の情報を取得・設定できる必要がある。これを実現するには、エージェントシステムの3要素について標準化を行う必要がある。特に「エージェントPF」並びに「装置アクセスソフトウェア」が具備するAPI(Application Programming Interface)とそれらの機能の標準化が重要である。エージェントプラットフォームの仕様に違いがある場合、A社製のエージェントは、B社製のエージェントプラットフォームへの移動はできない。また、装置アクセスインタフェースに違いがある場合、ベンダの数だけエージェントを開発し、かつエージェント間の協調方法を決める必要がある。しかも、様々なアプリケーションを段階的に導入する場合、導入する度に、これらの作業が発生する。
【００７９】
このように、装置アクセスインタフェースとエージェントプラットフォーム１８が提供するインタフェースと、両インタフェースを用いて利用する機能を標準化することで、エージェントはベンダの差異の影響を受けずに、保護制御システム全体に対して、装置の設定や情報取得を行うことが可能となる。そして、エージェントについては、エージェントPFと装置アクセスソフトウェアが提供するAPIを利用し、作成すればよい。なお、本実施例においては、1個のエージェントCPUにつき、１個のエージェントPFのみが動作する場合を想定したものとして説明しているが、当然これに限られるものではなく、電力送電系統に接続される膨大な数のエージェントCPUとエージェントPFとを対象とし得ることは言うまでもない。図１７に標準化（仕様化）するエージェントCPUで実装する各種機能等を示す。
【００８０】
具体的には、図１５に示す基本概念図のように、エージェントプラットフォーム１８は、(1)エージェントを生成・削除する、(2)エージェントの移動が要求されると、移動先のエージェントプラットフォームにエージェントを転送する、(3)エージェントが転送されてくると、そのエージェントを起動するといった基本的機能の他に、(4)エージェントに対する追跡・停止などの遠隔管理を行うプラットフォーム間通信機能、(5)異常検出機能や故障対応機能(イベント通知、履歴、装置アクセスソフトウェア連携)を追加することで、障害発生時に移動経路を変更するなどの自律的な処理を可能としたエージェント処理機能を備え、電力用としてエージェント管理の詳細化や耐障害性の向上を図るようにしている。また、装置アクセスソフトウェア１９は、(1)エージェントからの保護制御装置の情報取得、設定処理要求に基づき処理を実行し、結果をエージェントに返すエージェントとのインタフェース、並びに(2)：保護制御装置の状態変化（保護制御装置からの通知）を、エージェントプラットフォームを介してエージェントに通知する保護制御装置１６とのインタフェースを備えるようにしている。
【００８１】
尚、保護制御装置と接続する保守用CPUには、アナログ・ディジタル入出力のための物理的なインタフェースが必要である。制御装置は装置アクセスソフトウェアを持つ保守用CPUと接続されることによって、他のエージェントCPUである保守用CPUや各種サーバからはエージェントPFで規定した論理的なインタフェースを介して、装置情報の遠隔取得設定が可能とされる。また、エージェントCPUには、保護制御装置とIP網を接続するために、ネットワーク端末機能を備えている。
【００８２】
また、エージェントシステムを構成するソフトウェアは様々なベンダが提供する装置上で動作可能とするために、Java（登録商標）言語を用いた実装が好ましい。Java言語は、Windows（登録商標）やLinuxなど多様なOSが対応しており、今後のさらなる普及が期待でき、かつ保守用CPUでの実装事例がある。Java言語を用いて実装する場合、タイマー機能などスレッド処理の高度化とTCP/IPの高度な利用に当たっては、Java Standard Edition (SE)1.4以上が、CPU資源の詳細情報取得のために、Java SE 1.5以上が必要となる点から、Java SE 1.5以上の使用が好ましい。通信プロトコルについては、図４に示した通信プロトコルの階層のように、Javaの層では、通信インフラAPIを通じてプロトコル上位を利用できる必要がある。通信インフラAPIとしては、Java RMIや高度通信RPCを挙げることがある。なお、直列可能な情報とは、Java言語のjava. io. Serializable形式の情報である。
【００８３】
しかして、本実施例のエジェントシステムは、エージェントを異なるベンダーのエージェントCPU、エージェントPF間へ移動して、処理を行うことが可能となる。また、マルチベンダの保護制御装置の情報を統一した形式で利用可能となり、メーカ独自形式情報も集配信できる。
【００８４】
ここで、送電系統の保護・制御システムを実行するエージェントシステムには、以下に示す(1)〜(5)の基本機能と、(6)〜(8)の高信頼化のための機能を備えることが望まれる。
【００８５】
(1)情報収集の自動的開始
イベント（保護リレー装置動作、遮断器動作、リレー装置障害、一定時刻経過、スケジュールによる起動命令）を処理の起点として、エージェントは、情報の収集を自動的に開始することができる。尚、ある箇所（中給、給電制御所、保守所４）から自所および遠隔(例えば電気所)のエージェントプラットフォームに対してエージェントの起動要請をかけることができる。
【００８６】
(2)情報収集箇所の自律的選択
事前に用意された系統などの条件とその対応シナリオに従い、情報収集箇所を決定し情報収集することができる。
【００８７】
(3)エージェント(プログラム)の配信
保護リレー装置が発するイベント情報により、処理するエージェント（事故解析など）を選択することができる。得られた情報より自律的に処理するエージェントを選定し、配信することができる。
【００８８】
(4)処理結果配信箇所の自律的選択
系統の運転所、設備の保守所４、解析箇所など電圧階級や設備により情報を配信すべき箇所は異なる。これらを条件に基づいて判断し、情報を必要とする箇所に適切に配信することができる。
監視制御を行なっている箇所への事故速報の配信のように、同一電気所の事故においても、事故設備によって配信箇所を選択することが出来る。
【００８９】
(5)エージェントの状態の把握
エージェントの現在位置、処理状況を運用保守担当者などが把握できる。
【００９０】
(6)エージェントの詳細管理
エージェントシステムでは、エージェントによる確実な処理を実現するために、「エージェントPF」、「エージェントの種類」、「エージェント」のそれぞれの単位で状態を管理する。これにより、保守担当者などは状況に応じてエージェントに対して停止などの命令を効率的伝えることが可能となる。
【００９１】
(7)情報収集・配信失敗時の処理
(i)「情報収集・データ処理異常時への対応」
エージェントによる収集必要箇所となる保護制御装置のうち情報収集・データ処理が不可能なものがある場合、システムは以下の処理を行う。
1)情報収集・データ処理が不可能であることを認識し、その箇所を回避して情報を収集する。
2)情報収集・データ処理が不可能であった箇所およびどの情報が収集・処理できなかったかを保守担当者などへ通知する。
なお、収集不可能とは、装置アクセスソフトウェアがエラーあるいは例外を発している状況とする。
これにより、情報収集の実行が不可能な保護制御装置やデータ処理が不可能なエージェントCPUからの影響を抑えることが可能となる。
(ii)「移動の異常時の対応」
エージェントがコネクション断などの伝送路障害によって移動中に異常となったと判断された場合、システムは、以下の処理を行う。
1)エージェントが移動中に通信異常に陥った場合、移動のリトライを移動先となるエージェントPFにかける。
2)リトライをかけてもだめな場合はあきらめ、違う箇所へ情報を収集に回る。
これにより、処理実行不可能なエージェントCPUの影響を抑えることが可能となる。
(iii)「エージェント間通信の異常時の対応」
エージェントがエージェント間通信中に異常となった場合、システムは、通信のリトライを通信相手となるエージェントPFにかける。リトライに失敗した場合は、異常終了とする。
これにより、エージェント間連携における障害の影響を抑えることが可能となる。
(iv)「消失への対応」
エージェントが消失してしまった場合、システムはそれをシステム管理者へ通知すると共に、保守担当者などに通知する。異常終了によりエージェントが消失した等の場合は、消失の自動検出・通知が困難と考えられる。その場合は、担当者が位置管理機能やログ機能によりエージェントの追跡を行う。
これにより、消失箇所が限定でき、消失したエージェントの問題点の分析が容易となる。
(v)「エージェントの処理起動・中止・再開」
保守担当者は、エージェントに対して以下の起動・中止・再開に関する指令を発することが可能である。中止の指令が発されると、エージェントは中断状態、中止状態の順に移行する。
1) エージェント生成後、エージェントPFがエージェントに処理を開始させる指令。
2) エージェント中止後に保守担当者などが行う処理再開指令。
3) エージェントが移動先で、そこのエージェントCPU上のエージェントPFが、エージェントの処理を開始させる指令。
(vi)「起動失敗時の対応」
事故などの発生により、エージェントの起動が失敗した場合、以下の手順で処理を行うことができる。
1)エージェントが起動すべきときに起動しなかったことを検出し、通知する。
2)起動しなかったエージェントを外部から起動する。
これにより、保守担当者による強制的な起動が可能となり、緊急時においても必要な情報を取得できる可能性が高まる。
【００９２】
(8)リレー装置のリソースが不足しそうな場合の処理
(i)「リソース不足への対応」
エージェントCPUのリソース(メモリなど)が不足しそうな場合、対応処理を行う。
(a)リソース不足を回避する処理
1)エージェントの移動などによりエージェントCPUのリソースが不足するかどうかを判定する。
2)リソース不足に陥る場合は、リソース不足とならない状態になるまで待つ。あるいは、そのエージェントCPUでの処理を実行せずに、次のエージェントCPUへ移動する。
(b)占有状態対策
ここで、CPU資源が占有された状態は、以下の何れかの状態を想定する。
1)一定時間(処理期限)を越えた。
2)エージェントPFからの中止命令に応答しない。
エージェントPFがCPU占有状態を検出した際には、システムは以下の手順で処理を実行する。
1)エージェントの停止・削除
2)エージェントPFの再起動（保守用CPUではなく、サーバの場合、可能であれば、再起動前に占有しているエージェントの処理優先度を変更することで、占有状態の解消を図る。）
これらの機能により、リソース不足への一時的な対応が可能となり、可用性が向上する。
(ii)「優先処理」
優先すべきエージェントがあった場合は、現在処理中のエージェントを停止させ、優先すべきエージェントを先に処理する。これにより、緊急性を要するエージェントが迅速に処理を実行することができる。エージェントに、処理期限や優先度を付与することにより、エージェントPFは処理期限や優先度を用いて、エージェントを制御することができるので、個々のエージェントに必要な性能・信頼性を満足することができる。
【００９３】
また、上述の送電系統の保護・制御システムを実行するエージェントシステムに要望される機能を実現するため、エージェントPFは、エージェントの生成・移動などを実現するための基本機能だけでなく、高信頼化等の観点からその他多数の機能を具備する。基本機能については、MASIF規格やAglets で提供する機能を備えることで、一般的なモバイルエージェント機能を提供でき、将来の他のエージェントPFとの接続の容易さが期待できる。高信頼化については、独自のイベント処理機能やログ機能、処理管理機能などを設けることで対応している。図１８に全体構成を示し、各種機能の動作と対応するAPIであるオブジェクトクラスを以下に示す。
(1)エージェント生成／削除機能(Agent Create Delete) ５１
(2)移動機能 (Migration)５２
(3)エージェント間通信機能 (Agent Communication)５３
(4)処理ロジック管理機能 (Process Logic Manager)５４
(5)プラットフォームインタフェース (PFIF)５５
(6)プラットフォーム間通信機能 (PF Communication Infrastructure)５６
(7)ログ機能（Log）５７
(8)イベント処理機能 (Event Processor)５８
(9)外部サービスインタフェース (External Service Interface)５９
(10)リソース管理機能 (Resource Manager)６０
(11)エージェント処理管理機能 (Agent Process Manager)６１
(12)位置管理機能 (Location Manager)６２
(13)セキュリティ機能(Security Manager)６３
尚、図中の符号の後の()の中の符号は上述の機能を実現する手段を示している。
【００９４】
図２９にエージェントPFが提供する主な機能対応表を示す。この表が示すように、ほとんどの機能は高信頼化のために必須の機能である。1)エージェントPFと運用・保守担当者との連携のために、プラットフォームインタフェースとプラットフォーム間通信機能を、2)異常状態に対応するために、イベント処理機能とエージェント処理管理機能を利用する。尚、各種機能の詳細を指定する設定をプロファイルと呼ぶ。
【００９５】
（生成・削除機能）
アプリケーションや起動中のエージェントからの要求に基づき、エージェントの生成や削除などを行う。関連するオブジェクトクラスは、PFIF５５および、Agent Process Manager６１である。
【００９６】
（移動機能）
エージェント自らなどの要求に基づき、指定されたエージェントPFへそのエージェントを転送する。転送完了後、エージェントを起動する。通信網の障害などにより移動が失敗した場合、再送を行う。
図５(a)に示すように移動時には、エージェントPF間でエージェントPFのget_resourceメソッド、receive_agentメソッドの順で処理を行う。そして、移動先でのリソース不足に対して、エージェントには以下の1)〜3)の対応モードを指定することが出来る。
1) 中断（送信元に戻り、担当者への通知などの対応処理を行う。）
2) スキップ（何も処理を行わず、次のエージェントPFへ移動する。）
3) 待機
図５(b)に示すように、エージェントPFの移動機能は、通信網の障害などによりエージェントの移動が失敗した場合、再送を行う。また、ログ機能が移動などの処理失敗などをログとして記録する。図２６にエージェントの状態遷移を示す。担当者は、位置管理機能を用いてエージェントの管理モードを変更することで、遠隔地に移動したエージェントが可能である。関連するオブジェクトクラスは、PFIF５５とEvent Processor５８である。
【００９７】
（エージェント間通信）
図１９に示すように、エージェント間通信は、異なるエージェント間で情報交換するための機能である。授受する情報には、文字列情報や装置情報アクセスソフトウェアから得たオブジェクトなどを収容できる。エージェント間通信機能は、タイムアウト機能およびリトライ機能を提供する。タイムアウト時間およびリトライ回数は、プロファイルで指定する。
通信方法（トポロジ）としては、個別に通信する方法（1:1）とマルチキャストで通信する方法(1:m)をサポートする。
通信方法（応答の有無と手順）としては、次の1)〜3)の3種類をサポートする。
1) 応答ありの同期通信
2) 応答ありの非同期通信
3) 応答なしの片方向通信
授受する情報の形式は、シリアライザブルとする。
エージェント間通信機能は、タイムアウト機能を提供する。メッセージの送信・応答結果の受信については、オブジェクトクラスProxyを用いる。この方法により、外部から直接エージェントを操作することを防止する。関連するオブジェクトクラスは、PF Communication Infrastructure５６である。
【００９８】
（処理ロジック管理機能）
処理ロジック管理機能は、エージェントが生成あるいは到着した場合、処理ロジックを実行させる。処理ロジック管理機能は、エージェントPFのエージェント処理実行管理機能に含まれる。例えば、図１９（ｂ）に示すような、経路番号とエージェントCPU、ロジックID、ロジックがそれぞれ対応するテーブルをエージェント処理実行管理機能のメモりに有し、このテーブルに従って、図１９（ａ）に示すように所定のエージェントが所定の経路を通って所定のエージェントCPUで所定のロジックを実行する。関連するオブジェクトクラスは、Agent Process Manager６１である。
【００９９】
（プラットフォームインタフェース）
プラットフォームインタフェースは、保守担当者や他のエージェントPFと連携するためのインタフェースである。保守担当者からのエージェントの生成・起動・中止指令やエージェントPF間でのエージェント移動などの際に、利用する。
この機能はエージェント起動を承認・拒否の結果通知として、Boolean（True or False）など戻り値で結果を返す。詳細情報などその他の情報を呼び出し元のエージェントPFに通知する手段には、例外を用いる。
プラットフォームインタフェースは、エージェントPFを構成する他の機能と連携と保守担当者や他のエージェントCPUとの連携を可能とする。関連するオブジェクトクラスは、 Agent Process Manager６１、PF Communication Infrastructure５６である。
【０１００】
（プラットフォーム間通信機能）
プラットフォーム間通信機能は、通信ミドルウェアとエージェントPFを接続する役割を有する通信インフラストラクチャであり、以下の1)〜3)の機能に対して通信機能を提供する。
1) 移動機能
2) エージェント間通信
3) 外部サービスインタフェース
関連するオブジェクトクラスは、PF Communication Infrastructure５６、External Service Interface５９である。
【０１０１】
（ログ機能）
ログ機能は、エージェントの振る舞いや装置からのトリップ信号などによりイベントが発生した場合など、プロファイルに従い、日時やイベントを発した機能名や詳細情報を記録する。関連するオブジェクトクラスは、Log５７である。
【０１０２】
（イベント処理機能）
イベント処理機能は、イベントを受信すると、その内容に応じた処理を行う。プロファイルを用いて、ログ機能やエージェントなどに転送するイベントの種別を指定可能とする。
以下に示す1)〜4)のエージェントの基本的な振る舞い時に発生するイベントを処理する。
1) 生成／削除
2) 移動
3) エージェント間通信
4) 処理ロジックの実行
エージェントPFは、上記の処理の実行前後に、イベントを発することが出来る。プロファイルによりイベントの発生の有無を指定する。
図 ２０(a)に示すように、イベント処理機能は、イベントを受信すると、その内容に応じた処理を行う。イベントへの対応方法は、プロファイルによって指定することが出来る。例えば、プロファイルで指定されたログ機能やエージェントなどにイベントを転送する。イベントの転送については、以下の1)〜2)の機能を提供する。
1) 常駐エージェントへの通知
2) 移動しているエージェントへの通知（中止や中断等を想定）
移動しているエージェントへの通知は、位置管理機能との連携が必要となる。位置管理サーバへの負荷を考慮し、以下の1)〜3)の方法を利用することができる。
1)位置管理機能で検索し、エージェントPFから該当エージェントへ通知：
位置管理サーバの負荷：大
2)位置管理機能が検索・通知までを実施：位置管理サーバの負荷：中
3)ブロードキャスト通知：位置管理サーバの負荷：小
関連するオブジェクトクラスは、Event Processor５８である。
【０１０３】
（外部サービスインタフェース）
外部サービスには、装置アクセスソフトウェアと既存システムが含まれる。図 ２０(b)に示すように、外部サービスインタフェース (インターフェース)は、外部サービスからのイベントを受信することができる。また、イベントの内容に応じて、イベントを他APFへ転送することができる。
外部サービスがエージェントに対してイベントを発するために、外部サービスインターフェースを呼び出す。受信されたイベントは、イベント処理機能あるいは他のエージェントPFの外部サービスインターフェースへ転送される。他のエージェントPFとの通信には、プラットフォーム間通信機能を用いる。関連するクラスは、External Service Interface５９である。
【０１０４】
（リソース管理機能）
エージェントPFが動作するハードウェアのメモリ量や負荷、エージェント数を監視し、リソース不足を防止するための処理を行う。リソース不足を防止する処理としては、例えば、メモリ量が上限値を超過した場合には、ガーベッジコレクションを実行したり、エージェントの転送を拒否するように、移動機能に依頼するなどである。そして、リソース不足が発生すると、イベントを発する。このとき、イベント処理機能を利用して、エージェントの停止・削除、エージェントPFの再起動を実現することが出来る。関連するオブジェクトクラスは、Resource Manager６０である。
【０１０５】
（エージェント処理管理機能）
エージェント処理管理機能は、エージェントの生成あるいは到着後の処理の管理を行う。すなわち、起動処理も管理する。エージェント処理管理機能は、エージェントの状態遷移を管理し、状態遷移前後にイベントを発生することができる。エージェントの起動および演算異常に失敗した場合にもイベントを発生できる。
エージェントPFおよびエージェントは、保守担当者などが指定するモード例えば管理モード (Administrative State)と、システム側が発するモード例えば運用モード (Operational State)と使用モード (Usage State)、アラームモード (Alarm Status)の都合4種類のモードをそれぞれ具備する。このモードは、以下の単位でそれぞれ有する。
1) エージェントPF
2) エージェントの種類
3) 個々のエージェント
関連するオブジェクトクラスは、PFIFあるいは、Agent Create Deleteである。
エージェントの処理スケジューリングには、エージェントに割り当てられた処理期限や優先度などの情報を用いる。エージェントPF上に複数のエージェントが混在する場合、逐次処理を行うスケジューリングをベースとし、複数の常駐エージェント動作の実現や単一エージェントによる処理占有などを防止するために並行処理を行うスケジューリングを併用する。関連するオブジェクトクラスは、Resource Manager６０、 Event Processor５８である。
【０１０６】
（位置管理機能）
システム全体管理のために、管理対象となるエージェントPFからの情報を基に、エージェントの位置や処理進捗状況を管理する。位置管理機能を用いることで、エージェントの状態(移動中・処理中・停止中・アラーム等)の取得や、エージェントの動作（使用・ロック）の変更指示を可能とする。図２に位置管理機能の動作概要を示す。ログ機能と同様に、エージェントの移動開始時と到着時に位置管理機能に対して、通知を発することができる。関連するオブジェクトクラスは、Event Processor５８、Migration５２である。
【０１０７】
尚、本エージェントシステムは、通信網レベルで外部に対してクローズなシステムを構成し、新規なセキュリティ対策あるいはJavaレベルなど既存技術で実現容易なセキュリティ対策を施すことでセキュリティのレベルが高い状況を構築するものとしている。
例えば、処理の実行制御に対しては、プロファイルの内容により、エージェントが行う処理の許可と制約を設定可能とする。エージェントの種類毎に、あるいはエージェント単位で指定できるものとする。許可（permission）が与えられた処理（ex. 生成（子エージェント）や移動など）は、エージェントは、その処理を実行可能とする。逆に、制約（protection）が設定された処理は、エージェントは、その処理が実行できない。
また、通信に対しては、プロファイルによりエージェント移動に伴うプログラム(ダウンロード)に関する設定を可能とする。これにより、指定したユーザやノードからのみエージェントプログラムをダウンロード可能とする。さらに、通信機能 (ex. VLAN)と連携し、他のシステムと分離することも可能である。これにより、エージェントプログラムを盗聴されないようにできる。
【０１０８】
さらに、新規のアプリケーショの追加は、エージェントの追加およびエージェントPF用プロファイルの変更により、容易に可能である。本エージェントシステムは、保護制御に要求される高信頼化処理や異機種接続性を実現し、かつ拡張性が優れたものとなる。
【０１０９】
次に、装置アクセスソフトウェアについて説明する。装置アクセスソフトウェアは、エージェントが保護リレー装置や制御装置、センサなどの機器に対して情報取得や設定を行うために、その仲介機能として利用する。エージェントは、装置アクセスソフトウェアが提供するAPIを利用することで、装置情報を取得設定する。また、装置アクセスソフトウェアは、エージェントPFに対してイベントを発することができる。そのイベントを、エージェントはエージェントPFを介して受信することができる。これにより、保護リレー装置動作を起点とした事故解析処理などが可能となる。
【０１１０】
図２１に示すように、装置アクセスソフトウェア１９は、装置アクセス機能３８、情報モデルへの変換機能４０、メーカ独自の装置アクセス機能４１を含む。装置アクセス機能３８は、情報モデルを保持し、検索機能を提供する。情報モデル変換機能４０は、必要に応じてEquipmetData形式と装置固有データ形式の変換を行うものであり、エージェントからのEquipmetData形式の要求を独自アクセス機能に適した形式に変換して独自アクセス機能４１へ渡したり、あるいは独自アクセス機能４１を介して保護機能を実行するCPU(RyCPU)１６から取得した保護制御装置のデータ４６をEquipmetDataに変換してから該当情報収容部４４へ格納される。そのために、情報モデルは、個々の情報をオブジェクトとしてツリー構成４５で収容する(図２２(a))。個々の情報をオブジェクトとしてカプセル化することで、エージェントは様々な情報を集配信することが出来る。例えば、オブジェクトには、独自規定のものだけに限らず、電気所装置の情報を示すIEC61850などのオブジェクトも収容可能である。そして、オブジェクトの定義には、Java言語による規定だけではなく、データ表記方法であるXML（Extensible Mark-up Language）を適用可能とする。
【０１１１】
装置アクセスソフトウェアのAPIでは、エージェントとの連携をとるため、以下のメソッドを提供する。整定の処理ステップなどに対応するために、 情報取得（getData）や情報設定 (setData)命令を使う際には、“仮設定”や“運用”などのパラメータを指定可能である。
1) getData( オブジェクトのID、検索範囲、パラメータ）
2) getData( オブジェクトのID、検索範囲、検索条件パラメータ）
3) setData( オブジェクトのID、検索範囲、設定値、パラメータ）
4) setData( オブジェクトのID、検索範囲、検索条件、設定値、パラメータ）
【０１１２】
装置アクセスソフトウェア１９では、エージェントと授受するデータ形式としてラッパーオブジェクト形式（EquipmetData）を採用している。ラッパオブジェクトは、保護制御装置が入出力するデータの生データ（保守運用に必要な詳細情報を含む）、データ種別・形式、アクセス日時を保持する。同時に、装置アクセスソフトウェアでは、保護制御装置毎に保守用 CPUが接続されるだけではなく、電気所サーバなどが多数の保護制御装置と接続されることが想定されるため、装置アクセスソフトウェアには、装置情報をツリー構造でオブジェクトとして保持することにより、ツリー検索を可能としている。これを実現するためには、以下の項目を規定する必要がある。
1) ツリー階層構成：オブジェクトの読み書き方法が明確となる。
2) オブジェクトの基本定義（設備番号などを属性とする。）：オブジェクトに共通して必須となる属性が明らかとなる。
3) オブジェクトの定義(継承)：実保護制御装置を接続する際に必須である。
また、オブジェクト（EquipmetData）は、データを設定したタイムスタンプ（ Date timestamp）並びにデータのタイプ（String datatype）例えば、“XMLやPlain Old Java形式の種別“＋オブジェクトクラスIDを設定した属性と、装置から取得したデータ本体（Serializable Data）あるいは装置に入力するためのデータ本体（Serializable Data）を具備する。Euqipmentクラスは、これらの属性を具備することで、各種形式のJavaオブジェクトを収容するラッパークラスとして機能する。例えば、図２８に示すように、装置アクセスソフトウェアは3種類のオブジェクトを統一した方法で収容することで、エージェントは様々なデータ形式の集配信が可能となる。尚、オブジェクトの定義は、Java言語あるいはXMLで規定する。
【０１１３】
この実施例のアクセスソフトウェアにおいては、設備モデルと運用モデルの2種類の情報モデルを収容することを想定している。設備モデルは、各装置の型番などの設備情報を収容する。運用モデルは、整定値や動作状態などの情報を収容する。ツリーの階層の上位部は、両モデルとも共通とし、その下位にモデル毎にオブジェクトを配置する。上位部の階層を以下の通りである。下記は、ツリー構成を構成するための仮想のオブジェクトである。
・ Top
・ 電気所識別子(ex. 変電所A)
・ 設備識別子（ex. 送電線、変圧器）
・ 装置識別子（ex. 保護リレー装置、事故波形記録装置）
・ 回線識別子（ex. xxx線3L）
【０１１４】
オブジェクトの定義は、以下の通りである。
(1)設備モデル
図２３(a)にPCM保護リレー装置の例を示す。保護リレー装置に関する各種オブジェクトは、回線識別子となる仮想オブジェクトxxx3Lの下位に配置する。各オブジェクトは、以下の属性を持つ。
・ 名称：例えば、MainPCM001
・ データ種別：例えば、主保護各端各相判定PCM
・ 起動時刻
・ データ(複数)：型形式、メーカ名など
オブジェクトの定義において、属性として、メーカ固有形式のデータを追加することも可能である。
【０１１５】
(2)運用モデル
図２３(b)に運用モデルのオブジェクトの構成を示す。オブジェクトは、回線識別子となる仮想オブジェクトxxx3Lの下位に配置されている。下位部の構成は以下の通りとした。
第1層：整定、動作内容、異常状態、運用状態
第2層a（整定の下位）： 整定
第3層a：整定（リレー1）、整定（リレー2）、運用設定（リレー3）
第2層b（動作内容の下位）：最新動作内容、動作履歴
第2層c1（異常内容の下位）:最新異常内容、異常一覧、詳細情報
第2層c2（異常内容の下位）:異常履歴、詳細情報
第2層d（運用状態の下位）運用状態:リレー動作、入力電気量
例えば、整定の第3層のメインリレーは、要素1タップ、要素1倍率、要素1大電流域、要素2タップの値を属性として持つ。
【０１１６】
このように、ツリー構造を用いることで、設備情報と運用情報を体系的に収容することが可能となる。エージェントは、これらの情報モデルを装置アクセスソフトウェアのAPIを介して利用することが出来る。階層の段数や装置の名称や整定値などを検索条件(範囲)とすることで、遠隔運用保守に必要な情報を取得できる。直接階層上の位置を指定し、各オブジェクトを取得することも可能である。
ただし、情報ツリーを構成するオブジェクトとエージェントの移動先となるエージェントCPUは関連があり、エージェントCPUの種別に応じた検索条件の指定が必要となる。
【０１１７】
以下に移動先と検索内容の組み合わせの例を示す。
(1)変電所には変電所サーバのみが配置される場合
移動先：電気所サーバ（Top.変電所A）相当のIPアドレス
検索例1：送電線．保護Ry．ｘｘｘ3L.PCMCa以下を検索
検索例2：PCMCaという名称のオブジェクトを検索
検索例3：送電線．保護Ry．ｘｘｘ3L.PCMCa．MainPCM001の情報取得
(2)PCMCaに保守用CPUが接続される場合
移動先：PCMCaの保守用CPU（ Top.変電所A.保護Ry．ｘｘｘ3L.PCMCa）相当のIPアドレス
検索例1：全オブジェクトを検索
検索例2：PCMCaという名称のオブジェクトを検索
検索例3：MainPCM001の情報取得
【０１１８】
図２２(b)に示すように、装置アクセス機能３８は、情報ツリー検索部（名前検索部とも呼ぶ）４３と情報収容部４４から構成されている。情報収容部４４は、例えばXMLのDBやJava形式でデータを入出力するソフトウェアの組み合わせで構成される。名前検索部４３は、情報ツリーとDBの対応付けを管理する。
エージェントが装置アクセスAPIを呼び出すと、名前検索部４３は、装置アクセスの情報取得設定APIの引数に含まれる検索範囲を基に、該当する情報収容部４４を選択し、データ形式に応じたツリー検索機能を用いて検索する。即ち、装置アクセス機能３８の情報ツリー検索機能によって、スコープ情報から情報収容部を特定し、さらにフィルター情報を用いてデータ検索を行う。
このように、名前検索部４３がオブジェクトの形式を隠蔽することで、様々なデータ形式を統一的に利用することが可能となる。ただし、エージェントは、それぞれのデータ形式を処理できる必要がある。
装置アクセスソフトウェア１９は、リレー装置のトリップ動作や故障通知の状態変化を検出すると、エージェントPFの外部サービスインタフェースに対して通知を行う。この動作によって、この内容に応じて、エージェントPFはエージェントの生成やエージェントへの通知を行うことができる。
以上のように、装置アクセスソフトウェアを介することで、装置情報を標準形式に変換、あるいはベンダ固有形情報をXML形式でオブジェクトに収容した形で、集配信することができる。
【０１１９】
さらに、エージェントについて説明する。エージェントは、エージェントPFにより次に実行すべき振る舞いが指定される。振る舞いの内容は、エージェントパッケージのエージェントクラスから派生することで、エージェント毎に規定された属性とメソッド・処理ロジックに基づいて決定される。本実施例のエージェントは以下の機能を提供する。
（ａ） 生成／削除
（ｂ） 保存（永続化）
（ｃ） 移動
（ｄ） エージェント間通信
（ｅ） 処理ロジックの実行
（ｆ） エージェントの振る舞い指定の詳細化（再送回数などのパラメータや異常時処理ロジック）
（ｇ） 優先度、処理期限を用いたエージェントの制御
（ｈ） 複数の処理ロジックの組み合わせ
（ｉ） エージェント間通信への対応
（ｊ） 使用・ロックなどへの状態遷移の対応
（ｋ） 移動経路
（ｌ） 処理ロジックの振る舞い
（ｍ） 処理結果
（ｎ） 例外処理発生時対応
（ｏ） 状態
（ｐ） 優先度
（ｑ） 処理期限
尚、エージェントに与えられる優先度は、１から999までの整数値であり、値が大きい程、優先度が高いものとみなす。
【０１２０】
（状態遷移）
また、エージェントは「起動」、「活性（実行）中」、「中断」、「中止」、「停止」及び「ロック」の状態を遷移する。エージェントクラスにおいてこの状態遷移が、関連する属性statusである。DetailedStatusのクラスの型の属性であり、以下の情報を参照できる。
・ 管理モード（Administrative State）
・ 運用モード（Oprational State）
・ 使用モード（Usage State）
・ アラームモード（AlarmStatus）
・ 移動モード（Migration Behavior Mode={Hop、 Wait、 Return}）
・ 処理モード（Process Time={逐次、並行}）
【０１２１】
（保持するデータ）
エージェントは、以下のデータを保持し、外部からアクセス（読み書き）する機能を提供する。
・ Javaオブジェクト
・ XMLデータ
・ ファイル
ただし、データへのアクセスを制御することが可能である。
外部からアクセス可能なデータは、エージェントクラスのprogram Data属性に保持する。
【０１２２】
（生成／削除）
ａ）エージェントが生成される処理手順は以下の通りである。
1. エージェントPFへのエージェントの生成要求としてcreateエージェントメソッドが呼び出される。
2. エージェントのコンストラクタが呼び出される。
3. エージェントのonCreationメソッドが呼び出される。
4. イベントリスナに登録された処理が呼び出される。
5. 処理ロジック管理機能により処理ロジックが実行される。
【０１２３】
ｂ）エージェントが削除される処理手順は以下の通りである。
1. エージェントPFへのエージェントの削除要求としてterminateエージェントメソッドが呼び出される。
2. イベントリスナに登録された処理が呼び出される。
3. エージェントのonDisposingメソッドが呼び出される。
【０１２４】
（移動）
エージェントは、滞在しているノードでの処理が完了すると、指定された移動先のエージェント CPUに移動する。エージェントは、移動元での処理ロジックの進捗結果を保持し、移動先では、その次のロジックを実行する。また、migrateメソッドを呼び出すことでも移動するが可能である。
エージェントには、移動処理失敗への対策として、移動時間のタイムアウト値と再送回数を設定できる。タイムアウト値に達した場合、移動失敗となる。移動に一度失敗した場合、指定された回数の再送をエージェントPFが試行する。タイムアウト値や再送回数は、エージェントに指定が無い場合、エージェントPFが保持するデフォルト値を利用する。
エージェントの移動において、IP網上の他の通信の影響を回避するために、エージェントPFのプラットフォーム間通信機能がルータなどのQoS制御機能と連携するための通信制御を行う。また、移動先において、他のエージェントと競合した際には、エージェントPFのエージェント処理管理機能が、優先度や処理期限を参照して、事故解析エージェントを優先する。
【０１２５】
（保存 (永続化)）
エージェントがロック状態になった際に、そのエージェントは保存される。
【０１２６】
（イベント）
エージェントは、エージェントPFのイベント処理機能と連携し、以下のイベントを受信する。そして、Delegation-Based Event Modelに基づいて、イベント毎にそれに対応する処理を実行。
・ 生成
onCreationメソッド、あるいはCreation Event Listenerが処理を行う。
・ 削除
onDisposeメソッドがあるいはイベントリスナが処理を行う。
・ クローン
onClonningメソッドがあるいはイベントリスナが処理を行う。
・ 移動(送信)
onMigratingメソッドがあるいはイベントリスナが処理を行う。
・ 移動(受信)
onMigratedメソッドがあるいはイベントリスナが処理を行う。
・ 永続化(ファイルなどに保存)
onPeresitenceメソッドがあるいはイベントリスナが処理を行う。
・ 移動失敗（1回目）
onMigrationFailedメソッドがあるいはイベントリスナが処理を行う。
・ 移動再送失敗（最大回数、タイムアウト）
onRetryMigrationFailedメソッドがあるいはイベントリスナが処理を行う。
・ エージェント間通信失敗（1回目）
onエージェントCommunicationFailedメソッドがあるいはイベントリスナが処理を行う。
・ エージェント間通信再送失敗（最大回数、タイムアウト）
onRetryエージェントCommunicationFailedメソッドがあるいはイベントリスナが処理を行う。
・ 処理異常
onProcessFailedメソッドがあるいはイベントリスナが処理を行う。
・ 外部イベント受信
onExternalServiceEventRecivedメソッドあるいはイベントリスナが処理を行う。
【０１２７】
（処理ロジックの実行）
図１９（ｂ）に示すように、エージェントが行う処理内容は、複数のロジックの組み合わせで構成できる。そのために、エージェントは、処理ロジックの一覧を保持し、経路番号とロジック番号の組み合わせで構成される。図１９（ａ）に示すように、エージェントは、エージェントCPU毎に異なる処理を実行することができる。また、エージェントは、同一のエージェントCPUに対して複数の経路番号を割り当てることが出来る。これにより、処理内容の変更や処理割り込み（次のロジックを開始前に割り込む）が容易となる。
エージェントが実行する処理は、Logicクラスから派生したクラスに処理内容を記述する。処理ロジック管理機能が、これを実行する。
【０１２８】
以上のように構成された本実施例のエージェントシステムによれば、事故解析情報集配信機能に必要な機能を有しており、高信頼化、異機種接続性に対して有効である。このことを、以下に遠隔整定アプリケーションソフト、事故波形データ配信アプリケーションソフト並びに事故解析情報集配信アプリケーションソフトを実行する場合を例に挙げて説明する。
【０１２９】
（実施例１）
以下、本発明を遠隔整定を実行するアプリケーションソフトを例として、保守所４にいる担当者が遠隔の保護リレー装置の情報を取得設定する場合の動作について説明する。尚、保守所の担当者（当該エージェント所有者）が、保守サーバへ遠隔整定の開始を要求することで、システムが遠隔整定を行う場合を考える。
ここで、利用する遠隔整定エージェントは、以下の構成とする。
（１） エージェントの処理ロジック（保守サーバ）：アプリケーションを通じて、担当者と連携しつつ、現在値確認と仮設定、運用設定処理を行う。
（２） エージェントの処理ロジック（保守用CPU）：装置アクセスソフトウェアと情報の授受を行う。
（３） エージェントが保持するデータ：情報集配信を可能とするために、保守サーバからの情報取得設定要求と装置アクセスソフトウェアからの情報をデータとして収容する。
尚、保守所の担当者（当該エージェント所有者）が、保守サーバへ遠隔整定の開始を要求することで、システムが遠隔整定を行う場合を考える。本システムでは、以下の動作を行う。図２４に処理の流れを示す。
【０１３０】
まず、担当者は、端末を通じて保守サーバ１２の遠隔整定アプリケーション６４を起動する（ステップ1）。保守サーバ１２では、遠隔整定アプリケーション６４がエージェントPF１８のプラットフォームインタフェース５５を用いて、エージェントPF１８のエージェント生成削除機能５１にエージェント生成要求を行い（ステップ2-1）、遠隔整定エージェント(以下、整定エージェント)を生成する（ステップ2-2）。遠隔整定エージェントは、現在値確認のために、エージェントPF１８の移動機能５２に対して、移動を要求する（ステップ3）。移動機能５２は、エージェントPF間通信機能５６を利用して、保守用CPU１５のエージェントPF１８へエージェントを転送する（ステップ4）。保守用CPU１５は整定エージェントを受け取った後、エージェントを起動する（ステップ5）。起動されたエージェントは、装置アクセスソフトウェア１９を介して保護リレー装置１３の運用モデルの情報を取得し（ステップ6-1）、保守用ＣＰＵ１５のエージェントPF１８の移動機能５２に対して移動を要求し（ステップ6-2）、保守サーバ１２へエージェントを転送する（ステップ6-3）。保守サーバ１２では、転送されてきた遠隔制定エージェントをエージェント処理管理機能６１で起動させて（ステップ6-4）、保護リレー装置１３の状況を遠隔整定アプリケーションに通知し（ステップ7-1）、さらにエージェント担当者に対して保護リレー装置１３の状況を通知し（ステップ7-2）、整定値を書き込むための入力を待機する（ステップ7-3）。以後、保守担当者の指示に基づいて、ステップ1〜7と同様の処理の流れで、仮設定、保護リレー装置１３への整定値書き込み、運用開始の指示の順に行い（ステップ8）、整定を完了する。
以上のようにして、本エージェントシステムでは、遠隔整定に必要な起動、情報取得・設定を行う。
【０１３１】
（実施例２）
事故波形データ配信を例として、保護リレー装置の動作を起点として、保守所４にいる担当者へ事故波形データを配信する場合の動作を説明する。
ここで、保守用CPUのエージェントPFのプロファイルには、以下の指定を行う。
（１） 保護リレー装置の状態変化発生時、事故波形データ配信エージェントを生成し、保護リレー装置状態変化のイベントをログとして記録する。
利用する事故波形データ配信エージェントは、以下の構成とする。
（２） エージェントの処理ロジック（保守用CPU）：エージェント生成後、時刻と波形データを検索キーとして、事故波形データを取得する。検索終了後、プロファイルに指定されたサーバへ移動する。
（３） エージェントの処理ロジック（保全サーバ）：事故解析アプリケーションへ保護リレー装置動作を通知し、データをファイルとして保存する。
・ エージェントが保持するデータ：エージェントは、情報配信のために事故波形データを収容する。
尚、エージェントシステムは、保護リレー装置の動作を検出し、保護リレー装置が保持する事故波形データを取得し、保守サーバにデータを配信する場合を考える。本システムは、以下の動作を行う。図２５に処理の流れを示す。
【０１３２】
保護リレー装置１３が動作すると（ステップ1-1）、装置アクセスソフトウェア１９は、保護リレー装置１３に動作に伴う信号を検出する（ステップ1-2）。装置アクセスソフトウェア１９は、エージェントPF１８の外部サービスインタフェース５９の状変通知用APIを呼び出し状態変化を通知する（ステップ2-1）。また、保護リレー装置１３の動作情報を情報モデルの中に記録する（ステップ2-2）。外部サービスインタフェース５９は、イベント処理機能５８にその情報を伝える（ステップ3）。イベント処理機能５８は、ログ機能５７に対して履歴記録を要求する（ステップ4）。イベント処理機能５８は、エージェント生成機能５１に対して事故波形データ配信エージェントの生成を要求し（ステップ5）、エージェントを生成、あるいは起動する。事故波形データ配信エージェントは、装置アクセスソフトウェア１９に対して、事故に関する情報を取得するために、時刻と波形データを検索キーとして検索を要求する（ステップ6）。装置アクセスソフトウェア１９は、情報ツリー４５に対して検索を行い、運用モデルから取得した事故波形データをエージェントに要求の戻り値として与える（ステップ7）。事故波形データ配信エージエントは、生成時に指定された移動先である保守所４に対して移動するために、エージエントPF１８の移動機能５２に対して移動要求を出す（ステップ8-1）。エージェントPF１８はエージェントPF間通信機能５６を用いてエージェントを保守サーバ１２へ転送する（ステップ8-2）。保守サーバ１２へ転送された事故波形データ配信エージエントは起動され（ステップ8-3）、事故情報監視アプリケーション６５に状態通知し（ステップ9-1）、事故情報監視アプリケーション６５を通して保守担当者へ状態通知される（ステップ9-2）と共に、波形データが保守サーバ１２に記録される（ステップ9-3）。
このようにして、本エージェントシステムでは、保守対象の状態変化が起きたときに、そのことを検出して状態変化を示すデータ例えば事故波形データなどを自律的に収集して指定された箇所に配信することができる。なお、本実施例ではリレー装置の動作を起点とした基本的な処理について説明したが、その他の機器の動作並びにデータを処理させ得ることは言うまでもない。
【０１３３】
（実施例３）
事故解析情報集配信を例として、保守所４と電気所２だけではなく、関係する複数の電気所、系統の運転所までをエージェントの動作範囲として、エージェントによるシステムの広域集配信機能の動作を説明する。
ここで、保守用CPUのエージェントPFのプロファイルは、以下の指定を行う。
（１） 保護リレー装置の状態変化発生時には、事故解析情報集配信エージェントを生成し、かつ保護リレー装置状態変化のイベントをログとして記録する。
利用する事故解析情報集配信エージェントは、以下の構成とする。
（２） エージェントの処理ロジック（イベントが発生した保守用CPU）エージェント生成後、時刻と波形データを検索キーとして、事故波形データを取得する。検索終了後、構内の保守用CPUと電気所サーバを巡回する。
（３） エージェントの処理ロジック（構内の他の保守用CPUと電気所サーバ）装置アクセス内のイベント発生時前後の情報を検索し、取得する。巡回終了後、系統DBに移動する。
（４） エージェントの処理ロジック（系統DB）：関連する電気所の一覧を取得し、その電気所に移動する。
（５） エージェントの処理ロジック（装置情報DB）：エージェントの処理ロジック（系統DB）：装置情報DBに収集した情報を蓄積する。保守サーバへ移動する。
（６） エージェントの処理ロジック（保全サーバ）保全サーバのアプリケーションに収集した情報を伝え、待機する。保守所４の担当者が事故解析を行い、その結果がアプリケーションを通じて、エージェントへ渡されると、エージェントは他の保守所４および運転所を巡回する。
（７） エージェントの処理ロジック（他の保守所４と運転所）：解析結果から必要な情報を通知し、巡回する。巡回が完了すると、処理を終了する。
（８） エージェントが保持するデータ：エージェントは、情報集配信のために装置情報、系統情報（電気所一覧）、解析結果を収容する。
（９） エージェントの状態遷移：図２６に示すように、管理モードの変更によりエージェントを停止、終了できる。また、軽故障時には、処理を継続するが、重故障時には、エージェントの処理は終了する。
システムの振る舞いは以下の通りである。図２７に処理の流れを示す。
【０１３４】
保護リレー用CPU１６を介して保護リレー動作等の状態変化を、保守用CPU１５あるいは電気所サーバ９内の装置アクセスソフトウェア１９は検出し（ステップ1-1）、その情報をイベントとしてエージェントPF１８に送信する（ステップ1-2）。エージェントPF１８は、イベント内容に応じた事故解析エージェント生成（ステップ2-1）、やログ記録を行う（ステップ2-2）。生成された事故解析エージェントは、エージェントPF１８に移動を要求し（ステップ3-1）、装置アクセスソフトウェア１９を介して構内の関係する保守用CPU１０や電気所サーバ９を巡回し、事故に関連する情報を収集する（ステップ2-3）。保守用CPUや電気所サーバ内では、装置アクセスソフトウェア１９の検索機能を用いて、情報収容部４４の設備モデルおよび運用モデルから、必要な情報を収容したオブジェクトを保持する（ステップ3-2）。事故解析エージェントは、構内情報を収集後、系統DB５ｃに移動し、関連する電気所２を把握し（ステップ4-1）、その電気所２に移動して情報収集を行う（ステップ4-2）。事故解析エージェントは、収集した情報を装置情報DB５ｂに蓄積すると共に（ステップ5-1）、保守サーバ１２に収集した情報を伝える（ステップ5-2）。保守所４の担当者が事故解析を行い（ステップ5-3）、他の保守所４および運転所３に必要な分の解析結果の情報を通知し（ステップ5-4）、処理を終了する。
【図面の簡単な説明】
【０１３５】
【図１】本発明のモバイルエージェントによる制御システムの構成を示す図である。
【図２】位置管理装置の機能を示す機能ブロック図である。
【図３】本発明のモバイルエージェントによる制御システムの要部を示す機能ブロック図である。
【図４】ネットワーク端末で利用する通信プロトコルの構成を示す図である。
【図５】モバイルエージェントの移動処理を示す図であり、（ａ）はリソース不足への対応についての処理態様を示し、（ｂ）は通信障害への対応についての処理態様を示す。
【図６】エージェントＰＦ間での通信機能を示す図である。
【図７】装置アクセスソフトウェアの構成を示す機能ブロック図である。
【図８】ツリー構造とオブジェクトの構成を示す構成図である。
【図９】シーケンシャルファイルとオブジェクトとの対応関係を示す図である。
【図１０】対照テーブルの構成を示す図である。
【図１１】エージェントＰＦでの処理の流れを示すフローチャートである。
【図１２】保護制御装置からデータを取得する場合の処理の流れを示すフローチャートである。
【図１３】保護制御装置に対してデータ設定を行なう場合の処理の流れを示すフローチャートである。
【図１４】イベント監視部によるデータ取得の処理の流れを示すフローチャートである。
【図１５】エージェント技術を適用したシステムの基本アーキテクチャを示す図である。
【図１６】エージェントシステムモデルを示す図であり、（ａ）はハードウェア構成を示し、（ｂ）はソフトウェア構成を示す。
【図１７】仕様化する部位を示す図である。
【図１８】エージェントＰＦの構成を示す機能ブロック図である。
【図１９】異なるエージェント間で情報交換するための機能を示す図であり、（Ａ）はエージェントによる移動と処理ロジックの実行とを示し、（Ｂ）は処理ロジックの一例を示す。
【図２０】イベント処理機能と外部インターフェースの構成を示す図であり、（ａ）はイベント処理機能を示し、（ｂ）は外部インターフェースとの連携を示す。
【図２１】装置アクセスソフトウェアの構成を示す図である。
【図２２】装置アクセスソフト機能が収容するデータと処理内容を示すであり、（ａ）は検索ツリーとオブジェクトを示し、（ｂ）は情報取得時の処理内容を示す。
【図２３】情報モデルのツリー構成を示す図であり、（ａ）は設備モデルを示し、（ｂ）は運用モデルを示す。
【図２４】遠隔整定の処理態様を示す機能ブロック図である。
【図２５】事故情報配信の処理態様を示す機能ブロック図である。
【図２６】エージェントの状態遷移の処理態様を示す図である。
【図２７】モバイルエージェントが事故解析情報を集配信する態様を示す図である。
【図２８】装置アクセスソフトウェアにおける異なるデータの収容形態を示す図である。
【図２９】エージェントＰＦを構成している機能とその機能が対応する事柄との対応関係を示す図である。
【符号の説明】
【０１３６】
１ 制御システム
２ 電気所
３ 運転所
４ 保守所
５ データセンター
６ ＷＡＮ
７ ＬＡＮ
９ 電気所サーバ
１２ 設備保全サーバ
１５ 保守用ＣＰＵ
１６ リレー用ＣＰＵ
１７ 監視制御サーバ
１８ エージェントＰＦ
１９ 装置アクセスソフトウェア
２０ 外部サービスＩ／Ｆ
２１ イベント処理手段
２９ 外部イベント受信部
３０ 内部イベント受信部
３１ フィルター部
３２ 運用者用ルーチング部
３３ エージェント用ルーチング部
３４ 記憶部
３５ 履歴作成部
３６ 運用者用プロファイル
３６ａ、３７ａ 転送可否条件
３６ｂ、３７ｂ 転送先テーブル
３７ エージェント用プロファイル
３８ 装置アクセス機能
３９ イベント監視部
４０ 情報モデル変換部
４０ａ、４４ａ メモリ
４１ 独自アクセス部
４３ ツリー検索部
４４ データ収容部
４５ ツリー構造
【特許請求の範囲】
【請求項１】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するデータ処理システムにおいて、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データをラッパーオブジェクト形式で取得するデータ取得手段とを設けたことを特徴とするデータ処理システム。
【請求項２】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうデータ処理システムにおいて、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定を行なうデータ設定実行手段とを設けたことを特徴とするデータ処理システム。
【請求項３】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するデータ処理方法において、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データをラッパオブジェクト形式でデータ取得手段によって取得するステップとを設けたことを特徴とするデータ処理方法。
【請求項４】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうデータ処理方法において、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定実行手段によってデータ設定を行なうステップとを設けたことを特徴とするデータ処理方法。
【請求項１】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するデータ処理システムにおいて、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データをラッパーオブジェクト形式で取得するデータ取得手段とを設けたことを特徴とするデータ処理システム。
【請求項２】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうデータ処理システムにおいて、前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するデータ保持手段と、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データを指定するデータ指定手段と、このデータ指定手段によって指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定を行なうデータ設定実行手段とを設けたことを特徴とするデータ処理システム。
【請求項３】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に関するデータを取得するデータ処理方法において、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ取得要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データをラッパオブジェクト形式でデータ取得手段によって取得するステップとを設けたことを特徴とするデータ処理方法。
【請求項４】
入出力されるデータ形式が異なる複数の機器の中から機器を指定してその機器に対してデータ設定を行なうデータ処理方法において、データ保持手段によって前記複数の機器に関するデータをツリー構造を用いてラッパーオブジェクト形式で保持するステップと、入力されたデータ設定要求信号に基づいて前記ツリー構造から前記データをデータ指定手段によって指定するステップと、その指定された前記データを用いて、このデータに対応した前記機器に対してデータ設定実行手段によってデータ設定を行なうステップとを設けたことを特徴とするデータ処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２００７−５２５６３（Ｐ２００７−５２５６３Ａ）
【公開日】平成１９年３月１日（２００７．３．１）
【国際特許分類】
【出願番号】特願２００５−２３６１６８（Ｐ２００５−２３６１６８）
【出願日】平成１７年８月１６日（２００５．８．１６）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００５年２月１６日 社団法人電気学会主催の「保護リレーシステム研究会」において文書をもって発表
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１７年８月１０日から８月１２日 電気学会電力・エネルギー部門主催の「平成１７年 電気学会 電力・エネルギー部門大会」において文書をもって発表
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１７３８０９）財団法人電力中央研究所 (1,040)
【Ｆターム（参考）】
【公開日】平成１９年３月１日（２００７．３．１）
【国際特許分類】
【出願日】平成１７年８月１６日（２００５．８．１６）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００５年２月１６日 社団法人電気学会主催の「保護リレーシステム研究会」において文書をもって発表
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１７年８月１０日から８月１２日 電気学会電力・エネルギー部門主催の「平成１７年 電気学会 電力・エネルギー部門大会」において文書をもって発表
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１７３８０９）財団法人電力中央研究所 (1,040)
【Ｆターム（参考）】
[ Back to top ]