JP5072373B2 - 遠隔監視・診断システム - Google Patents

Description

本発明は、多数の監視対象を監視・診断する遠隔監視・診断システムに関する。

従来、遠隔地の監視対象を監視し制御する遠隔監視・診断システムとしては、様々な遠隔監視方法を取り入れた技術が開発され、既に提案されている。

以下、従来の幾つかの遠隔監視・診断システムについて説明する。
１つの遠隔監視・診断システムは、遠隔運用・遠隔保守を実施するための電力系統保護制御システムであって、監視対象のコントローラと遠隔監視センタがイントラネットにより接続され、ＨＴＭＬ言語で作成されたホームページを利用して監視する方法である（非特許文献１〜３）。

また、他の遠隔監視・診断システムは、遠隔監視拠点とプラント制御システムと監視対象プラントとからなり、遠隔監視拠点が搭載する監視・診断プログラムとプラント制御システムが搭載するプラント制御プログラムとが互いに連携を取りつつ、遠隔監視拠点の監視・診断プログラムがプラント制御システムから送られてくるデータに基づいて、プラントの監視・診断を行う構成である（特許文献１）。

さらに、他の遠隔監視・診断システムとしては、複数の発電プラントを遠隔地から監視・診断・保全するシステムがある（特許文献２）。

さらに、もう１つの遠隔監視・診断システムは、各監視対象の負荷状況を考慮した監視・診断ソフトの更新を行うことにより、周期的に繰り返し実行される複数の監視対象の監視によるシステムへの負荷の影響を極力少なくするスケジューリング方法である。
「変革を遂げる電力系統監視制御・保護システム」、津久井良一、増田文雄，鈴木邦明著、東芝レビュー、Ｖｏ１５４、Ｎｏ．６、２６〜２９頁、１９９９。 「イントラネット応用電力系統監視制御システム」、長谷川義朗，江幡良雄，林秀樹著、東芝レビュー、Ｖｏ．１５４、Ｎｏ．６、３０〜３３頁、１９９９。 「電力系統保護制御システムへのイントラネット技術適用」、関口勝彦，竹中章二，白田義博著、東芝レビュー、Ｖｏ．１５４、Ｎｏ．６、３４〜３７頁、１９９９。 特許第３６２１９３５号 特開２００３−１１４２９４号 特開２００１−２８２５５４号

しかしながら、以上のような遠隔監視・診断システムのうち、非特許文献１〜３及び特許文献１，２に記載されるシステムは、監視対象が電力系統などのプラントを対象としており、また、イントラネットによるデータ通信を主としている。また、特許文献３に記載されるシステムは、各監視対象の負荷状況を考慮した監視・診断ソフトの更新に関する提案がなされているが、多数の監視対象が存在する場合、多数の監視対象を含む全体システムとしての最適な監視・診断ソフトの更新を行うことは非常に難しい。

また、遠隔監視・診断ソフトの更新・変更要求に関しては、様々なものが考えられているが、多数の監視対象を考慮した具体的な更新技術については明確に記載されていない。

その結果、以上のようなシステムでは、次のような種々の問題が指摘されている。

（１） 監視・診断ソフトの事前検証が困難である。
（２） 様々な監視・診断ソフトの更新トリガへの対応が困難である。
（３） 多数の監視対象が接続されている場合、それら各監視対象への監視・診断ソフトの更新が難しい。

本発明は上記事情に鑑みてなされたもので、監視・診断ソフトの事前検証を可能とし、様々に更新トリガに対応可能とし、また、多数の監視対象が接続されている場合でも効率的に監視・診断ソフトを更新可能とする遠隔監視・診断システムを提供することを目的とする。

（１） 上記課題を解決するために、本発明に係る遠隔監視・診断システムは、中央側処理系と監視対象を監視、診断する複数の監視処理系とが通信ネットワークで接続され、各監視対象の監視・診断を行う遠隔監視・診断システムであって、
前記中央側処理系は、前記監視対象に関連するデータ及び仕様を分析し、当該監視対象の監視・診断アルゴリズムを作成する第１のアルゴリズム作成手段と、この作成された監視・診断アルゴリズムをもとに、前記監視対象を監視・診断するための監視・診断ソフトを作成するソフト作成手段と、この作成された監視・診断ソフトを前記監視処理系に伝送する際の伝送スケジュールを作成する伝送スケジュール作成手段と、この伝送スケジュールに従って前記監視・診断ソフトを必要とする前記各監視処理系に前記通信ネットワークを通して伝送する伝送手段と、前記各監視処理系から監視・診断ソフトの実行結果である前記各監視対象の監視データ及び診断結果を受信する受信手段と、この受信手段で受信された監視データ及び診断結果を受け取り、前記各監視処理系による監視・診断ソフトの実行結果を確認し修正変更する第２のアルゴリズム作成手段とを備え、
前記各監視処理系は、前記伝送手段から伝送されてくる監視・診断ソフトを受信する受信手段と、この受信された監視・診断ソフトを実行するソフト実行処理手段と、このソフト実行処理手段に対して所定のテスト信号を与えることにより、前記ソフト実行処理手段により実行される監視・診断ソフトの処理状況の確認や当該監視・診断ソフトの動作に想定外の誤動作、ソフトの改ざん、通常処理と異なる処理結果となるか否かを自動検証する自動検証手段と、前記ソフト実行処理手段による実行結果である前記監視対象の監視データ、診断結果及び検証結果を前記通信ネットワークを介して前記中央側処理系に送信する送信手段と、前記ソフト実行処理手段による実行結果である前記監視対象の監視データ及び診断結果と前記自動検証手段の検証結果とに基づき、少なくとも下記の何れか１つの条件のもとに監視・診断ソフトの更新が必要と判断されたとき、当該監視・診断ソフトの更新要請のトリガを送信する更新トリガ発生手段とを設け、
（ニ） 前記診断結果から監視・診断ソフトの調整が必要なとき。
（ホ） 前記監視データから劣化等の経年変化が生じているとき。
（へ） 前記検証結果から異常と検証されたとき。
さらに、前記中央側処理系は、各監視処理系の更新トリガ発生手段から更新要請のトリガを受けたとき、ソフト更新用のアルゴリズムを作成する前記第１のアルゴリズム作成手段に代る更新トリガ対応アルゴリズム作成手段を設けた構成である。

（２） 本発明に係る遠隔監視・診断システムは、少なくとも前記（１）項に記載する中央側処理系の構成に新たに、前記ソフト作成手段で作成された監視・診断ソフトを前記各監視処理系に伝送する前に事前に、前記中央側処理系内でシミュレーションによって検証するか、あるいは通信ネットワークに接続されるテスト用ローカル監視対象実機を用いて検証し、前記各監視処理系に対して適正な監視・診断ソフトを伝送可能とする検証処理手段を設けた構成である。

（３） 本発明に係る遠隔監視・診断システムは、少なくとも前記（１）項または前記（２）項に記載する中央側処理系の構成に新たに、少なくとも下記の何れか１つの条件のもとに監視・診断ソフトの更新要求を受付けたとき、更新トリガを発生する更新トリガ発生手段と、この更新トリガを受けたとき、ソフト更新用のアルゴリズムを作成する前記第１のアルゴリズム作成手段に代る更新トリガ対応アルゴリズム作成手段とを設けた構成とし、
（ａ） 新しい診断方法が開発されたとき。

（ｂ） 監視対象の保守実績のもとに更新必要と判断されたとき。

（ｃ） 監視対象の監視項目や診断項目に増減による変更が生じたとき。

（ｄ） 各監視対象側監視処理系から監視・診断ソフトの更新要請のトリガをじゅしんしたとき。

（４） さらに、本発明に係る遠隔監視・診断システムは、少なくとも前記（１）項ないし前記（３）項の何れかに記載する中央側処理系の構成に新たに、多数の前記監視処理系が前記通信ネットワークに接続されている場合、各監視対象側監視処理系の負荷状況や停止時間等を考慮し、前記監視・診断ソフトの更新タイミングを作成し、前記伝送手段を介して当該各監視対象側監視処理系へ伝送する前記伝送スケジュール作成手段に代る負荷考慮型伝送スケジュール作成手段を設け、
また、前記各監視対象側監視処理系としては、前記中央側処理系から前記通信ネットワークを介して伝送されてくる監視・診断ソフトを前記受信手段を通して受け取り、前記監視・診断ソフトの更新タイミングをもとに前記ソフト実行処理手段に対して監視・診断ソフトを更新するソフト更新処理手段をさらに設けた構成である。

本発明によれば、監視・診断ソフトの事前診断を検証でき、様々な条件のもとに更新トリガを発生でき、また、多数の監視対象が接続されている場合でも効率良く監視・診断ソフトを更新できる遠隔監視・診断システムを提供できる。

以下、本発明の実施の形態について図面を参照して説明する。
（実施の形態１）
図１は本発明に係る遠隔監視・診断システムの実施の形態１を示す構成図である。

この遠隔監視・診断システムは、中央センタの役割を持った中央側処理系１と、各監視対象２の監視・診断を行う監視対象側監視処理系３−１，…とが通信ネットワーク４で接続されている。

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

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

ここで、処理形態は各監視処理系３−１，…による監視対象の処理内容や処理目的に依存して異なる。また、処理能力は各監視対象２を監視・診断する各監視処理系３−１，…の処理速度や回転速度等の監視処理系自体の能力に依存して異なる。

また、事前に入手する各監視対象２に関するデータの例としては、各監視対象２に設置される各センサの計測値、指令値等が挙げられる。例えば監視対象２として電動機が使用されている場合、その電動機に与えられる指令値と回転数の計測値等が挙げられる。これらデータは、監視対象２から通信ネットワーク４を介して送られてくるデータのケースや保守員が実際に現地に出向いて必要なデータを収集し、中央側処理系１の計算機にアップロードもしくは手入力するケースもある。なお、中央側処理系１には、以上のように監視対象２の必要なデータを確実に取り込むために、プラットフォーム１３が設けられている。

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

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

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

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

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

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

監視・診断ソフト作成部１２は、監視・診断ソフト用アルゴリズム作成部１１で作成された監視・診断用アルゴリズムのもとに、各監視対象側監視処理系３−１，…にて動作可能な監視・診断ソフトを作成する。

監視・診断ソフトを作成するトリガとしては、幾つかのタイミングのもとにソフトを作成する
ａ．監視・診断ソフト用アルゴリズム作成部１１から監視・診断ソフト用のアルゴリズムが送られてきたとき。

ｂ．監視・診断ソフト作成部１２や中央側処理系１自体にヒューマンインタフェース（ＨＭＩ）が具備されている場合、ヒューマンインタフェースを介してソフト作成用トリガを受けたときである。監視・診断ソフト作成部１２は、ヒューマンインタフェースを通してソフト作成用トリガを受けたとき、監視・診断ソフト用アルゴリズム作成部１１に対してアルゴリズム作成用トリガをかけ、必要とする監視用又は診断用アルゴリズムの作成を促す。

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

監視・診断用ソフトの出力形式としては、各監視対象２の監視処理系３−１，…で実行可能なものであれば、どのような形式でも良い。例えばそのまま実行可能なプログラムファイル、Ｗｅｂページを作成する記述言語やSoap（Simple object access protocol）に基づいて作成されたファイルであってもよい。

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

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

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

監視・診断ソフト伝送部１７は、監視・診断ソフト作成部１２で作成された監視・診断ソフトのうち、監視対象側監視処理系３−１，…で必要とする処理内容を持ったソフトに送信先識別データを付した状態で、通信ネットワーク４を介して必要な監視対象側監視処理系３−１，…に伝送する。

通信ネットワーク４としては、インターネット、イントラネット、公衆回線等が用いられる。通信ネットワーク４を利用してソフト、データを伝送する場合、例えばＴＣＰ／ＩＰプロトコルやＳＮＭＰプロトコルなどを使用して伝送する。

監視・診断ソフト伝送部１７は、監視対象側監視処理系３−１，…で必要とする監視・診断ソフトを伝送するに当たり、監視・診断ソフト伝送スケジュール作成部１８で作成された伝送スケジュールに従って監視・診断ソフトを伝送する。

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

監視対象データ情報受信部１９は、監視・診断ソフト伝送部１７から所要のソフトを監視処理系例えば３−１に伝送し、当該監視処理系例えば３−１からソフトの実行結果である監視対象２の監視データ、診断結果（フィードバックデータ）が返送されてくると、その監視データ、診断結果を受信し、監視・診断ソフト実行処理部１４及び予防保全支援情報作成部１５に送出する。

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

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

また、監視・診断ソフト実行処理部１４は、監視対象側監視処理系３−１，…から送信されてくるデータをプラットフォーム１３の監視対象情報受信部１９を通して受け取り、前記中央側処理系１で扱う監視・診断ソフトを用いて、監視及び診断を実行する。

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

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

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

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

次に、各監視対象側監視処理系３−１，…においては、監視・診断ソフト受信部３１と、監視・診断ソフト実行処理部３２と、監視処理結果用データベース３３と、監視対象情報送信部３４とで構成される。

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

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

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

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

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

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

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

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

監視処理結果用データベース３３と監視対象２とのデータのやり取りは、ＲＳ２３２Ｃ接続による伝送やＵＳＢ接続、ネットワーク接続により実施できる。

次に、以上のような構成のシステムの動作について説明する。
監視・診断ソフト用アルゴリズム作成部１１から監視・診断用アルゴリズムが送られてきたことをトリガとし、監視・診断ソフト作成部１２が監視・診断用アルゴリズムに基づいて監視・診断ソフトを作成し、監視・診断ソフト伝送部１７に送出する。

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

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

中央側処理系１の監視・診断ソフト実行処理部１４は、監視対象情報受信部１９で受け取った現時点の各監視対象側監視処理系３−１，…の監視結果、監視データを受け取ると、監視・診断ソフト作成部１２から提供される中央側処理系１のみで必要とする監視・診断ソフトを実行し、監視対象の状態変化、部品劣化の状態や異常のレベル等を診断し、予防保全支援情報作成部１５に提供する。予防保全支援情報作成部１５は、現時点の各監視対象側監視処理系３−１，…の監視結果、監視データと監視・診断ソフト実行処理部１４の実行結果のデータとを用いて、予防保全支援情報を作成し、予防保全最適化処理部１６に送出する。

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

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

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

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

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

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

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

（実施の形態２）
図２は本発明に係る遠隔監視・診断システムの実施の形態２を示す構成図である。

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

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

プラットフォーム１３ａは、前述したように監視・診断ソフト伝送部１７、監視・診断ソフト伝送スケジュール作成部１８及び監視対象情報受信部１９の他、ソフトバージョン管理部２０及びデータベース管理部２１が設けられている。

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

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

次に、以上のようなシステムの動作について説明する。
監視・診断ソフト用アルゴリズム作成部１１から監視・診断用アルゴリズムが送られてきたことをトリガとし、監視・診断ソフト作成部１２が監視・診断用アルゴリズムに基づいて監視・診断ソフトを作成し、監視・診断ソフト伝送部１７に送出する。

このとき、監視・診断ソフト伝送部１７は、監視・診断ソフトを伝送する際、ソフトバージョン管理部２０に対して、新たなソフト名、ソフトの改定内容を伴うバージョン、伝送先である相手側の監視対象機器を特定する番号（ＩＤ等）を対として格納した後、伝送スケジュールに従って監視・診断ソフトを所定の通信プロトコルによりソフトを必要とする監視対象側監視処理系例えば３−１に伝送する。

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

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

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

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

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

（実施の形態３）
図３は本発明に係る遠隔監視・診断システムの実施の形態３を示す構成図である。

この遠隔監視・診断システムは、中央センタの役割を持った中央側処理系１と、各監視対象２の監視・診断を行う監視対象側監視処理系３−１，…とが通信ネットワーク４で接続されている。

中央側処理系１は、図２に示す全部の構成要素１１〜２１の他、新たに監視・診断ソフト作成部１２に監視・診断ソフト検証処理部２２を付加した構成である。従って、図３に示す中央側処理系１の構成要素１１〜２１は、既に実施の形態１，２で説明しているので、ここではその説明を省略する。

一方、各監視対象側監視処理系３−１，…は、図１，図２に示す全部の構成要素３１〜３４の他、新たに監視・診断ソフト自動検証処理部３５が設けられている。従って、図３に示す構成要素３１〜３４は、既に実施の形態１，２で説明しているので、ここではその説明を省略する。

監視・診断ソフト検証処理部２２は、監視・診断ソフト作成部１２で作成された監視・診断ソフトの検証処理を行う。すなわち、監視・診断ソフト検証処理部２２は、予め実装されるシュミレーションモデルを実装し、監視・診断ソフト作成部１２から監視・診断ソフトを受け取り、仮想的に監視・診断ソフトを適用し、その実行結果を評価することにより、検証を行う。この検証には、予め想定されるケース及び実行結果を準備しておき、作成された監視・診断ソフトの実行結果とを比較し、評価することにより検証を行う。なお、この際、シュミレーションモデルとしては、監視対象２と同等のハードモデル又は監視対象２のサイズ縮小モデル、またはソフトシュミレーションソフトを用いることで実現できる。

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

そして、監視・診断ソフト検証処理部２２において、検証が終了した監視・診断ソフトは、監視・診断ソフト作成部１２から監視・診断ソフト伝送部１７を介して監視対象側監視処理系３−１，…に送られ、監視対象２に対して実行される。

一方、各監視対象側監視処理系３−１，…の監視・診断ソフト自動検証処理部３５は、監視・診断ソフト実行処理部３２で実行されている監視・診断ソフトの実行状況から、監視・診断ソフトが正常に動作しているかどうかを自動検証する。

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

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

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

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

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

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

各監視対象側監視処理系３−１，…には、監視対象２によって異なる各種の監視処理計算機５２の他、監視・診断ソフト検証機能を有する監視処理計算機５２ａが設置されている。例えばサーバレベルの計算機、ノートＰＣレベルの計算機、ボードコンピュータレベルのものが用いられる。

この監視処理計算機５２，５２ａには、通信手段、ＣＰＵ、ソフト実行結果のデータ等を格納するメモリ、監視・診断ソフトを格納する記憶媒体の他、マンマシンインタフェース機能を持ったコンソール等で構成される。通信手段には、監視・診断ソフト受信部３１、監視対象情報送信部３４等が設けられる。ＣＰＵとしては、機能的には、監視・診断ソフト実行処理部３２や監視・診断ソフト自動検証処理部３５を実現する。メモリには、監視処理結果用データベース３３が設けられる。

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

（実施の形態４）
図５は本発明に係る遠隔監視・診断システムの実施の形態４を示す構成図である。
この遠隔監視・診断システムは、中央側処理系１と各監視対象側監視処理系３−１，…とが通信ネットワーク４で接続されている。

中央側処理系１は、図１〜図３と同様な構成要素１１〜２２の他、新たに監視・診断ソフト更新トリガ発生部２３及び前述する監視・診断ソフト用アルゴリズム作成部１１に相当する更新トリガ対応監視・診断ソフト用アルゴリズム作成部２４が設けられている。よって、図５に示す構成要素１１〜２２については実施の形態１〜３の説明に譲る。

各監視対象側監視処理系３−１，…は、同じく図１〜図３と同様の構成要素３１〜３５の他、新たに監視・診断ソフト更新トリガ発生部３７が設けられている。よって、図５に示す構成要素３１〜３５は実施の形態１〜３の説明に譲る。

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

監視・診断ソフトの更新が必要と判断されるケースとしては、幾つか挙げられる。
Ａ１．新しい診断方法が開発されたとき。
Ａ２．監視対象２の保守実績から更新が必要と判断されたとき。
Ａ３．監視項目や診断項目が増減したとき。

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

更新トリガ対応監視・診断ソフト用アルゴリズム作成部２４、監視・診断ソフト更新トリガ発生部２３から監視、診断ソフトの更新用トリガを受けたとき、該当監視対象２に対応する監視対象側監視処理系例えば３−１の監視・診断ソフト用アルゴリズムを作成し、監視・診断ソフト作成部１２に送出する。

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

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

Ｂ１．監視・診断ソフトの実行による監視対象２の診断結果から更新が必要と判断されたとき。
Ｂ２．一定期間の監視データから、監視対象の経年変化などが原因でソフト更新が必要と判断されたとき。
Ｂ３．監視・診断ソフトの自動検証結果から更新が必要と判断されたとき。

従って、この実施の形態では、以上のようなケースのもとに監視・診断ソフト更新トリガ発生部３７や監視・診断ソフト更新トリガ発生部２３から更新トリガ信号を発生すると、この更新トリガ信号は直接又は通信ネットワーク４を通して更新トリガ対応監視・診断ソフト用アルゴリズム作成部２４に送信する。

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

このアルゴリズムの作成例としては、前述した更新のケースに応じて次のような各種のアルゴリズムを作成する。
（Ａ１）．新しい診断方法が開発されたとき。
統計手法やデータマイニング手法等の技術向上によって新しい診断方法が開発された場合、それらの技術を用いた診断方法を適用するためにソフトを更新する。これによって、より診断性能を向上させることができる。

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

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

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

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

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

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

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

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

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

（実施の形態５）
図６は本発明に係る遠隔監視・診断システムの実施の形態５を示す構成図である。
この遠隔監視・診断システムは、中央側処理系１と各監視対象側監視処理系３−１，…とが通信ネットワーク４で接続されている。

中央側処理系１は、新たにプラットフォーム１３ａの監視・診断ソフト伝送スケジュール作成部１８に代えて、負荷考慮形監視・診断ソフト伝送スケジュール作成部２５を設けた構成である。よって、中央側処理系１は、負荷考慮形監視・診断ソフト伝送スケジュール作成部２５を除けば、他の構成部分は図１〜図３、図５と同様な構成であるので、ここではその説明を省略する。

一方、各監視対象側監視処理系３−１，…は、新たに監視・診断ソフト受信部３１と監視・診断ソフト実行処理部３２との間に監視・診断ソフト更新処理部３８を設けたものであり、他の構成部分は図１〜図３、図５と同様な構成であるので、ここではその説明を省略する。

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

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

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

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

各監視対象側監視処理系３−１，…の監視・診断ソフト更新処理部３８は、通信ネットワーク４を介して送られてくる負荷考慮形監視・診断ソフト伝送スケジュール作成部２５で作成された監視・診断ソフトの更新タイミング信号を受け取り、当該更新タイミングに従って監視・診断ソフトを更新する。

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

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

（実施の形態６）
図７は本発明に係る遠隔監視・診断システムの実施の形態６を示す構成図である。

この実施の形態６は実施の形態５と同様な構成である。この実施の形態６において、特に異なるところは、中央装置１に相当する構成部分を複数の計算機で分担分けして実現する例である。

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

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

監視診断ソフト作成用計算機１ｂは、監視・診断ソフト作成部１２、監視・診断ソフト実行処理部１４及び監視・診断ソフト検証処理部２７に関する処理を実行する。

プラットフォーム用計算機１ｃは、前述したプラットフォーム３，３ａに関する処理を分担分けして受け持つ構成である。

予防保全支援用計算機１ｄは、予防保全支援情報作成部１５及び予防保全最適化処理部１６の一連の処理を実行する。

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

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

本発明に係る遠隔監視・診断システムの一実施の形態を示す構成図。 本発明に係る遠隔監視・診断システムの他の実施の形態を示す構成図。 本発明に係る遠隔監視・診断システムのさらに他の実施の形態を示す構成図。 本発明に係る遠隔監視・診断システムを実現するためのハードウェア構成の一例を示す図。 本発明に係る遠隔監視・診断システムのさらに他の実施の形態を示す構成図。 本発明に係る遠隔監視・診断システムのさらに他の実施の形態を示す構成図。 本発明に係る遠隔監視・診断システムのさらに他の実施の形態を示す構成図。

符号の説明

１…中央側処理系、１ａ…アルゴリズム作成用計算機、１ｂ…監視診断ソフト作成用計算機、１ｃ…プラットフォーム用計算機、１ｄ…予防保全支援用計算機、２…監視対象、３−１，… …監視対象側監視処理系、４…通信ネットワーク、１１…監視・診断ソフト用アルゴリズム作成部、１２…監視・診断ソフト作成部、１３、１３ａ…プラットフォーム、１４…監視・診断ソフト実行処理部、１５…予防保全支援情報作成部、１６…予防保全最適化処理部、１７…監視・診断ソフト伝送部、１８…監視・診断ソフト伝送スケジュール作成部、１９…監視対象情報受信部、２０…ソフトバージョン管理部、２１…データベース管理部、２２…監視・診断ソフト検証処理部、２３…監視・診断ソフト更新トリガ発生部、２４…更新トリガ対応監視・診断ソフト用アルゴリズム作成部、２５…負荷考慮形監視・診断ソフト伝送スケジュール作成部、３１…監視・診断ソフト受信部、３２…監視・診断ソフト実行処理部、３３…監視処理結果用データベース、３４…監視対象情報送信部、３５…監視・診断ソフト自動検証処理部、３６…監視・診断ソフト検証装置、３７…監視・診断ソフト更新トリガ発生部、３８…監視・診断ソフト更新部。

Claims (9)

1. 中央側処理系と監視対象を監視、診断する複数の監視処理系とが通信ネットワークで接続され、各監視対象の監視・診断を行う遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   前記監視対象に関連するデータ及び仕様を分析し、当該監視対象の監視・診断アルゴリズムを作成する第１のアルゴリズム作成手段と、この作成された監視・診断アルゴリズムをもとに、前記監視対象を監視・診断するための監視・診断ソフトを作成するソフト作成手段と、この作成された監視・診断ソフトを前記監視処理系に伝送する際の伝送スケジュールを作成する伝送スケジュール作成手段と、この伝送スケジュールに従って前記監視・診断ソフトを必要とする前記各監視処理系に前記通信ネットワークを通して伝送する伝送手段と、前記各監視処理系から監視・診断ソフトの実行結果である前記各監視対象の監視データ及び診断結果を受信する受信手段と、この受信手段で受信された監視データ及び診断結果を受け取り、前記各監視処理系による監視・診断ソフトの実行結果を確認し修正変更する第２のアルゴリズム作成手段とを備え、
   前記各監視処理系は、
   前記伝送手段から伝送されてくる監視・診断ソフトを受信する受信手段と、この受信された監視・診断ソフトを実行するソフト実行処理手段と、このソフト実行処理手段に対して所定のテスト信号を与えることにより、前記ソフト実行処理手段により実行される監視・診断ソフトの処理状況の確認や当該監視・診断ソフトの動作に想定外の誤動作、ソフトの改ざん、通常処理と異なる処理結果となるか否かを自動検証する自動検証手段と、前記ソフト実行処理手段による実行結果である前記監視対象の監視データ、診断結果及び検証結果を前記通信ネットワークを介して前記中央側処理系に送信する送信手段と、前記ソフト実行処理手段による実行結果である前記監視対象の監視データ及び診断結果と前記自動検証手段の検証結果とに基づき、少なくとも下記の何れか１つの条件のもとに監視・診断ソフトの更新が必要と判断されたとき、当該監視・診断ソフトの更新要請のトリガを送信する更新トリガ発生手段とを設け、
   （ニ） 前記診断結果から監視・診断ソフトの調整が必要なとき。
   （ホ） 前記監視データから劣化等の経年変化が生じているとき。
   （ヘ） 前記検証結果から異常と検証されたとき。
   前記中央側処理系は、
   各監視処理系の更新トリガ発生手段から更新要請のトリガを受けたとき、ソフト更新用のアルゴリズムを作成する前記第１のアルゴリズム作成手段に代る更新トリガ対応アルゴリズム作成手段をさらに設けたことを特徴とする遠隔監視・診断システム。
2. 請求項１に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   前記受信手段で受信された監視データ及び診断結果をもとに、前記ソフト作成手段で作成される中央側処理系で必要とする監視・診断ソフトを用いて実行し、その監視・診断結果を出力する監視・診断ソフト実行処理手段と、前記各監視処理系から送られてくる監視データ及び診断結果を受信し、これら監視データ及び診断結果と前記監視・診断ソフト実行処理手段で得られる監視・診断結果とに基づき、各監視対象の保全支援情報を作成する予防保全支援情報作成手段と、この作成された予防保全支援情報を用いて、最適な保全計画を立てる予防保全計画最適化処理手段とを設けたことを特徴とする遠隔監視・診断システム。
3. 請求項１または請求項２に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   前記伝送手段で監視・診断ソフトを伝送する際、当該伝送する監視・診断ソフトのバージョンを管理するソフトバージョン管理手段と、前記中央側処理系の受信手段で受信された前記各監視処理系からの監視データ、診断結果を保存し管理する保存管理手段とをさらに設けたことを特徴とする遠隔監視・診断システム。
4. 請求項１ないし請求項３の何れか一項に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   前記ソフト作成手段で作成された監視・診断ソフトを前記各監視処理系に伝送する前に事前に、前記中央側処理系内でシミュレーションによって検証するか、あるいは通信ネットワークに接続されるローカル監視対象実機を用いた監視・診断ソフト検証装置により検証し、前記各監視処理系に対して適正な監視・診断ソフトを伝送可能とする検証処理手段をさらに設けたことを特徴とする遠隔監視・診断システム。
5. 請求項１ないし請求項４の何れか一項に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   少なくとも下記の何れか１つの条件のもとに監視・診断ソフトの更新要求を受付けたとき、更新トリガを発生する更新トリガ発生手段と、この更新トリガを受けたとき、ソフト更新用のアルゴリズムを作成する前記第１のアルゴリズム作成手段に代る更新トリガ対応アルゴリズム作成手段とを設けたことを特徴とする遠隔監視・診断システム。
   （イ） 新しい診断方法が開発されたとき。
   （ロ） 監視対象の保守実績のもとに更新必要と判断されたとき。
   （ハ） 監視対象の監視項目や診断項目に増減による変更が生じたとき。
6. 請求項１ないし請求項５の何れか一項に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、
   多数の前記監視処理系が前記通信ネットワークに接続されている場合、各監視対象側監視処理系の負荷状況や停止時間を考慮し、前記監視・診断ソフトの更新タイミングを作成し、前記伝送手段を介して当該各監視対象側監視処理系へ伝送する前記伝送スケジュール作成手段に代る負荷考慮型伝送スケジュール作成手段を設け、
   前記各監視対象側監視処理系は、
   前記中央側処理系から前記通信ネットワークを介して伝送されてくる監視・診断ソフトを前記受信手段を通して受け取り、前記監視・診断ソフトの更新タイミングをもとに前記ソフト実行処理手段に対して監視・診断ソフトを更新するソフト更新処理手段をさらに設けたことを特徴とする遠隔監視・診断システム。
7. 請求項６に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系の負荷考慮型伝送スケジュール作成手段は、前記各監視対象側監視処理系から受信した監視データ及び診断結果を、前記中央側処理系の負荷状況を考慮しつつ所要とする構成要素に送出するタイミングを決定し、この決定されたタイミングに従って当該所要とする構成要素に送出することを特徴する遠隔監視・診断システム。
8. 請求項１ないし請求項７の何れか一項に記載の遠隔監視・診断システムにおいて、
   前記中央側処理系は、更新トリガ発生系を含むアルゴリズム作成系と、監視・診断ソフト作成・実行・検証系と、伝送スケジュールを含む伝送・受信及び管理系と、予防保全系とに分け、それぞれ個別の計算機で構成することを特徴とする遠隔監視・診断システム。
9. 請求項１ないし請求項８の何れか一項に記載の遠隔監視・診断システムにおいて、
   前記監視・診断ソフトをエージェントとして作成することを特徴とする遠隔監視・診断システム。

Images