JP2021028751A - 故障予兆診断システムおよび方法 - Google Patents

Abstract

【課題】機器を良く知るエンジニアの知識を分析フローに反映することで、高精度な故障予兆診断システムを提供する【解決手段】エンジニアの入力した重要なセンサの組み合わせを蓄積するデータ蓄積部２と、センサデータの関連性を計算するセンサ関連性計算部３と、センサデータの関連性と重要センサの組み合わせを使って、センサグループ候補を作成するセンサグループ候補作成部５と、エンジニアに候補を提示し選択を促すエンジニア向けＩ／Ｆ部８と、作成したセンサグループ候補を使って、故障予兆診断のための学習と診断を実行する学習部６と診断部７で構成される故障予兆診断システム１。【選択図】図１

Description

本発明は、対象機器の故障を予兆する技術に関する。なお、故障には、異常、不具合等が含まれる。

発電用ガスタービンなど、社会インフラ向け機械は、１日２４時間稼働することが要求されている。機械の高い稼働率を維持するためには、その計画外停止を防がねばならない。そのためには、従来の機械の稼働時間に基づいた定期保守から、機械の状態に基づいて予防保全を適切に行う状態監視保守への移行が必要である。状態監視保守を実現するためには、機械に設けられた各種センサを介して収集されるセンサデータを分析し、機械の異常や故障の予兆を診断する故障予兆診断システムの役割が重要となる。

このセンサデータを使った分析には、データの分析手順を記述した分析フローを使用する。分析フローは、データ準備、前処理、モデリング、評価の順にデータを処理する。

データ準備とは、稼動データの欠損値およびの異常値を削除するなどの処理である。

前処理とは、センサ選択、状態抽出で構成される。センサ選択とは、対象機器の故障モードをとらえるセンサグループを抽出する処理である。また状態抽出とは、機器の診断対象となる状態を抽出する処理である。

モデリングとは、機械学習を使用して、機器の正常状態をモデリングする処理である。

評価とは、準備した評価用のデータを使って、モデリングの妥当性を評価する処理である。

特許文献１には、障害の予兆を検出し、発生場所の特定が可能な運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラムとして、「システムを構成する複数の被管理装置から複数種の性能種目毎の性能情報を取得して、前記被管理装置を運用管理する運用管理装置であって、前記性能種目又は前記被管理装置を要素とした場合に、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを前記各要素間の組み合わせについて求める相関モデル生成部と、前記被管理装置から新たに検出し取得される前記性能情報に基づいて、前記相関モデルの変化を分析する相関変化分析部と、を含む」発明が記載されている。

特開2009-199533号公報

特許文献１に記載の技術は、蓄積したデータを使って障害の予兆を検知する手法が記載されている。このようなデータドリブンな手法は、蓄積したデータの品質に予兆診断の精度が左右されてしまう。このため、故障予兆の精度は限定的である。そこで、本発明の目的は、より故障予兆の精度を高めることにある。

上記課題を解決するために、本発明では、機器を良く知るエンジニアの機器のセンサに関する知識を、対話的・双方向的に分析フローに反映する。すなわち、エンジニアから入力されるセンサの重要度を示す指標とセンサ間の関連性を用いて、センサグループ候補を作成し、作成されたセンサグループ候補に対するエンジニアからの選択に従いセンサグループを特定し、特定されたセンサグループを用いて故障予兆診断のための学習と診断を実行する。重要度を示す指標には、重要センサの指定やその組み合わせが含まれる。また、重要センサとは、エンジニアを含むユーザーの選択を受けたセンサである。

さらに、機器の運転モードをセンサ間の関連性を用いて時系列方向への分類した結果である複数パターンを運転モード候補として生成し、これに対するエンジニアからの選択を受け付けることも本発明に含まれる。この場合、選択された運転モード候補と特定されたセンサグループを用いて故障予兆診断のための学習と診断を実行するとより好適である。

なお、上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明によれば、エンジニアが有する知識を活かした故障予兆の精度向上を図ることが可能になる。

本発明の一実施例において、予兆診断システム、エンジニア、保守員の関係と、予兆診断システムの詳細を示す概念図である。 本発明の一実施例において、データ蓄積部２のセンサデータ２１の例を示す図である。 本発明の一実施例において、センサ関連性計算部３の処理フローを示す図である。 本発明の一実施例において、データ蓄積部２のセンサ関連性計算結果２２の例を示す図である。 本発明の一実施例において、運転モード抽出部４の処理フローを示す図である。 本発明の一実施例において、運転モード抽出部４の概要を示す図である。 本発明の一実施例において、データ蓄積部２の運転モード抽出候補２４の例を示す図である。 本発明の一実施例において、エンジニアＩ／Ｆ部８の運転モード抽出候補の選択画面の例を示す図である。 本発明の一実施例において、データ蓄積部２の運転モード抽出結果２５の例を示す図である。 本発明の一実施例において、センサグループ候補作成部５の処理フローを示す図である。 本発明の一実施例において、データ蓄積部２のエンジニア知識２６の例を示す図である。 本発明の一実施例において、スペクトラルクラスタリングの例を示す図である。 本発明の一実施例において、データ蓄積部２のセンサグループ候補２７の例を示す図である。 本発明の一実施例において、エンジニアＩ／Ｆ部８のセンサグループ候補の選択画面の例を示す図である。 本発明の一実施例において、データ蓄積部２のセンサグループ選択結果２８の例を示す図である。 本発明の一実施例において、学習部６の処理フローの例を示す図である。 本発明の一実施例において、診断部７の処理フローの例を示す図である。 本発明の一実施例において、データ蓄積部２の学習結果２９の例を示す図である。 本発明の一実施例において、データ蓄積部２の診断結果３０の例を示す図である。

以下、図１〜図１９を参照して、本発明の一実施例について説明する。

図１は、故障予兆診断システム１、エンジニアＭ１、保守員Ｍ２の関係と、故障予兆診断システム１の詳細を示している。図１は、故障予兆診断システム１と、エンジニアＭ１と、保守員Ｍ２で構成されている。故障予兆診断システム１は、対象機器のデータをデータ蓄積部２で蓄積し、蓄積したデータを使って、故障予兆診断の分析フローを設計する。故障予兆診断システムは、設計フェーズと実行フェーズで構成される。設計フェーズでは、エンジニアＭ１が、故障予兆診断システム１のエンジニアＩ／Ｆ（インターフェース）部８を介して、分析フローを設計する。実行フェーズでは、故障予兆診断システム１は、対象機器の収集データを分析フローに従って処理し、故障の予兆がある場合は、アラーム情報を現場向けＩ／Ｆ部９に出力する。このことにより、アラーム情報が現場向けＩ／Ｆ部９を介して、保守員Ｍ２が確認可能となる。この内容に基づき、保守員Ｍ２は、対象機械の保守を実行する。

図示していない対象機器には、センサやアラームシステムが取り付けられており、そのデータは故障予兆診断システム１のデータ蓄積部２に蓄積する。

エンジニアＭ１は、対象機器に関する知識を有しているものとする。一方、保守員Ｍ２は、現場で作業するワーカー以外にも、遠隔でアセットオーナーまたは作業員に指示を出すコールセンターワーカーでもよい。エンジニアＭ１と保守員Ｍ２は、複数人いることもある。
（故障予兆診断システム１の詳細説明）
故障予兆診断システム１は、表示装置、操作卓、制御コンピュータ、パーソナルコンピュータやワークステーションなどによって構成され、有線または無線の通信システムを介して、対象機器に接続されている。

図１は、故障予兆診断システム１の機能的な構成を示すブロック図を示している。図１に示すように、データ蓄積部２、センサ関連性計算部３、運転モード抽出部４、センサグループ候補作成部５、学習部６、診断部７、エンジニアＩ／Ｆ部８、現場向けＩ／Ｆ部９を備える。ここで、センサ関連性計算部３、運転モード抽出部４、センサグループ候補作成部５、学習部６、診断部７のそれぞれの機能は、コンピュータの演算装置（ＣＰＵ）が所定のプログラムを実行することで実現される。

なお、本実施例は、特定のアセット・機器、診断技術、分析技術に限定されるものではないが、事例として発電プラントの診断を例として、以降の説明を行う。
（データ蓄積部２の説明）
データ蓄積部２は、故障予兆診断システム１が扱うデータを蓄積する。具体的には、対象アセットのセンサデータ２１、センサ関連性計算結果２２、センサリスト２３、運転モード抽出候補２４、運転モード抽出結果２５、エンジニア知識２６、センサグループ候補２７、センサグループ選択結果２８、学習結果２９、診断結果３０を格納している。以下、各機能の説明にて、データ蓄積部２の詳細も説明する。

図２は、データ蓄積部２のセンサデータ２１の例である。センサデータ２１は、機器にセンサデータを格納している。具体的には機器の識別ＩＤおよびセンサ毎のタイムスタンプとセンサデータの値を格納している。ここでは発電量、温度Ａ、温度Ｂ、温度Ｃ、圧力Ａを記載している。また、センサリストも格納している。このセンサリストは、センサを識別するものであればよく、図２に示すセンサデータの種別の他、センサＩＤを記録してもよい。

センサ関連性計算部３は、蓄積したセンサデータを使って、センサ間の関連性を定量化する。図３は、センサ関連性計算部３の処理フローを示した図である。

初めにステップＳ３０１では、エンジニアＩ／Ｆ部８を介してエンジニアＭ１が入力した窓幅を使って、データ蓄積部２のセンサデータ２１を分類する。例えば窓幅６０分の場合は、センサデータのタイムスタンプを使って、センサデータを６０分単位で分離する。次にステップＳ３０２ｓ及びＳ３０２eでは、データ蓄積部２のセンサデータ２１のセンサリストから1つを選択し、ステップＳ３０３ｓ、Ｓ３０４、Ｓ３０５、Ｓ３０３ｅを実行する。この処理は、センサリストの各センサについて、処理するまで繰り返す(例えば、センサリストの全センサについて繰り返す)。

次に、ステップＳ３０３ｓ及びステップＳ３０３ｅでは、同様にセンサリストの各センサに対して処理するまでステップＳ３０４とＳ３０５を行う(例えば、センサリストの全センサについて繰り返す)。つまり、ステップＳ３０２とステップＳ３０３でセンサの２つの組み合わせについて、センサの関連性を定量化する。

ステップＳ３０４では、ステップＳ３０２で選択したセンサ（以下センサ（ｉ））、ステップＳ３０３で選択したセンサ（以下センサ（ｊ））同士のセンサデータの関連性を計算する。具体的には、センサ（ｉ）とセンサ（ｊ）のデータの相関係数である。また非線形な関係を定量化する指標（例えばMaximal information coefficient）でもよく、１つの方法に限定されるものではない。本実施例では、定量化された関連性は０から１に正規化されているものとする。ここでは１が最も関連性が強く、０は関連性がないことを意味する。

また、相関係数の他、センサ間のセンサデータの散布図を作成し、散布図におけるセンサデータの密集具合を定量化して関連性としてもよい。

ステップＳ３０５では、ステップＳ３０４の結果を、データ蓄積部２のセンサ関連性計算結果２２に格納する。図４は、データ蓄積部２のセンサ関連性計算結果２２の例である。センサ関連性計算結果２２は、機器ＩＤ、関連性を計算したときのデータの開始時刻、終了時刻、窓幅および関連性計算結果テーブルを含んでいる。関連性計算結果テーブルは、センサリストの順番に並べられているセンサ数×センサ数の行列である。さらに関連性の計算結果は、センサの順番に依存しない。つまり（ｉ,ｊ）と（ｊ,ｉ）の関連性の計算経過は同じである。このため行列は対象行列となる。

運転モード抽出部４は、センサ関連性計算部３の結果を使って、機器の運転モードを時系列方向に分類する。この分類により、運転モードのパターンを複数生成する(複数パターンを生成する)。次に、エンジニアＩ／Ｆ部８は、生成された複数パターンを運転モード抽出の候補として表示する。このことで、候補をエンジニアＭ１に提示することになる。図５は、運転モード抽出部４の処理フローである。まず、ステップＳ４０１では、対象のセンサデータと関連性計算結果を読み込む。具体的には、センサデータはデータ蓄積部２のセンサデータ２１から、関連性計算結果は、データ蓄積部２のセンサ関連性計算結果２２から読み込む。ステップＳ４０２ｓからＳ４０２ｅでは、あらかじめ設定した運転モード抽出のパラメータの各組み合わせについて、ステップＳ４０３，Ｓ４０４の処理を繰り返し実行する。なお、組み合わせについては、全ての組み合わせとしてもよい。ここでのパラメータとは、ステップＳ４０３のクラスタリングアルゴリズムのパラメータである。例えば、クラスタリングアルゴリズムとして、Ｋ平均法を採用する場合は、クラスタ数がそのパラメータになる。ステップＳ４０３では、読み込んだデータをクラスタリングする。具体的には、各ウィンドウの関連性計算結果を類似性のあるもの同士でまとめる。ここで、類似性があるものとは、一定の基準を満たせばよく、例えば、所定値以上の類似度を有するもの同士でまとめる。

図６に、運転モード抽出部の概要を示す。図６（ａ）は、センサの時系列データの模式図である。６０分単位で分割している。図６（ｂ）は、各ウィンドウの関連性計算結果を時系列方向に並べたものである。具体的には関連性計算結果テーブルが時系列順に並んでいる。図６（ｃ）は、関連性計算結果テーブルの１つを１サンプルとして、Ｋ平均法で３つのクラスタに分類した結果の例である。図６（ｄ）は、発電量の時系列データにクラスタリング結果をマッピングしたものである。ここでのクラスタＮｏは、１，２，３はクラスタ固有のＩＤである。クラスタリングはデータドリブンなアプローチであるため、その結果を後付けで解釈する必要がある。図６（ｄ）は、クラスタＮｏ（１）は発電量が上昇、クラスタＮｏ（２）は発電量が一定、クラスタＮｏ（３）は発電量が下降を表しているといえる。

ステップＳ４０４は、クラスタリング結果をデータ蓄積部２の運転モード抽出候補２４に書き込む。図７は、データ蓄積部２の運転モード抽出候補２４の例を図示したものである。運転モード抽出候補２４には、機器を識別するＩＤ、元のデータの開始時刻と終了時刻及び窓幅と運転モード抽出候補テーブルが格納されている。運転モード抽出候補テーブルは、窓幅単位の時刻とパラメータ単位でクラスタＮｏが格納されている。

エンジニアＩ／Ｆ部８は、データ蓄積部２のセンサデータ２１と運転モード抽出候補２４を読み込んで表示する。このことで、エンジニアＭ１に候補を提示することになる。これを受け、エンジニアＭ１が、自分の知識に照らし合わせて最も確からしい結果を選択する。選択した結果を、エンジニアＩ／Ｆ部８が受け付け、運転モード抽出結果２５に格納する。図８にエンジニアＩ／Ｆ部８で運転モード抽出候補の表示例を示す。図８では、クラスタ数２から４の結果が表示されている。「センサ切替」のボタンを押すと、表示するセンサを切り替えることできる。エンジニアＭ１から、例えば、最も確からしい運転モード抽出候補の選択の結果である「決定」ボタンの押下を検知すると、その結果がデータ蓄積部２の運転モード抽出結果２５に書き込まれる。表示するセンサの事例列データとクラスタリング結果の重畳表示では、背景に識別できる模様（パターン）を付けたり、色を付けたりする。このことで、事例列データとクラスタリング結果をユーザーに提示することになる。

図９は、データ蓄積部２の運転モード抽出結果２５の例を示しているデータ蓄積部２の運転モード抽出結果２５は、運転モード抽出候補２４と同様に機器を識別するＩＤ、元のデータの開始時刻と終了時刻及び窓幅が格納されている。さらに運転モード抽出をしたエンジニアＭ１の識別ＩＤ及び決定したパラメータ（ここではクラスタ数３）が格納されている。さらに運転モード抽出結果がテーブルで格納されている。

センサグループ候補作成部５は、データ蓄積部２のセンサ関連性計算結果２２を使って、関連性の強いセンサ同士をクラスタリングして、学習部６と診断部７に入力するセンサをグルーピングする。センサグループ候補作成部５の処理フローを図１０に示す。ステップＳ５０１は、データ蓄積部２のセンサ関連性計算結果２２を読み込む。さらにステップＳ５０１では、エンジニアＭ１の知識を反映する。エンジニアＭ１の知識とは、エンジニアＩ／Ｆ部８を介して、エンジニアＭ１が重要なセンサの組み合わせ及び不要な(除外)センサのリストである。具体的には、データ蓄積部２のエンジニア知識２６に格納されている。図１１にデータ蓄積部２のエンジニア知識２６の例を示す。エンジニアＩ／Ｆ部８を介して、エンジニアＭ１が重要なセンサの組み合わせ及び不要なセンサを入力する。つまり、故障予兆診断システム１は、エンジニアＩ／Ｆ部８を介して、エンジニアＭ１からの入力を受け付ける。また、重要なセンサ、不要な(除外)センサとは、エンジニアＭ１から入力されるセンサに関する重要度を示す指標であればよく、重要、不要以外の指標や、リニアな数値を受付けられるようにしてもよい。この場合、非重要センサの指定を受け付け、それ以外を重要センサと判断する構成してもよい。

図１１は、エンジニアＭ１の識別ＩＤと作成日が記載されている。さらにエンジニア知識テーブルが格納されている。エンジニア知識テーブルは、縦軸にセンサ名が並び、横軸に重要なセンサグループおよび除外対象のセンサグループが並んでいる。例えばグループ１は、重要なセンサとして、センサ１、センサ２、センサ３を選択している。具体的には、センサ１、センサ２、センサ３に「１」になっている。また除外センサとは、エンジニアＭ１が不要と判断したセンサである。ここではセンサ４が除外対象とし、「１」としている。

次に、ステップＳ５０２では、エンジニアＭ１の知識を反映する。具体的にはエンジニアＭ１の熟練度に応じて、重みを変えて、データ蓄積部２のセンサ関連性計算結果２２を加工する。熟練度は０から１の数値で記載される情報である。１が最も熟練しているエンジニアとする。この熟練度は、図示しないエンジニア熟練度管理テーブルで定義されている。これを定義するのは、エンジニアグループのリーダーとする。具体的な反映方法は、エンジニアＭ１の熟練度が低い場合は、エンジニアＭ１の入力したセンサリストの反映度合いを低くする。逆に高い場合は、エンジニアＭ１の入力したセンサリストの反映度合いを高くする。データ蓄積部２のセンサ関連性計算結果２２のセンサ（ｉ）とセンサ（ｊ）の関連性計算結果をＳｃｏｒｅ（ｉ，ｊ）とする。aijをエンジニアＭ１の知識反映後の関連性計算結果とする。List1とは，モデリングに適さないセンサのリスト（図１１で除外対象に相当するもの），List2とは一緒に扱うべきセンサのリスト（図１１で重要なセンサとして選ばれたもの）である。

センサがList1に含まれている場合は，隣接行列の要素を0とする。一方，センサがList2に含まれる場合は，隣接行列の要素をαとする。αは，エンジニアの熟練度を表している。

次にステップＳ５０３ｓからＳ５０３eでは、あらかじめ設定したグルーピングのアルゴリズムのパラメータの各組み合わせ(例えば、全組み合わせ)について、ステップＳ５０４とステップＳ５０５を実行する。ステップＳ５０４では、ステップＳ５０２の結果（aij）を使って、クラスタリングのアルゴリズムを使って、センサをグルーピングする。クラスタリングの手法には、例えばスペクトラルクラスタリングがある。この手法は、グラフの隣接行列の固有値問題を解くことで，グラフの連結成分を分解する手法である。グラフの隣接行列は、A=(aij)である。

図１２に、スペクトラルクラスタリングの例を示す。図１２(a)は、隣接行列を図示したものである。各ノードはセンサを表す。センサ間の距離は、aijに反比例する。つまり、関連性が高いほど、ノード間の距離が近くなるよう表示になっている。ここでは１２個のセンサを表示している。図１２（ｂ）は、グループ作成結果である。図１２（ｂ）では、３個のセンサグループを作成した。スペクトラルクラスタリングは、初めに分割するグループ数を指定する。このためＳ５０３ｓとＳ５０３eでは、あらかじめ設定したグループ数を複数個用意し、すべての組み合わせで処理する。スペクトラルクラスタリングは一例であって、クラスタリングの手法であれば、１つに限定されるものではない。

ステップＳ５０５では、クラスタリングの結果をデータ蓄積部２のセンサグループ候補２７に格納する。図１３にデータ蓄積部２のセンサグループ候補２７の例を示す。データ蓄積部２のセンサグループ候補２７は、機器の識別ＩＤ、使用したセンサデータの開始時刻と終了時刻及びセンサグループ候補テーブルで構成される。センサグループ候補は、ステップＳ５０３ｓからＳ５０３ｅで計算した各パラメータの組み合わせ（例えば、全組み合わせ）について、ステップＳ５０４で計算したセンサグループを格納する。具体的には、センサグループ候補のユニークＩＤ、パラメータ、同一パラメータ内でユニークなグループＮｏ、センサグループの構成センサで構成される。この構成センサは、センサリストにフラグを立てる形で記載される。例えばセンサグループＩＤ０００１は、センサ１、センサ２、センサ３の３つのセンサで構成される。

これらのセンサグループ候補は、エンジニアＩ／Ｆ部８を介して表示され、このことでエンジニアＭ１に提示することになる。エンジニアＩ／Ｆ部８は、自身が表示したセンサグループ候補に対するエンジニアＭ１からの選択を受け付ける。これは、エンジニアＭ１自身の知識・経験に照らし合わせた確からしいセンサグループを複数個選択することで可能になる。また、選択されたセンサグループをエンジニアＭ１の入力に従って編集し、一部のセンサを追加・削除することもできる。この表示、編集機能も故障予兆診断システム１の機能である。

図１４は、センサグループ候補の表示画面である。１４０１は、パラメータをプルダウンで選択するウィンドウである。ここでは、グループ数３が選択されている。この結果、グループ数３のセンサグループが全て表示されている。なお、表示するセンサグループはその全てでなくとも構わない。１４０２は、「選択」のボタンである。エンジニアＭ１は、知識・経験に照らし合わせて、確からしいセンサグループを「選択」ボタンで選択する。つまり、エンジニアＩ／Ｆ部８は、その「選択」ボタンの選択を受け付ける。１４０３は、表示されたセンサグループを起点にセンサを追加・削除するための「編集」ボタンである。また、データ蓄積部２のエンジニア知識２６の重要センサを強調して表示する。これはエンジニアの候補の選択をサポートするための機能である。選択・編集したセンサグループをデータ蓄積部２のセンサグループ選択結果２８に格納する。これら各機能は、故障予兆診断システム１により実行される。

図１５に、データ蓄積部２のセンサグループ選択結果２８の例を示す。データ蓄積部２のセンサグループ選択結果２８は、機器を識別するＩＤ、エンジニアＭ１の識別ＩＤ及び作成日時とセンサグループ選択結果テーブルが格納されている。センサグループ選択結果テーブルには、センサグループＩＤと構成するセンサリストが格納されている。

学習部６は、データ蓄積部２の運転モード抽出結果２５とセンサグループ選択結果２８及び機械学習アルゴリズムを使って、対象機器の正常状態をモデリングする。具体的には、切り出した運転モードとセンサグループで入力データを作成し、機械学習を適用する。学習部６の処理フローを図１６に示す。初めにステップＳ６０１では、学習対象のセンサデータから、データ蓄積部２の運転モード抽出結果２５の運転モード、センサグループ選択結果２８の複数のセンサグループを使って、複数の学習用データを抽出する。次にステップＳ６０２ｓからＳ６０２ｅまでの複数の学習用データを使って、ステップＳ６０３とＳ６０４を実行する。ステップＳ６０３では、Ｓ６０２で選択した入力データとあらかじめ設定した機械学習のアルゴリズムを使って、機器の正常状態をモデリングする。次にステップＳ６０５では、モデリング結果をデータ蓄積部２の学習結果２９に書き込む。図１８に、学習結果２９を示す。学習結果２９として、使用した学習データを識別するＩＤを示す「学習データＩＤ」、対象の「機器ＩＤ」、使用したデータの「開始時刻」と「終了時刻」、使用した機械学習の「アルゴリズム」、「センサグループＩＤ」およびモデリングされた「データモデル」が格納される。ここでは機械学習のアルゴリズムとして、K平均法の例を記載する。K平均法では、学習データを予め設定したクラスタ数でクラスタリングし、その結果をモデリングデータとして格納する。診断の際には、診断データとK平均法でクラスタリングした結果との距離を計算する。

診断部７は、収集した対象機器の新しいデータの入力を受付け、学習部６の結果（データ蓄積部２の学習結果２９）を使って、対象機器の状態を定量化する。診断部７の具体的な処理フローを図１７に示す。初めにステップＳ７０１では、データ蓄積部２の学習結果２９を読み込む。次に、ステップＳ７０２では、データ蓄積部２センサグループ選択結果２８を読み込み、診断のための診断データを生成する。ステップＳ７０３ｓからステップＳ７０３ｅまでの間に複数の選択したセンサグループのそれぞれついてステップＳ７０４、Ｓ７０５を実行する（例えば、全センサに対して実施）。ステップＳ７０４では、正常状態と診断対象データの差異を定量化する。具体的には、正常状態との距離を計算する。例えば、正常状態がクラスタでモデリングしているとき、計算すべき差異は、診断データと最近傍クラスタとの距離である。最後にステップＳ７０５は、データ蓄積部２の診断結果３０に書き込む。図１９に、診断結果３０を示す。診断結果３０は、診断結果を識別するＩＤを示す「診断結果ＩＤ」、対象の「機器ＩＤ」、使用したデータの「開始時刻」と「終了時刻」、使用した学習データの「学習データＩＤ」、使用した機械学習の「アルゴリズム」、「センサグループＩＤ」および各センサグループで計算した距離の時系列情報であるTimestamp」と「距離」が格納されている
現場向けＩ／Ｆ部９は、診断部７の結果を表示することで、保守員Ｍ２に診断部７の結果を提供する。保守員Ｍ２が診断結果３０を見て、保守をするか否かを判断する。

以上、本実施例によれば、センサの関連性とエンジニアの知識を反映した対象機器の状態抽出とセンサグループを生成し、診断・学習することで、分析フローの高精度化が可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施の形態例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１・・・故障予兆診断システム、Ｍ１・・・エンジニア、Ｍ２・・・保守員、２・・・データ蓄積部、３・・・センサ関連性計算部、４・・・運転モード抽出部、５・・・センサグループ候補作成部、６・・・学習部、７・・・診断部、８・・・エンジニアＩ／Ｆ部、９・・・現場向けＩ／Ｆ部、２１・・・センサデータ、２２・・・センサ関連性計算結果、２３・・・センサリスト、２４・・・運転モード抽出候補、２５・・・運転モード抽出結果、２６・・・エンジニア知識、２７・・・センサグループ候補、２８・・・センサグループ選択結果、２９・・・学習結果、３０・・・診断結果３０

Claims (7)

1. 機器の状況を示す複数のセンサデータを用いて、前記機器に対する故障の予兆診断を実行する故障予兆診断システムであって、
   当該故障予兆診断システムを利用するエンジニアからの入力を受け付けるインターフェース部と、
   前記複数のセンサデータそれぞれの関連性を示すセンサ関連性および前記エンジニアから指定されたセンサの重要度を示す指標を用いて、センサグループ候補を作成するセンサグループ候補作成部と、
   作成したセンサグループ候補に対する前記エンジニアからの選択結果を用いて、故障予兆診断のための学習を実行する学習部とを有することを特徴とする故障予兆診断システム。
2. 請求項１に記載の故障予兆診断システムにおいて、
   前記センサ関連性を計算するセンサ関連性計算部をさらに有し、
   前記センサ関連性計算部は、前記複数のセンサデータを使って、複数のセンサ間のセンサデータの相関係数を算出し、算出された前記相関係数を前記センサ関連性として計算することを特徴とする故障予兆診断システム。
3. 請求項１に記載の故障予兆診断システムにおいて、
   前記センサ関連性を計算するセンサ関連性計算部をさらに有し、
   前記センサ関連性計算部は、前記複数のセンサデータを使って、複数のセンサ間のセンサデータの散布図を作成し、前記散布図におけるセンサデータの密集具合を定量化して前記センサ関連性を計算することを特徴とする故障予兆診断システム。
4. 請求項１乃至３のいずれかに記載の故障予兆診断システムにおいて、
   前記学習部は、前記機器の運転モードに対する前記エンジニアからの選択結果も用いて、前記故障予兆診断のための学習を実行することを特徴とする故障予兆診断システム。
5. 請求項４に記載の故障予兆診断システムにおいて、
   前記運転モードを、前記センサ関連性を使って、時系列方向への分類した結果である複数パターンを運転モード候補として生成する運転モード抽出部をさらに有し、
   前記インターフェース部は、前記エンジニアから前記運転モード候補に対する選択を受け付けることを特徴とする故障予兆診断システム。
6. 機器の状況を示す複数のセンサデータを用いて、前記機器に対する故障の予兆診断を実行する故障予兆診断システムを利用した故障予兆診断方法であって、
   前記故障予兆診断システムを利用するエンジニアからの入力を受け付けるステップと、
   前記複数のセンサデータそれぞれの関連性を示すセンサ関連性および前記エンジニアから指定されたセンサの重要度を示す指標を用いて、センサグループ候補を作成するステップと、
   作成したセンサグループ候補に対する前記エンジニアからの選択結果を用いて、故障予兆診断のための学習を実行するステップとを有することを特徴とする故障予兆診断方法。
7. 請求項６に記載の故障予兆診断方法において、
   前記機器の運転モードを時系列方向への分類した結果である複数パターンを運転モード候補として生成するステップさらに有し、
   前記エンジニアから前記運転モード候補に対する選択を受け付けることを特徴とする故障予兆診断方法。

Images