JP6823576B2 - 異常検出システムおよび異常検出方法 - Google Patents

Description

本発明は、機械装置などについて自動で実施される、運転状況の診断技術に関するものである。特に装置やシステムの異常検出システムおよび異常検出方法に関するものである。

各種の機械装置について、その運転状況を自動的に診断し、故障やその予兆など異常状態を検知する技術がある。

例えば、特許文献１には、地震の発生が感知された後、複数のモードで診断運転を実施する診断運転制御手段と、診断運転の各モードにおけるかごの走行時に、昇降路内の音響を集音する集音手段と、診断運転のモード毎に設定された複数の異常音基準値が記憶された異常音基準値記憶手段と、異常音基準値記憶手段に記憶されたモード毎の異常音基準値に基づいて、集音手段により集音された音響が異常音であるか否かを判定する異常音判定手段と、診断運転の同一モードにおけるかごの複数回の走行において、異常音が昇降路の同一位置で検出されたか否かを判定する異常音情報判定手段とを備えることにより、各モードに適した異常音の検出を実施し、偶発的に発生した音響の誤検出等を防止することが記載されている。

特開２００７−２２３７５０号公報

各種の機械、装置、あるいはシステム等（以下「診断対象」という）の運転状況を、低コスト、高精度で監視することが求められている。このため、診断対象に種々のセンサを取り付けて、センサから得られたデータを分析することにより、自動的に診断対象の状況を監視することが検討されている。

このとき、一般に診断対象は種々の運転モードで動作することが考えられるが、運転モードを区別しないで分析を実施すると、状態が大きく異なるデータを比較するため、分析精度が悪化する。

このため、其々の運転モードで診断のための運転を行い、別々に分析を行うことが考えられるが、通常運転を停止して診断運転を行う必要があり、実稼働時間が短縮されてしまう。また、診断運転中の運転状況のみを診断する場合には、通常運転中の監視はできていないため、突発的な異常には対応しきれない。

そこで、通常運転中に運転モードを考慮したセンサデータの分析を可能とし、高精度の診断を行うことが望まれる。

本発明の一側面は、診断対象に設けた検出素子からの検出信号に基づき、診断対象の異常を検出する異常検出システムであって、通常運転時における検出素子からの検出信号に基づき、診断対象の第１の運転モード時および第２の運転モード時における異常の有無を判定する異常判定部と、異常判定部で判定した第１の運転モードおよび第２の運転モードの異常の有無の組み合わせに基づき、診断対象の異常の原因を判断して検出する異常原因検出部と、を備える。

記憶装置、入力装置、処理装置、出力装置を備えた情報処理装置を用い、診断対象の異常を検出する異常検出方法であって、入力装置が、診断対象の状態を検出する検出素子からのセンサデータを取得し、処理装置が、センサデータを診断対象の運転モード毎に分類する分類処理と、分類した運転モード毎に異常検出を行なう異常検出処理を行なう。

通常運転中に運転モードを考慮したセンサデータの分析を可能とし、高精度の診断を行うことができる。

空圧機にセンサを実装した状況を示す概念図。 振動センサの検出信号の例を示すグラフ図。 実施例の運転状況の診断システムの全体構成を示すブロック図。 エッジ演算部が行う、診断処理の流れを示すフロー図。 異常判定部内の機能ブロックを示すブロック図。 異常原因推定テーブルの例を示す表図。 学習フェーズの動作を示すフロー図。 モードを識別するための閾値を設定する処理の概念を示す概念図。 運用フェーズの動作を示すフロー図。 実施例の診断システムの運転スケジュールの例を示す概念図。 実施例２において空圧機にセンサを実装した状況を示す概念図。 実施例２の異常判定データの概念を示す概念図。 実施例２の異常原因推定テーブル例を示す表図。 実施例３において空圧機にセンサを実装した状況を示す概念図。 実施例３の異常原因推定テーブル例を示す表図。 実施例４において切削加工機にセンサを実装した状況を示す概念図。 実施例５において半導体製造装置にセンサを実装した状況を示す概念図。 端末に表示される工場監視状況モニタの例を示すレイアウト図。 端末に表示される保守管理モニタの例を示すレイアウト図。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

実施例１では、診断対象として空気圧縮機（以下「空圧機」という）を構成する回転機を例とし、この回転機に振動センサを取り付けて、異常を遠隔監視するシステムを例に説明する。回転機の具体例としてモーターがあり、振動センサの具体例としてＭＥＭＳ（MEMS Micro Electro Mechanical System）センサがある。ただし、後の実施例で説明するように、診断対象やセンサの種類は種々のものを適用可能である。

空圧機の例で説明すると、本例で対象とする空圧機には停止・アンロード・ロードの３つの運転モードがある。停止は回転機が停止している状態であり、アンロードは回転機は回転しているが負荷がかかっていない状態であり、ロードは回転機が回転しており負荷がかかっている状態である。３つの運転モードでは、振動の状態が大きく異なっている。

＜１．診断対象（空圧機）＞
図１は空圧機にセンサを実装した状況を示す概念図である。空圧機１００は回転機１０２を備えており、回転機１０２は空気圧縮弁１０４を介して、空気槽１０６内の空気を圧縮する。振動センサ１０８は、空圧機１００に後付けで取り付けられている。後に詳細に説明するが、取り付け箇所は任意であり、個数も任意である。先に述べたように、回転機１０２が回転しているかどうか、および、回転機１０２に空気圧縮の負荷がかかっているどうかにより、空圧機は３つの運転モードで運転可能である。

＜２．センサデータ＞
図２は、３つの運転モード其々における、振動センサ１０８のセンサデータの例を示すグラフ図である。空圧機は停止・アンロード・ロードの３つの運転モードで動作するが、当該３つの運転モードでは、取得されるセンサデータに顕著な差異が認められる。図２では横軸に時間、縦軸には加速度を表示している。図２のグラフから判断できるように、加速度の大きさは、停止とロード・アンロードでは１桁以上異なる。また、波形のパターンも異なることが分かる。従って、これらのデータを区別せずに、同一の判定基準を用いて異常判断を行なうと、高精度の診断が困難である。

＜３．診断システム構成＞
図３は、実施例の運転状況の診断システムの構成を示すブロック図である。空圧機１００に振動センサ１０８が取り付けられており、センサデータは空圧機１００の付近に置かれたエッジ演算部３００に送信される。

エッジ演算部３００は、記憶装置３０１、入力装置３０２、処理装置（プロセッサあるいはＣＰＵ（Central Processing Unit））３０３、出力装置３０４、および、これらを接続する図示されないバスを備えた一般的な情報処理装置、例えばマイコンもしくはサーバーで構成することができる。本実施例では計算や制御等の機能は、記憶装置３０１に格納されたプログラムが処理装置３０３によって実行されることで、定められた処理を他のハードウェアと協働して実現される。計算機などが実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」、「ユニット」、「モジュール」等と呼ぶ場合がある。処理装置３０３は機能として、異常判定部３０５と異常原因検出部３０６を備えており、異常の判定結果をネットワーク３１０を介して中央演算部３２０に送信する。

中央演算部３２０も、記憶装置３２１、入力装置３２２、処理装置３２３、出力装置３２４、および、これらを接続する図示されないバスを備えた一般的なマイコンもしくはサーバーで構成することができる。中央演算部３２０は操作画面表示部３２５を備えており、出力装置３２４を介して端末３３０に操作画面を表示する。

振動センサ１０８とエッジ演算部３００の間の通信は、無線通信または有線通信のいずれでよい。本実施例では、Ｉ２Ｃ（Inter−Integrated Circuit）シリアルバスを用いた有線通信を想定している。ただし、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等の無線通信でもよい。通信のために必要なインターフェースは、公知の構成を振動センサ１０８と入力装置３０２が其々備えるものとする。

本実施例では異常原因検出部３０６はエッジ演算部３００に含まれているが、中央演算部３２０に含まれていてもよい。また、異常判定部３０５と異常原因検出部３０６の両方が中央演算部３２０に含まれていてもよい。その場合は、エッジ演算部３００は異常の判定結果ではなく、センサデータを中央演算部３２０に送信する。また、上記の構成は、診断対象に付属する単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。

本実施例では振動センサ１０８は一つを想定しているが、複数のセンサあるいは温度センサなど他の種類のセンサがあってもよい。複数のセンサは、一つのエッジ演算部３００にセンサデータを送信してもよいし、図示していない別のエッジ演算部にセンサデータを送信してもよい。すなわち、本実施例ではエッジ演算部３００を一つ想定しているが、複数のエッジ演算部があってもよい。

本実施例では端末３３０を一つ想定しているが、複数の端末があってもよい。また、中央演算部３２０と端末３３０の間の通信は無線通信と有線通信のいずれでよい。本実施例では、操作画面表示部３２５はＨＴＭＬサーバーを想定しており、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ（Cascading Style Sheets）、ＰＨＰ、Ｒｕｂｙ、Ｊａｖａ（登録商標）等の言語で記述されたコードを出力する。端末３３０は小型のコンピュータであるタブレット機器を想定しており、ウェブブラウザ上に操作画面を表示することを想定している。

本実施例で、記憶装置、入力装置、処理装置、出力装置といった場合には、公知の一般的な装置を適宜適用できるものとする。例えば、記憶装置としては磁気ディスク装置や各種半導体メモリを適用することができる。入力装置としてはキーボード、マウス、あるいは各種の入力インターフェースを適用することができる。出力装置としてはディスプレイ、プリンタ、あるいは各種の出力インターフェースを適用することができる。

なお、上記説明中、ソフトウェアで構成した機能と同等の機能は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェアでも実現できる。そのような態様も本願発明の範囲に含まれる。

＜４．診断処理フロー＞
図４は、エッジ演算部３００が行う、診断処理の流れを示すフロー図である。
処理Ｓ４０１では、空圧機１００を構成する回転機１０２に取り付けられた振動センサ１０８で振動を測定し、センサデータを入力装置３０２を介して取得する。取得したセンサデータは、後の処理のために、必要に応じて記憶装置３０１に格納する。

処理Ｓ４０２では、異常判定部３０５がセンサデータの運転モードを判定する。空圧機１００が生成した圧縮空気は空気槽１０６にて蓄えられる。圧縮空気は例えば工場等の設備内へと送られ、別の機械装置で使用される。空圧機１００は、空気槽１０６に貯蔵された圧縮空気が一定の圧力レベルを保つように吐出圧力制御を行う。空圧機では、この運用時を通常運転時とする。また、一般に通常運転とは、装置や設備がその本来の目的を達成するために動作する運転状態をいい、それ以外の例えば、診断、検査、修理、メンテナンスのみのために動作する運転状態と区別される。

通常運転時において、図１に示した空圧機１００には運転モードが３通りある。まず、回転機１０２が停止している停止モードがある。次に、回転機１０２は回転しているが、空気圧縮弁１０４が閉じている、空転状態のアンロードモードがある。最後に、空気圧縮弁１０４が開き、空気槽１０６に圧縮空気を送り込むロードモードがある。これらの３通りの運転モードを区別し、各運転モードごとにセンサデータデータベース（ＤＢ）３０１１として収集する。このとき、運転モードごとに独立したデータベースとするのがよい。処理Ｓ４０２で運転モードを判定するためのアルゴリズムの具体例については、後に説明する。なお、上記の説明中、吐出圧力制御の方式としてロード・アンロード方式を用いた空圧機を想定しているが、他の方式としてオンオフ方式、スライド弁方式、吸込絞り方式を用いた空圧機も本願発明の範囲に含まれる。

処理Ｓ４０３では、異常判定部３０５が運転モードごとに異常を判定する。センサデータを基にした異常判定の方法については、公知の種々の方法を採用できる。例えば、深層学習、強化学習、あるいはベイジアンネットワークを使うことが想定される。異常判定の方法については、基本的に制限はないが、処理Ｓ４０２の運転モード判定のためのアルゴリズムとは、異なるアルゴリズムを選択してもよい。異常判定のための解析対象となる特徴量も、運転モード判定とは異なる特徴量を用いてもよい。一般には、運転モード判定のためのアルゴリズムは処理量が小さいほうが望ましく、異常判定のためのアルゴリズムは処理量よりも精度を重視する。また、運転モードごとに異なるアルゴリズムあるいは特徴量を使うことも可能である。

図５は、異常判定部３０５内の機能ブロックを示すブロック図である。異常判定部３０５は、運転モード判定のための閾値を学習する学習部３０５１と、学習した閾値を用いてセンサデータのモードの判定を行なうモード判定部３０５２と、異常検出部３０５３を含む。これらの各部で用いるアルゴリズムや処理プログラムは、記憶装置３０１に格納されているものを、処理装置３０３で実効するものとする。

モード判定部３０５２は、運転モード判定Ｓ４０２を行い、モードごとに分けられたセンサデータを、モードごとに分けてセンサデータデータベース３０１１−１、３０１１−２、３０１１−３として格納する。異常検出部３０５３は、モードごとに分けられたセンサデータを用い、各モードのデータごとに異常を検出する。

図４に戻り、処理Ｓ４０４では、異常原因検出部３０６が異常原因推定テーブル３０１２を参照して、異常原因の推定を行なう。処理Ｓ４０３で、３つのモードごとに異常判定処理を行なった結果、各センサデータと正常、異常の組み合わせは、８通りのパターンとなる。この組み合わせを用いて、空気圧縮機の異常原因の推定を行う。

図６は、異常原因推定テーブル３０１２の例を示す表図である。図６（A）は、８通りのパターンごとに、推定される異常原因を格納している。異常原因推定テーブル３０１２の異常原因は、図３の処理に先立って、管理者が経験、実験、あるいはシミュレーションに基づいて作成して格納しておくものとする。また、異常原因は本システムを運用中に管理者によって追加、修正されることができる。

例えば、パターン２では、空圧機１００が停止しているにも関わらず異常が生じているため、空圧機１００以外の外的な要因に起因した異常であると推定できる。パターン３では、回転機１０２から見て負荷となる空気槽１０６の影響が無い状態で異常が発生しているため、回転機１０２のみを原因とする異常であると推定でき、例えば軸受けの劣化が考えられる。パターン４では、負荷を原因とする異常であると想定でき、例えば工場内の圧縮空気使用量が一時的に大きくなり、過剰負荷となったことが考えられる。このように、運転パターンを区別して異常判定することにより、細やかに装置の状態を監視することができる。

処理Ｓ４０５では、推定された異常原因は、出力装置３０４からネットワーク３１０を介して、中央演算部３２０へ送信される。中央演算部３２０は、端末３３０に異常原因を表示させる。

センサデータは、従来では一つのデータとして格納されていたが、図５に示したように、本実施例では運転モード別にデータを格納し、其々について異常を判定する。従来では異常時のデータの組み合わせとして、正常・異常の２パターンしか得られないため、異常原因の特定は困難であった。本実施例では８パターンが得られるため、異常の組み合わせから、異常原因の高精度な推定が可能となる。

また、組み合わせだけではなく、時系列上でパターンの遷移を辿ることで、さらに多くの情報を得ることもできる。例えば、パターン４からパターン６と遷移した場合、「連続的に過剰負荷をかけた結果、モーターに損傷が生じた」などといった解釈が可能となる。このためには、図６（Ｂ）に示すように、異常原因推定テーブル３０１２の一部として、パターンの遷移に対応する異常原因を予め登録しておく。これは、図３の処理に先立って、管理者が経験、実験、あるいはシミュレーションに基づいて作成して格納しておくものとする。一方、記憶装置３０１にはパターンの遷移を履歴データとして残しておき、定期的あるいは任意の時点に異常原因推定テーブル３０１２と照合し、データの分析を行なえばよい。

＜５．運転モードの判定＞
処理Ｓ４０２における、異常判定部３０５の運転モードの判定方法について説明する。空圧機等の診断対象では、監視機能が予め搭載されていることもあるが、センサを後付けする場合も考えられる。そのため、後付のセンサでも運転モードを識別できる構成が望まれる。

第１の構成例は、診断対象の装置から装置の制御情報を取得する構成である。例えば、診断対象の装置が予め備える、制御信号を出力するインターフェースを利用し、制御信号を取得して運転モードを判定する。この方法は、インターフェースが利用可能であれば、正確で演算処理不要、かつリアルタイム性に優れた理想的な方法である。しかし、レガシー装置では制御信号を出力しないこともあり、実現性は診断対象の装置に依存する。

また、制御盤に制御情報が表示される装置については、別途カメラを設置して診断対象の装置の画像を取得し、画像認識して運転モードを判定することも考えられる。制御盤に制御情報が表示されていればレガシー装置にも適用できるが、ハードウェアとソフトウェアの追加が必要であり、コスト面の課題がある。

第２の構成例は、センサを冗長化する構成である。例えば空圧機では、電気系統に電流センサを配置し、空気系統に気圧センサを配置し、これらからのセンサデータの組み合わせで運転モードを判定する。運転モードの判定のためには、各センサから得られるセンサデータの演算処理が必要であり、そのための閾値の設定等が必要である。このためコスト要因となるが、適切な設定が行なえれば正確な運転モード判定が期待できる。

第３の構成例は、センサデータの実効値や平均値を用いて閾値判定を行なう構成である。センサを後付けした場合において、他のセンサを必要とせず、ハードウェアの追加を避けることができるため、他の構成例と比べて最もコスト面に優れている。ただし、演算処理と学習による閾値の設定が必要である。

＜５．運転モード判定の詳細説明＞
以下、上記第３の構成例の具体的構成例について詳述する。図５で示した異常判定部３０５の構成は、第３の構成例に対応する。この例では、後付した単一センサのデータを用いて動作モードの判定をする。運転モードの判定は、異常判定部３０５により、運用フェーズと学習フェーズの２つに分かれて行なわれる。モード判定部３０５２により実行される運用フェーズでは、計算コストの小さい閾値判定でモードを判定する。そのため、まず学習部３０５１により実行される学習フェーズで最適な閾値を決定する。

図７は学習フェーズの動作を示すフロー図である。この機能は、学習部３０５１として実装される。学習フェーズでは、あるデータに対してクラスタリング判定と閾値判定を行い、クラスタリング判定が正答として両者の結果を比較し、閾値を設定する。

処理Ｓ７０１では、所定期間にわたって取得したセンサデータを学習の処理対象データとする。処理対象データとしては、例えば１分間の時系列のセンサデータを用意し、このデータを１秒間×６０個のデータに分割する。

処理Ｓ７０２では、想定されるモード数を取得する。モード数は予め分かっている場合は規定値でもよいが、入力装置３０２から利用者が入力しても良い。ロード・アンロード方式の空圧機の場合は、モード数３を入力する。

一般的なクラスタリングの解析では、解析精度を高めるために、同じデータに対して様々なクラスタ数で計算を行い、クラスタ分割の精度を確認し、最適なクラスタ数を調整する必要がある。本実施例では、入力データとして「クラスタ数（＝運転モード数）」を利用者が入力可能とするインターフェースを導入する（後述）。診断対象である機械装置を理解している利用者のＯＴ（オペレーショナル・テクノロジー）を利用可能とすることで、最適なモード数を選択でき、高精度の診断を可能とすることができる。

処理Ｓ７０３では、処理対象データに対してクラスタリングを実行し、モードを判定する。この際、必要に応じて処理対象データに対して、標準化、主成分分析、次元削減等の処理を行なう。これらはデータ解析の手法としては公知なので、詳細は省略する。クラスタリングの手法も公知の種々の手法を適用できる。振動センサで取得したデータであれば、例えば、時間波形とスペクトルから特徴量を抽出し、標準化と主成分分析を行った後、k−means法を用いてクラスタを判定することができる。このときのクラスタリング判定の前提として、処理Ｓ７０１で得たモード数を用いる。単純な例では、主成分に対応するものとして実効値と特定の周波数成分が想定できる。

クラスタリング判定の結果、「６０個の点（データ）がどのクラスタに所属しているか」の情報が得られる。また「３つのクラスタの中心点」「３つのクラスタの半径」の情報も推定できる。本実施例では、公知のk−means法によるクラスタリングを想定している。k−means法によるクラスタリングでは一般に、判定精度を向上するために、まず最適なクラスタ数を決定する必要がある。すなわち、様々なクラスタ数を入力して計算をやり直し、判定結果から判定精度を評価し、最適なクラスタ数を選択するプロセスを行う。このプロセスは人による判断が必要となるため、自動化が難しく、実現にあたりコストが大きい。一方で本実施例では、上述したように、予め運転モード数を最適なクラスタ数として入力することができるので、最適なクラスタ数を決定するプロセスが不要となる。このため、実現のためのコストを抑えて、精度の高い判定が可能となる。

次に、各モードを識別するための閾値を設定する。閾値はモードごとにあるので、モード数ｎ回処理を行なう（Ｓ７０４）。

処理Ｓ７０５では、モードについて閾値の初期値Ａｎを設定する。値は任意でよいが、例えばいくつかの正答が含まれるであろう値を設定しておき、徐々に拡大または縮小させるようにする。

処理Ｓ７０６では、処理Ｓ７０５で設定した閾値を用いて、入力されたデータを判別する。

処理Ｓ７０７では、各データについて、処理Ｓ７０３でクラスタリングで判別したモードと、処理Ｓ７０６で閾値で判別したモードとの一致不一致を判定し、正答率を計算する。

図８に、モードを識別するための閾値を設定する処理の概念を示す。２つの主成分で規定される平面上に、例えば６０個のデータがプロットされている。四角、丸および星型で表示される各データは、クラスタリング判定の結果判別されたデータのモードである。処理Ｓ７０６では、閾値を用いて入力されたデータを判別する。

例としてクラスタ２に対して、閾値Ａ２を適用する場合を考える。図８の２次元空間上で、閾値の初期値Ａ２を設定（処理Ｓ７０５）、閾値判定（処理Ｓ７０６）、正答率計算（処理Ｓ７０７）、正答率評価（処理Ｓ７０８）を行いながら、徐々に閾値を変化させる（処理Ｓ７０９）。

図８（A）は閾値Ａ２が初期値である場合を想定している。閾値Ａ２の初期値は、中心座標をクラスタ２のデータの幾何学的重心とした半径で定義される。図８（A）では、点線の円で示される閾値A２内のデータは全てクラスタ２であるため、正答率計算Ｓ７０７による正答率は１００％である。この場合は、正答率評価Ｓ７０８による正答率評価結果はＮＧとして、処理Ｓ７０９で閾値Ａ２を更新する。この場合には、閾値Ａ２を所定数増加させる。

図８（B）は閾値Ａ２を何回か所定数増加させた結果であり、正答率は１００％である（Ｓ７０７）。この状態が閾値の最適値であるが、最適値を最終的に判定するために、正答率評価結果はＮＧとして（Ｓ７０８）、さらに閾値Ａ２を所定数増加させる（Ｓ７０９）。

図８（C）は閾値Ａ２をさらに所定数増加させた結果であり、クラスタＡ３のデータが含まれるため、正答率が１００％を下回る。

学習部３０５１は学習フェーズの正答率評価処理Ｓ７０８において、正答率が１００％である状態では正答率評価をＮＧとして、閾値Ａｎを増加方向に更新させる。しかし、正答率が１００％を下回った場合、閾値Ａｎを減少方向に更新させる。そして、次に正答率が１００％になった時点の閾値Ａｎを最適閾値として設定する。この結果、図８（B）に示す閾値Ａ２が最適閾値となる。

上記の説明では、閾値を増加から減少に遷移させているが、逆に減少から増加に遷移させる方法でも、同様に最適閾値を設定することができる。なお、上記の例では、中心座標は不動として閾値の半径を調整しているが、同様にして中心座標を調整することもできる。

以上のようにして、学習部３０５１は、３つのモードに対する閾値（中心座標および半径）を設定することができる。求められた閾値は、適宜更新を行い最適値を維持するものとする。

図９は運用フェーズの動作を示すフロー図である。この機能は、モード判定部３０５２として実装される。運用フェーズでは、学習フェーズで定めた閾値を用いて、データのモードを判別する。

処理Ｓ９０１では、所定期間にわたって取得したセンサデータを処理対象データとする。処理対象データとしては、例えば１分間の時系列のセンサデータを用意し、このデータを１秒間×６０個のデータに分割する。

処理Ｓ９０２では、学習フェーズで定めた閾値を用いて、データのモードを判別する。図９では省略しているが、判別はモードごとに並列的あるいは直列的に行なわれる。

処理Ｓ９０３では、データのモードを判定する。すなわち図８で概念を説明したように、点線の丸で示される閾値内に存在するデータを例えば３つのモードに分類する。

処理Ｓ９０４では、図５に示したように、分類されたデータをモードごとに記憶装置３０１に格納する。このとき、時間情報をデータに対応付けて格納するものとする。

図１０は、実施例の診断システムの運転スケジュールの例を示す概念図である。運転時区分１００１に示すように、本実施例では、空圧機１００は基本的に通常運転状態である。運転モード１００２は、上述したように、空圧機１００では、停止、アンロード、ロードの３つがあり、これらは任意のタイミングで切り替えることができる。

フェーズ１００３には、図７で示す学習フェーズと、図９で示す運用フェーズが含まれる。図７で示した学習フェーズは、任意のタイミングで行なうことができるが、基本的に正常動作していることが前提である。この意味から、例えば振動センサ１０８を設置した際に、別途正常動作を確認したうえで手動で学習部３０５１を起動して学習フェーズに入り、閾値を学習させることが考えられる。図１０に示すように、学習のためには、３つの運転モード全てをカバーできるだけの学習時間が必要である。

一度設定した閾値は、空圧機１００の経時的変化により変化する可能性がある。このため、定期的に学習フェーズを行ない、閾値算出を行って閾値を更新することが考えられる。ただし、学習フェーズにおいて、空圧機１００が正常動作していることが保証されない場合には、経時変化による閾値の微量なシフトは反映して閾値を更新するが、閾値の変動量が所定値を超える場合には、更新しない、あるいはエラー信号を発生するなどの構成が考えられる。

処理動作１００４に示すように、学習フェーズにおいては閾値算出と閾値更新が行なわれる。また、運用フェーズにおいては、図９に示したように、モード判定部３０５２による運転モードの判定と、異常検出部３０５３による異常検出が行なわれる。

実施例１では単一の振動センサ１０８を使用したが、複数のセンサを用いても、同様の方式が適用可能である。すなわち、１台の空圧機に含まれる単一ないし複数の圧縮機回転機構（以下、回転機）をそれぞれ別のセンサで測定し、各センサごとにデータを格納する。回転機として、例えば、スクリュー圧縮機や、スクロール圧縮機や、レシプロ圧縮機がある。

図１１に、モーター１０２ａと、一段側スクリュー１０２ｂと、二段側スクリュー１０２ｃで構成された空圧機１００の例を示す。図１１に示すように、モーター１０２ａにセンサ１０８ａ、一段側スクリュー１０２ｂにセンサ１０８ｂ、二段側スクリュー１０２ｃにセンサ１０８ｃが設置され、其々がセンサデータを出力する。

図１２に示すように、各センサデータは、実施例１で説明したのと同様な方法により、それぞれモードが判別されて、記憶装置３０１にセンサデータデータベース３０１１として格納される。

図１３に示すように、この場合に異常原因推定テーブル３０１２に格納される異常データ組み合わせ表は、8³=512パターンとなり、より詳細に異常原因の推定が可能である。

空圧機は複数台の台数制御で運用するシステムが一般的である。そこで、台数制御の状態を運転モードとして扱っても、実施例１と同様の考え方が適用可能である。

図１４は、複数台の台数制御で運用するシステムの構成例を示す図である。例えば、一定速のベースロード機２台（１００−１，１００−２）と、可変速の負荷吸収機２台（１００−３，１００−４）による台数制御で、負荷吸収機１００−３をセンサで測定するとき、同時に可動しているベースロード機（１００−１，１００−２）および負荷吸収機１００−４の台数を運転モード数として入力すると、異常データの組み合わせは2⁴=16通りとなる。

図１５に、この場合の異常原因推定テーブル３０１２に格納される異常データ組み合わせ表を示す。より詳細に異常原因の推定が可能である。

この構成では、同時に可動しているベースロード機（１００−１，１００−２）および負荷吸収機１００−４の台数によって負荷の大きさが変化する。例えば、３号機１００−３だけを稼動している場合と、１号機１００−１と３号機１００−３を同時に稼動している場合では、３号機１００−３に設けたセンサのデータは異なると考えられる。また、振動センサの場合には、１号機１００−１から生じた振動が配管や地面等を伝わり、３号機１００−３の振動センサに影響を及ぼすことが考えられる。従って、これらの状況を区別して異常判定を行なうことで、精度の高い判定が可能となる。

以上の実施例では空圧機を例に説明したが、その他の装置の状態検出にも適用可能である。切削加工機の異常監視の場合の実施例を説明する。切削加工機は切削工具を用いてワークを切削または研削する装置であり、例えば、ボール盤や、フライス盤や、マシニングセンタや、NC(Numerically Control: 数値制御)旋盤がある。

図１６に切削工具としてドリル１６１を備えた切削加工機の一例を示す。ドリル１６１はドリル保持部１６２により保持される。ドリル保持部１６２がドリル１６１を回転させ、ドリル保持部１６２が下降することでドリル１６１とワーク１６３が接触し、穴あけ加工を行う。切削加工機の異常を監視するために、ドリル保持部１６２に振動センサ１０８ｖを取り付ける。また、穴あけ加工の加工状態を監視するために、ワーク１６３に振動センサ１０８iを取り付ける。

この装置には主に４つの運転モードがある。まず、ドリル１６１が停止している停止モードがある。次に、ドリル１６１は回転するがワーク１６３の切削を行っていない空転モードがある。その後、ドリル１６１が下降し、ワーク１６３に穴を空ける穴あけ切削モードがある。最後に、ワーク１６３を削りながらドリル保持部１６２が移動し、ワーク１６３を線状に切削する線切削モードがある。センサ１０８から得たセンサデータを実施例１と同様のシステム構成により処理することで、これらの運転モードを区別し、切削加工機の状態を正確に判定することができる。

半導体製造装置の異常監視を行なう実施例を説明する。半導体製造装置は真空チャンバを備えるものが一般的で、例えば、金属蒸着装置や、スパッタ装置や、プラズマＣＶＤ（Chemical Vapor Deposition: 化学蒸着）装置や、ＩＣＰ（Inductively Coupled Plasma: 誘導結合プラズマ）エッチング装置や、ＲＩＥ（Reactive Ion Etching: 反応性イオンエッチング）装置や、アッシング装置や、電子線描画装置や、ＦＩＢ（Focused Ion Beam: 集束イオンビーム）装置がある。また、半導体検査装置も同様に真空チャンバを備えるものがあり、例えば、ＳＥＭ（Scanning Electron Microscope: 走査型電子顕微鏡）や、ＴＥＭ（Transmission Electron Microscope: 透過型電子顕微鏡）がある。基本的な構成の差異はあるが、半導体製造装置として同様に適用することができる。

図１７に粗引き用ポンプと本引き用ポンプを備えた半導体製造装置の構成の一例を示す。粗引き用のスクロールポンプ１７１と、本引き用のターボ分子ポンプ１７２は、それぞれ図のように粗引き弁１７３と本引き弁１７４を通して真空チャンバ１７５と接続している。ターボ分子ポンプ１７２の背圧を下げるために、スクロールポンプ１７１は背圧弁１７６を通してターボ分子ポンプ１７２と接続している。この装置の異常を監視するために、スクロールポンプ１７１に振動センサ１０８ｖと電流センサ１０８ｉを、真空チャンバ１７５に圧力センサ１０８ｐを取り付ける。

この装置には５つの運転モードがある。まず、スクロールポンプ１７１とターボ分子ポンプ１７２が停止している停止モードがある。次に、スクロールポンプ１７１が稼動し、粗引き弁１７３が開き、真空チャンバ１７５内の圧力を大気圧から真空圧まで下げる粗引きモードがある。その後、粗引き弁１７３を閉め、背圧弁１７６を空け、ターボ分子ポンプ１７２が稼動する、空転モードがある。次に、本引き弁１７４を開け、真空チャンバ１７５内の圧力を真空圧から超高真空圧まで下げる、本引きモードがある。最後に、真空チャンバ１７５内で半導体加工を行う加工モードがある。加工モードでは、図示していない装置の要素が稼動する。例えばＲＩＥ装置では、真空チャンバ１７５内に反応性ガスが注入される。センサ１０８から得たセンサデータを実施例１と同様のシステム構成により処理することで、これらの運転モードを区別し、半導体製造装置の状態を正確に判定することができる。

実施例１〜５を用いて、工場の装置監視員（以下、ユーザー）が装置を監視する場合の、監視状況を表示するインターフェースの実施例を示す。ユーザーは、図３に示した端末３３０に表示される工場監視状況モニタを通して、装置等の状況を把握することができる。モニタは具体的にはパーソナルコンピュータのディスプレイやタブレット端末のディスプレイに表示される。表示される情報は、エッジ演算部３００から中央演算部３２０を経て、端末３３０に送られる。

図１８は、端末３３０に表示される工場監視状況モニタの一例である。工場監視状況モニタ１８１は、各装置の運転モード数を設定する運転モード数入力欄１８２を備えており、ユーザーは運転モード数を設定できる。ここで入力したモード数は、図７の処理Ｓ７０２で取得される。

モニタ１８１は、装置の状態を運転モードごとに表示する装置状況表示ウィンドウ１８３を一個または複数個備える。各運転モードにおける異常判定は、図４の処理Ｓ４０３で実行され、結果が端末３３０に送られる。各運転モードで異常が発生したときに、該当するモードの異常ランプ１８４が点灯することで、ユーザーは装置の異常を知ることができる。

保守提案ウィンドウ１８５では、想定される異常原因に応じて最適な保守方法を表示する。想定される異常原因は、図４の処理Ｓ４０４で推定され、推定結果が端末３３０に送られる。保守ボタン１８６を押下すると、任意のネットワークを経由して、保守会社に見積り依頼メールが送信される。

実施例１〜５を用いて、保守会社の装置監視員（以下、ベンダー）が各工場の装置を監視し、保守状況を表示するインターフェースの実施例を示す。ベンダーは一つまたは複数の工場を同時に監視しており、装置状況に応じてタイムリーな修理（またはメンテナンス）をユーザーに提供することができる。ハードウェア、ソフトウェア構成は実施例６と同様である。

図１９は、端末３３０に表示される保守管理モニタの一例である。ベンダーは、図３に示した端末３３０に表示される保守管理モニタ１９１を通して装置状況と保守状況を把握することができる。装置状況ウィンドウ１９２には装置の異常状況と想定原因が表示される。想定される異常原因は、図４の処理Ｓ４０４で推定され、推定結果が端末３３０に送られる。

保守状況ウィンドウ１９３には、修理提案状況が表示される。ベンダーがメールや電話やFAXや郵送のボタンを押下すると、各連絡手段を用いてユーザーに修理提案の連絡が送信される。また、保守状況ウィンドウには担当保守員の氏名と、担当保守員のスケジュールが表示される。ベンダーは、保守員のスケジュールを確認した上で、ユーザーに修理提案の連絡ができるため、修理日程の迅速な決定が可能となる。また、保守状況ウィンドウには修理部材の在庫個数が表示される。ベンダーが発注ボタン１９４を押下すると、各部材メーカーに発注情報が送信される。ベンダーは、装置状況を確認した上で修理に必要な部材の在庫管理ができるため、在庫管理の効率を向上する。例えば、装置故障の発生を検出したとき、あらかじめ必要な部材の在庫を確保しておくことで、修理の納期を短縮することができる。また、発生頻度の低い故障（例えば１０年に１度の頻度で発生する故障）に対して必要な部材は、在庫を少なく所持しておくことで、保守会社の所持資産を軽減することができ、ＲＯＥ（株主資本利益率）の向上に繋がる。

以上詳細に説明したように、運転モードを区別しないで分析を実施すると、状態が大きく異なるデータを比較するため、分析精度が悪化していた。例えば主成分分析とクラスタ分析を用いる場合、大きく異なるデータをまとめて標準化するため、各成分の分解能が低下していた。また、異常データを別クラスタの正常データとして誤判定する懸念があった。

本実施例の構成を用い、運転モードを区別して異常判定を行うことで、分析精度が向上する。特に、通常運転時のセンサデータを用いて診断を行うことができるため、運転を止めずに診断が可能である。すなわち、診断運転期間を特に設ける必要が無いため、設備の稼働率の低下を防止することができる。また、運転モードごとのデータの組み合わせから、異常原因の推定を精緻に行なうことが可能である。また、センサデータから運転モードの特定と異常判定の両方を行う場合には、運転モード特定用に追加センサを導入する必要が無い。このため、導入コストが軽減される。また、監視画面等の入出力インターフェース画面において、運転モードごとに正常・異常の状態を表示するインジケーターがあることにより、使用者が得られる情報量が増える。

さらに、実施例に記載したように、診断対象である機械装置に設けた検出素子からの信号に基づき機械装置の異常を検出する際に、機械装置の運転モード数を入力する運転モード数入力部と、検出素子の信号に基づき、運転モードを特定するための閾値を算出する運転モード閾値算出部と、検出素子の信号に基づき、閾値を用いて機機械装置の運転モードを特定する運転モード特定部と、を備えるシステムを用いる。この構成では、閾値との比較により、軽い処理によって運転モードを判定することができる。また、閾値の学習の際にリファレンスとなる分類を行なうアルゴリズムの実行に際しては、運転モード数（例：停止・アンロード・ロードの３種類)を入力可能とすることにより、ＯＴを活用して運転モードの判別精度を上げることができる。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

３０５：異常判定部
３０６：異常原因検出部
３０１１：センサデータデータベース
３０１２：異常原因推定テーブル
３０５１：学習部
３０５２：モード判定部
３０５３：異常検出部

Claims (13)

1. 診断対象に設けた検出素子からの検出信号に基づき、前記診断対象の異常を検出する異常検出システムであって、
   通常運転時における前記検出素子からの検出信号に基づき、前記診断対象の第１の運転モード時および第２の運転モード時における異常の有無を判定する異常判定部と、
   前記異常判定部で判定した前記第１の運転モードおよび前記第２の運転モードの異常の有無の組み合わせに基づき、前記診断対象の異常の原因を判断して検出する異常原因検出部と、
   を備え、
   前記異常判定部は、
   前記検出信号に基づき、運転モードを判定するための閾値を学習する学習部と、
   前記検出信号に基づき、前記閾値を用いて前記診断対象の運転モードを判定し、前記運転モードごとに前記検出信号を分類するモード判定部と、
   分類された前記検出信号ごとに、前記診断対象の異常を検出する異常検出部と、を備えることを特徴とする異常検出システム。
2. 請求項１に記載の異常検出システムであって、
   前記診断対象は、第１の要素装置と第２の要素装置で構成されており、
   前記第１の運転モードおよび前記第２の運転モードは、前記第１の要素装置と第２の要素装置の稼動状態の組み合わせに依存するモードであることを特徴とする、異常検出システム。
3. 請求項１に記載の異常検出システムであって、
   前記検出素子からの検出信号は、前記診断対象の前記運転モードに因らずに生じる外的要因によって変化し、
   前記異常原因検出部は、前記第１の運転モード時および前記第２の運転モード時の異常の有無の組み合わせに基づき、前記診断対象の異常か前記外的要因に起因する異常かを判断することを特徴とする、異常検出システム。
4. 請求項１に記載の異常検出システムであって、
   前記検出素子は、複数設けられ、
   前記異常判定部は、各検出素子毎に各運転モード時に検出する検出信号に基づき異常の有無を判定し、
   前記異常原因検出部は、各運転モードで各検出素子から検出した異常の有無の生み合わせに基づき、前記診断対象の異常の原因を判断して検出することを特徴とする、異常検出システム。
5. 請求項１に記載の異常検出システムであって、
   前記第１の運転モードおよび前記第２の運転モードの異常の有無の組み合わせに対して、想定される異常原因を格納した異常原因推定テーブルを格納した記憶装置を備え、
   前記異常原因検出部は、前記異常原因推定テーブルを参照して異常の原因を判断して検出することを特徴とする、異常検出システム。
6. 請求項１に記載の異常検出システムであって、
   前記学習部は、
   第１のアルゴリズムを用いて前記検出信号に基づき、運転モードを判定し、当該判定結果を用いて前記閾値を学習し、
   前記異常検出部は、
   前記第１のアルゴリズムとは異なる第２のアルゴリズムを用いて、前記診断対象の異常を検出することを特徴とする、異常検出システム。
7. 請求項６に記載の異常検出システムであって、
   前記第１のアルゴリズムは、k-means法によるクラスタリングであり、
   前記診断対象の運転モード数を外部から入力する入力装置を備えることを特徴とする、
   異常検出システム。
8. 記憶装置、入力装置、処理装置、出力装置を備えた情報処理装置を用い、診断対象の異常を検出する異常検出方法であって、
   前記入力装置が、前記診断対象の状態を検出する検出素子からのセンサデータを取得し、
   前記処理装置が、前記センサデータを前記診断対象の運転モード毎に分類する分類処理と、分類した前記運転モード毎に異常検出を行なう異常検出処理を行ない、
   前記分類処理では、
   第１のアルゴリズムを用いて前記センサデータを前記診断対象の運転モード毎に分類し、分類結果に基づいて運転モード毎に閾値を学習する学習処理と、
   学習した前記閾値により前記センサデータを運転モード毎に判定するモード判定処理と、を行なう、
   異常検出方法。
9. 前記学習処理では、
   前記第１のアルゴリズムとしてk-means法を用い、前記k-means法を実行する際に、前記入力装置から運転モード数を入力可能とし、前記センサデータを前記運転モード数にクラスタリングする、
   請求項８記載の異常検出方法。
10. 前記記憶装置に、前記運転モード毎の異常の有無の組み合わせに対して、想定される異常原因を格納した異常原因推定テーブルを格納しておき、
    前記異常検出処理では、
    前記運転モード毎に異常検出を行ない、異常検出の結果を前記異常原因推定テーブルに当てはめ、該当する前記異常原因を前記出力装置から出力する、
    請求項８記載の異常検出方法。
11. 前記異常原因推定テーブルは、さらに、前記運転モード毎の異常の有無の組み合わせの遷移パターンに対して、想定される異常原因を格納する、
    請求項１０記載の異常検出方法。
12. 前記異常検出処理では、前記第１のアルゴリズムとは異なる第２のアルゴリズムを用いて、前記運転モード毎に異常検出を行なう、
    請求項８記載の異常検出方法。
13. 前記異常検出処理では、前記運転モード毎に異なるアルゴリズムあるいは特徴量を用いて異常検出を行なう、
    請求項１２記載の異常検出方法。

Images