JP6393533B2 - 診断システム及び診断サーバ - Google Patents

Description

本発明は、機器の故障予兆検知技術に関する。特に、消耗部品や摩耗部などの、定期的な保守が必要な部位を備えた機器の故障予兆検出技術に関する。

従来、機器の保守は機器運転時間を基準とした「時間基準保守(Time-Based Maintenance)」が主流だったが、機器稼働状況のセンシング技術の発達により、機器稼働状況を基準とした「状態基準保守(Condition-Based Maintenance)」が広まりつつある。

本技術分野の背景技術として、（特許文献１）がある。この背景技術では、搬送装置(特に、エレベータ)の保守分野において、エレベータに付帯する監視装置側で、検出器(センサ)や制御装置の出力を用いてエレベータの状態をセンシングするとともにその値があらかじめ登録された正常範囲の境界値を超えるか近づく場合に故障予兆を検出し、サーバ側で故障予兆の階級分けを実施する技術が示されている。

また、別の背景技術として、（特許文献２）がある。この背景技術では、自動車分野において、車両の制御及び診断処理において、時間的に余裕がない制御処理を車両側で、また、時間的に余裕のある診断処理を診断サーバ側で、それぞれ分担実行する技術が示されている。

これらの従来技術では、機器の状態診断や保守に関わる技術として、診断対象機器側で診断する構成と、診断対象機器に対してネットワークで接続された診断サーバ側で診断する構成の、両方が示されている。

しかし、これらの構成は、診断対象機器毎の事情に応じて、個別に開発されている。

具体的には、例えば、エレベータの場合は監視機器がサーバと有線接続されているため通信の安定性は期待でき、通信速度は設置場所に依存する(都市は高速通信可能だが、僻地は通信速度が落ちる、など)。このため、診断対象となるエレベータが都市部に設置されている場合には診断機能をサーバ側で実行する構成にすることもできるが、僻地の場合は診断に足る量のセンサデータをサーバに送ることができず、診断機能を監視機器側で実行する構成となる。また、例えば、自動車の場合は、診断対象自体が移動体であることから無線通信ネットワークが前提となるため、通信の安定性は期待しにくい。このため、診断機能を車両側で実行する構成が一般的である(但し、自動車は民生品であるため車両部品にかけられるコスト制約が厳しく、高性能な演算リソースを使えない。従って、複雑な診断アルゴリズムは実行できない)。

つまり、従来は、(1)診断対象機器側の演算性能、(2)診断サーバ側の演算性能、(3)診断対象機器〜診断サーバ間のネットワーク性能、の制約条件に合わせて、診断システムを個別開発していた。より具体的には、個別開発する際に、診断対象機器側とサーバ側それぞれの演算能力、及び、ネットワークの通信能力に対して設計マージン(安全マージン)を加味して能力上限を定め、その能力上限に合わせて診断機能を実行する演算リソースとネットワーク伝送内容を静的に設計していた。

特許03288255号公報 特表2005-529419号公報

一方、故障予兆診断機能の提供事業者側には、診断対象機器に応じて個別にシステム開発していては開発期間や開発費用が個別に必要なため「一つのシステムで複数の異なる診断対象機器(及び、機器が対象とする事業分野)をカバーしたい」という開発要求が存在する。しかしながら、前述の通り、個別開発となってしまう理由は演算性能やネットワーク性能などの物理制約に由来するため、従来の技術では、異なる診断対象機器に対する制約条件を一つのシステムで満たすことができない、という課題があった。

さらに、通信が不安定な状況ではセンサデータを安定してサーバに伝送することができないため、サーバ側で診断する構成として設計した場合に診断を継続できない、という課題があった。

さらに、複数診断項目を並行処理するなど演算余力が変動する状況では、診断機能を診断対象機器またはサーバのいずれかに静的に割り当てる構成として設計すると演算能力が足りなくなった際に診断を継続できない、という課題があった。

上記課題を達成するために、本発明は診断実行部と、配置部と、診断対象機器と、診断サーバと、ネットワークを備えた故障予兆診断システムにおいて、前記診断実行部は、センサ入力処理、前処理、診断処理、後処理の処理モジュールと、前記処理モジュールを接続する共通インタフェースを備え、前記配置部は、前記処理モジュールを、前記診断対象機器または前記診断サーバに配置して、実行させることを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記配置部は、負荷データ収集処理、配置先決定処理、配置実行処理を備え、前記配置部が、前記診断対象機器、前記ネットワーク、前記診断サーバそれぞれの処理負荷を計測し、前記処理負荷の変動に応じて、前記処理モジュールの配置実行先を前記診断対象機器、又は前記診断サーバに配置変更することを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記共通インタフェースは、ファイル入力、メモリ入力、通信入力、データベース入力から入力手段を選択し、かつ、ファイル出力、メモリ出力、通信出力、データベース出力から出力手段を選択し、選択された入出力手段の種別が異なる場合に、データ変換部が、入力されたデータを出力手段に合致するように変換することを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記共通インタフェースは、該共通インタフェースの入力側に接続された処理モジュールの処理状況を前段処理ステータスとして保持し、かつ、前記配置部は、前段処理ステータスが正常でない場合に、該共通インタフェースの出力側に接続された前記処理モジュールの処理を中断することを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記処理モジュールが診断対象機器または診断サーバのどちらに配置されているかを示す画面を表示ことを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記処理モジュールの配置可否を示すサービス可否データを有し、前記配置部が、前記サービス可否データを用いて、前記処理モジュール群のうち一部の処理モジュールに限って診断対象機器、又は診断サーバに配置することを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記共通インタフェースは、前記処理モジュール４種のうち該共通インタフェースの入力側に接続されたものと同種の処理モジュールを、該共通インタフェースの出力側に対して直列接続したことを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記共通インタフェースは、該共通インタフェースの出力側に対して、前記処理モジュール４種のうち同種の処理モジュールを並列接続したことを特徴とするものである。

更に、本発明は故障予兆診断システムにおいて、前記処理モジュール間の依存関係定義データを備え、前記配置部が、前記処理モジュールの配置実行先を、前記依存関係条件を満たすように診断対象機器または診断サーバに配置することを特徴とするものである。

本発明によれば、診断機能を前記処理モジュールに分割し、モジュール間の接続インタフェースを共通化するとともに、共通インタフェース内部に複数の切替可能な入出力手段とデータ変換手段を備えたことにより、処理モジュールのそれぞれを診断対象機器側と診断サーバ側のどちらにも配置実行することができる。よって、一つのシステムで異なる診断対象機器に対する制約条件を満たすことができる。

具体的には、診断対象機器の演算能力、ネットワークの通信能力、診断サーバの演算能力に合わせて、処理モジュールのうちセンサ入力処理と前処理を診断対象機器側に、診断処理と後処理を診断サーバ側にそれぞれ配置したり、別な構成として、センサ入力処理のみを診断対象機器側に、前処理、診断処理、後処理を診断サーバ側にそれぞれ配置するなど、柔軟に構成することができる。

また、本発明によれば、ネットワークの通信負荷状況に応じて診断処理をサーバ側から診断対象機器側に動的に変更することができるため、通信が不安定な状況ではサーバ側にセンサデータを送信せずに診断対象機器側で診断を継続することができる。

また、本発明によれば、診断対象機器及び診断サーバの処理負荷状況に応じて、診断対象機器の負荷が大きい場合には診断サーバ側に、逆に、診断サーバ側の負荷が大きい場合には診断対象機器側に、処理モジュール単位でその配置実行先を動的に変更することができるため、診断対象機器または診断サーバのいずれか処理負荷が低いほうで診断を継続することができる。

本発明の構成概要を示す図である。 共通インタフェースの構成を示す図である。 負荷データ収集処理の処理フローを示す図である。 配置先決定処理内で用いる配置条件判定ルールを示す図である。 配置先決定処理の処理フローを示す図である。 配置データのデータ構造及び再配置例を示す図である。 故障予兆診断システムの運用画面例を示す図である。 実施例２における配置データのデータ構造及び例を示す図である。 実施例３における共通インタフェースの構成を示す図である。 実施例３における入力切替部の構成を示す図である。 実施例３における出力切替部の構成を示す図である。 実施例３における診断実行部の構成例を示す図である。 実施例４における配置データのデータ構造及び例を示す図である。

以下、図面を用いて実施例を説明する。

図1に、本実施例の構成概要を示す。尚、図中の実線矢印は処理の流れを、点線矢印はデータの流れを、一点鎖線矢印は処理の配置実行(後述)を示す。

本発明で示す故障予兆診断システムは、診断実行部１００、配置部２００、診断対象機器３００、診断サーバ４００、ネットワーク５００で構成される。なお、図１では診断対象機器と診断サーバは１台ずつ記載しているが、実際にはそれぞれ複数台の構成を採用することも可能である。

診断実行部１００内部の処理は、センサ入力処理Ｓ１１０、前処理Ｓ１２０、診断処理Ｓ１３０、後処理Ｓ１４０と、Ｓ１１０〜Ｓ１４０を繋ぐ共通インタフェース１５０から構成される。尚、本発明では、Ｓ１１０〜Ｓ１４０の4種の処理をまとめて処理モジュールと呼び、処理モジュールを共通インタフェースで繋いで構成された故障予兆検出処理フローを実行することにより、診断機能が実現される。この際、機器診断を連続して実現するため、後処理Ｓ１４０までの処理が完了したら、センサ入力処理Ｓ１１０に戻る。

センサ入力処理Ｓ１１０は、診断対象機器３００に対して取り付けられた各種センサ(例えば、振動センサ、温度センサなどの物理センサ)値や、診断対象機器の制御出力値(例えば、モータ回転数やバルブ開度など)を「機器の稼働状態情報」として取り込む。この処理で取り込まれた値はセンサ出力値や制御出力値などの値を未加工で取り込んだものであり、ノイズや異常値を含むことがある。

前処理Ｓ１２０は、前段処理であるセンサ入力処理Ｓ１１０によって取り込まれたセンサ値データに対して、後段の診断処理Ｓ１３０での処理に適するようにデータ加工を施す。例えば、外気温が２５５℃などの明らかなセンサ故障とみなせる値を除去したり、振動データに対して周波数フィルタをかける、などの処理を行う。

診断処理Ｓ１３０は、診断の根幹をなす部分であり、センサ毎の閾値診断処理や、複数センサ値を束ねたセンサベクトルに対して、パターン認識や識別器等による異常度診断を行う。例えば、時刻Ｔ＝Ｔｉの時点での前処理の結果を３次元のベクトルＳｉ＝(Ｓｉ１,Ｓｉ２,Ｓｉ３)とするときに、閾値診断の場合はベクトルの各次元に対応する閾値(ＴＨ１,ＴＨ２,ＴＨ３)を定めておき、前処理結果ベクトルＳｉの各次元について閾値を超えた次元数を集計することで異常度ランクとして出力してもよいし、識別器による診断の場合は、あらかじめ機器が正常稼働している時の前処理結果ベクトルを学習させておき、診断時に得られた前処理結果ベクトルを識別器にかけることで異常度を求めるなどしてもよい。

後処理Ｓ１４０は、診断処理Ｓ１３０が出力する異常度を元に、故障予兆検出システムが機器異常を発報するかどうかを最終判定する。例えば、診断処理が一瞬だけ高い異常度を出した場合には発報せず、ある一定時間継続して高い異常度を出した場合には発報する、などの条件判定を行う。

診断機能を構成する各処理モジュールは診断対象機器または診断サーバのいずれかの計算機リソースに配置及び実行される。この際に、各処理モジュールの配置実行先を決定する機能を担うのが診断部２００である。なお、本実施例では配置部２００の処理は診断サーバ４００上で行うものとするが、本実施例の制約事項ではない。例えば、診断対象機器の演算リソースが十分であれば、診断対象機器上で実行しても構わない。

配置部２００は処理負荷データ収集処理Ｓ２１０、配置先決定処理Ｓ２２０、配置実行処理Ｓ２３０の各処理と、負荷データＤ２１０、配置データＤ２２０の各データにより構成される。以下、処理概要を示す。

まず、負荷データ収集処理Ｓ２１０が診断対象機器３００、診断サーバ４００、ネットワーク５００の処理負荷を計測し、負荷データＤ２１０に記憶する。次に、配置先決定処理Ｓ２２０が、蓄積された負荷データを元にして、Ｓ１１０〜Ｓ１４０の各処理モジュールを診断対象機器と診断サーバのどちらに配置するか決定し、決定内容を配置データＤ２２０に記憶する。この処理の詳細は後述する。最後に、配置実行処理Ｓ２３０が、配置データＤ２２０に基づいて各処理モジュールを診断対象機器３００または診断サーバ４００に配置及び実行する。なお、処理モジュールの配置については、処理モジュール自体を都度配信する(つまり、配置と実行の両方を都度実施する)方式でも、診断対象機器や診断サーバに事前に記憶された処理モジュールを都度起動する(つまり、配置は事前実施しておき、実行だけを都度実施する)方式でも構わない。

次に、図２に、共通インタフェース１５０の詳細を示す。

共通インタフェース１５０は、ファイル入力部２１０、メモリ入力部２１５、通信入力部２２０、データベース(以下、ＤＢ)入力部２２５、ファイル出力部２７０、メモリ出力部２７５、通信出力部２８０、ＤＢ出力部２８５の、それぞれ入力と出力で対をなす入出力手段と、前記入出力手段を切り替える切替部２３０，２９０と、前段処理ステータス確認部２４０と、前記確認した結果を記憶する前段処理ステータスデータＤ２５０と、データ変換部２６０により構成される。

以下、各部位の構成について述べる。

まず、各入力部２１０〜２２５は、該共通インタフェースの前段で実行された処理モジュール(以下、このモジュールを前段処理モジュールと呼ぶ。例えば、前処理Ｓ１２0)の出力を受け取る。この際、どのような手段を用いて受け取るかを選択する「スイッチ」の役割を持つのが切替部２３０である。

次に、前段処理ステータス確認部２４０が、各入力部２１０〜２２５のうちいずれかの入力部を経由して得られた情報から、該共通インタフェースの前段で実行された処理モジュールＳ１１０〜Ｓ１４０の処理が正常終了したかどうかを確認し、その確認結果を、前段処理ステータスデータＤ２５０に記憶する。

次に、データ変換部２６０が、入力部２１０〜２２５を通じて得られた、前段処理モジュールの処理結果データを必要に応じて変換する。この際、変換の要否は以下の方法により判断する。

・変換が不要な場合＝入力部２１０〜２２５で選択された入力手段と、出力部２７０〜２８５で選択された出力手段が同じ場合(例：入出力いずれもファイルの場合)。

・変換が必要な場合＝入力部２１０〜２２５で選択された入力手段と、出力部２７０〜２８５で選択された出力手段が異なる場合(例：入力＝ファイル、出力＝通信の場合)
最後に、出力部２７０〜２８５が、該共通インタフェースの後段で実行される処理モジュール(以下、このモジュールを後段処理モジュールと呼ぶ。例えば、診断処理Ｓ１３0)に、データ変換後の前段処理モジュール処理結果を出力する。この際、どのような手段を用いて出力するかを選択する「スイッチ」の役割を持つのが切替部２９０である。

なお、本実施例ではデータの入出力手段としてファイル、メモリ、通信、データベースの４種類のみ示しているが、他の手段でも構わない。例えば、インターネット上のリポジトリサービスを経由するなどしても構わない。

次に、図３に、負荷データ収集処理Ｓ２１０の処理詳細を示す。

負荷データ収集処理Ｓ２１０では、まず、診断対象機器側の負荷を取得し、負荷データＤ２１０に記憶する(Ｓ３１０)。例えば、診断対象機器のＣＰＵ使用率、メモリ使用率、消費電力、バッテリ残量などを計測する。

次に、診断サーバ側の負荷を取得し、負荷データＤ２１０に記憶する(Ｓ３２０)。例えば、診断サーバのＣＰＵ使用率、メモリ使用率、Ｉ／Ｏ占有率、消費電力などを計測する。

次に、ネットワークの負荷を取得し、負荷データＤ２１０に記憶する(Ｓ３３０)。例えば、診断対象機器〜診断サーバ間の通信可否、応答時間、通信速度などを計測する。

最後に、診断実行部１００に含まれる全ての共通インタフェース１５０が有する前段処理ステータスデータＤ２５０を集約し、負荷データＤ２１０に記憶する(Ｓ３４０)。

次に、図４に、後述する配置先決定処理Ｓ２２０で処理モジュールの配置先を決定する際に用いられる、配置条件判定ルールを示す。なお、図中の「Ｌ」は負荷が低い状態を、「Ｈ」は負荷が高い状態を示す。

配置条件判定ルールは配置先決定処理Ｓ２２０に組みこまれるもので、負荷データ収集処理Ｓ２１０で収集された負荷データにより表わされる前段処理ステータスと、前記ステータスに応じた再配置方法を、場合分けして定めたものである。

以下、Ｃａｓｅ番号毎に説明する。

Ｃａｓｅ０は、前段処理モジュールが正常終了しており、負荷も問題ないため、再配置は行わない。

Ｃａｓｅ１は、診断サーバ側の負荷だけが高い状態である。後段処理モジュールが機器側に配置済みの場合は特に配置変更は行わないが、診断サーバ側に配置済みの場合は、別の診断サーバに再配置する。

Ｃａｓｅ２は、ネットワーク負荷だけが高い状態で、機器側と診断サーバ側のいずれも処理負荷は問題ないが、機器側で実行済みの前段処理モジュール処理結果を診断サーバ側に全て送りきれない状況である。処理モジュールの再配置自体は行わないものの、診断サーバ側に配置済みの後段処理モジュールの処理開始を、機器側からのデータ到着まで遅らせる。

Ｃａｓｅ３は、ネットワークと診断サーバの負荷が高い状況で、後段処理がオーバフローしている状況である。従って、後段処理モジュールを機器側に再配置し、処理負荷を肩代わりする。但し、機器側は一般的に診断サーバよりも演算リソースが少ないため、再配置前に機器側演算リソースの上限をチェックし、再配置により機器側もオーバフローしてしまうようであれば処理負荷警告を出すなどしてもよい。

Ｃａｓｅ４は、機器側の負荷だけが高い状態である。後段処理モジュールが診断サーバ側に配置済みの場合は特に配置変更は行わないが、機器側に配置済みの場合は、診断サーバ側に再配置する。

Ｃａｓｅ５は、機器側と診断サーバ側のどちらも負荷が高い状況であり、どちらでも後段処理を分担できない。従って、処理負荷警告を出す。

Ｃａｓｅ６は、機器側とネットワークのどちらも負荷が高い状況であり、機器側から処理負荷を逃がしたいがネットワークも逼迫しているという状況である。機器側から診断サーバ側に後段処理モジュールを再配置するとともに、再配置後モジュールの処理開始を、機器側からのデータ到着まで遅らせる。

Ｃａｓｅ７は、機器側、ネットワーク、診断サーバ側の全ての負荷が高い状況であり、診断を継続できる状況ではない(仮に継続しても、診断結果が信頼できない)。従って、高負荷エラーを出し、処理を中段する。

尚、本実施例では、負荷の高低判断方法としてあらかじめ指定された単一の負荷率閾値との比較を用いるが、他の方法を用いても構わない。例えば、負荷率閾値を上限閾値と下限閾値の２種類指定しておき、実際の負荷率が上限を超えたときに高負荷、下限を下回ったときに低負荷と判断してもよい。この判断方法によれば、高低判断にヒステリシス性を持たせ、単一負荷率閾値近辺で負荷率が周期変動する場合に、高低判定結果が頻繁に切り替わることを防ぐことができる。

また、本発明では、配置条件判定ルールの判定基準を機器側負荷、ネットワーク負荷、診断サーバ側負荷に限定するものではない。例えば、本実施例では消費電力やバッテリ残量などを入れていないが、機器側バッテリ残量が残り少ない場合にはＣａｓe４と同様に処理モジュールを診断サーバ側に再配置するなど、別のルールを適用してもよい。

次に、図５に、配置先決定処理Ｓ２２０の処理詳細を示す。

配置先決定処理Ｓ２２０では、まず、診断実行部１００に含まれる全ての共通インタフェースに対して、前段処理ステータスが正常かどうか判定し(Ｓ５１５)、正常でない場合は異常通知を行う(Ｓ５２０)。

続いて、診断実行部１００に含まれる全ての処理モジュールに対して、図４で述べた配置条件判定ルールにしたがって配置条件判定を行い(Ｓ５３５)、判定結果に応じて処理内容を決定する。以下、場合分けして、Ｃａｓe番号毎に説明する。

Ｃａｓｅ１の場合は、現在ステータス確認中の共通インタフェースに対する後段処理モジュールの配置先を、現在割り当て中の診断サーバから別サーバに再配置する(Ｓ５４０)。

Ｃａｓｅ２の場合は、特に再配置は行わないが、後段処理モジュールの処理開始を遅らせる(Ｓ５４５)。

Ｃａｓｅ３の場合は、まず機器側の処理性能上限をチェックし(Ｓ５５０)、上限を超えていなければ後段処理モジュールを診断サーバ側から機器側に再配置する(Ｓ５５５)。もし上限を超えていれば、処理負荷警告を出す(Ｓ５７０)。

Ｃａｓｅ４の場合は、後段処理モジュールを機器側から診断サーバ側に再配置する(Ｓ５６０)。その後、ネットワーク負荷をチェックして(Ｓ５６５)、負荷が大きい場合がＣａｓe６に該当する。

Ｃａｓｅ６の場合は、Ｃａｓｅ４の処理に加えて、後段処理モジュールの処理開始を遅らせる(Ｓ５４５)。

Ｃａｓｅ５及び７の場合は、処理負荷警告を出す(Ｓ５７０)。この際、Ｓ５７０のステップで、さらにＣａｓｅ５かＣａｓｅ７かの条件判定を行い、Ｃａｓｅ５の場合は警告にとどめ、Ｃａｓｅ７の場合はエラーとするなどの場合分けを行ってもよい。

次に、図６に、配置データＤ２２０のデータ形式と、処理モジュールの再配置の例を示す。なお、図６(Ａ)は再配置前(つまり、初期配置時点)の配置データの例、図６(Ｂ)は再配置後の配置データの例である。

配置データＤ２２０には、処理ＩＤと、モジュール名と、配置先と、処理待ち有無フラグの４種のデータが記憶される。

処理ＩＤは一つの機器に対する一つの診断項目に付与されるＩＤである。例えば、診断対象機器がＮ台、一つの機器あたり診断項目(ポンプ診断と軸受診断、など)がＭ種ある場合に、診断項目１種につきセンサ入力、前処理、診断処理、後処理の各モジュールがセットになるため、同セット内の処理モジュールには同じ処理ＩＤが割り振られる。

モジュール名は、診断モジュールの種類を表す。

配置先は、各診断モジュールがどの機器に対して配置されるかを表す。尚、配置実行処理Ｓ２３０により再配置を行う際に、この配置先情報に沿って処理モジュールが配置され、実行される。

処理待ち有無フラグは、該処理モジュールが前段処理モジュールの処理結果到達を待つべきかどうかを表すフラグである。

次に、再配置の例について述べる。

まず、(Ａ)は診断対象機器として機械Ａ〜Ｄがあり、それぞれの機械に診断項目１〜４が一つずつ割り当てられている例である。さらに、処理ＩＤ１〜４のいずれも、初期配置として、センサ入力と前処理の２処理モジュールは機器側に、診断処理と後処理の２処理モジュールは診断サーバ側に、それぞれ配置実行されている。

次に、配置先決定処理Ｓ２２０の処理の結果、再配置が行われた後の状態が(Ｂ)である。この例では処理ＩＤ毎に異なるＣａｓeを例示しているため、順に説明する。なお、図中、反転表示部分が変更箇所を示す。

まず、処理ＩＤ１は、前記配置条件判定ルールのＣａｓe１に相当する。元々配置されていた診断サーバＡの負荷が高まったため別の診断サーバＥに処理モジュールを振り替えた例である。

次に、処理ＩＤ２は、Ｃａｓe２に相当する。ネットワーク負荷は高いが機械Ｂも診断サーバＢも負荷に余裕があるため、処理待ちフラグをＯｎにして機械Ｂ側の前処理結果が診断サーバＢ側の診断処理に入力されるのを待つ。

次に、処理ＩＤ３は、Ｃａｓe３に相当する。診断サーバＣの負荷とネットワーク負荷が同時に高まったため、機械Ｃ側で診断処理及び後処理まで処理を完結させる。

次に、処理ＩＤ４は、Ｃａｓe４に相当する。機械Ｄ側負荷が高まったため診断サーバＤ側に処理モジュールを振り替えるが、前処理モジュールだけを振り替えることで機械Ｄ側の負荷が十分に下がり、センサ入力処理は機械Ｄ側に残った例である。

次に、図７に、本発明を適用した故障予兆検出システムの運用画面例を示す。

運用管理画面７１０には運用状態一覧表７２０が表示される。

運用状態一覧表に表示される項目は、機器名と診断項目名、処理モジュール名とその配置実行先である。

機器名と診断項目名は、別途管理される一般的な機器台帳等と、配置データＤ２２０内の処理ＩＤとの割付データを元に生成され、「どの機器の、どのような項目を診断しているか」を示す。

図７の例では、表の縦軸１行が一つの診断項目を示し、表の横軸は処理モジュールを示す。また、表の直行部分に入る機器名または診断サーバ名が、各処理モジュールの現在の配置実行先を示す。

さらに、図７の例では、処理モジュールが配置変更された部分を反転表示で示し、処理待ちが生じている部分を機器名またはサーバ名の末尾に「△」を付記して示している。但し、これは本発明の制約事項ではなく、配置変更の有無と、処理待ちの有無が区別できれば他の手段でも構わない。例えば、配置変更と処理待ちのそれぞれを表すアイコンを用いてもよい。また、配置変更があった機器、処理待ちがあった機器、いずれもない(つまり、問題がない)機器を分けて表示するなどしてもよい。

なお、本実施例では運用管理画面７１０は診断サーバ４００のいずれかに表示されるものとするが、これは本発明の制約事項ではない。例えば、診断サーバとは別の運用管理サーバを設けてそちらに表示しても構わない。

次に、図８に、本発明の実施例２を示す。

本実施例は、実施例１で述べたセンサ入力処理、前処理、診断処理、後処理の処理モジュール全てを含む故障予兆検出処理フロー構成だけでなく、部分的な処理フローを提供する例である。なお、実施例１と発明の構成が異なる部分のみ示し、同じ部分については省略する。

まず、図８に実施例２における配置データＤ２２０を示す。

実施例２における配置データＤ２２０には、実施例１における配置データＤ２２０と同じ項目に加えて、サービス可否データＤ８１０が追加される。

サービス可否データＤ８１０には、あらかじめ処理モジュール毎のサービス可否情報が記憶されている。なお、本実施例では、サービス可否情報＝Ｏｎの場合にサービス提供可、＝Ｏｆｆの場合にサービス提供不可とする。

実施例１における配置実行処理は配置データＤ２２０内の配置先情報のみを用いて処理モジュールを配置実行するのに対し、実施例２における配置実行処理Ｓ２３０では、まず前記サービス可否情報をチェックし、サービス提供不可の場合は処理モジュールの配置実行を行わない。

次に、サービス提供不可に設定した場合の例を説明する。

実施例２における処理ＩＤ１のケースは、前処理以降の処理モジュールは配置実行せず、センサ入力処理の結果をそのままユーザに提供する。従って、診断対象機器設計者向けの機器稼働詳細情報モニタリング機能を構築することが可能になる。

実施例２における処理ＩＤ２のケースは、診断処理以降の処理モジュールは配置実行せず、前処理の結果をユーザに提供する。従って、診断アルゴリズム分析者向けの機器稼働データ収集機能を構築することが可能になる。

実施例２における処理ＩＤ３のケースは、後処理モジュールは配置実行せず、診断処理の結果(つまり、サンプリング周期毎の異常度出力値)をユーザに提供する。従って、機器異常度トレンドのモニタリング機能を構築することが可能になる。

次に、図９〜１２に、本発明の実施例３を示す。

本実施例は、実施例１で述べたセンサ入力処理、前処理、診断処理、後処理の各処理モジュールについて、同じ種類の処理モジュールを直列または並列に接続することによって、より複雑な故障予兆検出処理フローを構成する例である。なお、実施例１と発明の構成が異なる部分のみ示し、同じ部分については省略する。

まず、図９に実施例３における共通インタフェース１５０を示す。

実施例３における共通インタフェースは、実施例１における共通インタフェースのうち、入出力の切替部のみが異なる。具体的には、入力側の切替部２３０が入力切替部９１０に、出力側の切替部２９０が出力切替部９２０にそれぞれ交換されている。

次に、図１０に、入力切替部９１０の詳細を示す。

入力切替部９１０は、あらかじめ定義された数(Ｎ個)の入力端子１０１０と、一つのスイッチ１０２０により構成される。スイッチは入力端子のうちいずれか一つと、ファイル入力２１０、メモリ入力２１５、通信入力２２０、ＤＢ入力２２５のうちいずれかを選択して接続する。従って、入力切替部９１０はＮ入力から１入力を選んで１出力に繋ぐ「セレクタ」として機能する。

次に、図１１に、出力切替部９２０の詳細を示す。

出力切替部９２０は、一つのスイッチ１１１０と、中継端子１１２０と、分配経路１１３０と、あらかじめ定義された数(Ｍ個)の出力端子１１４０により構成される。スイッチ１１１０はファイル出力２７０、メモリ出力２７５、通信出力２８０、ＤＢ出力２８５のうちいずれか一つと中継端子を１：１に接続する。つまり、スイッチ１１１０は出力手段２７０〜２８５の選択機能を持つ。次に、中継端子１１２０を経由して流れる情報は分配経路１１３０を通じて全ての出力端子１１４０に出力される。従って、出力切替部９２０は４入力から１入力を選んで全出力端子に分配する「セレクタ兼分配器」として機能する。

次に、図１２に、実施例３における診断実行部１００の構成例を示す。

実施例３における診断実行部１００は、実施例１における診断実行部に対して、前処理Ｓ１２０を２個直列に配置し、診断処理Ｓ１３０を２個並列に配置した点が異なる。例えば、前処理としてセンサ故障判定と周波数帯域フィルタを直列にかけて、その後、２種の診断アルゴリズムを切り替えて使うケースを示したものである。実施例１における共通インタフェースは入出力数が１入力１出力のインタフェースであるためこのような処理フローを構成することができないが、実施例３における入力切替部９１０及び出力切替部９２０を用いることで構成可能になる。

次に、図１３に、本発明の実施例４を示す。

本実施例は、実施例１で述べたセンサ入力処理、前処理、診断処理、後処理の各処理モジュールについて、配置先を変更するにあたって、その前後の処理モジュールの配置先と同じ演算リソースに配置するように制約をつける例である。なお、実施例１と発明の構成が異なる部分のみ示し、同じ部分については省略する。

まず、図１３に実施例４における配置データＤ２２０を示す。

実施例４における配置データＤ２２０には、実施例１における配置データＤ２２０と同じ項目に加えて、後段分離不可フラグＤ１３１０が追加される。

後段分離不可フラグＤ１３１０には、あらかじめ、各処理モジュールが、該処理モジュールの後段に接続されている処理モジュールと別の演算リソースに分離配置してよいかどうかを示す情報が記憶されている。ここで、本実施例では後段分離不可フラグ＝Ｏｎの場合に分離不可、＝Ｏｆｆの場合に分離可能とする。

実施例１における配置実行処理は配置データＤ２２０内の配置先情報のみを用いて処理モジュールを配置実行するのに対し、実施例４における配置実行処理Ｓ２３０では、まず前記後段分離不可フラグをチェックし、分離不可な処理モジュールについてはは再配置を中止する。

次に、分離不可に設定した場合の例を説明する。

実施例４における処理ＩＤ５のケースは、センサ入力処理の後段処理(つまり、前処理)が分離不可になっている。従って、仮に配置先決定処理Ｓ２２０で前処理配置実行先が変更されたとしても、その結果はキャンセルされ、センサ入力処理と前処理が同じ機械Ｅ上に配置実行される。

実施例４における処理ＩＤ６のケースは、前処理の後段処理(つまり、診断処理)が分離不可になっている。従って、仮に配置先決定処理Ｓ２２０で診断処理配置実行先が変更されたとしても、その結果はキャンセルされ、前処理と診断処理が同じ機械Ｆ上に配置実行される。

１００ 診断実行部
２００ 配置部
３００ 診断対象機器
４００ 診断サーバ
５００ ネットワーク
Ｓ１１０ センサ乳量処理
Ｓ１２０ 前処理
Ｓ１３０ 診断処理
Ｓ１４０ 後処理
１５０ 共通インタフェース
Ｓ２１０ 負荷データ収集処理
Ｓ２２０ 配置先決定処理
Ｓ２３０ 配置実行処理
Ｄ２１０ 負荷データ
Ｄ２２０ 配置データ

Claims (10)

1. センサ及び第一の処理手段を有する診断対象機器と、
   前記診断対象機器とネットワークを介して結ばれた第二の処理手段を有するサーバと、を備えた診断システムにおいて、
   前記第一の処理手段または前記第二の処理手段のいずれかの計算機リソースに配置及び実行される、前記センサからの入力信号を処理する入力処理、前記入力処理からの信号を加工処理する前処理、前記前処理からの信号により前記診断対象機器を診断して異常度を求める診断処理、又は、前記診断処理からの信号により前記診断対象機器の異常を判定する後処理を備えるとともに、
   前記診断対象機器、前記サーバ及び前記ネットワークの負荷の変動に応じて、前記入力処理、前記前処理、前記診断処理、又は前記後処理を前記第一の処理手段と前記第二の処理手段のどちらに配置するか決定することを特徴とする診断システム。
   
2. 請求項１において、
   前記ネットワークの負荷が高いと判断された場合には、再配置を行わないことを特徴とする診断システム。
   
3. 請求項２において、
   前記入力処理と前記前処理との間、前記前処理と前記診断処理との間、又は、前記診断処理と前記後処理との間で、データの変換が行われることを特徴とする診断システム。
   
4. 請求項２において、
   サービス可否データを有し、
   前記入力処理、前記前処理、診断処理、前記後処理のうち、前記サービス可否データが否の処理を行わないことを特徴とする診断システム。
   
5. 請求項２において、
   配置データを備え、
   前記配置データが分離不可を示す前記入力処理と前記前処理とを、前記配置データが分離不可を示す前記前処理と前記診断処理とを、又は、前記配置データが分離不可を示す前記診断処理と前記後処理とを、前記第一の処理手段又は前記第二の処理手段へ割り当てを変更することを特徴とする診断システム。
   
6. 処理手段を備え、
   センサ及び他の処理手段を有する診断対象機器とネットワークを介して結ばれる診断サーバにおいて、
   前記第一の処理手段または前記第二の処理手段のいずれかの計算機リソースに配置及び実行される、前記センサからの入力信号を処理する入力処理、前記入力処理からの信号を加工処理する前処理、前記前処理からの信号により前記診断対象機器を診断して異常度を求める診断処理、又は、前記診断処理からの信号により前記診断対象機器の異常を判定する後処理を備えるとともに、
   前記診断対象機器、前記サーバ及び前記ネットワークの負荷の変動に応じて、前記入力処理、前記前処理、前記診断処理、又は前記後処理を前記第一の処理手段と前記第二の処理手段のどちらに配置するか決定する変更手段を備えたことを特徴とする診断サーバ。
   
7. 請求項６において、
   前記ネットワークの負荷が高いと判断された場合には、再配置を行わないことを特徴とする診断サーバ。
   
8. 請求項７において、
   前記入力処理と前記前処理との間、前記前処理と前記診断処理との間、又は、前記診断処理と前記後処理との間で、データの変換が行われることを特徴とする診断サーバ。
   
9. 請求項７において、
   サービス可否データを有し、
   前記入力処理、前記前処理、診断処理、前記後処理のうち、前記サービス可否データが否の処理を行わないことを特徴とする診断サーバ。
   
10. 請求項７において、
    配置データを備え、
    前記配置データが分離不可を示す前記入力処理と前記前処理とを、前記配置データが分離不可を示す前記前処理と前記診断処理とを、又は、前記配置データが分離不可を示す前記診断処理と前記後処理とを、前記第一の処理手段又は前記第二の処理手段へ割り当てを変更することを特徴とする診断サーバ。