JP7470766B1 - 異常予兆診断装置およびプログラム - Google Patents

Abstract

【課題】診断モデルの更新の要否を適切に判定できるようにする。【解決手段】監視対象設備２００の状態を取得した稼働データＤ２と、診断モデルＤ３と、に基づいて、前記監視対象設備の異常予兆の発生を示す異常予兆アラート・データＤ６を生成する予兆検知部１１６と、前記監視対象設備に異常事象が発生した場合に、当該異常事象は、前記予兆検知部が対応する前記異常予兆アラート・データを事前に生成すべき検知対象であるか否かを判定する検知対象判断部１２７と、前記検知対象判断部の判定結果が肯定であった場合に、前記異常事象に対応する前記異常予兆アラート・データが事前に生成されていない失報が生じたか否かを判定し、前記失報が生じた場合には、前記診断モデルの更新が必要である旨を判定する検索処理部１２８と、を異常予兆診断装置１００に設けた。【選択図】図１

Description

本発明は、異常予兆診断装置およびプログラムに関する。

本技術分野の背景技術として、下記特許文献１の要約には、「［課題］機械設備の再稼動時にも異常予兆の有無を適切に診断する異常予兆診断システム等を提供する。［解決手段］異常予兆診断システム１は、所定の機械設備の停止期間後の再稼動時において、当該機械設備の診断に用いられる正常モデルとして、当該機械設備と同機種である他の機械設備の中の一つの最新の正常モデルを選択する正常モデル選択手段１６２と、正常モデル選択手段１６２によって選択された正常モデルに基づいて、当該機械設備の異常予兆の有無を診断する診断手段１６３と、を備える。」と記載されている。

特開２０２０－０３５２８１号公報

ところで、上述した技術において、異常予兆を判定するための診断モデルをできるだけ自機のデータを使って正しく更新したほうが好ましい場合があり、診断モデルの更新の要否を適切に判定したいという要望がある。
この発明は上述した事情に鑑みてなされたものであり、診断モデルの更新の要否を適切に判定できる異常予兆診断装置およびプログラムを提供することを目的とする。

上記課題を解決するため本発明の異常予兆診断装置は、監視対象設備の状態を取得した稼働データと、診断モデルと、に基づいて、前記監視対象設備の異常予兆の発生を示す異常予兆アラート・データを生成する予兆検知部と、前記監視対象設備に異常事象が発生した場合に、前記異常事象の種類を識別する異常事象識別情報と、前記異常事象識別情報が検知対象であるか否かを定めた検知当否情報と、を対応付けた対象事象設定テーブルを参照して、前記異常事象は、前記予兆検知部が対応する前記異常予兆アラート・データを事前に生成すべき前記検知対象であるか否かを判定する検知対象判断部と、前記検知対象判断部の判定結果が肯定であった場合に、前記異常事象に対応する前記異常予兆アラート・データが事前に生成されていない失報が生じたか否かを判定し、前記失報が生じた場合には、前記診断モデルの更新が必要である旨を判定する検索処理部と、を備え、前記検索処理部は、前記異常事象の発生時刻または前記異常事象の登録時刻から、前記異常事象の種類毎に設定した期間である検索対象時間だけ過去に遡った時刻までの期間に発生した前記異常予兆アラート・データの中から、前記異常事象に対応する前記異常予兆アラート・データが存在するか否かを判定し、判定結果が否定である場合に前記失報が生じたと判定することを特徴とする。

本発明によれば、診断モデルの更新の要否を適切に判定できる。

第１実施形態による異常予兆診断装置ブロック図である。 コンピュータのブロック図である。 信憑性判断データベースの具体例を示す図である。 データベースの要部の対応関係を示す図である。 各種テーブルの関係を示す図である。 他の各種テーブルの関係を示す図である。 制御プログラム等の内容を模式的に示したフローチャート（１／２）である。 制御プログラム等の内容を模式的に示したフローチャート（２／２）である。 異常度とセンサ・データとの関係の一例を示す図である。 異常度とセンサ・データとの関係の他の例を示す図である。 事象対応処理ルーチンのフローチャートである。 異常度の推移の一例を示す図である。 異常度の推移の他の例を示す図である。

［実施形態の概要］
一般的な異常予兆診断システムにおいて、予兆診断結果が「異常予兆あり」の場合、異常予兆アラートが発出されるが、異常予兆アラートは確報と誤報の２つに分類することができる。そのため、保守計画担当者は、過去のアラート発出状況、アラートに関連するセンサ・データなどを参照して、異常予兆アラートが確報と誤報の何れに分類されるかを、過去の運転実績等から得た経験に基づいて判断していた。そこで、この種の判断を自動化できれば好ましい。また、異常予兆アラートが誤報であった場合、その後は異常予兆診断システムから誤報が発報されないよう、異常予兆診断の診断モデルを更新することが好ましい。そこで後述する実施形態は、異常予兆ありと判断された予兆診断結果に基づいて、診断モデルの更新要否を適切に判定しようとするものである。

ここで、ガスエンジンの異常予兆診断を例として、異常予兆の信憑性を判断する意義を、さらに詳細に説明する。
（１）異常予兆診断装置が異常予兆アラートを発報した後、数日間に渡って同様のセンサ・データを伴ってアラートを発生し続ける場合がある。このようなアラートは誤報である可能性が高い。また、ある異常予兆アラートが過去に発報されたにもかかわらず、対応する故障が何も発生しなかったとする。すると、このアラートに近似するアラートも、誤報である可能性が高い。このような知見は、熟練作業者の経験や保守計画担当者の知識の中に蓄積された情報である。

熟練作業者等が「誤報である」と判定した場合には、異常予兆診断装置が発報したアラートよりも熟練作業者等の経験の方を優先し、当該アラートを無視することが好ましい場合が多い。すると、当該事象に対して「誤報」という識別を付け、そもそも当該アラートを発報させないことが望ましい。

（２）センサ・データにおいて、過去に経験した故障と同様のトレンドが発生した場合、診断モデルが異常予兆アラートを発生させる場合がある。しかし、この異常予兆アラートは、「発生が早すぎる誤報」と判断すべき場合がある。診断モデルにおいてセンサ・データに重みづけを付与する際、重みづけ係数が大きすぎることが、この種の誤報が発生する原因であることが多い。この場合、重みづけ係数を変更することによって、誤報を抑制することが可能になる。

（３）作業者等は、異常予兆アラートが正しいか否かの判断に迷った場合、反応しているセンサ・データおよび関連するセンサ・データのトレンドグラフと、センサ周辺の保守履歴や部品交換情報を参照し、誤報であるか確報であるかを判断することが多い。
また、センサ・データが正常時とは異なる傾向を示している場合や、関連するセンサ・データの連動状態が通常とは異なる場合などは、外気温、外気圧、湿度、燃料情報などの信憑性を疑うべき場合がある。また、不具合を発生させる人為的な要因（例えば、異物が吸気口を塞いでいるなど）が発生している場合がある。そこで、このような要因を推定および特定し対策を講じることが好ましい。
また、前回保守を行った時からの経過時間が短いにもかかわらず、信頼性の高い部位での異常予兆アラートが発生すると、それは誤報であると判断すべき場合が多い。
また、作業員等が異常な運転を行った場合に異常予兆アラートが発生する場合もある。但し、これは人的な情報を照合した結果として、事後になって誤報であると判明する場合が多い。また、この種のケースでは、年単位で遅れて誤報であると判明する場合が多い。

これらの場合、作業者等が診断モデルのモデル係数を変更して対処することがある。また、作業者等は、上述のような異常な推移を示すセンサ・データのトレンドの状態に紐づけて、異常予兆アラートを誤報と分類する場合もある。また、本来は発生すべき異常予兆アラートが発生しなかったことを「失報」と呼ぶ。失報が生じた場合には、その後は、同様の失報が生じにくくするように対処することが望ましい。そこで後述する実施形態においては、上述の（１）～（３）を信憑性判断データベースによって体系化するとともに、当該信憑性判断データベースに基づいて、異常予兆の確報または誤報を判定し、さらに失報を検出しやすくなるように対応できるようにした。

［第１実施形態］
〈第１実施形態の構成〉
図１は、第１実施形態による異常予兆診断装置１００のブロック図である。異常予兆診断装置１００は、監視対象設備２００の異常予兆を診断するシステムである。監視対象設備２００は、例えば、ガスエンジン発電機である。但し、監視対象設備２００は、これに限定されるものではなく、化学プラント、原子力プラント、医療設備、通信設備等であってもよい。また、監視対象設備２００は、全ての構成要素が近隣に設置されているものであってもよく、各構成要素が複数の離散した箇所に設置されていてもよい。

異常予兆診断装置１００は、予兆分析部１１０と、モデル更新制御部１２０と、センサ部１５０と、ＤＢ部１６０と、を備えている。なお、「ＤＢ」は「データベース」を意味する。ＤＢ部１６０は、稼働データベース１６２と、モデル管理データベース１６４と、診断結果データベース１６５と、原因診断データベース１６６と、信憑性判断データベース１６８と、事象マスタデータベース１７２と、保守対応実績データベース１７４と、対象事象照合データベース１７６と、を備えている。上述した各データベースには、磁気ディスク装置、光ディスク装置、半導体記憶装置等を適用することができる。

また、予兆分析部１１０は、運転監視部１１２と、診断モデル選択部１１４と、予兆検知部１１６（予兆検知手段）と、原因診断部１１８と、を備えている。また、モデル更新制御部１２０（モデル更新制御手段）は、予兆経験判定部１２２と、予兆信憑性判定部１２４と、モデル更新判定部１２６と、検知対象判断部１２７（検知対象判断手段）と、検索処理部１２８（検索処理手段）と、を備えている。

センサ部１５０は、監視対象設備２００の状態を計測する複数のセンサ（図示略）を備えている。稼働データベース１６２は、これらセンサの検出値（センサ・データ）に基づいて、稼働データＤ２を蓄積する。稼働データＤ２は、上記各センサの識別情報、監視対象設備２００を構成する機器のうち各センサが設置されている機器の識別情報、各センサ・データ、検出日時等の情報を含んでいる。この稼働データＤ２は、予兆分析部１１０に供給される。

運転監視部１１２は、稼働データＤ２に基づいて、監視対象設備２００の運転状態を監視する。モデル管理データベース１６４は、複数の予兆診断項目にそれぞれ対応する複数の診断モデルＤ３を記憶する。ここで予兆診断項目とは、例えば「エンジン混合気温度異常」、「冷却水圧力低下」、「油漏れ」等である。ここで、個々の診断モデルＤ３は、監視対象設備２００の状態や、監視しようとする予兆診断項目に応じて、監視対象設備２００の正常状態における動作内容を記述したデータである。診断モデル選択部１１４は、これら複数の診断モデルＤ３の中から、監視対象設備２００の状態および予兆診断項目に応じた一つの診断モデルＤ３を選択する。

予兆検知部１１６は、稼働データベース１６２に記憶されている現在および過去の稼働データＤ２と、選択された診断モデルＤ３と、に基づいて、予兆診断項目に応じた異常度Ｄ４を出力する。ここで、異常度Ｄ４は、正常状態からの乖離の大きさを表す指標である。また、予兆検知部１１６は、異常度Ｄ４に基づいて、監視対象設備２００の異常予兆診断を行う。ここで、「異常予兆診断」とは、監視対象設備２００が稼動不能となる異常な状態に達するか否かを診断することに限らず、正常な状態の範囲で稼動可能ではあるが監視対象設備２００の性能低下が起こっている場合に、その性能低下の程度を診断することも含むものである。そして、予兆検知部１１６は、この異常度Ｄ４に基づき、監視対象設備２００の異常予兆の有無を診断し、その結果を判定データＤ５として出力する。判定データＤ５は、“０”（異常予兆なし）または“１”（異常予兆あり）の値をとる二値のデータである。

予兆検知部１１６は、例えば異常度Ｄ４が所定の閾値以上である場合に判定データＤ５を“１”（異常予兆あり）とし、それ以外の場合に判定データＤ５を“０”（異常予兆なし）とすることが考えられる。また、予兆検知部１１６は、予兆診断項目と、稼働データＤ２と、異常度Ｄ４との関係に基づいて、異常度Ｄ４に信憑性が有るか否かを判定し、異常度Ｄ４に信憑性があり、かつ、異常度Ｄ４が所定の閾値以上である場合に判定データＤ５を“１”（異常予兆あり）とし、それ以外の場合に判定データＤ５を“０”（異常予兆なし）とすることも考えられる。

予兆検知部１１６は、判定データＤ５が“１”（異常予兆あり）である場合に異常予兆アラート・データＤ６を生成し、診断結果データベース１６５に書き込む。この異常予兆アラート・データＤ６は、予兆診断項目と、稼働データＤ２と、異常度Ｄ４と、信憑性データＤ１０と、を紐づけたものである。ここで、信憑性データＤ１０は、当該異常予兆アラート・データＤ６について「確報」、「誤報」または「未定」の何れかを示すデータであり、異常予兆アラート・データＤ６が作成された時点では「未定」である。但し、信憑性データＤ１０は、モデル更新制御部１２０によって、「確報」または「誤報」に変更される。

ここで、「確報」とは、異常予兆アラート・データＤ６に対する対策を何ら行わない場合、異常予兆アラート・データＤ６が生成された後、一定期間経過後に、監視対象設備２００に異常状態が表出する可能性が高いことを意味する。また、「誤報」とは、異常予兆アラート・データＤ６に対する対策を何ら行わない場合、異常予兆アラート・データＤ６が生成された後、一定期間経過後も、監視対象設備２００に対応する異常状態が表出しない可能性が高いことを意味する。

そして、予兆検知部１１６は、当該異常予兆アラート・データＤ６をモデル更新制御部１２０に供給する。ところで、異常予兆アラート・データＤ６に含まれる信憑性データＤ１０は、異常予兆アラート・データＤ６が新たに生成された時点では「未定」である。そこで、後述する処理により、異常予兆アラート・データＤ６には、「確報」または「誤報」の信憑性データＤ１０が後に追加される。このように、「確報」または「誤報」である異常予兆アラート・データＤ６を、「評価済異常予兆アラート・データＤ６Ａ」と呼ぶことがある。

さらに、予兆検知部１１６は、稼働データＤ２を学習データとした統計的手法（データマイニング）に基づいて、監視対象設備２００の稼動情報の正常範囲を示す所定の診断モデルを学習する。予兆検知部１１６は、その学習結果を、診断モデルＤ３としてモデル管理データベース１６４に登録する。

原因診断部１１８は、異常予兆アラート・データＤ６に対して「影響センサ」を特定する場合がある。影響センサとは、センサ部１５０に属する各センサのセンサ・データのうち、予兆検知部１１６が「異常予兆あり」と判定するに至った原因として、最も影響が大きかったセンサ・データを出力したセンサである。また、原因診断部１１８は、原因診断データＤ８を生成し、原因診断データベース１６６に書き込む。ここで、原因診断データＤ８は、予兆診断項目と、影響センサのパターンと、異常予兆アラート・データＤ６と、を紐づけたデータである。

上述したように、モデル更新制御部１２０は、異常予兆アラート・データＤ６を、予兆分析部１１０から受信する。
モデル更新制御部１２０の予兆経験判定部１２２は、原因診断データベース１６６に今回受信した異常予兆アラート・データＤ６に類似する既存の評価済異常予兆アラート・データＤ６Ａ（以下、「既存類似データ」と呼ぶ）が記録されているか否かを判定する。

ここで、「類似」の意義を説明しておく。稼働データＤ２がｎ個のセンサ・データを含む場合、これらセンサ・データはｎ次空間内の一つの点に対応する。既存の評価済異常予兆アラート・データＤ６Ａに含まれる稼働データＤ２に係るｎ次空間内の点と、今回受信した異常予兆アラート・データＤ６に含まれる稼働データＤ２に係るｎ次空間内の点との距離が所定値以下であった場合、両者の異常予兆アラート・データＤ６は「類似する」ものとする。

また、予兆信憑性判定部１２４は、新たに発生した異常予兆アラート・データＤ６に対する既存類似データが存在しない場合に、監視対象設備２００に対する経過観察を行うことにより、当該異常予兆アラート・データＤ６の信憑性を判定する。さらに、予兆信憑性判定部１２４は、異常予兆アラート・データＤ６に対する既存類似データが存在する場合には、この既存類似データが「確報」であるのか「誤報」であるのかを判定する。

そして、予兆信憑性判定部１２４は、既存類似データに含まれる「確報」または「誤報」の信憑性データＤ１０と同一の信憑性データＤ１０を、新たに発生した異常予兆アラート・データＤ６にも追加する。これにより、当該異常予兆アラート・データＤ６は、評価済異常予兆アラート・データＤ６Ａになる。また、予兆信憑性判定部１２４は、この評価済異常予兆アラート・データＤ６Ａの信憑性データＤ１０が「確報」である場合には、当該評価済異常予兆アラート・データＤ６Ａの内容を原因診断データベース１６６にも格納する。

モデル更新判定部１２６は、新たに発生した異常予兆アラート・データＤ６が「誤報」である場合に、対応する診断モデルＤ３の更新の要否を判定する。さらに、モデル更新判定部１２６は、診断モデルＤ３を更新する場合に、その更新態様として「新規作成」または「一部更新」の何れを採用するかを決定する。

ここで、「新規作成」および「一部更新」の意義について説明しておく。診断モデルＤ３は、アルゴリズムと、そのアルゴリズムに適用される定数であるパラメータと、を含んでいる。ここで、アルゴリズムを変更することなく定数のみを変更することを「一部更新」と呼び、アルゴリズムそのものを変更することを「新規作成」と呼ぶ。

検知対象判断部１２７は、監視対象設備２００において何らかの異常事象が発生した場合に、この新たな異常事象は、対応する異常予兆を事前に検知すべき対象（検知対象）であるか否かを判定する。また、検索処理部１２８は、検知対象判断部１２７によって「検知対象である」と判定された異常事象について、実際に異常予兆が事前に検知されたか否かの検索処理を行う。

図２は、コンピュータ９００のブロック図である。図１に示した異常予兆診断装置１００は、このコンピュータ９００を備えている。
図２において、コンピュータ９００は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７と、を備える。通信Ｉ／Ｆ９０５は、通信回路９１５に接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６に接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。

ＲＯＭ９０３には、ＣＰＵによって実行される制御プログラム、各種データ等が格納されている。ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだアプリケーションプログラムを実行することにより、各種機能を実現する。先に図１に示した、異常予兆診断装置１００の内部は、アプリケーションプログラム等によって実現される機能をブロックとして示したものである。但し、異常予兆診断装置１００は、１台のコンピュータ９００を用いて構成してもよく、通信回路９１５を介して接続した複数のコンピュータ９００を用いて構成してもよい。

〈信憑性判断データベースの具体例〉
図３は、信憑性判断データベース１６８に記憶されている信憑性判断データＤ３０の具体例を示す図である。
図３において、信憑性判断データＤ３０は、予兆診断項目部３０と、判断基準部３４と、評価情報部３６（評価情報）と、を有している。予兆診断項目部３０は、複数の予兆診断項目３０ａ，３０ｂ，３０ｃ等を記憶する。判断基準部３４は、各々の予兆診断項目に対して、複数の判断基準＃１～＃４を記憶する。

また、評価情報部３６は、これら判断基準＃１～＃４の組合せに応じて、「○」または「×」の評価情報を記憶する。ここで、「○」の評価情報とは、当該予兆診断項目に対して、異常予兆が発生した場合に、その異常予兆が信頼できる（確報であると考えられる）という意味である。また、「×」の評価情報とは、当該予兆診断項目に対して、異常予兆が発生した場合に、その異常予兆が信頼できない（誤報であると考えられる）という意味である。この信憑性判断データＤ３０の内容は、熟練作業者の経験や保守計画担当者の知識を体系化したものである。

図示の例において、予兆診断項目３０ａは「エンジン混合気温度異常」であり、判断基準＃１として、「入口温度（吸気温度）と出口温度（排気温度）の実測値差ΔＴ」について「所定温度ｋ℃以上」であるか「ｋ℃未満」であるかが挙げられている。また、当該判断基準＃１の結果のそれぞれに対して、判断基準＃２として、「冷却水液面高さの実測値Ｈ」について「所定高さｈ１以上」であるのか「ｈ１未満」であるかが挙げられている。また、判断基準＃１および判断基準＃２の判断結果の各組合せに対して、判断基準＃３として、「前回の保守時に冷却タンクに水を充填したか」について「Ｙｅｓ」か「Ｎｏ」か、が挙げられている。

また、予兆診断項目３０ｂは「冷却水圧力低下」であり、判断基準＃１として、「圧力低下速度Ｖが所定速度Ｖ１を超える」か否かが挙げられている。そして、判断基準＃１について「圧力低下速度Ｖが所定速度Ｖ１を超える」場合に、判断基準＃２として、「圧力低下の周期性有無」について「Ｙｅｓ」か「Ｎｏ」か、が挙げられている。そして、判断基準＃３として、「冷却水ヒータ温度Ｔ」について、「Ｔ１＜Ｔ≦Ｔ２」、「Ｔ＞Ｔ２」（但し、Ｔ１，Ｔ２は所定温度）が挙げられている。

また、予兆診断項目３０ｃは「油漏れ」であり、判断基準＃１として「油圧は低下しているか」について「Ｙｅｓ」か「Ｎｏ」か、が挙げられている。そして、判断基準＃１について「Ｙｅｓ」である場合に、判断基準＃２として、冷却水量Ｑについて「所定値ｑ１以上」か「ｑ１未満」が、が挙げられている。そして、判断基準＃３として、「前回保守時に弁は正常であったか」について「Ｙｅｓ」か「Ｎｏ」か、が挙げられている。

〈データベースの要部の対応関係〉
図４は、データベースの要部の対応関係を示す図である。
すなわち、図４は、図１に示した事象マスタデータベース１７２と、保守対応実績データベース１７４と、対象事象照合データベース１７６と、の対応関係を示す。事象マスタデータベース１７２には、後述する事象マスタテーブルＤ１７２が記憶されている。また、保守対応実績データベース１７４には、後述する保守対応実績テーブルＤ１７４と、照合済テーブルＤ１７５と、が記憶されている。

また、対象事象照合データベース１７６には、後述する対象事象設定テーブルＤ１７６が記憶されている。事象マスタテーブルＤ１７２、保守対応実績テーブルＤ１７４および対象事象設定テーブルＤ１７６は、後述する事象ＩＤによって相互に対応付けられている。また、保守対応実績テーブルＤ１７４と、照合済テーブルＤ１７５とは、後述する対応ＩＤによって対応付けられている。

図５は、各種テーブルの関係を示す図である。
図５において、保守対応実績テーブルＤ１７４は、異常事象に対応する複数のレコード（行）に対して、対応ＩＤと、件名と、対応日と、完了日と、対応内容と、登録日と、を記憶するものである。ここで、「対応ＩＤ」とは、当該異常事象に対して作業者等が故障等の異常事象に対応する保守作業を行った場合に付与される識別情報である。また、「件名」とは、当該異常事象の内容を表現する文字列である。また、「対応日」および「完了日」は、異常事象に対応する保守作業の開始日および終了日の日付である。「対応内容」は、保守作業の内容を表現する文字列である。「登録日」とは、当該レコードを保守対応実績テーブルＤ１７４に登録した日付である。

また、照合済テーブルＤ１７５は、異常事象に対応する複数のレコード（行）に対して、対応ＩＤと、事象ＩＤ（異常事象識別情報）と、照合状況と、を記憶するものである。ここで、「対応ＩＤ」は、保守対応実績テーブルＤ１７４のものと同様である。「事象ＩＤ」は、異常事象の種類毎に付与された識別情報である。「照合状況」とは、保守対応実績テーブルＤ１７４において、当該対応ＩＤが付与されたレコードを、後述する対象事象設定テーブルＤ１７６（図６参照）と照合したか否かを示す情報であり、照合済（○印）または未照合（空欄）の何れかになる。

照合済テーブルＤ１７５から照合状況が空欄（照合未実行）であるレコードを抽出し、抽出したレコードの対応ＩＤと同一の対応ＩＤを有する保守対応実績テーブルＤ１７４内のレコードも抽出し、両者の内容をマージする。これにより、図示の照合対象データＤＸ２が得られる。

図６は、他の各種テーブルの関係を示す図である。
図６において、対象事象設定テーブルＤ１７６は、事象種別に対応する複数のレコード（行）に対して、事象ＩＤと、検知当否情報と、を記憶するものである。上述のように、「事象ＩＤ」は異常事象の種類毎に付与された識別情報である。

また、検知当否情報は、当該異常事象の種類が、「予兆検知部１１６によって対応する異常予兆を検知すべき事象種類」（以下、検知対象と呼ぶ）であるかを示す情報である。検知当否情報は、検知対象（○印）または非検知対象（×印）の何れかになる。また、事象マスタテーブルＤ１７２は、各々異常事象の種類に対応する複数のレコード（行）に対して、事象ＩＤと、事象名称と、「事象名称」は、当該異常事象の種類の内容を表す文字列である。

事象マスタテーブルＤ１７２から任意のレコード（例えば、「油漏れ」および「燃料タイプ切替過多」）を指定し、抽出したレコードの事象ＩＤと同一の事象ＩＤを有する対象事象設定テーブルＤ１７６内のレコードも抽出し、両者の内容を合わせると、図示の検知対象一覧データＤＸ４が得られる。検知対象一覧データＤＸ４においては、事象マスタテーブルＤ１７２で指定したレコード（上記例では「油漏れ」および「燃料タイプ切替過多」）が、それぞれ、検知対象であるか否かを判別できる。

〈第１実施形態の動作〉
図７および図８は、本実施形態に適用される制御プログラム等の内容を模式的に示したフローチャートである。なお、図７および図８において、実線は主として処理の流れを示し、破線はデータの流れを示す。
図７において処理がステップＳ２に進むと、予兆検知部１１６は、新規の診断モデルＤ３を作成する。次に、処理がステップＳ４に進むと、予兆検知部１１６は、作成した診断モデルＤ３が適正か否かを判定する。ここで「Ｎｏ」と判定されると、処理はステップＳ２に戻り、予兆検知部１１６は診断モデルＤ３が再作成する。以後、診断モデルＤ３が適正であると判断されるまで、ステップＳ２，Ｓ４が繰り返される。一方、ステップＳ４において「Ｙｅｓ」と判定されると、処理はステップＳ６に進む。ここでは、予兆検知部１１６は、作成された新たな診断モデルＤ３をモデル管理データベース１６４に登録する。

次に、処理がステップＳ７に進むと、運転監視部１１２は、稼働データベース１６２から稼働データＤ２を取得する。また、診断モデル選択部１１４は、診断対象とする予兆診断項目に応じた診断モデルＤ３を選択し、モデル管理データベース１６４から読み出す。

次に、処理がステップＳ７２に進むと、予兆検知部１１６は、選択された診断モデルＤ３に基づいて診断処理を行う。次に、処理がステップＳ７４に進むと、予兆検知部１１６は、この診断処理の結果と、稼働データＤ２と、に基づいて、異常度Ｄ４を算出し、異常度Ｄ４に基づいて判定データＤ５を算出する。

次に、処理がステップＳ７６に進むと、予兆検知部１１６は、判定データＤ５が“１”（異常予兆あり）であるか否かを判定する。ここで、判定データＤ５が“０”（異常予兆なし）であった場合、ステップＳ７６において「Ｎｏ」と判定され、処理はステップＳ７に戻る。これにより、運転監視部１１２は、稼働データベース１６２から再び稼働データＤ２を取得し、ステップＳ７２以降の処理が実行される。従って、稼働データＤ２において異常予兆を示すデータが含まれない場合、判定データＤ５は“０”（異常予兆なし）であり続けるため、ステップＳ７～Ｓ７６の処理が繰り返される。

一方、判定データＤ５が“１”（異常予兆あり）であると、ステップＳ７６において「Ｙｅｓ」と判定され、処理はステップＳ７８に進む。予兆検知部１１６は、異常予兆アラート・データＤ６を生成し、生成した異常予兆アラート・データＤ６を診断結果データベース１６５およびモデル管理データベース１６４に登録する。なお、上述のように、異常予兆アラート・データＤ６は、予兆診断項目と、稼働データＤ２と、異常度Ｄ４とを紐づけたデータである。

次に、処理がステップＳ１０に進むと、モデル更新制御部１２０の予兆経験判定部１２２は、既存の異常予兆アラート・データＤ６のうち、ステップＳ７８において新規登録された異常予兆アラート・データＤ６に対して、既存類似データ（類似する既存の評価済異常予兆アラート・データＤ６Ａ）が存在する否かを判定する。ステップＳ１０において「Ｎｏ」と判定されると、処理は図８のステップＳ５０に進み、経過観察処理が実行される。ここで、経過観察処理とは、所定の経過観察期間に、監視対象設備２００に故障が生じたか否かを観察する処理である。

次に、処理がステップＳ５２に進むと、予兆検知部１１６は、ステップＳ５０の経過観察期間において、異常予兆アラート・データＤ６に係る予兆診断項目に応じた故障が発生したか否かを判定する。ここで「Ｎｏ」と判定されると、処理はステップＳ５３に進み、予兆経験判定部１２２は、診断結果データベース１６５に対して、新規登録された異常予兆アラート・データＤ６の信憑性データＤ１０が「誤報」であった旨を記録する。

一方、ステップＳ５２において「Ｙｅｓ」と判定されると、処理がステップＳ５４に進む。ここでは、作業員等が、故障に対応する保守作業を行う。次に、処理がステップＳ５６に進むと、原因診断部１１８は、ステップＳ５４の保守作業の結果に応じて、ステップＳ５２，Ｓ５３における異常予兆診断装置１００の対応を評価する。まず、上述したように、ステップＳ５２において、予兆検知部１１６は、経過観察期間において故障が発生したか否かを判定した。原因診断部１１８は、この判定内容を評価し、その正誤を診断結果データベース１６５に記憶させる。また、原因診断部１１８、は、異常予兆アラート・データＤ６に係る故障原因についてもその正誤を原因診断データベース１６６に記憶させる。なお、上述したステップＳ５６の処理は、作業者等が実行してもよい。

また、図７のステップＳ１０において、「Ｙｅｓ」（既存類似データあり）と判定されると、処理はステップＳ１２に進む。ステップＳ１２において、予兆信憑性判定部１２４は、信憑性判断データＤ３０に基づいて、以下の手順により、新たに発生した異常予兆アラート・データＤ６が確報であるか誤報であるかを判定する。

すなわち、予兆信憑性判定部１２４は、予兆診断項目３０ａ，３０ｂ，３０ｃ等（図３参照）の中から、異常予兆アラート・データＤ６に含まれる予兆診断項目を選択する。次に、予兆信憑性判定部１２４は、選択した予兆診断項目における判断基準＃１～＃４等と、異常予兆アラート・データＤ６に含まれる稼働データＤ２と、を照合し、評価情報部３６に記憶されている評価情報に基づいて、当該異常予兆アラート・データＤ６に信憑性がある（確報である）、または信憑性が無い（誤報である）のかを判定する。

新たに発生した異常予兆アラート・データＤ６が「誤報」であった場合、ステップＳ１２において「Ｎｏ」と判定され、処理はステップＳ１３に進む。異常予兆アラート・データＤ６が誤報であったため、以降の処理においては、当該異常予兆アラート・データＤ６を生成する際に用いた診断モデルＤ３を更新する。但し、上述したように、診断モデルＤ３の更新態様には、「新規作成」または「一部更新」の２種類がある。

そこで、ステップＳ１３において、モデル更新判定部１２６は、「誤報」である既存類似データに係る診断モデルＤ３に対する更新態様として「新規作成」または「一部更新」の何れかを選択する。なお、その選択方法の詳細については後述する。次に、処理が図８のステップＳ１４に進むと、選択された更新態様は新規作成であるのか否かが判定される。ここで、「Ｙｅｓ」と判定されると、処理は図７のステップＳ２に戻り、予兆検知部１１６は、診断モデルＤ３を新規に作成し、その内容をモデル管理データベース１６４に登録する。その後、上述したステップＳ４以降の処理が繰り返される。

一方、診断モデルＤ３の更新態様として一部更新が選択された場合、処理は図８のステップＳ２２に進み、予兆検知部１１６は、モデル管理データベース１６４に記憶されている診断モデルＤ３の中から、更新すべき診断モデルＤ３を選択する。次に、処理がステップＳ２４に進むと、予兆検知部１１６は、更新すべき診断モデルＤ３をモデル管理データベース１６４に仮登録する。

次に、処理がステップＳ２６に進むと、予兆検知部１１６は、稼働データベース１６２に記憶されている稼働データＤ２に基づいて、仮登録した診断モデルＤ３の再学習を実行する。次に、処理がステップＳ２８に進むと、予兆検知部１１６は、仮登録した診断モデルＤ３が適正であるか否かを判定する。

ステップＳ２８において「Ｙｅｓ」（適正）と判定されると、処理はステップＳ２９に進み、予兆検知部１１６は、仮登録した診断モデルＤ３を正式登録する。一方、ステップＳ２８において「Ｎｏ」（適正ではない）と判定されると、処理はステップＳ２２に戻り、ステップＳ２２～Ｓ２８の処理が繰り返される。ステップＳ２９の処理が終了すると、処理はステップＳ７２に戻り、上述したステップＳ７２以降の動作が繰り返される。

また、ステップＳ１２において、「Ｙｅｓ」（新たに発生した異常予兆アラート・データＤ６が「確報」）と判定されると、処理はステップＳ３０（図８参照）に進む。ここでは、予兆信憑性判定部１２４は、原因診断データベース１６６に対して、既存類似データが「確報」であった旨を登録する。次に、処理がステップＳ３２に進むと、予兆信憑性判定部１２４は、入出力装置９１６（図２参照）に含まれるディスプレイに、所定のチェックリストを表示させる。作業者等は、このチェックリストを介して、各種データを入力する。

ところで、監視対象設備２００が導入された際、監視対象設備２００に対しては所定の初期調査が実行されている（Ｓ３４）。次に、処理がステップＳ３２からステップＳ３６に進むと、予兆信憑性判定部１２４は、上述の初期調査の結果と、作業者等によるチェックリストへの入力内容と、に基づいて、異常予兆アラート・データＤ６が発生した原因を診断する。

次に、処理がステップＳ３８に進むと、予兆信憑性判定部１２４は、作業者等に対して、異常予兆アラート・データＤ６に対応して、故障等を未然に防止する対応策を提案する。次に、処理がステップＳ４０に進むと、作業者等は、監視対象設備２００に対する保守計画を作成する。次に、ステップＳ５４では、作業員等が、監視対象設備２００に対する保守作業を行う。次に、処理がステップＳ５６に進むと、原因診断部１１８は、ステップＳ５４の保守作業の結果に応じて、ステップＳ３０～Ｓ３８における異常予兆診断装置１００の対応を評価する。そして、原因診断部１１８は、上述したように、評価結果を診断結果データベース１６５および原因診断データベース１６６に記憶させる。

〈ステップＳ１３の詳細〉
上述したステップＳ１３において、診断モデルＤ３に対する更新態様として新規作成または一部更新を選択する方法の詳細を説明する。
上述したように、稼働データＤ２は、複数のセンサ・データを含んでいる。そこで、モデル更新判定部１２６は、異常度Ｄ４の時系列データと、異常度Ｄ４に寄与しているセンサ・データとの相関分析を行い、各々の相関度を算出する。異常度Ｄ４が大きくなる原因は、特定のセンサに紐づいた一または複数の機器の減耗による劣化である場合が多い。従って、このような場合、異常度Ｄ４の増加に伴って、センサ・データは漸増または漸減の傾向を示す。

しかし、診断モデルＤ３のアルゴリズムが不適切である場合には、センサ・データは漸増または漸減とは大きく外れることがある。例えば、異常度Ｄ４に対して強い相関を持つセンサ・データが診断モデルＤ３にそもそも含まれていなかった場合が挙げられる。また、監視対象設備２００は、例えば始動、定常、停止、空転等、様々異なる運転状態になる場合がある。診断モデルＤ３に、運転状態に基づく突発事象が組み込まれていない場合も、異常度Ｄ４とセンサ・データとの関係が不自然なものになる。このように診断モデルＤ３のアルゴリズムそのものが不適切であった場合に、モデル更新判定部１２６は、ステップＳ１３における更新態様として「新規作成」を選択し、それ以外の場合に「一部更新」を選択する。

図９は、異常度Ｄ４とセンサ・データとの関係の一例を示す図である。
図９の横軸は時刻ｔであり、縦軸はセンサ・データおよび異常度Ｄ４である。図９においてＳＤ１は異常度Ｄ４に対する寄与度が第１位のセンサ・データである。なお、寄与度とは、異常度Ｄ４の大きさに最も影響を与えているセンサ・データの全体のセンサ・データにおける寄与の割合を示す。図示の例では、センサ・データＳＤ１の異常度Ｄ４に対する相関度が高いため、ステップＳ１３では、「更新態様」として「一部更新」が選択される傾向が高くなる。

図１０は、異常度Ｄ４とセンサ・データとの関係の他の例を示す図である。
図１０の横軸は時刻ｔであり、縦軸はセンサ・データおよび異常度Ｄ４である。図１０においてＳＤ１，ＳＤ２，ＳＤ３は、異常度Ｄ４に対する寄与度が第１位、第２位および第３位のセンサ・データである。そして、センサ・データＳＤＸは、実際には診断モデルＤ３において参照されていないセンサ・データである。

モデル更新判定部１２６は、例えば以下のような場合に、「更新態様」として「新規作成」を選択する傾向が強くなる。
（１）センサ・データＳＤ１の時刻ｔ1，ｔ2における突発的な変動が、診断モデルＤ３に組み込まれていない。
（２）センサ・データＳＤ２の重みづけが、センサ・データＳＤ１の重みづけと比較して極端に低い。
（３）異常度Ｄ４に対してセンサ・データＳＤＸの相関度が高いにも関わらず、センサ・データＳＤＸが診断モデルＤ３に組み込まれていない。

〈事象対応処理〉
図１１は事象対応処理ルーチンのフローチャートである。
本ルーチンは、モデル更新制御部１２０（図１参照）において所定時間毎に起動される。
図１１において処理がステップＳ１０１に進むと、検知対象判断部１２７は、前回に当該ステップＳ１０１を実行した時と比較して、保守対応実績データベース１７４の保守対応実績テーブルＤ１７４および照合済テーブルＤ１７５に新たなレコード、すなわち新たな異常事象に対するレコードが登録されているか否かを判定する。ここで「Ｎｏ」と判定されると、本ルーチンの処理が終了する。

ところで、監視対象設備２００（図１参照）何らかの異常事象（例えば「油漏れ」）が発生すると、作業者等は監視対象設備２００の状況を確認し、保守対応作業を行う。そして、保守が完了した後、保守対応日、保守完了日、および具体的な対応内容等の情報を、保守対応実績テーブルＤ１７４および照合済テーブルＤ１７５（図５参照）の新たなレコードとして追加する。

例えば、この新たなレコードが、図５の保守対応実績テーブルＤ１７４および照合済テーブルＤ１７５における「対応ＩＤ：００ｎ－１」および「対応ＩＤ：００ｎ」のレコードであったとする。その後に、本ルーチンが起動されると、検知対象判断部１２７は、ステップＳ１０１において「Ｙｅｓ」と判定し、処理はステップＳ１０２に進む。

ステップＳ１０２において、検知対象判断部１２７は、照合済テーブルＤ１７５（図５参照）から照合状況が空欄（照合未実行）であるレコードを抽出し、抽出したレコードの対応ＩＤと同一の対応ＩＤを有する保守対応実績テーブルＤ１７４内のレコードも抽出し、両者の内容を合わせて照合対象データＤＸ２（図５参照）を取得する。照合対象データＤＸ２の各レコードを、照合対象レコードと呼ぶ。図５に示した例においては、照合対象データＤＸ２には、対応ＩＤが「００ｎ－１」および「００ｎ」である二つの照合対象レコードが含まれている。

次に、処理がステップＳ１０３に進むと、検知対象判断部１２７は、照合対象レコードに対応する、対象事象設定テーブルＤ１７６（図６参照）と、事象マスタテーブルＤ１７２を参照し、検知当否一覧データＤＸ４を生成する。図５に示した例においては、検知対象判断部１２７は、照合対象レコードにおける２つの事象ＩＤ「００ｎ－１」および「００ｎ」をキーとして、対象事象設定テーブルＤ１７６（図６参照）と、事象マスタテーブルＤ１７２を参照し、検知当否一覧データＤＸ４を生成する。

そして、検知対象判断部１２７は、検知当否一覧データＤＸ４に基づいて、２つの事象ＩＤ「００ｎ－１」および「００ｎ」照合対象レコードが検知対象であるか否かを判別する。図６の示の例では、事象ＩＤ「００ｎ－１」の「油漏れ」は検知対象であり、事象ＩＤ「００ｎ」の「燃料タイプ切替過多」は検知対象ではない。

次に、処理がステップＳ１０４に進むと、検知対象判断部１２７は、照合済テーブルＤ１７５における各レコードのうち、照合対象レコードに対応する照合状況を照合済（○）に変更する。図５の例では、検知対象判断部１２７は、照合済テーブルＤ１７５における対応ＩＤが「００ｎ－１」および「００ｎ」レコードにおいて、照合状況を照合済（○）に変更する。

次に、処理がステップＳ１０５に進むと、検知対象判断部１２７は、検知対象一覧データＤＸ４の中に検知対象となるレコードが含まれているか否かを判定する。すなわち、検知当否一覧データＤＸ４において検知対象（○）とされているレコードが含まれているか否かを判定する。含まれていない場合はここで「Ｎｏ」と判定され、本ルーチンの処理は終了する。
図６に示した検知当否一覧データＤＸ４の例においては、事象ＩＤが「００ｎ－１」である「油漏れ」に関する保守作業のレコードは検知対象である。従って、この場合は「Ｙｅｓ」と判定され、処理はステップＳ１０６に進む。

ステップＳ１０６において、検索処理部１２８は、照合対象データＤＸ２の中の検知対象であるレコードについて、所定の検索期間内における異常予兆アラート・データＤ６を検索する。ここで、「検索期間」とは、「保守作業のレコードを保守対応実績テーブルＤ１７４に登録した時刻（または異常事象の発生時刻であってもよい）から所定の検索対象時間Ｔｊ（図１２参照）だけ過去まで遡った期間」である。なお、検索対象時間Ｔｊは、予め定めた固定的な期間であってもよく、異常事象の種類毎に個別に設定した期間であってもよい。

次に、処理がステップＳ１０７に進むと、検索処理部１２８は、異常予兆の失報が発生したか否かを判定する。換言すれば、検索処理部１２８は、診断モデルＤ３の更新が必要であるか否かを判定する。すなわち、異常事象に対応する異常予兆アラート・データＤ６が存在しない場合には、失報が発生したことになり、検索処理部１２８は、診断モデルＤ３の更新が必要である旨を判定する。一方、対応する異常予兆アラート・データＤ６が存在する場合は、失報は発生していないため、検索処理部１２８は、診断モデルＤ３の更新が不要である旨を判定する。すなわち、ステップＳ１０７において「Ｎｏ」と判定され、本ルーチンの処理は終了する。

一方、失報が発生した場合、すなわち対応する異常予兆アラート・データＤ６が存在しない場合には、ステップＳ１０７において「Ｙｅｓ」と判定され、処理はステップＳ１３（図７参照）に進む。但し、失報が生じた場合に直ちにステップＳ１３に進むことに代えて、失報が生じた旨を作業者等に報知し、作業者等が診断モデルＤ３の更新を指示した場合にステップＳ１３以降の処理を実行するようにしてもよい。ステップＳ１３において、モデル更新判定部１２６は、保守対応実績テーブルＤ１７４に追加されたレコードに対応して、診断モデルＤ３の更新態様（新規作成または一部更新）を決定する。以降の処理は上述したものと同様である。

例えば、「一部更新」を行う場合には、ステップＳ２６（図８参照）において、予兆検知部１１６は、稼働データベース１６２に記憶されている稼働データＤ２に基づいて、仮登録した診断モデルＤ３の再学習を実行する。この場合における再学習の内容は、稼働データＤ２に基づいて、失報になった（出力されなかった）異常予兆アラート・データＤ６が、次回からは出力されるように、診断モデルＤ３の再学習を行うことである。

また、診断モデルＤ３の「新規作成」を行う場合は、ステップＳ２（図２参照）において、予兆検知部１１６は、新規の診断モデルＤ３を作成する。この場合も、予兆検知部１１６は、稼働データＤ２に基づいて、失報になった（出力されなかった）異常予兆アラート・データＤ６が、次回からは出力されるように、新規の診断モデルＤ３を作成する。

図１２は、異常度Ｄ４の推移の一例を示す図である。
図１２において、縦軸は異常度Ｄ４であり、横軸は時刻ｔである。予兆検知部１１６（図１参照）は、異常度Ｄ４が閾値ＴｈＤを超えた場合に異常予兆アラート・データＤ６を生成する。そして、時刻ｔ10に、異常度Ｄ４に対応する異常事象が発生したとする。なお、時刻ｔ10は、保守作業のレコードを保守対応実績テーブルＤ１７４に登録した時刻であってもよい。時刻ｔ10から検索対象時間Ｔｊだけ過去に遡った時刻をｔ4とする。図示の例では、時刻ｔ4～ｔ10の期間内に含まれる時刻ｔ6，ｔ8において異常度Ｄ４が閾値ＴｈＤを超えている。従って、時刻ｔ6，ｔ8において異常予兆アラート・データＤ６が発生するため、検索処理部１２８（図１参照）は「失報は発生していない」と判定する。

図１３は、異常度Ｄ４の推移の他の例を示す図である。
図１３においても、縦軸は異常度Ｄ４であり、横軸は時刻ｔであり、検索対象時間Ｔｊ、時刻ｔ4，ｔ10の意義も図１２と同様である。図１３の例においては、時刻ｔ4以前の時刻ｔ2において異常度Ｄ４が閾値ＴｈＤを超えており、その時点で異常予兆アラート・データＤ６が発生する。しかし、時刻ｔ4以前に発生した異常予兆アラート・データＤ６は、時刻ｔ10における異常事象との関連性が薄いものと考えられる。このため、本実施形態においては、図示のような状況では、「失報が発生した」と判定し、上述のように診断モデルＤ３を更新するようにした。

［実施形態の効果］
以上のように上述の実施形態によれば、異常予兆診断装置１００は、監視対象設備２００の状態を取得した稼働データＤ２と、診断モデルＤ３と、に基づいて、監視対象設備２００の異常予兆の発生を示す異常予兆アラート・データＤ６を生成する予兆検知部１１６と、監視対象設備２００に異常事象が発生した場合に、当該異常事象は、予兆検知部１１６が対応する異常予兆アラート・データＤ６を事前に生成すべき検知対象であるか否かを判定する検知対象判断部１２７と、検知対象判断部１２７の判定結果が肯定であった場合に、異常事象に対応する異常予兆アラート・データＤ６が事前に生成されていない失報が生じたか否かを判定し、失報が生じた場合には、診断モデルＤ３の更新が必要である旨を判定する検索処理部１２８と、を備える。これにより、現状の診断モデルＤ３によって失報が生じたか否かを判定できるため、診断モデルＤ３の更新の要否を適切に判定できる。

また、検知対象判断部１２７は、異常事象の種類を識別する異常事象識別情報（事象ＩＤ）と、異常事象識別情報（事象ＩＤ）が検知対象であるか否かを定めた検知当否情報と、を対応付けた対象事象設定テーブルＤ１７６を参照して、異常事象が検知対象であるか否かを判定すると一層好ましい。これにより、対象事象設定テーブルＤ１７６によって、検知対象とする異常事象と、それ以外の異常事象とを明確に区別できる。

また、検索処理部１２８は、異常事象の発生時刻または異常事象の登録時刻から所定の検索対象時間Ｔｊだけ過去に遡った時刻までの期間に発生した異常予兆アラート・データＤ６の中から、異常事象に対応する異常予兆アラート・データＤ６が存在するか否かを判定し、判定結果が否定である場合に失報が生じたと判定すると一層好ましい。これにより、異常予兆アラート・データＤ６の発生から対応する異常事象が発生するまでの時間が長すぎる場合には、失報が生じたと判定できるため、診断モデルＤ３の更新の要否を一層適切に判定できる。

［変形例］
本発明は上述した実施形態に限定されるものではなく、種々の変形が可能である。上述した実施形態は本発明を理解しやすく説明するために例示したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記実施形態の構成に他の構成を追加してもよく、構成の一部について他の構成に置換をすることも可能である。また、図中に示した制御線や情報線は説明上必要と考えられるものを示しており、製品上で必要な全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。上記実施形態に対して可能な変形は、例えば以下のようなものである。

（１）上記実施形態における異常予兆診断装置１００のハードウエアは一般的なコンピュータによって実現できるため、図７、図８、図１１に示したフローチャート、その他上述した各種処理を実行するプログラム等を記憶媒体に格納し、または伝送路を介して頒布してもよい。

（２）図７、図８、図１１に示した処理、その他上述した各処理は、上記実施形態ではプログラムを用いたソフトウエア的な処理として説明したが、その一部または全部をＡＳＩＣ(Application Specific Integrated Circuit；特定用途向けＩＣ)、あるいはＦＰＧＡ(Field Programmable Gate Array)等を用いたハードウエア的な処理に置き換えてもよい。

（３）上記実施形態において実行される各種処理は、図示せぬネットワーク経由でサーバコンピュータが実行してもよく、上記実施形態において記憶される各種データも該サーバコンピュータに記憶させるようにしてもよい。

１００ 異常予兆診断装置
１１６ 予兆検知部（予兆検知手段）
１２７ 検知対象判断部（検知対象判断手段）
１２８ 検索処理部（検索処理手段）
２００ 監視対象設備
９００ コンピュータ
Ｄ２ 稼働データ
Ｄ３ 診断モデル
Ｄ６ 異常予兆アラート・データ
Ｔｊ 検索対象時間
Ｄ１７６ 対象事象設定テーブル

Claims (2)

1. 監視対象設備の状態を取得した稼働データと、診断モデルと、に基づいて、前記監視対象設備の異常予兆の発生を示す異常予兆アラート・データを生成する予兆検知部と、
   前記監視対象設備に異常事象が発生した場合に、前記異常事象の種類を識別する異常事象識別情報と、前記異常事象識別情報が検知対象であるか否かを定めた検知当否情報と、を対応付けた対象事象設定テーブルを参照して、前記異常事象は、前記予兆検知部が対応する前記異常予兆アラート・データを事前に生成すべき前記検知対象であるか否かを判定する検知対象判断部と、
   前記検知対象判断部の判定結果が肯定であった場合に、前記異常事象に対応する前記異常予兆アラート・データが事前に生成されていない失報が生じたか否かを判定し、前記失報が生じた場合には、前記診断モデルの更新が必要である旨を判定する検索処理部と、を備え、
   前記検索処理部は、前記異常事象の発生時刻または前記異常事象の登録時刻から、前記異常事象の種類毎に設定した期間である検索対象時間だけ過去に遡った時刻までの期間に発生した前記異常予兆アラート・データの中から、前記異常事象に対応する前記異常予兆アラート・データが存在するか否かを判定し、判定結果が否定である場合に前記失報が生じたと判定する
   ことを特徴とする異常予兆診断装置。
2. コンピュータを、
   監視対象設備の状態を取得した稼働データと、診断モデルと、に基づいて、前記監視対象設備の異常予兆の発生を示す異常予兆アラート・データを生成する予兆検知手段、
   前記監視対象設備に異常事象が発生した場合に、前記異常事象の種類を識別する異常事象識別情報と、前記異常事象識別情報が検知対象であるか否かを定めた検知当否情報と、を対応付けた対象事象設定テーブルを参照して、前記異常事象は、前記予兆検知手段が対応する前記異常予兆アラート・データを事前に生成すべき前記検知対象であるか否かを判定する検知対象判断手段、
   前記検知対象判断手段の判定結果が肯定であった場合に、前記異常事象に対応する前記異常予兆アラート・データが事前に生成されていない失報が生じたか否かを判定し、前記失報が生じた場合には、前記診断モデルの更新が必要である旨を判定する検索処理手段、
   として機能させるためのプログラムであって、
   前記検索処理手段は、前記異常事象の発生時刻または前記異常事象の登録時刻から、前記異常事象の種類毎に設定した期間である検索対象時間だけ過去に遡った時刻までの期間に発生した前記異常予兆アラート・データの中から、前記異常事象に対応する前記異常予兆アラート・データが存在するか否かを判定し、判定結果が否定である場合に前記失報が生じたと判定する
   ことを特徴とするプログラム。

Images