以下図面を参照して、本発明の各実施形� ��について説明する。

(第1の実施形態)
 図1は第1の実施形態に係る遠隔監視・診断� �ステムの構成図である。

 この遠隔監視・診断システムは、中央セ� ��タの役割を持った中央側処理系1と、各監視 対象2の監視・診断を行う監視対象側監視処� �系3-1,…とが通信ネットワーク4で接続されて いる。

 中央側処理系1は、監視・診断ソフト用ア ルゴリズム作成部11と、監視・診断ソフト作� ��部12と、ソフト及びデータの受け渡しの基� �ベースとなるフラットフォーム13と、監視・ 診断ソフト実行処理部14と、予防保全支援情� ��作成部15と、予防保全最適化処理部16とが設 けられている。

 監視・診断ソフト用アルゴリズム作成部1 1は、各監視対象の処理形態や各監視処理系3- 1,…の処理能力に応じた監視、診断の手順等� ��規定するソースコードのアルゴリズムを作� ��する。そのためには、事前に各監視対象2に 関するデータや仕様を入手し、これら入手し たデータや仕様に基づいて各監視対象2を監� �及び診断する監視アルゴリズム及び診断ア� �ゴリズム(以下、監視・診断アルゴリズムと� ��称する)を作成する。

 ここで、処理形態は各監視処理系3-1,…に よる監視対象の処理内容や処理目的に依存し て異なる。また、処理能力は各監視対象2を� �視・診断する各監視処理系3-1,…の処理速度� ��回転速度等の監視処理系自体の能力に依存� ��て異なる。また、事前に入手する各監視対� ��2に関するデータの例としては、各監視対象 2に設置される各センサの計測値、指令値等� �挙げられる。例えば監視対象2として電動機� ��使用されている場合、その電動機に与えら� ��る指令値と回転数の計測値等が挙げられる� ��これらデータは、監視対象2から通信ネット ワーク4を介して送られてくるデータのケー� �や保守員が実際に現地に出向いて必要なデ� �タを収集し、中央側処理系1の計算機にアッ� ��ロードもしくは手入力するケースもある。

 なお、中央側処理系1には、以上のように 監視対象2の必要なデータを確実に取り込む� �めに、プラットフォーム13が設けられている 。

 事前に入手する各監視対象の仕様の例と� ��ては、各監視対象2に使用される部品等の仕 様である。例えば監視対2に電動機が使用さ� �る場合、その電動機の仕様等である。

 監視に関するアルゴリズムに関しては、� ��視したいデータを分析し、必要であればフ� ��ルタリング処理を実施したり、監視対象2の データに最適なフィルタを選択することによ り、監視に最適なアルゴリズムを作成する。

 診断に関するアルゴリズムの例としては� ��例えば予め監視対象2の状態を表す監視デー タ(例えばセンサ計測値、操作指令値)に対す� ��しきい値を設定し、1種類もしくは複数種類 の監視データがしきい値を超えたとき、警報 もしくは異常通報を表す診断結果を出力する アルゴリズムが一例となる。複数種類の監視 データを利用する場合、各しきい値を用いて 、監視データ判定用の式を作成することも考 えられる。例えば複数種類の監視データが1� �のしきい値を超えたときに軽レベル異常、2� ��のしきい値を超えたとき中レベル異常、3つ 以上のしきい値を超えたとき重レベル異常等 と診断するごときである。

 さらに、監視対象2に操作を加える必要が ある場合には、必要な操作手順を記述した操 作用アルゴリズムを作成する。

 なお、アルゴリズムの作成方法としては� ��プログラム文法によるソースファイルやフ� ��ーチャート形式で作成する。

 また、監視・診断ソフト用アルゴリズム� ��成部11は、後記する監視・診断ソフト作成� �12で作成された監視ソフト及び診断ソフト(� �下、監視・診断ソフトと呼ぶ)の各監視対象� ��監視処理系3-1,…による実行結果である監視 データや診断結果等のフィードバックデータ を取り込み、アルゴリズム作成者が対話形式 を取りながら、作成された監視・診断ソフト 用アルゴリズムを適宜修正・変更し、各監視 対象2に最適な監視・診断ソフト用アルゴリ� �ムを作成する。

 監視・診断ソフト作成部12は、監視・診� �ソフト用アルゴリズム作成部11で作成された 監視・診断用アルゴリズムのもとに、各監視 対象側監視処理系3-1,…にて動作可能な監視� �診断ソフトを作成する。

 監視・診断ソフトを作成するトリガとして� ��、以下のようなタイミングに基づいてソフ� ��を作成する。即ち、
(a)監視・診断ソフト用アルゴリズム作成部11� ��ら監視・診断ソフト用のアルゴリズムが送� ��れてきたタイミングである。

(b)監視・診断ソフト作成部12や中央側処理� ��1自体にヒューマンインタフェース(HMI)が具� ��されている場合、ヒューマンインタフェー� ��を介してソフト作成用トリガを受けたタイ� ��ングである。

 監視・診断ソフト作成部12は、ヒューマ� �インタフェースを通してソフト作成用トリ� �を受けたとき、監視・診断ソフト用アルゴ� �ズム作成部11に対してアルゴリズム作成用ト リガをかけ、必要とする監視用又は診断用ア ルゴリズムの作成を促す。

 監視・診断ソフトとしては、各監視・診� ��用アルゴリズムを実行するための純粋なプ� ��グラムソフトに、入力データ(移動プログラ ム等)を参照するためのサブルーチン、各監� �処理系3-1,…が診断結果等を出力するための� ��ブルーチン、OSなどの他のプログラムとや� �取りするためのサブルーチン等を追加する� �とにより作成する。

 監視・診断用ソフトの出力形式としては� ��各監視対象2の監視処理系3-1,…で実行可能� �ものであれば、どのような形式でも良い。� �えばそのまま実行可能なプログラムファイ� �、Webページを作成する記述言語やSoap(Simple o bject access protocol)に基づいて作成されたファ イルであってもよい。

 さらに、監視・診断ソフトを自律的な判� ��・実行機能を持たせたエージェントとして� ��成することも可能である。エージェントは� ��(イ)自律的に移動・動作すること、(ロ)他の エージェントと連携を取ることが可能である こと、(ハ)周りの変化に順応しつつ動作する� ��とが可能であること、(ニ)自発的に作業を� �施することが可能である等の特徴を有する� �すなわち、エージェントは、ユーザの意図� �理解しつつ自律的な判断に基づいて所要の� �理を実行する機能を持たせたものであって� �JAVA(登録商標)やXML、エージェント間通信用� �語(ACL)等を利用して作成する。

 しかし、監視・診断ソフトを利用する場� ��にはソフトを利用する実行環境が必要であ� ��と同様に、エージェントを利用する場合に� ��利用するエージェントの実行環境を整える� ��要がある。なお、監視診断ソフトをエージ� ��ントとして利用する場合、監視用エージェ� ��ト、診断用エージェント、監視のために監� ��対象2を操作する操作用エージェントのよう に、個別ソフトに分けて作成することも可能 である。

 プラットフォーム13は、前述したように� �フト・データの受け渡しの基本ベースとな� �機能を持つ部分であって、監視・診断ソフ� �伝送部17と、監視・診断ソフト伝送スケジュ ール作成部18と、監視対象情報受信部19とで� �成される。

 監視・診断ソフト伝送部17は、監視・診� �ソフト作成部12で作成された監視・診断ソフ トのうち、監視対象側監視処理系3-1,…で必� �とする処理内容を持ったソフトに送信先識� �データを付した状態で、通信ネットワーク4� ��介して必要な監視対象側監視処理系3-1,…に 伝送する。

 通信ネットワーク4としては、インターネ ット、イントラネット、公衆回線等が用いら れる。通信ネットワーク4を利用してソフト� �データを伝送する場合、例えばTCP/IPプロト� �ルやSNMPプロトコルなどを使用して伝送する� ��

 監視・診断ソフト伝送部17は、監視対象� �監視処理系3-1,…で必要とする監視・診断ソ� ��トを伝送するに当たり、監視・診断ソフト� ��送スケジュール作成部18で作成された伝送� �ケジュールに従って監視・診断ソフトを伝� �する。

 伝送スケジュールの一例としては、莫大� ��数の監視対象2,…が存在する場合、一定間� �毎の伝送スケジュールを作成し、かつ、該� �監視処理系例えば3-1が確実に受信したかの� �認をとりつつ、伝送スケジュールにそって� �送するための指示を監視・診断ソフト伝送� �17に送出する。これにより、監視・診断ソフ ト伝送部17は伝送時のエラーを無くすことが� ��能となる。

 監視対象データ情報受信部19は、監視・� �断ソフト伝送部17から所要のソフトを監視処 理系例えば3-1に伝送し、当該監視処理系例え ば3-1からソフトの実行結果である監視対象2� �監視データ、診断結果(フィードバックデー� ��)が返送されてくると、その監視データ、診 断結果を受信し、監視・診断ソフト実行処理 部14及び予防保全支援情報作成部15に送出す� �。

 監視・診断ソフト実行処理部14は、監視� �診断ソフト作成部12で作成された監視・診断 ソフトのうち、中央側処理系1自身で処理す� �き処理内容を持った監視・診断ソフトを受� �取り、監視データ、診断結果に対して更な� �監視・診断を実行する。

 中央側処理系1で実施するソフトの一例と しては、例えば1つの監視対象側監視処理系3- 1,…の監視、診断処理を補完するソフト、或� ��は複数の監視対象側監視処理系3-1,…から受 け取るデータを考慮しつつ診断するソフトな どが挙げられる。

 また、監視・診断ソフト実行処理部14は� �監視対象側監視処理系3-1,…から送信されて� ��るデータをプラットフォーム13の監視対象� �報受信部19を通して受け取り、前記中央側処 理系1で扱う監視・診断ソフトを用いて、監� �及び診断を実行する。

 この監視・診断ソフト実行処理部14は、� �監視対象側監視処理系3-1,…から送られてく� ��監視・診断ソフトの実行による診断結果や� ��視データを受信し、中央側処理系1自身で処 理されるべき内容を持った監視・診断ソフト を用いたシュミレーションモデル等を用いて 各監視対象側監視処理系3-1,…の処理能力不� �を補完し、或いは連携関係にある複数の各� �視対象側監視処理系3-1,…の状態を監視、診� ��し、例えば診断結果や監視データに基づき� ��既に管理保存中の類似性の高い過去の診断� ��果や監視データとを比較し、監視対象の構� ��部品の劣化や監視対象の能力低下や軽・中� ��重レベル異常等を見つけ出し、予防保全支� ��情報作成部15に送出する。

 この予防保全支援情報作成部15は、プラ� �トフォーム13の監視対象情報受信部19から受� ��取る各監視対象側監視処理系3-1,…の診断結 果及び監視データと、監視・診断ソフト実行 部14から得られる監視結果、監視データのも� ��に、予防保全の支援となる情報、例えば部� ��の点検、交換予測時期、さらに軽・中・重� ��ベル異常等の警告が出たとき、そのレベル� ��見合う速やかな点検、交換予測時期等の予� ��保全支援情報を作成し、予防保全最適化処� ��部16に送出する。

 予防保全最適化処理部16は、予防保全支� �情報作成部15で作成された予防保全支援情報 に基づき、マンマシンインタフェースを通し て対話形式で予防保全計画を作成する。例え ば各月の予定表等に既に書込み中の保守点検 場所と重複しないように調整したり、構成部 品の劣化や監視対象の能力低下に基づき、点 検周期を短くしたり、過去の経験等から致命 的な異常が発生する恐れがあるとき、該当部 品の交換を促すメッセージを出すなどである 。また、点検、交換予測時期を用いることに より、その時点における最適な点検保守、部 品交換計画を立てる。

 さらに、監視、診断を続けていくうちに� ��視対象2の状態が変化していくことが多いが 、初期の計画では最適な点検保守・部品交換 ができない可能性があるが、時々刻々変化し ていく状況を監視・診断することにより、劣 化傾向が明確となり、あるいは性能低下が顕 著に現れてくるので、最適な点検保守、部品 交換の計画を作成することができる。

 次に、各監視対象側監視処理系3-1,…にお いては、監視・診断ソフト受信部31と、監視� ��診断ソフト実行処理部32と、監視処理結果� �データベース33と、監視対象情報送信部34と� ��構成される。

 監視・診断ソフト受信部31は、監視・診� �ソフト伝送部17で扱う通信プロトコルと同一 の通信プロトコルを用いて、通信監視・診断 ソフト伝送部17から通信ネットワーク4を介し て伝送されてくる監視・診断ソフトを受信し 、監視・診断ソフト実行処理部32に送出する� ��

 監視・診断ソフト実行処理部32は、監視� �診断ソフト受信部31から受け取った監視ソフ トを実行し、監視対象2の監視データを取得� �て監視処理結果用データベース33に格納し、 また診断ソフト実行し、データベース33に格� ��された監視対象2の監視データの診断結果を 取得する。

 監視・診断ソフトの実行に関しては、監� ��、診断ソフトがEXE(EXECUTE)ファイル等の実行� ��ァイルの場合、そのファイルを実行する。

 また、監視・診断ソフト実行処理部32は� �監視・診断ソフトがエージェントである場� �にはエージェント実行環境のもとに、監視� �診断・操作用のエージェントを実行する。� �監視対象側監視処理系3-1,…では、例えば監� ��、診断ソフトをエージェントで作成されて� ��る場合、監視・診断・操作用のエージェン� ��を実行するが、これらのエージェントは次� ��ような作用を有する。

(監視用エージェント)
 監視用エージェントは、監視対象2の監視デ ータを監視しつつ、中央側処理系1で必要と� �るデータを監視対象情報送信部34に通知する 。監視対象情報送信部34は、通知内容に基づ� ��、監視処理結果用データベース33からデー� �を読み出し、通信ネットワーク4を介して中� ��側処理系1に送信する。

(診断用エージェント)
 診断用エージェントは、監視対象2の状態を 診断する。診断用エージェントは、監視処理 結果用データベース33から監視対象2の監視デ ータを取得し、監視対象2がどのような状況� �あるかを診断する。予め監視対象の状態を� �す監視データ(例えばセンサ計測値、操作指� ��値)に対するしきい値を設定し、1種類もし� �は複数種類の監視データがしきい値を超え� �とき、警報もしくは異常通報を表す診断結� �を出力するアルゴリズムが一例となる。複� �種類の監視データを利用する場合、各しき� �値を用いて、監視データ判定用の式を作成� �ることも考えられる。例えば複数種類の監� �データが1つのしきい値を超えたときに軽レ� ��ル異常、2つのしきい値を超えたとき中レベ ル異常、3つ以上のしきい値を超えたとき重� �ベル異常等と診断するごときである。

(操作用エージェント)
 操作用エージェントは、所定周期ごとに監� ��対象2の各センサの出力を取り込むための指 令を出したり、診断の目的や監視対象の動作 改善のために、自律的に監視対象2の機能を� �スト動作させたり、パラメータやしきい値� �変更する指令を出力する。

 前記監視処理結果用データベース33は、� �視・診断ソフト実行処理部32からの命令に基 づいて、監視対象2との制御データ及び監視� �ータのやり取りが可能な機能を有する。監� �処理結果用データベース33は予め定める期間 分のデータを保持する。データの保持期間に 関しては、取得データの種類や各監視対象側 監視処理系3-1,…の性能、監視・診断ソフト� �要求仕様により決定される。

 監視処理結果用データベース33と監視対� �2とのデータのやり取りは、RS232C接続による� ��送やUSB接続、ネットワーク接続により実施� ��きる。

(システムの動作)
 次に、以上のような構成のシステムの動作� ��ついて説明する。

 監視・診断ソフト用アルゴリズム作成部1 1から監視・診断用アルゴリズムが送られて� �たことをトリガとし、監視・診断ソフト作� �部12が監視・診断用アルゴリズムに基づいて 監視・診断ソフトを作成し、監視・診断ソフ ト伝送部17に送出する。

 このとき、監視・診断ソフト伝送部17は� �監視、診断ソフトを伝送する際、伝送スケ� �ュールに従って監視、診断ソフトを所定の� �信プロトコルにより通信ネットワーク4を介� ��て必要とする監視対象側監視処理系例えば3 -1に伝送する。

 また、監視対象側監視処理系例えば3-1の� ��視・診断ソフト実行処理部32は、監視・診� �ソフト受信部31で受信された監視・診断ソフ トのもとに実行し、監視データ及び診断結果 を取得し、監視処理結果用データベース33に� ��納するとともに、診断結果及び所定の周期� ��いし中央側処理系1の要求のもとに監視デー タの送信通知を監視対象情報送信部34に送る� ��監視対象情報送信部34は、通知内容に基づ� �、監視処理結果用データベース33から診断結 果及び必要な監視データを読み出し、通信ネ ットワーク4を介して中央側処理系1宛に送信� ��る。

 中央側処理系1の監視・診断ソフト実行処 理部14は、監視対象情報受信部19で受け取っ� �現時点の各監視対象側監視処理系3-1,…の監� ��結果、監視データを受け取ると、監視・診� ��ソフト作成部12から提供される中央側処理� �1のみで必要とする監視・診断ソフトを実行� ��、監視対象の状態変化、部品劣化の状態や� ��常のレベル等を診断し、予防保全支援情報� ��成部15に提供する。予防保全支援情報作成� �15は、現時点の各監視対象側監視処理系3-1,� �の監視結果、監視データと監視・診断ソフ� �実行処理部14の実行結果のデータとを用いて 、予防保全支援情報を作成し、予防保全最適 化処理部16に送出する。

 予防保全最適化処理部16は、予防保全支� �情報のもとに、対話形式を取りながら現時� �にて最適な予防保計画を作成し、保守セン� �や部品配送センタに送信する。

 また、監視・診断ソフト用アルゴリズム� ��成部11は、必要に応じて例えばアルゴリズ� �作成時または適宜な時期に、監視対象情報� �信部19で受信した各監視対象側監視処理系3-1 ,…の監視結果、監視データを取り込み、作� �された監視・診断ソフト用アルゴリズムの� �否を確認し、適宜修正・変更を加えること� �より、監視対象2にとって最適な監視・診断� ��フト用アルゴリズムを作成する。

 従って、以上のような実施形態によれば� ��中央側処理系1において、各監視対象側監視 処理系3-1,…の制御対象2の処理形態や各監視� ��象側監視処理系3-1,…自身の,処理能力に応� �た監視・診断ソフトを作成し、各監視対象� �監視処理系3-1,…に伝送するので、多数の監� ��対象が接続されている場合でも、個々の監� ��対象2を監視、診断する監視対象側監視処理 系3-1,…に十分対応でき、また、監視対象側� �視処理系3-1,…の監視・診断ソフトの更新が� ��較的容易に行うことができる。

 また、中央側処理系1から監視・診断ソフ トを伝送する際、中央側処理系1の伝送スケ� �ュールに基づき、ソフト伝送の成功、不成� �を確認することにより、監視・診断ソフト� �必要とする監視対象側監視処理系3-1,…に確� ��に提供できる。

 さらに、監視・診断ソフト実行処理部14� �、各監視対象側監視処理系3-1,…の監視結果� ��監視データを受け取ると、監視・診断ソフ� ��作成部12から提供される監視・診断ソフト� �実行し、監視対象の状態変化、部品劣化の� �態や異常のレベル等を診断し、予防保全支� �情報作成部15に提供するので、適切な予防保 全支援情報を作成し、最適な予防保全計画を 作成できる。

 さらに、監視・診断ソフト用アルゴリズ� ��作成部11としては、例えばアルゴリズム作� �時または適宜な時期に、監視対象情報受信� �19で受信した各監視対象側監視処理系3-1,…� �監視結果、監視データを取り込み、監視・� �断ソフト用アルゴリズムの良否を確認でき� �ので、監視対象2にとって最適な監視・診断� ��フト用アルゴリズムを作成できる。

 なお、中央側処理系1は、複数の監視対象 2,…がほぼ同じ監視・診断を行う場合には、� ��一の処理内容を持つ監視・診断ソフトを作� ��し、それら複数の監視対象2,…に一斉に監� �・診断ソフトを伝送するものである。以下� �各実施の形態においても同様である。

(第2の実施形態)
 図2は、第2の実施形態に係る遠隔監視・診� �システムの構成図である。

 この遠隔監視・診断システムは、中央セ� ��タの役割を持った中央側処理系1と、各監視 対象2の監視・診断を行う監視対象側監視処� �系3-1,…とが通信ネットワーク4で接続されて いる点で、実施の形態1と同様である。

 本実施形態において、特に異なるところ� ��、中央側処理系1のプラットフォーム13aにあ る。従って、プラットフォーム13aを除く他の 構成は、第1の実施形態と同様の構成である� �で、その説明を省略する。

 プラットフォーム13aは、前述したように� ��視・診断ソフト伝送部17、監視・診断ソフ� �伝送スケジュール作成部18及び監視対象情報 受信部19の他、ソフトバージョン管理部20及� �データベース管理部21が設けられている。

 ソフトバージョン管理部20は、監視、診� �ソフト伝送部17から監視・診断ソフトを伝送 する際、その伝送されたソフトの管理を行う 。管理の一例としては、既に伝送済みのソフ トとは異なる新たなソフト名、ソフトの改定 内容を伴うバージョン、伝送先である相手側 の監視対象機器を特定する番号(ID等)を対と� �、各監視対象2及び伝送された監視・診断ソ� ��トのバージョンが把握可能となるように管� ��する。これにより、各監視対象2の監視・診 断ソフトのバージョンを管理できることから 、監視対象側監視処理系3-1,…と相互に通信� �ることにより、ソフトバージョンを確認す� �ことで、ソフト伝送の際の成功、不成功の� �認が可能となる。

 データベース管理部21は、監視対象情報� �信部19で受信された各監視対象側監視処理系 3-1,…の診断結果、監視データ等の情報を一� �期間にわたって保存する役割を持っている� �保存する期間は、中央側処理系1の計算機の� ��能、監視対象2の数、監視項目の数、診断項 目の数等により決定する。

(システムの動作)
 次に、以上のようなシステムの動作につい� ��説明する。

 監視・診断ソフト用アルゴリズム作成部1 1から監視・診断用アルゴリズムが送られて� �たことをトリガとし、監視・診断ソフト作� �部12が監視・診断用アルゴリズムに基づいて 監視・診断ソフトを作成し、監視・診断ソフ ト伝送部17に送出する。

 このとき、監視・診断ソフト伝送部17は� �監視・診断ソフトを伝送する際、ソフトバ� �ジョン管理部20に対して、新たなソフト名、 ソフトの改定内容を伴うバージョン、伝送先 である相手側の監視対象機器を特定する番号 (ID等)を対として格納した後、伝送スケジュ� �ルに従って監視・診断ソフトを所定の通信� �ロトコルによりソフトを必要とする監視対� �側監視処理系例えば3-1に伝送する。

 また、監視対象側監視処理系例えば3-1の� ��視・診断ソフト実行処理部32は、監視・診� �ソフト受信部31で受信された監視・診断ソフ トのもとに実行し、監視データ及び診断結果 を取得し、監視処理結果用データベース33に� ��納するとともに、診断結果及び所定の周期� ��いし中央側処理系1の要求のもとに監視デー タの送信通知を監視対象情報送信部34に送る� ��監視対象情報送信部34は、通知内容に基づ� �、監視処理結果用データベース33から診断結 果及び必要な監視データを読み出し、通信ネ ットワーク4を介して中央側処理系1宛に送信� ��る。

 中央側処理系1の監視対象情報受信部19は� ��監視対象側監視処理系3-1,…から送られてく る診断結果及び必要な監視データを受信する と、データベース管理部21に一定期間にわた� ��て保存し、必要に応じて中央側処理系1の構 成部から提供要請を受けたとき、データベー ス管理部21から読み出し、要請元に提供する� ��

 また、監視・診断ソフト用アルゴリズム� ��成部11においては、各監視対象側監視処理� �3-1,…からのフィードバックデータである診� ��結果及び監視データを取り込み、監視・診� ��ソフトの修正・変更等を行いつつ、該当監� ��対象2の監視、診断に最適な監視・診断ソフ トを作成することができる。

 従って、以上のような実施形態によれば� ��第1の実施形態と同様の効果を奏する他、中 央側処理系1にて監視・診断ソフトのバージ� �ン管理を行うことにより、監視・診断ソフ� �の誤伝送を無くして伝送先に確実に監視・� �断ソフトを提供できる。

 また、中央側処理系1の監視対象情報受信 部19は各監視対象側監視処理系3-1,…から送ら れてくる診断結果及び必要な監視データをデ ータベース管理部21に一定期間保存し、必要� ��ときに要請元に提供するので、例えば監視� ��診断ソフト実行処理14は、同一の監視対象2� ��関するデータと各監視対象側監視処理系3-1, …から受け取る現時点のデータとを比較しつ つ、監視対象2の変化の推移や劣化の進行状� �を診断でき、また異常時の適切なレベルを� �断でき、より精度の高い診断結果等を予防� �全支援情報作成部15に提供できる。

(第3の実施形態)
 図3は、第3の実施形態に係る遠隔監視・診� �システムの構成図である。

 この遠隔監視・診断システムは、中央セ� ��タの役割を持った中央側処理系1と、各監視 対象2の監視・診断を行う監視対象側監視処� �系3-1,…とが通信ネットワーク4で接続されて いる。

 中央側処理系1は、図2に示す全部の構成� �素11~21の他、新たに監視・診断ソフト作成部 12に監視・診断ソフト検証処理部22を付加し� �構成である。従って、図3に示す中央側処理� ��1の構成要素11~21は、第1及び2の各実施形態� �同様のため説明を省略する。

 一方、各監視対象側監視処理系3-1,…は、 図1,図2に示す全部の構成要素31~34の他、新た� ��監視・診断ソフト自動検証処理部35が設け� �れている。従って、図3に示す構成要素31~34� �、第1及び2の各実施形態と同様のため説明を 省略する。

 監視・診断ソフト検証処理部22は、監視� �診断ソフト作成部12で作成された監視・診断 ソフトの検証処理を行う。すなわち、監視・ 診断ソフト検証処理部22は、予め実装される� ��ュミレーションモデルを実装し、監視・診� ��ソフト作成部12から監視・診断ソフトを受� �取り、仮想的に監視・診断ソフトを適用し� �その実行結果を評価することにより、検証� �行う。この検証には、予め想定されるケー� �及び実行結果を準備しておき、作成された� �視・診断ソフトの実行結果とを比較し、評� �することにより検証を行う。

 なお、この際、シュミレーションモデル� ��しては、監視対象2と同等のハードモデル又 は監視対象2のサイズ縮小モデル、またはソ� �トシュミレーションソフトを用いることで� �現できる。

 また、監視・診断ソフト検証処理部22は� �通信ネットワーク4を介して各監視対象側監� ��処理系3-1,…の出力データや予めネットワー ク上に接続されるシミュレーションモデル群 となる試作のテスト用ローカル監視対象実機 36を用いて、仮想的に監視・診断ソフトを実� ��し、検証を行うことも可能である。

 そして、監視・診断ソフト検証処理部22� �おいて、検証が終了した監視・診断ソフト� �、監視・診断ソフト作成部12から監視・診断 ソフト伝送部17を介して監視対象側監視処理� ��3-1,…に送られ、監視対象2に対して実行さ� �る。

 一方、各監視対象側監視処理系3-1,…の監 視・診断ソフト自動検証処理部35は、監視・� ��断ソフト実行処理部32で実行されている監� �・診断ソフトの実行状況から、監視・診断� �フトが正常に動作しているかどうかを自動� �証する。

 自動検証の例としては、監視・診断ソフ� ��自動検証処理部35が例えば仮想的にテスト� �信号を、監視・診断ソフト実行処理部32に送 信し、監視・診断ソフトの処理状況を確認す るとか、監視・診断ソフトのプログラムサイ ズの監視を実施することにより、想定外の誤 動作、ソフトの改ざん、通常処理と異なる処 理結果となるか否かを自動検証する。

 監視・診断ソフト自動検証処理部35は、� �視・診断ソフトが異常であると判断すると� �監視・診断ソフトを停止し、これら監視・� �断ソフトのロールバックなど、監視・診断� �フトが正常に実施されるような処理を行う� �また、監視・診断ソフト自動検証処理部35に よる検証結果は、監視対象情報送信部34に送� ��れ、中央側処理系1の監視対象情報受信部19� ��介してデータベース管理部21に格納し、必� �なときに読み出して検証結果を把握可能と� �る。

 従って、以上のような実施形態によれば� ��前述した第1及び2の各実施形態と同様な効� �を奏する他、監視・診断ソフト作成部12で作 成された監視・診断ソフトが監視・診断ソフ ト検証処理部22によりシミュレーションモデ� ��で検証し、或いはネットワーク4上のローカ ル監視対象実機である監視・診断ソフト検証 装置36により、正常に動作しているかどうか� ��自動検証するので、一定の評価が得られた� ��質の監視・診断ソフトを各監視対象側監視� ��理系3-1,…に提供できる。

 また、各監視対象側監視処理系3-1,…に設 けられた監視・診断ソフト自動検証処理部35� ��、テスト用信号を監視・診断ソフト実行処� ��部32に送出し、監視・診断ソフト実行処理� �32による監視・診断ソフトの実行結果を監視 し、異常時に正常な監視・診断ソフトの実施 を促すことできる。

(ハードウェア構成)
 図4は、前述した各実施形態を実現するため のハードウェア構成を示す図である。

 中央側処理系1には中央側計算機51が設置� ��れる。この中央側計算機51は、各種のアル� �リズムやソフトを作成するためのデータそ� �他必要な制御指示を入力する入力手段、所� �の処理を実行する処理フローを格納する記� �媒体、この記憶媒体に格納される処理フロ� �に従って所定の機能を実現するCPU、メモリ� �通信手段が設けられている。CPUにより実現� �る機能部としては、監視・診断ソフト用ア� �ゴリズム作成部11、監視・診断ソフト作成部 12、監視・診断ソフト実行処理部13、予防保� �支援情報作成部16、予防保全最適化処理部16� ��監視・診断ソフト検証処理部22が挙げられ� �。メモリは、ソフトバージョン管理部20及び データベース管理部21等を構成するデータベ� ��スとしての役割を有する。通信手段には、� ��ラットフォーム13、13a等に含む各構成部17~19 が設けられる。

 各監視対象側監視処理系3-1,…には、監視 対象2によって異なる各種の監視処理計算機52 の他、監視・診断ソフト検証機能を有する監 視処理計算機52aが設置されている。例えばサ ーバレベルの計算機、ノートPCレベルの計算� ��、ボードコンピュータレベルのものが用い� ��れる。

 この監視処理計算機52,52aには、通信手段� ��CPU、ソフト実行結果のデータ等を格納する� ��モリ、監視・診断ソフトを格納する記憶媒� ��の他、マンマシンインタフェース機能を持� ��たコンソール等で構成される。通信手段に� ��、監視・診断ソフト受信部31、監視対象情� �送信部34等が設けられる。CPUとしては、機能 的には、監視・診断ソフト実行処理部32や監� ��・診断ソフト自動検証処理部35を実現する� �メモリには、監視処理結果用データベース33 が設けられる。

 なお、図4に示すハードウェア構成は、以 下に説明する各実施形態でも同様に適用され ることは言うまでもない。

(第4の実施形態)
 図5は、第4の実施形態に係る遠隔監視・診� �システムの構成図である。

 この遠隔監視・診断システムは、中央側� ��理系1と各監視対象側監視処理系3-1,…とが� �信ネットワーク4で接続されている。

 中央側処理系1は、図1~図3と同様な構成要 素11~22の他、新たに監視・診断ソフト更新ト� ��ガ発生部23及び前述する監視・診断ソフト� �アルゴリズム作成部11に相当する更新トリガ 対応監視・診断ソフト用アルゴリズム作成部 24が設けられている。よって、図5に示す構成 要素11~22については、第1から第3の実施形態� �同様のため説明を省略する。

 各監視対象側監視処理系3-1,…は、同じく 図1~図3と同様の構成要素31~35の他、新たに監� ��・診断ソフト更新トリガ発生部37が設けら� �ている。よって、図5に示す構成要素31~35は� �第1から第3の実施形態と同様のため説明を省 略する。

 前記中央側処理系1の監視・診断ソフト更 新トリガ発生部23は、人為的な判断や監視対� ��側からの更新要請に基づき、監視・診断ソ� ��トの更新が必要と判断されたとき、監視・� ��断ソフトの更新トリガを発生する機能を有� ��る。

 監視・診断ソフトの更新が必要と判断さ� ��るケースとしては、以下のような場合があ� ��。

(A1)新しい診断方法が開発された場合であ� �。

(A2)監視対象2の保守実績から更新が必要と� ��断された場合である。

(A3)監視項目や診断項目が増減した場合で� �る。

 監視・診断ソフト更新トリガ発生部23は� �前記A1~A3のようなケースが生じたとき、オペ レータがマンマシンインタフェースを介して 操作指示を入力し、監視、診断ソフトの更新 用トリガを発生する。

 更新トリガ対応監視・診断ソフト用アル� ��リズム作成部24は、監視・診断ソフト更新� �リガ発生部23から監視、診断ソフトの更新用 トリガを受けたとき、該当監視対象2に対応� �る監視対象側監視処理系例えば3-1の監視・� �断ソフト用アルゴリズムを作成し、監視・� �断ソフト作成部12に送出する。

 一方、各監視対象側監視処理系3-1,…の監 視・診断ソフト更新トリガ発生部37は、実際� ��監視・診断ソフトを実行している状況下に� ��って、ソフトの更新が必要であると判断さ� ��た場合にソフト更新のトリガ信号を発生さ� ��る。ソフトの更新が必要とするケースとし� ��は、例えば監視・診断ソフト自動検証処理� ��35にて作成され監視対象側の検証結果や監� �・診断ソフト実行処理部32にて作成された監 視対象側の診断結果、監視処理結果用データ ベース33から得られた監視対象2の監視データ をもとに、監視・診断ソフトの更新の必要性 を評価する。

 監視対象側の監視・診断ソフトの更新を� ��要とする具体的なケースとしては、次のよ� ��な場合が挙げられる。

(B1)監視・診断ソフトの実行による監視対� �2の診断結果から更新が必要と判断された場� ��である。

(B2)一定期間の監視データから、監視対象� �経年変化などが原因でソフト更新が必要と� �断された場合である。

(B3)監視・診断ソフトの自動検証結果から� �新が必要と判断された場合である。

 従って、本実施形態では、以上のような� ��ースに基づいて、監視・診断ソフト更新ト� ��ガ発生部37や監視・診断ソフト更新トリガ� �生部23から更新トリガ信号が発生すると、こ の更新トリガ信号は、直接又は通信ネットワ ーク4を通して更新トリガ対応監視・診断ソ� �ト用アルゴリズム作成部24に送信される。

 更新トリガ対応監視・診断ソフト用アル� ��リズム作成部24は、監視・診断ソフトの更� �トリガを受け取ったとき、前述した監視・� �断ソフト用アルゴリズム作成部11に相当する 監視・診断用アルゴリズムを作成する。

 このアルゴリズムの作成例としては、前� ��した更新のケースに応じて次のような各種� ��アルゴリズムを作成する。

(A1)新しい診断方法が開発された場合
 統計手法やデータマイニング手法等の技術� ��上によって新しい診断方法が開発された場� ��、それらの技術を用いた診断方法を適用す� ��ためにソフトを更新する。これによって、� ��り診断性能を向上させることができる。

(A2)監視対象2の保守実績から更新する必要が� ��ると判断された場合
 例えば定期的な保守実績から監視・診断ソ� ��トの診断結果が十分に対応していないと判� ��されたとき、ソフトの調整ないし更新を実� ��する。例えば監視・診断ソフトの診断結果� ��は、故障の確率が低く出ているが、実際に� ��障するケースが増えてきた場合等である。� ��た、診断性能または調整が悪いとか、現状� ��合っていない場合、新しい監視データのも� ��に監視・診断ソフトのパラメータ等の調整� ��素を再調整するために、監視・診断ソフト� ��更新を行う。

(A3)監視項目や診断項目が増減した場合
 新規保守サービスの追加などにより、診断� ��たい項目が増加したり、監視対象2に新たな センサが設置され、監視する項目が増えた場 合、それらの項目増加に対応させるためにソ フトを更新する。また、監視対象2の設計仕� �において、新しい設計仕様を利用する場合� �は、その仕様に対応するためにソフトを更� �する。また、監視項目が増加した場合、従� �採用できなかった診断アルゴリズムが採用� �能となるので、この場合には新しい診断ア� �ゴリズムへの更新が必要になる
 さらに、エージェントを採用する場合、診� ��項目毎に専用の診断エージェントを作成す� ��形式とした場合、新しく増加した診断項目� ��用の診断用エージェントを作成し、追加す� ��。

 ここで、前述のような場合に、監視・診� ��ソフトの更新を行なう。

(B1)監視・診断ソフトの実行による監視対象2� ��診断結果から更新が必要と判断された場合
 例えば監視対象2に対する監視・診断ソフト の診断結果から、診断のしきい値の設定が甘 いなどの理由でアラームが頻繁に発生する場 合等のごとき、監視・診断ソフトの調整が必 要と判断された場合にはソフトの更新を行う 。また、現在使用中の監視・診断ソフトの診 断性能や調整が悪いか、もしくは現状の監視 対象2と合っていない場合、新しい監視デー� �を用いて、新しい監視データのもとに監視� �診断ソフトのパラメータ等の調整要素を再� �整するために、監視・診断ソフトの更新を� �う。

(B2)一定期間の監視データから、監視対象の� �年変化などが原因でソフト更新が必要と判� �された場合
 経年変化や環境の変化に伴い、センサの計� ��値を利用して監視データや診断結果等を取� ��する際、新たな前処理もしくは現状とは別� ��高度な前処理が必要となったとき、ソフト� ��更新する必要がある。一例としては、監視� ��象2の監視項目において、ノイズを含む時系 列的な計測値を取り込む場合、システム設置 当初に監視・診断ソフト内にフィルタ機能(� �も簡単なものは移動平均等)を含める。通常� ��ノイズを含む時系列的な計測値であっても� ��ノイズの傾向が変化しないときにはそのま� ��利用可能である。

 しかし、経年変化やノイズ発生原因要素( 電源等)が新たに発生する等により、ノイズ� �傾向が大きく変化した場合、当初採用した� �ィルタではノイズの影響を削除できない場� �が出てくる。

 そこで、適宜な時期にフィルタの高度化( 例えばフィルタの係数を調整したり、適応フ ィルタの高度なフィルタへの置換え等)を図� �ためにソフトを更新する。

 また、外的要因によりノイズが増加し、� ��視・診断ソフトの性能が劣化した場合、監� ��・診断ソフトの性能を向上させるために監� ��・診断ソフトの更新を行う。

(B3)監視・診断ソフトの自動検証結果から更� �が必要と判断した場合
 監視・診断ソフト自動検証処理部35の検証� �果において、監視・診断ソフトが異常であ� �とする結果が得られたとき、同じバージョ� �の監視・診断ソフトを送信したり、解析の� �果、バグがあると判明したとき、バグを除� �したバージョンの監視・診断ソフトに更新(� ��換え)する。

 従って、以上のような実施形態によれば� ��前述した第1から第3の実施形態と同様の効� �を奏する他、中央側処理系1及び各監視対象� ��監視処理系3-1,…にそれぞれ監視・診断更新 トリガ発生機能を設け、所定の条件のもとに 発生する監視・診断更新トリガを受付けるこ とにより、比較的容易に監視・診断ソフトの 更新を行うことができる。これにより、監視 対象の監視・診断能力アップに即座に対応で き、また監視対象の経年変化や環境変化に応 じて一定品質の監視及び診断を実施するため に監視・診断ソフトの更新が行うことができ る。

(第5の実施形態)
 図6は、第5の実施形態に係る遠隔監視・診� �システムの構成図である。

 この遠隔監視・診断システムは、中央側� ��理系1と各監視対象側監視処理系3-1,…とが� �信ネットワーク4で接続されている。

 中央側処理系1は、新たにプラットフォー ム13aの監視・診断ソフト伝送スケジュール作 成部18に代えて、負荷考慮形監視・診断ソフ� ��伝送スケジュール作成部25を設けた構成で� �る。よって、中央側処理系1は、負荷考慮形� ��視・診断ソフト伝送スケジュール作成部25� �除けば、他の構成部分は、図1~図3、図5と同� ��な構成であるので、説明を省略する。

 一方、各監視対象側監視処理系3-1,…は、 新たに監視・診断ソフト受信部31と監視・診� ��ソフト実行処理部32との間に監視・診断ソ� �ト更新処理部38を設けたものであり、他の構 成部分は、図1~図3、図5と同様な構成である� �で、説明を省略する。

 前記負荷考慮形監視・診断ソフト伝送ス� ��ジュール作成部25は、前述した監視・診断� �フト伝送スケジュール作成部18に相当する機 能に対して更に能力アップを図ったものであ って、通信ネットワーク4を介して多数の監� �対象側監視処理系3-1,…が接続されているこ� ��から、これら多数の監視対象側監視処理系3 -1,…を総合的に考慮し、各監視対象側監視処 理系3-1,…の監視・診断ソフトの更新タイミ� �グ信号を作成する。

 更新タイミングの1つの作成例としては、 各監視対象2,…の動作状況である負荷状況や� ��止時間を評価関数とする最適化ソフトを用� ��て、最適な更新タイミングを作成する。

 負荷考慮形監視・診断ソフト伝送スケジ� ��ール作成部25で作成された各監視対象側監� �処理系3-1,…への監視・診断ソフトの更新タ� ��ミング信号は通信ネットワーク4を介して該 当する監視対象側監視処理系例えば3-1に送信 する。

 また、負荷考慮形監視・診断ソフト伝送� ��ケジュール作成部25は、更新タイミング信� �を作成するだけでなく、中央側処理系1にお� ��る図4に示す中央側計算機51の演算負荷状況� ��応じて、フラットフォーム13aから監視対象� ��監視処理系3-1,…から受け取った診断結果及 び監視データを中央側処理系1内部の構成要� �例えば14,15,24に送信する送信タイミングを決 定する機能も有する。従って、プラットフォ ーム13aは、決定された送信タイミングに基づ き、中央側処理系1内部の構成要素例えば14,15 ,24に対して、診断結果及び監視データの送信 を実施する。

 各監視対象側監視処理系3-1,…の監視・診 断ソフト更新処理部38は、通信ネットワーク4 を介して送られてくる負荷考慮形監視・診断 ソフト伝送スケジュール作成部25で作成され� ��監視・診断ソフトの更新タイミング信号を� ��け取り、当該更新タイミングに従って監視� ��診断ソフトを更新する。

 この実施形態によれば、多数の監視対象2 ,…を有するシステムであっても、これら多� �の監視対象2,…を考慮した場合の最適な監理 ・診断ソフトの更新タイミングを用いること ができる。また、中央装置1において、更新� �イミングを作成しているので、システム全� �として最適な更新タイミングを作成できる� �

 さらに、中央側処理系1のプラットフォー ム3aにおいて、装置内負荷の状況を考慮しつ� ��装置内部の必要な構成部分に必要な診断結� ��及び監視データを送信するので、計算機リ� ��ースを有効に利用できる。

(第6の実施形態)
 図7は、第6の実施形態に係る遠隔監視・診� �システムの構成図である。

 本実施形態は、第5の実施形態と同様な構 成である。本実施形態において、第5の実施� �態と特に異なるところは、中央装置1に相当� ��る構成部分を複数の計算機により分担して� ��現する構成である。

 具体的には、アルゴリズム作成用計算機1 a、監視診断ソフト作成用計算機1b、プラット フォーム用計算機1c及び予防保全支援用計算� ��1dで構成される。

 アルゴリズム作成用計算機1aは、監視・� �断ソフト更新トリガ発生部23及び更新トリガ 対応監視・診断ソフト用アルゴリズム作成部 24による一連の処理を実行する。

 監視診断ソフト作成用計算機1bは、監視� �診断ソフト作成部12、監視・診断ソフト実行 処理部14及び監視・診断ソフト検証処理部27� �関する処理を実行する。

 プラットフォーム用計算機1cは、前述し� �プラットフォーム3,3aに関する処理を分担分� ��して受け持つ構成である。

 予防保全支援用計算機1dは、予防保全支� �情報作成部15及び予防保全最適化処理部16の� ��連の処理を実行する。

 従って、以上のような実施形態によれば� ��中央側処理系1に相当する構成部分を複数の 計算機1a~1dに分担分けし、イントラネット等� ��接続すれば、専門部署ごとや専門機関ごと� ��分担して必要な処理作業を進めることがで� ��る。また、プラットフォーム用計算機1cは� �ソフトの送信、バージョン監理、情報の送� �信及びデータベース管理等を行うことから� �情報の一元管理が可能となり、ソフト及び� �報の管理が効率的に実施できる。

 その他、本発明は、前記各実施形態に限� ��されるものでなく、その要旨を逸脱しない� ��囲で種々変形して実施できる。