(57)【要約】【課題】被監視装置の状態を容易に判定する。【解決手段】被監視装置の装置状態を判定するメンテナンスシステムであって、個々のモジュールの状態をモジュール状態として判定する複数のモジュール状態判定手段と、前記装置状態を判定する被監視装置状態判定手段と、少なくとも前記装置状態を伝送する伝送手段とを備え、前記複数のモジュール状態判定手段、前記被監視装置状態判定手段および前記伝送手段は前記被監視装置内部に具備され、前記被監視装置状態判定手段は複数の前記モジュール状態から前記装置状態を判定することを特徴とする。【選択図】  図１
2004192192.tif 000002
【特許請求の範囲】
【請求項１】
被監視装置の装置状態を判定するメンテナンスシステムであって、個々のモジュールの状態をモジュール状態として判定する複数のモジュール状態判定手段と、前記装置状態を判定する被監視装置状態判定手段と、少なくとも前記装置状態を伝送する伝送手段とを備え、前記複数のモジュール状態判定手段、前記被監視装置状態判定手段および前記伝送手段は前記被監視装置内部に具備され、前記被監視装置状態判定手段は複数の前記モジュール状態から前記装置状態を判定することを特徴とするメンテナンスシステム。
【請求項２】
前記装置状態は前記モジュール状態を集約した情報であることを特徴とする請求項１に記載のメンテナンスシステム。
【請求項３】
前記装置状態はひとつの前記被監視装置に対してひとつ定義されることを特徴とする請求項１または２に記載のメンテナンスシステム。
【請求項４】
前記伝送手段は伝送路を介してマネージャと接続され、前記マネージャは前記装置状態を取得することを特徴とする請求項１から３のいずれかに記載のメンテナンスシステム。
【請求項５】
前記伝送手段は伝送路を介してマネージャと接続され、前記マネージャは前記装置状態および前記モジュール状態を取得することを特徴とする請求項１から３のいずれかに記載のメンテナンスシステム。
【請求項６】
前記被監視装置は前記装置状態を表示する表示手段を備えることを特徴とする請求項１から３のいずれかに記載のメンテナンスシステム。
【請求項７】
前記装置状態はＭＩＢ構成とすることを特徴とする請求項１から５のいずれかに記載のメンテナンスシステム。
【請求項８】
前記モジュール状態および前記装置状態はＭＩＢ構成とすることを特徴とする請求項１から５のいずれかに記載のメンテナンスシステム。
【請求項９】
前記マネージャおよび前記被監視装置は前記装置状態の伝送にＳＮＭＰを使用することを特徴とする請求項４または５に記載のメンテナンスシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は複数のモジュールから構成される被監視装置の状態を監視するメンテナンスシステムに関する。
【０００２】
【従来の技術】
従来、ネットワーク（伝送路）を構成するルータ、交換機、スイッチ等のいわゆるネットワーク機器のメンテナンスにおいては、例えば一定時間のパケットの受信個数等、機器自身が収集した状態を外部に知らせるために公開する情報をＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ：ＲＦＣ  １１５６、ＲＦＣ  １２１３）として定義し、ＭＩＢの情報をＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ：ＲＦＣ  １１５７、ＲＦＣ  １９０５）を用いて取得してメンテナンスを効率よく行う手法が当業者にはよく知られている。上記手法において、監視される側の装置（非監視装置）をエージェント、監視する側の装置をマネージャと呼ぶ。
【０００３】
図２はメンテナンスシステムの一般的構成を示すブロック図である。図２において１００はエージェント、２００はマネージャ、２０１は伝送路（ネットワーク）である。図２ではエージェントはひとつの例を示しているが、一般的は複数のエージェントが伝送路２０１に接続されて、マネージャ２００によって監視される。またエージェントは上記のネットワーク機器だけでなくプリンタやコンピュータ等様々な機器である。
【０００４】
マネージャはたとえばパーソナルコンピュータ（ＰＣ）等で構成され、マネージャ上でＳＮＭＰを用いて監視するソフトウェアが多数販売されている。ＭＩＢはオブジェクトと呼ばれる管理項目の定義の集まりである。ネットワーク機器の基本的なＭＩＢはＲＦＣ  １２１３にいわゆるＭＩＢ−ＩＩとして定義されており、パケットの処理個数等が定義されている。
【０００５】
また、検査対象の装置にＭＩＢを定義してＳＮＭＰで監視する方法は、ネットワーク機器のみならず映像機器にも広がりつつある。例えば、ＰｒｏｐｏｓｅｄＳＭＰＴＥ  Ｒｅｃｏｍｍｅｎｄｅｄ  Ｐｒａｃｔｉｃｅ  ４ｔｈ  Ｄｒａｆｔ  ｆｏｒ  Ｔｅｌｅｖｉｓｉｏｎ  ＤＤＲＭＯＮ−ＭＩＢ−１  Ａ  Ｄｉｇｉｔａｌ  Ｄｉｓｋ  Ｒｅｃｏｒｄｅｒ  Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  （Ｓｅｐｔｅｍｂｅｒ  ２００２）がある（以下、従来技術１）。
【０００６】
従来技術１はディジタルディスクレコーダに関するＭＩＢを定義している。ＭＩＢのオブジェクト定義の一例として、機器内部のモジュールの状態を表すものがある。具体的には、電源のコンディションをｎｏｒｍａｌ（正常）、ｆａｕｌｔｙ（異常）あるいはｎｏｔ−ｉｎｓｔａｌｌｅｄ（実装されていない）で表し、装置に取り付けられたファンの状態をｆａｎ−ｏｋ（正常）あるいはｆａｎ−ｆａｕｌｔ（異常）で表す。
【０００７】
一般的には、モジュールの状態（エラー）を表すためにＭＩＢでよく用いられる具体的例として以下のような５段階に分けられる場合がある。Ｃｒｉｔｉｃａｌは被監視装置を至急停止してエラーを解決する必要がある状態。Ｍａｊｏｒは致命的なエラーではないが重要なエラーである状態。Ｍｉｎｏｒは致命的なエラーではないが警告が発せされるべき状態。Ｗａｒｎｉｎｇは保守や運用のために通知が発せられるべき状態。Ｃｌｅａｒ（Ｎｏｒｍａｌ）は正常状態である。
【０００８】
【非特許文献１】
アール・エフ・シー１１５６（ＲＦＣ１１５６）
【非特許文献２】
アール・エフ・シー１２１３（ＲＦＣ１２１３）
【非特許文献３】
アール・エフ・シー１１５７（ＲＦＣ１１５７）
【非特許文献４】
アール・エフ・シー１９０５（ＲＦＣ１９０５）
【非特許文献５】
アール・エフ・シー１２１３（ＲＦＣ１２１３）
【非特許文献６】
プロポーズド・エス・エム・ピー・ティー・イー・レコメンデド・プラクティス・４ス・ドラフト・フォー・テレビジョン・ディー・ディー・アール・エム・オー・エヌ−エム・アイ・ビー−１  エイ・ディジタル・ディスク・レコーダー・シンプル・ネットワーク・マネージメント  プロトコル・マネージメント・インフォメーション・ベース（セプテンバー２００２）（（Ｐｒｏｐｏｓｅｄ  ＳＭＰＴＥ  Ｒｅｃｏｍｍｅｎｄｅｄ  Ｐｒａｃｔｉｃｅ  ４ｔｈ  Ｄｒａｆｔｆｏｒ  Ｔｅｌｅｖｉｓｉｏｎ  ＤＤＲＭＯＮ−ＭＩＢ−１  Ａ  Ｄｉｇｉｔａｌ  Ｄｉｓｋ  Ｒｅｃｏｒｄｅｒ  Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  （Ｓｅｐｔｅｍｂｅｒ  ２００２））
【０００９】
【発明が解決しようとする課題】
しかしながら上記従来の構成では以下のような問題点を有していた。従来技術１のように被監視装置内部の個々のモジュールの状態を通知するためのオブジェクトが定義され、マネージャがそれら全てをＳＮＭＰで取得して表示してもマネージャに表示された多数のモジュールの状態を見て管理者が被監視装置の全体としての状態を把握するのには時間がかかるという問題点を有していた。ここで注意が必要なのは従来技術１では、２つのモジュールの状態が簡易に定義されているにすぎないが、一般的には被監視装置は多数のモジュールで構成され、かつより複雑な状態定義がされる可能性があるという点である。
【００１０】
具体的には、例えばモジュールのコンディションが１００個定義されていた場合、マネージャのＰＣには１００個の状態が表示される。この場合、９９個のモジュールがＣｌｅａｒであり、１個のモジュールがＣｒｉｔｉｃａｌであった場合、Ｃｒｉｔｉｃａｌを見逃してしまい、本来は被監視装置は至急停止されてエラーを解決されるべきであるのに正常であると思われて引き続き使用されてしまう危険性がある。
【００１１】
上記の例は２種類のエラーしか発生していない場合であるが、別の例としてＣｒｉｔｉｃａｌが１個、Ｍａｊｏｒが３個、Ｍｉｎｏｒが６個、Ｗａｒｎｉｎｇが２０個、Ｃｌｅａｒが７０個の場合に、Ｃｒｉｔｉｃａｌが発生しているかを探すのが困難であることは容易に想像がつく。さらに、個々のモジュールの状態が刻々とマネージャの端末に表示されて、その表示部分がスクロールしている場合は、さらに被監視装置の状態を一目で判断するのは不可能である。しかもこれらのエラー表示は多くの場合重大なエラー順には表示されないので、被監視装置の状態を一目で判断するのはますます困難となる。
【００１２】
つまり複数のモジュール状態の表示のみで瞬時に被監視装置の状態を知ることは不可能であるという問題点を有していた。
【００１３】
この問題は、例えば上記ディジタルディスクレコーダが放送局で使用されていた場合、再生不良の状態となりオンエアできないというような放送事故を起こしても管理者がすぐには気づかずに、多数の視聴者が放送を見ることができない状態が長く続いてしまうというような危険性があるということである。また被監視装置が例えば発電所、医療、交通等に使用される機器の場合、事故や生命にかかわる状態が管理者に長時間発見されないという危険性がある。
【００１４】
上記課題を解決する方法の一例として、ＳＮＭＰで取得したＭＩＢ情報のモジュール状態の情報から重大なエラーを抽出して報告するソフトウェアをマネージャ上に実装する手法が考えられる。しかしながらこの手法は、エージェントが特定のメーカーの装置だけで構成されている場合であって、かつそれらを管理するための特別なソフトウェアを具備したマネージャを使用する場合にのみ有効である。その理由として以下のようなことがある。エラーの段階の区別はメーカによってばらつきが発生すると考えられ、各モジュールのエラーの組み合わせから総合的な被監視装置の状況を判定する一般的アルゴリズムを開発することは困難である。また上記の５段階の区別は一例であってメーカによって例えば３段階やその他の場合もあり、これらの場合はさらに状況は複雑である。
【００１５】
さらには多くの場合、管理者は上記ディジタルディスクレコーダを監視する場合でも、当然ネットワーク経由で監視する以上、ネットワーク機器も監視対象となるので、ネットワーク機器の監視に対応した市販のマネージャソフトウェアを用いる場合が多数である。これらの場合は上記解決策は有効ではない。
【００１６】
上記問題点は、本質的には被監視装置の個々のモジュールの状態はエージェント側で判定しているが被監視装置の総合的な状態をエージェントが判定していないことに起因する。
【００１７】
【課題を解決するための手段】
上記課題を解決するために本願発明は、被監視装置の装置状態を判定するメンテナンスシステムであって、個々のモジュールの状態をモジュール状態として判定する複数のモジュール状態判定手段と、前記装置状態を判定する被監視装置状態判定手段と、少なくとも前記装置状態を伝送する伝送手段とを備え、前記複数のモジュール状態判定手段、前記被監視装置状態判定手段および前記伝送手段は前記被監視装置内部に具備され、前記被監視装置状態判定手段は複数の前記モジュール状態から前記装置状態を判定することを特徴とする。
【００１８】
さらに好適には、前記装置状態は前記モジュール状態を集約した情報であることを特徴とする。
【００１９】
また、さらに好適には、前記装置状態はひとつの前記被監視装置に対してひとつ定義されることを特徴とする。
【００２０】
これにより装置状態を監視することにより、被監視装置の状態を一目で確認することを可能とする。
【００２１】
【発明の実施の形態】
（実施の形態１）
図１は本願発明によるエージェントの一実施例を示すブロック図である。本実施の形態ではエージェントの一例として、ビデオテープレコーダ（ＶＴＲ）を例とする。図１において１００は被監視装置（エージェント）、１０１はモジュール状態判定手段であり、具体的にはＶＴＲのテープへの記録及び再生を行うヘッドを搭載したシリンダとその状態を監視して判定する機能を有している（以下、シリンダ１０１と称す）。１０２は同じくモジュール状態判定手段であり、ＶＴＲの電源と電源状態を監視して判定する機能を有している（以下、電源１０２と称す）。１０３も同じくモジュール状態判定手段であり、ＶＴＲ内部の温度上昇を抑えるために内部空気を外部に排出するファンとファンの状態を監視して判定する機能を有している（以下、ファン１０３と称す）。なお１０１、１０２および１０３のモジュール状態判定手段は一例であり、被監視装置内部のモジュール状態判定手段の個数および種類はこれに限るものではなく、被監視装置に応じて変わることは言うまでもない。
【００２２】
１０４は被監視装置状態判定手段であり、上記１０１、１０２および１０３のモジュール状態判定手段からモジュール状態の情報を取得して集約し、装置全体の状態を代表する装置状態を判定する。１０６は伝送手段であり、図２に示した伝送路２０１に接続され、マネージャに装置状態を伝送する。
【００２３】
なお、表示手段１０５は被監視装置１００に具備された装置状態を表示するための装置であり、例えばＬＥＤで状態が表示されるが、遠隔のマネージャで被監視装置を監視する場合には必須構成要件ではない。
【００２４】
次に個々のモジュール状態判定手段の動作の一例について詳細に説明する。個々のモジュールの状態の定義はモジュール状態と称し、そのレベルについてはすでに説明した、Ｃｒｉｔｉｃａｌ、Ｍａｊｏｒ、Ｍｉｎｏｒ、Ｗａｒｎｉｎｇ、Ｃｌｅａｒの５段階を例とする。なお、これらの区分けは説明のための例であり、これに限るものではない。
【００２５】
シリンダ１０１は例えばテープ再生時のエラーレートでモジュール状態が定義される。一例としては、エラーレートが１＊１０＾（−４）以上であればＣｒｉｔｉｃａｌ、５＊１０＾（−５）以上であればＭａｊｏｒ、１＊１０＾（−５）以上であればＭｉｎｏｒ、５＊１０＾（−６）以上であればＷａｒｎｉｎｇ、以上に当てはまらなければＣｌｅａｒとして、もっとも重度の高い値が設定される（ここで、＊は掛け算を、＾はべき乗を意味する）。
【００２６】
電源１０２は、内部で使用する＋５Ｖの電源の電圧のモジュール状態が定義される。一例としては、＋４．６Ｖ以下であればＣｒｉｔｉｃａｌ、＋４．７Ｖ以下であればＭａｊｏｒ、＋４．８Ｖ以下であればＭｉｎｏｒ、＋４．９Ｖ以下であればＷａｒｎｉｎｇ、以上に当てはまらなければＣｌｅａｒとして、もっとも重度の高い値が設定される。
【００２７】
ファン１０３はファンの回転数のモジュール状態が定義される。一例としては、通常回転数の６０％以下であればＣｒｉｔｉｃａｌ、７０％以下であればＭａｊｏｒ、８０％以下であればＭｉｎｏｒ、９０％以下であればＷａｒｎｉｎｇ、以上に当てはまらなければＣｌｅａｒとして、もっとも重度の高い値が設定される。
【００２８】
被監視装置状態判定手段１０４はシリンダ１０１、電源１０２およびファン１０３からのモジュール状態を取得して集約し、被監視装置の総合的な状態を判定して被監視装置の状態を代表する装置状態として一つのオブジェクトを生成する。
【００２９】
なお、本実施の形態では装置状態は一個のオブジェクトとして説明を行うが、本願発明において重要な点は、装置状態はモジュール状態の情報を集約した情報であるという点である。つまり、モジュール状態の個数よりも装置状態の個数のほうが少なくなる。したがって、被監視装置の監視者が瞬時に被監視装置の状態を把握できる個数であれば、装置状態はいくつであってもよい。
【００３０】
次に被監視装置状態判定手段１０４での装置状態判定の一例を説明する。シリンダ１０１のモジュール状態がＣｌｅａｒ、電源１０２のモジュール状態がＭａｊｏｒ、ファン１０３のモジュール状態がＭｉｎｏｒを判定し、被監視装置状態判定手段１０４に入力された場合を考える。この場合、３つのモジュール状態のうち最も重度の高い電源１０２のモジュール状態のＣｒｉｔｉｃａｌを装置状態として判定する。
【００３１】
この場合、被監視装置全体の装置状態を代表する装置状態としてＭａｊｏｒ  が設定され、さらに個々のモジュールのモジュール状態として、シリンダ１０１のモジュール状態がＣｌｅａｒ、電源１０２のモジュール状態がＣｒｉｔｉｃａｌ、ファン１０３のモジュール状態のＭｉｎｏｒが設定されている。つまり個々のモジュール状態はそのまま保持され、新たに被監視装置全体の装置状態が判定される。
【００３２】
ここで、本願発明において重要な点は、装置状態の判定がマネージャによって行われるのではなくエージェント（被監視装置）において行われるという点である。これによりマネージャはひとつのオブジェクトを取得するだけで被監視装置の状態を瞬時に判定可能となる。なお、被監視装置状態判定手段１０４は安価なマイコン等を用いてソフトウェアで判定アルゴリズムを実装すれば容易に実現可能である。
【００３３】
装置状態およびモジュール状態は伝送手段１０６から伝送路２０１（図２）を介してマネージャ２００（図２）が取得して監視者が確認する。
【００３４】
次に、本願発明の効果を具体的に説明するためにマネージャの端末を監視する監視者の立場から本願発明の有効性を説明する。
【００３５】
図３はオブジェクト情報表示の模式図である。マネージャは伝送路２０１経由で取得した被監視装置１００のオブジェクト情報を表示する。３００はディスプレイ全体を示す。３０１は被監視装置の装置状態の表示（装置状態表示）を示す。３０２はモジュール状態の表示（モジュール状態表示）を示す。
【００３６】
監視者は常に装置状態表示３０１を監視することで被監視装置がどのような状態であるかを容易に知ることができる（図３ではＭａｊｏｒの例を示している）。重度の大きな障害が発生した場合は各障害レベルのライトが表示されているので即時に知ることができ。例えばＣｒｉｔｉｃａｌの場合は、至急被監視装置を停止させる等の処置を施すことができる。つまり、機器全体の状態をすばやく知り、必要であれば適切な処置を施した後で、モジュールのどの部分の障害が原因であるかをモジュール表示状態３０２で解析する。
【００３７】
ここで従来の方法と比較する。従来の手法では、モジュール状態しか表示されないので機器の障害を見逃す危険性があった。具体的にはモジュール状態表示装置３０２にはたくさんのモジュールの状態が表示されるために、極端な場合は表示エリアが足りず、常にモジュール状態表示がスクロールするなどして監視者が障害を見逃す場合が発生した。本願発明ではそのような危険性は全く排除される。
【００３８】
なお、本願発明の効果をよりわかりやすく説明するために、図３を用いてグラフィカルユーザーインタフェース（ＧＵＩ）を用いて説明したが、市販のＳＮＭＰマネージャソフトウェアを使用した場合は、装置状態を示すオブジェクトを常に監視すればよい、この時、装置状態のオブジェクトは少ない個数であるため（本実施の形態では一つ）ＧＵＩを用いなくても監視が容易であることは言うまでも無い。つまり、取得したモジュール状態から監視状態を判定するソフトウェアを新規に開発するまでもなく、市販のソフトウェアで監視が可能となる。
【００３９】
なお、本実施の形態では装置状態を判定する例として、複数のモジュール状態のうち、最も重大な状態を装置状態とする例を説明したがこれに限るものではない。例えば、シリンダ１０１のモジュール状態がＣｌｅａｒ、電源１０２のモジュール状態がＭｉｎｏｒ、ファン１０３のモジュール状態がＭａｊｏｒを判定し、被監視装置状態判定手段１０４に入力された場合を考える。この場合でも、例えばファンは内部温度の上昇を抑える目的で取り付けられたが、ファンが無くても十分な放熱が行われ、ファンは予備的に設置されている場合、あるいは別途内部温度センサーが具備されモジュール状態として定義されており、特に問題となる温度上昇が見られない場合等は必ずしもファン１０３のモジュール状態のＭａｊｏｒを装置状態をとする必要はなく、電源１０２のＭｉｎｏｒを被監視装置の装置状態とする場合もありうる。
【００４０】
つまり、被監視装置の装置状態の判定は、個々の装置により独自の判定方法があり、同じような装置でもメーカが異なれば独自の判定アルゴリズムが存在する。このような理由からも装置状態の判定は装置を開発したメーカが独自にエージェントに実装することが必須である。従来の技術で説明したように、仮にマネージャソフトウェアが判定する場合は、世の中に存在するすべての機器の装置状態判定のアルゴリズムを実装しなければならず、実装規模の大きさやメーカから必ずしもアルゴリズムが開示されるとは限らないのでそのようなことは実現不可能であることは言うまでもない。
【００４１】
なお、本実施の形態ではひとつの被監視装置の装置状態はひとつ定義されるが、例えばあるエージェントが独自バス等を用いて他の機器の状態を代理でマネージャに対して返答する、代理構成（プロキシ構成）をとる場合は、代理のエージェントが見かけ上複数の装置状態を保持しＭＩＢのテーブル構成等にすることも可能であり、そのような場合でも本願発明の趣旨からは外れておらず、本願発明の範囲から排除するものではない。
【００４２】
また、本実施の形態では図１において、個々のモジュール状態を伝送するために、非監視状態判定手段１０４を経由して伝送手段１０６から伝送路２０１に送出する方法を例示したが、これに限らず、個々のモジュール状態は直接伝送手段１０６経由で伝送路２０１に送出されてもよい。また、モジュール状態、装置状態さらにはその他の状態の情報を一旦マイコン等で収集してから伝送手段１０６から送出するなどしてもよい。
【００４３】
また、本実施の形態では、個々のモジュール状態は状態表示のみを行う場合を例としたが、モジュール状態に付随して、インデックス、エラーレベル、エラーコード、エラー説明、エラー時間等とセットにしてテーブル形式のＭＩＢオブジェクト等としてもよい。その場合上記のプロキシ構成とする場合はプロキシを加えてもよい。
【００４４】
また、本実施の形態では装置状態のオブジェクトは１個としたが、モジュールの種別ごとに装置状態を集約することで装置状態を複数個設定してもよい。
【００４５】
また、本実施の形態では装置状態のオブジェクトは１個としたが、その場合、ＭＩＢ構成上は独立した単一のオブジェクトとすればよいが、数個の装置状態を定義する場合はテーブル構成としてもよい。その場合、インデックス、エラーレベル、エラーコード、エラー説明、エラー時間等とセットにしてテーブル形式のＭＩＢオブジェクト等としてもよい。その場合上記のプロキシ構成とする場合はプロキシを加えてもよい。
【００４６】
また、本実施の形態では説明の簡易化のため、３個のモジュール状態を１個の装置状態に集約する例を説明したが、これらの個数に限らないことは言うまでもない。
【００４７】
また、本願の説明において、装置の状態をＭＩＢで定義し、マネージャがＳＮＭＰで取得する場合を例としたが、装置状態が各装置に定義され、その装置状態を管理装置から取得するものであれば、ＭＩＢとＳＮＭＰに限るものではなく、本願発明の範囲から排除するものではない。
【００４８】
また、本実施の形態においてはＶＴＲを例としたがこれに限るものではないことは言うまでもない。
【００４９】
また、ＳＮＭＰにおいて、エージェントがマネージャに対してトラップと呼ばれる手法で状態を通知する方法が用いられるが、本願においても装置状態やモジュール状態をエージェントが能動的に上記状態をマネージャに通知する手法を用いれば、さらにすばやく監視者に異常を通知することができ、本願発明の効果がさらに高まることは言うまでもない。したがってそのような場合でも本願発明の範囲から排除するものではない。
【００５０】
【発明の効果】
以上説明したように本願発明においては、被監視装置の装置状態をエージェント側で独立のオブジェクトとして定義して、マネージャが取得することにより、管理者が被監視装置の異常を見逃す危険性を排除することが可能となる。
【００５１】
さらに、管理者が機器全体の状態を判定でき、必要に応じて的確な処置をすばやく行うことが可能となる。また、同時にモジュールの状態を取得することで障害の原因を究明することが可能となる。
【００５２】
また、被監視装置を製造したメーカにかかわらず、汎用のマネージャソフトウェアがそのまま使用可能であり安価な監視システムを構築可能である。
【００５３】
また、ネットワーク経由で遠隔で監視できることは言うまでもない。
【図面の簡単な説明】
【図１】本願発明によるエージェントの一実施例を示すブロック図
【図２】メンテナンスシステムの一般的構成を示すブロック図
【図３】オブジェクト情報表示の模式図
【符号の説明】
１００  被監視装置（エージェント）
１０１  モジュール状態判定手段（シリンダ）
１０２  モジュール状態判定手段（電源）
１０３  モジュール状態判定手段（ファン）
１０４  被監視装置状態判定手段
１０５  表示手段
１０６  伝送手段
【図１】
2004192192.tif 000003
【図２】
2004192192.tif 000004
【図３】
2004192192.tif 000005