JP5129725B2 - 装置異常診断方法及びシステム - Google Patents

Description

本発明は、装置（設備等）の異常の診断、検知及び保守等の技術に関し、特に、装置の異常予兆の検知時または異常発生時に、その原因を診断し、対策またはメンテナンス（保守）内容等を指示するための、異常診断モデルの作成方法及びそのシステムに関する。

例えばコジェネレーション装置や真空装置など、各種の装置は、故障無く安定稼動することが必要最低限の機能として求められている。また、当該装置が故障した際にも、できるだけ早く正常な状態に復旧させなければならない。一方、複雑化や多機能化が進む装置では、装置故障の種類も多数存在する。しかしながら、必ずしも事前に全ての故障に対する対策方法が確立している訳ではない。そのため、装置の異常予兆を検知した際や異常が発生した際における対策は、保守作業を行う者（作業員）の過去の知識に依存することも多い。

このような作業員の知識に依存する保守作業では、取り扱う装置の台数が増加することに伴い、保守作業の品質が低下するという問題が生じてくる。

そこで、情報処理システムを用いて、装置の異常を診断、検知し、対策または保守内容等を指示することが考えられる。

従来においても、装置の故障対策に関する属人的な知識を情報処理システムに格納し、今までの作業員の知見に基づく判断に代わり、情報処理システムに装置で発生している現象を与え、その異常の原因や対策方法を出力する異常診断の方法またはシステムが報告されている。例えば以下のような従来技術がある。

特開平４−７４２２４号公報（特許文献１）の技術では、診断対象となる機器の構成要素の相互関係を示す構造知識と、構成要素毎の故障知識を入力し、これらの知識の推論処理により機器の構成要素の相互関係に基づいた故障の因果関係の連鎖を作成している。

特開平４−３５９６４０号公報（特許文献２）の技術では、装置で発生する現象とその原因項目の因果関係を記号で表現し、記号の種類に基づき因果関係の強さが区別できる数値に置き換え、原因毎の加算値の合計値が大きい順に原因となる可能性が高い候補として出力する。

特開平９−７３３１５号公報（特許文献３）の技術では、故障に関する事例を、症状、原因、処置、及び処置の評価に分けて、各項目に関する自然言語による自由構文で入力した情報を格納し、事例情報の中から、症状、原因、処置、及び処置の評価を特徴付ける用語を抽出し、症状、原因、処置、及び処置の評価別の用語に整理された形で故障事例を作成している。そして、症状、原因、及び処置に関するキーワードの入力により、過去の故障事例から類似するまたは一致する故障事例を検索している。

特開２００１−３３７８２８公報（特許文献４）の技術では、予め、装置の構成要素毎に、異常症状、症状の判定条件、原因、及び対策を入力して異常知識ルールを作成する。そして、装置から警報が発生した際、異常知識ルールに基づき、ルールに該当する異常症状、原因、及び対策を出力する。
特開平４−７４２２４号公報 特開平４−３５９６４０号公報 特開平９−７３３１５号公報 特開２００１−３３７８２８号公報

前記従来技術例（異常診断方法等）では、診断や対策指示等の実現のためには、所定のモデル（異常診断モデル）の存在が前提条件となっている。また、故障事例の情報、例えば装置の構成要素毎に発生した、症状、原因、及び対策等に関する情報の入力が前提条件となっている。

しかしながら、モデルを作成または更新するために人的作業が必要であり、故障事例の情報の入力自体に多くの工数を要し、コストが高くなる。特に、診断対象となる装置の数や故障の種類が多くなるにつれて、異常診断に必要な故障事例の情報の入力に要する工数が大きくなり、システムの実際の運用が難しくなってくる。

また、新しい故障事例を入力する際、入力者の判断により故障事例の表現が異なるため、正しく故障事例データを作成できない可能性もある。

また、診断対象となる装置の複雑化（複数のセンサを設ける等）により、適切なモデルの作成が難しくなってくる。

また、必ずしも、システム（異常診断システム）の導入段階において、全ての故障に対する対策方法が入力されているとは限らない。そのため、新規の故障事例に対しても容易にモデルを追加・更新することができる仕組みが必要であると考えられる。

前記特許文献１の技術では、前記構造知識と構成要素毎の故障知識の入力が必要であるが、これらの情報を自動的に入力する手段については説明されていない。

前記特許文献２の技術では、装置で発生する現象とその原因項目の因果関係が入力情報となっているが、その因果関係を自動的に入力する手段については説明されていない。

前記特許文献４の技術では、装置の構成要素毎に、異常症状、症状の判定条件、原因、及び対策が入力情報となっているが、これらの情報を自動的に入力する手段については説明されていない。

前記特許文献３の技術では、故障に関する事例を、前記症状、原因、処置、及び処置の評価に分けて、各項目に関する自然言語による自由構文が入力情報であるため、上記特許文献１，２，４の技術と比べると、入力自体に要する工数は少なくなるが、入力する手段については説明されていない。

本発明は以上のような問題に鑑みてなされたものであり、その主な目的は、装置異常診断システムに係わり、最初及び新規（追加・更新）の故障事例に対して容易にモデル（異常診断モデル）を作成及び追加・更新することができ、そのモデルを用いることで異常の診断・検知や対策・保守指示等を、的確に、効率的に実現できる技術を提供することである。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。前記目的を達成するために、本発明の代表的な実施の形態は、コンピュータによる情報処理を用いて、対象とする装置の異常予兆の検知時または異常の発生時（一般的に「異常時」等と総称できる）に、その異常原因を診断・推定し、その対策または保守の作業内容等を指示（情報出力）するための装置異常診断処理を行う方法またはシステムに係わり、以下に示す構成を有することを特徴とする。

本形態では、装置異常診断処理に用いるモデル（異常診断モデル）を情報処理（統計的処理）によって自動的に作成及び追加・更新等し、そのモデルを用いて装置異常診断処理を行う。本特徴の１つは、そのモデルの作成方法であり、従来技術とは異なるグラフネットワークを用いる技術である。

本形態は、装置異常診断処理のための装置異常診断モデル作成処理において、例えば以下のような処理ステップ（コンピュータの情報処理により実現される）を有する。

（Ｓ１）前記装置に関する保守作業データ（装置識別番号、保守作業の日時、種類、及び保守対象となった部品情報などを含む）と、当該保守作業データ（日時など）をもとに、所定時間内に発生した、前記アラームデータ（アラームの種類、及び発生日時などを含む）、及び前記稼動イベントデータ（当該装置の稼働イベント（動作状態）の種類、及び発生日時などを含む）と、を取得（収集）する第１の処理ステップ。

（Ｓ２）前記第１の処理ステップで取得したデータを用いて、当該保守作業データ（種類など）とそれに関連する稼動イベント（種類など）またはアラーム（種類など）の少なくとも一方との間の因果関係を、グラフネットワーク構造によって表現される因果関係モデルとして作成する第２の処理ステップ。

（Ｓ３）前記第２の処理ステップで作成した新規の因果関係モデルを今までに作成された因果関係モデル（（旧）異常診断モデル）に対して合成し、当該グラフネットワーク構造における更新されたノード間の発生確率を再計算することで、当該因果関係モデルを含んで成る前記異常診断モデルを更新する処理を行う第３の処理ステップ。

更に、本形態の方法は、新規の前記稼働イベントデータまたはアラームデータの少なくとも一方と、前記第３の処理ステップで更新された最新の異常診断モデルとを用いて、前記装置異常診断処理を行う第４の処理ステップを有する。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。本発明の代表的な実施の形態によれば、装置異常診断システムに係わり、最初及び新規（追加・更新）の故障事例に対して容易にモデル（異常診断モデル）を作成及び追加・更新することができ、そのモデルを用いることで異常の診断・検知や対策・保守指示等を、的確に、効率的に実現できる。

特に、本形態によれば、新規に発生する異常対策結果を容易にモデルに反映させることができるため、取り扱う装置の台数が多い場合においても効率的に異常診断が可能である。また、統計的な処理を行うことより、今まで気づかなかった故障メカニズムの解明に寄与することができる。

以下、本発明の実施の形態（装置異常診断モデル作成方法を含む装置異常診断方法、及びその方法に従う処理を実行する情報処理システム）を図面（図１〜図２１）に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。本診断方法は、本作成方法により作成する異常診断モデルを用いて、対象の装置の異常予兆検知時または異常発生時にその原因を診断する方法である。

本実施の形態のシステムでは、概要として、図１のような構成において、装置１を対象とした異常診断モデルを作成する処理においては（図５）、保守作業、稼働イベント、及びアラームのデータ間におけるグラフネットワーク構造の因果関係モデルを作成し（Ｓ１０４、及び図７等）、旧モデルを更新する（Ｓ１０６）。また、その異常診断モデルを用いて装置１の異常を診断する処理においては（図６）、所定時間単位で、保守作業、稼働イベント、及びアラームのデータから作成したアラーム構造データ（Ｓ２０３）に一致するデータをモデル内から抽出し（Ｓ２０４）、異常対策候補情報を出力する（Ｓ２０５）。

＜システム＞
図１は、本実施の形態の情報処理システム（異常診断システムを含む）のブロック構成を示す。本情報処理システムにおいて、装置１、外部の異常検知システム（センサデータ条件検知システム）２、異常診断システム１００を含んでいる。その他、保守の作業員が使用する保守端末９０などを有する。本実施の形態の情報処理システムは、異常診断システム１００を中心に構成される。異常診断システム１００は、所定の装置（設備等）１を対象として、装置異常診断モデル作成処理と装置異常診断処理とを含む処理を行う機能を備える。異常診断システム１００は、１つ以上のコンピュータ等から構成される。当該コンピュータは、例えばプロセッサ、メモリ、通信インタフェース等（データ演算部）を備える一般的なコンピュータであり、本システムの管理者等が使用する。

異常診断システム１００は、データ収集処理部４、装置データ履歴格納部５、保守作業データ履歴格納部６、異常診断モデル作成処理部７、異常診断モデル格納部８、異常診断処理部１０などを備える。各機能は、例えばプロセッサがメモリ上のプログラムを実行すること等により実現される。各格納部は、例えばデータベースなどにより実現される。

装置１は、複数のセンサデータＤ１、稼動イベントデータＤ２、アラームデータＤ３などのデータを出力する。装置１は、図１では１つの装置であり、複数のセンサが搭載（内蔵または外部設置）されている。

外部の異常検知システム２は、装置１からのデータ（複数のセンサデータＤ１、稼動イベントデータＤ２）の入力（収集）をもとに、異常予兆または異常の検知の処理を行うことで、アラームデータＤ３（Ｄ３’）などのデータを出力する。なお装置１からのアラームデータＤ３と異常検知システム２からのアラームデータＤ３（Ｄ３’）とは、同種の情報である。

また装置１を保守した実績・内容を表す情報として、保守作業データＤ４を有する。例えば、装置１を保守する作業員が使用する保守端末９０に、作業員により、保守作業データＤ４が入力される。

データ収集処理部４は、保守作業データＤ４、アラームデータＤ３、および稼動イベントデータＤ２などのデータを収集する。装置データ履歴格納部５は、装置データＤ７（アラームデータＤ３、稼働イベントデータＤ２等）及びその履歴を格納する。保守作業データ履歴格納部６は、保守作業データＤ４及びその履歴を格納する。異常診断モデル格納部７は、異常診断モデルデータＤ５を格納する。

異常診断モデル作成処理部７は、新規に収集した保守作業データＤ４に対して、アラーム（Ｄ３）及び稼動イベント（Ｄ２）と保守作業種類（Ｄ４）との間の因果関係モデルを作成し、過去に作成済みの（旧）因果関係モデルを含んで成る（旧）異常診断モデルを更新する。異常診断モデル作成処理部７は、一番最初のモデルの作成も、そのモデルの更新も行う。

データ収集処理部４では、装置１から出力されるアラームデータＤ３及び／又は稼動イベントデータＤ２（少なくとも一方）を収集し、装置データ履歴格納部５に登録する。また、データ収集処理部４は、外部の異常検知システム２から出力されるアラームデータＤ３（Ｄ３’）に関しても収集し、装置データ履歴格納部５に登録する。また、データ収集処理部４では、装置１に関する保守作業が実施された後、作成される当該保守作業データＤ４を収集し、保守作業データ履歴格納部６に登録する。

外部の異常検知システム２では、装置１から出力される複数のセンサデータＤ１を収集し、当該センサデータＤ１と、予め設定されているしきい値とを用いたデータ処理により、センサデータＤ１に関し異常予兆（または異常）があるかどうかを判定し、ある場合はアラームデータＤ３（Ｄ３’）を出力する。例えば、センサデータＤ１の値が、設定された上限のしきい値を超えた場合、または下限のしきい値を下回った場合、異常検知システム２からアラームデータＤ３（Ｄ３’）が出力される。この異常予兆の判定処理では、センサデータＤ１を収集した後、標準偏差や平均値といった所定の演算を行った結果に関して、しきい値判定を行ってもよい。

異常診断モデル作成処理部７では、データ収集処理部４を介して新規に保守作業データＤ４を収集した際、装置データ履歴格納部５から、該当装置１に関する過去のアラーム（Ｄ３）及び稼動イベント（Ｄ２）の履歴データ（装置データＤ７）を取得する。そして、異常診断モデル作成処理部７では、アラーム（Ｄ３）及び稼動イベント（Ｄ２）と保守作業種類（Ｄ４）との因果関係モデルを作成し、（旧）異常診断モデルを更新し、これによる最新の異常診断モデルを異常診断モデル格納部８に登録する。

装置データ履歴格納部５は、データ収集処理部４、異常診断モデル作成処理部７、異常診断処理部１０に接続されており、データ収集処理部４から送信されるデータを登録し、異常診断モデル作成処理部７からの要求に応じて、蓄積されているデータを引渡す。装置データ履歴格納部５の装置データＤ７として、アラームデータＤ３または稼動イベントデータＤ２の少なくとも一方の情報データなどが含まれる（図３）。この装置データＤ７におけるアラームデータＤ３は、例えば、装置個体番号、アラーム種類、およびアラーム発生日時を含む。またこの装置データＤ７における稼動イベントデータＤ２は、装置個体番号、装置の動作状態の種類（稼働イベント種類）、および装置動作の発生日時（稼働イベント発生日時）を含む。

保守作業データ履歴格納部６は、データ収集処理部４および異常診断モデル作成処理部７に接続されており、データ収集処理部４から送信されるデータを登録し、異常診断モデル作成処理部７からの要求に応じて、蓄積されているデータを引渡す。保守作業データ履歴格納部６の保守作業データ（履歴）Ｄ４として、例えば、装置個体番号、保守作業の日時（開始・終了日時）、保守作業の種類、及びその際に保守対象となった部品番号、などが含まれる（図４）。

異常診断モデル格納部８は、異常診断モデル作成処理部７及び異常診断処理部１０に接続されており、異常診断モデル作成処理部７で作成された異常診断モデルのデータＤ５を登録する。異常診断モデルは、例えば、保守作業種類に関連する稼動イベント及びアラーム種類の因果関係を表すグラフネットワーク構造データである。異常診断モデルは、グラフネットワークのノード毎に、該当ノードへの入力関係となる１つ以上のノード間の発生パターン、及び、該当ノードからの出力関係となる１つ以上のノード間の発生パターン、のすべての組み合わせに応じた発生確率データを備えている（図１２等）。なお、異常診断モデルは、１つ以上の因果関係モデルの合成から成る。

また、本システムは、異常診断処理に係わる異常診断処理部１０を有する。異常診断処理部１０は、１つ以上の保守作業種類、対象の部品番号、及びその発生確率などの情報を取得し、画面に出力する。当該画面は、例えば異常診断システム１００または保守端末９０等が備える表示装置の画面である。

異常診断処理部１０では、データ収集処理部４を介して新規にアラームデータＤ３を取得した際、装置データ履歴格納部５から、該当装置１に関する、所定時間内に発生した過去のアラーム（Ｄ３）及び稼動イベント（Ｄ２）の履歴データ（装置データＤ７）を取得し、アラーム（Ｄ３）及び稼動イベント（Ｄ２）の発生パターンを作成する。そして、異常診断処理部１０では、異常診断モデル格納部８から該当装置１の（旧）異常診断モデルのデータＤ５を取得し、今回のアラーム（Ｄ３）及び稼動イベント（Ｄ２）の発生パターンと一致する中から、今回の発生パターンと一致する、１つ以上の保守作業種類、対象部品番号、及びその発生確率の情報を取得し、異常対策候補情報（保守内容指示情報）Ｄ６として、画面に出力する。

＜センサデータ＞
図２は、装置１から出力されるセンサデータＤ１の出力結果の一例を示す。装置１に搭載されている１つ以上（本例では複数）のセンサは、一定周期で、各センサにおける計測結果（状態計測値）を出力する。センサデータＤ１の項目として、例えば、ａで示す装置個体番号、ｂで示す計測日時、ｃで示す１つ以上のセンサの計測結果（センサデータ）、などが含まれる。

＜装置データ（アラームデータ、稼働イベントデータ）＞
図３は、装置１のアラームデータＤ３及び稼動イベントデータＤ２を含む装置データＤ７（履歴）の出力結果の一例を示す。稼動イベントデータＤ２は、装置１の稼働イベント（動作状態）に関する情報である。アラームデータＤ３は、異常予兆または異常発生を表す情報である。

装置データＤ７（履歴）におけるアラームデータＤ３及び稼動イベントデータＤ２の項目として、例えば、ａで示す装置個体番号、ｂで示す発生日時、ｃで示すデータ種別、ｄで示すコード番号、及びｅで示す内容情報、などが含まれる。

発生日時（ｂ）は、アラーム発生日時または稼動イベント発生日時などを示す。データ種別（ｃ）は、当該データ（行）が、装置１から出力されるアラームデータＤ３または稼動イベントデータＤ２であるか、もしくは、外部の異常検知システム２から出力されるアラームデータＤ３（Ｄ３’）であるか、等の種別を判別するための情報である。本例では、“Ｅ”の記号は装置１から出力された稼働イベントデータ（Ｄ２）を示し、“Ａ”の記号は装置１から出力されたアラームデータＤ３を示し、“Ｗ”の記号は、外部の検知システムから出力されたアラームデータＤ３（Ｄ３’）を示す。コード番号（ｄ）は、アラーム種類、または稼動イベント種類などを示す。コード番号（ｄ）は、先頭の記号はデータ種別（ｃ）と共通であり、その記号に続く“００１”等の数値により、より詳細な内容を規定する。内容情報（ｅ）は、当該コード番号（ｄ）に対応付けられる、アラームもしくは稼動イベント等の内容を、テキストで表す情報である。アラームは、例えば、センサデータＤ１の値が正常なしきい値範囲に収まらないことを示すアラームなどがある。稼動イベントは、例えば、電源オン／オフ、起動、停止等がある。

アラームデータＤ３には、アラーム種類としては、装置異常に至る前の予兆状態（異常予兆）を警報するアラーム種類や、異常が発生した後の装置停止状態（指示）を出力するアラーム種類などが存在する。本例では、このようなアラーム種類は、コード番号（ｄ）におけるデータ種別（ｃ）の記号に続く数値の違いにより区別されている。例えば、“Ａ００１”は、センサＡの上限のしきい値を超えることを示す。“Ａ００２”は、センサＢの下限のしきい値を下回ることを示す。“Ａ００３”は、装置１の圧力異常の発生により装置１を停止させることを示す。

なお、装置異常診断処理にあたっては、アラームデータＤ３と稼動イベントデータＤ２の両方が必要になるとは限らず、一方を用いることで可能な場合もある。

＜保守作業データ＞
図４は、装置１の保守作業データＤ４（履歴）の出力結果の一例を示す。保守作業データＤ４の項目として、例えば、ａで示す装置個体番号、ｂで示す保守作業の発生日時、ｃで示す作業者番号、ｄで示す作業種別、ｅで示す作業コード番号、ｆで示す部品番号、ｇで示す作業内容情報、などが含まれる。

作業種別（ｄ）は、定期点検やトラブル対策等の、保守作業の種別を示す。本例では、“Ｃ”の記号は、定期的（例えば、日次もしくは週次など）で定型の保守作業もしくは確認作業の種類を表す。“Ｔ”の記号は、装置１に故障や不具合が発生した際に非定常的に行うトラブル対策の保守作業を表す。作業コード番号（ｅ）は、各保守作業の種類を示す。作業コード番号（ｅ）は、先頭の記号は作業種別（ｄ）と共通であり、その記号に続く“００１”等の数値により、より詳細な内容を規定する。

部品番号（ｆ）は、該当保守作業において対象とした部品の部品番号を示す。作業内容情報（ｇ）は、当該作業コード番号（ｅ）に対応付けられる保守作業内容を、テキストで表す情報である。

＜異常診断モデル作成処理フロー＞
図５は、本実施の形態における装置異常診断モデル作成処理のフローを示す（Ｓは処理ステップを示す）。処理主体は異常診断システム１００の各処理部（主に異常診断モデル作成処理部７）である。

まずＳ１０１において、異常診断モデル作成処理部７は、装置個体番号、保守作業の開始・終了日時、保守作業の種類、及びその際に保守対象となった部品番号を含む、保守作業データＤ４を取得する。

Ｓ１０２では、異常診断モデル作成処理部７は、Ｓ１０１で取得した保守作業データＤ４の内容が、トラブル対策作業であるかどうか判定する。この判定は、保守作業データＤ４における前記作業種別（ｄ）（または作業コード番号（ｅ））を参照することで可能であり、前記“Ｔ”の場合がトラブル対策作業である。今回取得した保守作業データＤ４がトラブル対策作業を示している場合（Ｙ）、Ｓ１０３に進む。トラブル対策作業ではなく定期点検または確認作業等であった場合（Ｎ）は、本処理を終了する。

Ｓ１０３では、異常診断モデル作成処理部７は、今回取得した保守作業日時（前記発生日時（ｂ））から所定時間内に発生した、該当装置１のアラーム種類及びアラーム発生日時を含むアラームデータＤ３と、装置１の動作状態の種類及び装置動作の発生日時を含む稼動イベントデータＤ２とを取得する。尚ここで取得するアラームデータＤ３は、装置１から直接出力されるアラームデータＤ３の他に、外部の異常検知システム２から出力されるアラームデータＤ３’を含んでいてもよい。

Ｓ１０４において、異常診断モデル作成処理部７は、Ｓ１０１及びＳ１０３で取得したデータ（Ｄ４，Ｄ３，Ｄ２）を用いて、保守作業種類（前記作業コード番号（ｅ））に関連する稼動イベント及びアラーム種類（前記コード番号（ｄ））の間の因果関係をグラフネットワーク構造によって表現する因果関係モデルを作成する。これら３つの情報の間の因果関係モデルの作成方法については、後ほど図１２等を用いて詳細に説明する。

Ｓ１０５において、異常診断モデル作成処理部７は、異常診断モデル格納部８からの検索により、該当装置１に関する複数の因果関係モデルの合成で表現される既存の異常診断モデルを取得する。

Ｓ１０６では、異常診断モデル作成処理部７は、Ｓ１０５で取得した既存（旧）の異常診断モデルに対し、前記Ｓ１０４で作成した新規の因果関係モデルを合成し、更新されたノード間の発生確率を再計算し、処理を終了する。Ｓ１０６における因果関係モデルの合成処理、並びにノード間の発生確率の計算方法については、後ほど図９〜図１２等を用いて詳しく説明する。

＜異常診断処理フロー＞
図６は、本実施の形態における装置異常診断方法に従う装置異常診断処理のフローを示す。まずＳ２０１において、異常診断処理部１０は、アラームデータＤ３（装置個体番号、アラーム種類、およびアラーム発生日時を含む）を取得する。

Ｓ２０２では、異常診断処理部１０は、Ｓ２０１で取得したアラームデータＤ３の発生日時から所定時間内に発生した、該当装置１のアラームデータＤ３、稼動イベントデータＤ２（装置の動作状態の種類および装置動作の発生日時を含む）、及び保守作業データＤ４（保守作業の開始・終了日時、保守作業の種類を含む）を取得する。

Ｓ２０３において、異常診断処理部１０は、Ｓ２０１及びＳ２０２で取得したアラームデータＤ３、稼動イベントデータＤ２、及び保守作業データＤ４における発生日時順に基づいて、今回のアラーム発生時における、アラーム、稼動イベント、及び保守作業種類の発生順序パターンを表すアラーム構造データ（後述）を作成する。この際、アラーム構造データは、１つに限らず、Ｓ２０２で取得したデータ（Ｄ２，Ｄ３，Ｄ４）の組み合わせに応じて、複数が作成される。

Ｓ２０４において、異常診断処理部１０は、複数の因果関係モデルで表現される（旧）異常診断モデル内から、Ｓ２０３で作成した１つ以上のアラーム構造データに一致するグラフネットワーク部を抽出する。このグラフネットワーク部抽出処理では、対象とするアラーム構造データにおけるアラームまたは稼動イベントまたは保守作業種類の発生パターンの順に、当該異常診断モデルにおけるグラフ経路（ノード、リンク）を探索してゆく。そして、当該異常診断モデル内に当該アラーム構造データと経路が一致するグラフパターン箇所が存在し、かつ、最後のノードから出力先となるノードが保守作業種類である場合に、即ちこの場合を抽出条件として、当該アラーム構造データと一致したグラフネットワーク部が抽出される。

異常診断モデルの各ノードには、該当ノード（例えばＡ０２）への入力関係となるノードの組み合わせ（例えばＡ０１、Ｅ０１、Ａ０１→Ｅ０１）、および、該当ノードからの出力関係となるノードの組み合わせ（例えばＴ０１、Ｔ０２、Ｔ０３）に応じた発生確率データ（例えば８０１）を持っている。そのため、対象となるアラーム構造データの発生確率を計算することができる。

Ｓ２０５において、異常診断処理部１０は、Ｓ２０４で抽出された、今回のアラーム構造データと一致する異常診断モデルのグラフネットワーク部のデータを用いて、今回のアラーム構造データ毎の、対策すべき保守作業種類、対象となる部品番号、及び発生確率などを含む情報（異常対策候補情報Ｄ６）を出力する。

＜因果関係モデル、異常診断モデル＞
図７は、稼動イベント、アラーム種類、及び保守作業種類の因果関係を表す異常診断モデルの一例を示す。簡単のため、１つのノードに関する因果関係モデルのみを含んで成る異常診断モデルの場合を示しているが、複数の因果関係モデルの合成から成る場合も同様である。本例では、「Ａ０２」ノードに関する因果関係モデルを含む異常診断モデル８００、及び「Ａ０２」ノードに関する発生確率データ（表）８０１を示している。

丸枠で囲まれたノードは、アラーム種類もしくは稼動イベント種類を示す。四角枠で囲まれたノードは、保守作業種類を示す。ここでは、ノードのラベルが「Ａ」で始まるコード番号は、アラーム種類を示す。ノードのラベルが「Ｅ」で始まるコード番号は、稼動イベント種類を示す。ノードのラベルが「Ｔ」で始まるコード番号は、保守作業種類（トラブル対策）を示す（図３や図４のコードと同様）。各ノード間の矢印によるリンクは、それぞれのノード間の因果関係を示しており、矢印の元となるノードが、矢印の先となるノードに影響を与えている。

本例では、因果関係モデル（８００）において、「Ａ０２」は、「Ａ０１」及び「Ｅ０１」が入力関係にあり、「Ｔ０１」及び「Ｔ０２」及び「Ｔ０３」が出力関係となる。また、「Ａ０２」には、表（８０１）に示す通り、入力関係となるノードと出力関係となるノードとの組み合わせに対応した発生確率データを備えている。この表（８０１）に従うと、「Ａ０１」の後に「Ａ０２」が発生した場合（入力の「Ａ０１」の行）、「Ｔ０１」の作業が行われた確率が“０．６”、「Ｔ０２」の作業が行われた確率が“０．４”となっている。また同様に、「Ｅ０１」の後に「Ａ０２」が発生する場合（入力の「Ｅ０１」の行）、「Ｔ０１」の発生確率が“０．５”、「Ｔ０３」の発生確率が“０．５”となる。また、「Ａ０１」の後の「Ｅ０１」の後に「Ａ０２」が発生する場合（入力の「Ａ０１→Ｅ０１」の行）、「Ｔ０１」の発生確率が“０．３”、「Ｔ０１」の発生確率が“０．３”、「Ｔ０４」の発生確率が“０．４”となる。また、「Ａ０２」が単独で発生する場合（入力の「−」（無し）の行）、「Ｔ０２」の発生確率が“０．８”、「Ｔ０３」の発生確率が“０．２”となる。

前記Ｓ２０３で作成されるアラーム構造データは、アラームに関する組み合わせ関係、ないし発生パターン（言い換えれば、装置１に関する、アラーム、稼動イベント、及び保守作業種類の発生順序パターン）を示す。図７の例では、「Ａ０２」ノード（第２のアラーム）に関するアラーム構造データにおいて、入力を例えば「Ａ０１」ノード（第１のアラーム）としたとき、出力が「Ｔ０１」ノードまたは「Ｔ０２」ノードとなる（表（８０１）：入力の「Ａ０１」の行）。

＜異常診断結果＞
図８は、本診断方法による異常診断処理部１０の処理（図６）における装置異常診断結果の一例（診断結果情報９００）を示している。診断結果情報９００において、ａで示すアラーム構造データ、ｂで示す発生確率、ｃで示す対策作業コード、ｄで示す作業内容、ｅで示す対象部品番号を有する。

本例では、ａで示すアラーム構造データにより「Ａ０１」→「Ａ０２」の順でアラームが発生している。図７で示した異常診断モデル８００により、今回のアラーム構造データ（ａ）に一致するグラフネットワーク部を抽出した結果（Ｓ２０４、表（８０１）：入力の「Ａ０１」の行）、対策すべき作業を示す作業コード（ｃ）である「Ｔ０１」，「Ｔ０２」、及びそれら作業の発生確率（ｂ）である“０．６”，“０．４”が情報として出力される。また、各対策作業コード（ｃ）と一対一に関係付けられている、作業内容（ｄ）の情報や、対象部品番号（ｅ）の情報も同時に出力される。例えば、「Ｔ０１」は装置１の部品交換を示し、また、その対象となる部品の番号が“Ｐ００１”である。また、発生確率（ｂ）が“０．６”と大きい方の情報から順に出力される。これら出力情報は、異常対策候補（リスト）情報Ｄ６として、例えば異常診断処理部１０から保守端末９０へ送信され画面へ表示される。作業員は、その画面の情報を見て、対策作業として例えば「Ｔ０１」の部品交換が有効の可能性が高いとすぐに判断でき、効率的に作業を行うことができる。

＜装置例＞
図９は、本実施の形態で対象とする装置１の事例として用いる真空装置（システム）２００の概略構成を示す。本真空装置２００は、Ｐ０１〜Ｐ０６までの６種類の構成要素（部品）、及びＳ０１〜Ｓ０４までの４種類のセンサから構成される。Ｐ０１：高圧ガス供給部、Ｐ０２：ガスバルブ、Ｐ０３：バルブコントローラ、Ｐ０４：炉体、Ｐ０５：ポンプコントローラ、Ｐ０６：真空ポンプ、Ｓ０１：バルブ開閉センサ、Ｓ０２：ガス流量センサ、Ｓ０３：圧力センサ、Ｓ０４：ポンプ回転センサである。

基本的な動作として、高圧ガス供給部（Ｐ０１）、ガスバルブ（Ｐ０２）、及びバルブコントーラ（Ｐ０３）によって、所定のガス流量が炉体（Ｐ０４）内に送り込まれ、その炉体内（Ｐ０４）の排気が行われている。以下に各構成要素の主機能を説明する。

高圧ガス供給部（Ｐ０１）：炉体（Ｐ０４）に高圧ガスを供給する。

ガスバルブ（Ｐ０２）：バルブコントーラ（Ｐ０３）からの指示により当該ガスバルブ（Ｐ０２）の開閉部が制御されることにより、高圧ガス供給部（Ｐ０１）から炉体（Ｐ０４）に供給されるガスの流量が制御される。ガスバルブ（Ｐ０２）には、バルブ開閉度センサ（Ｓ０１）が備え付けられており、バルブの開閉度を計測している。

バルブコントーラ（Ｐ０３）：ガス流量センサ（Ｓ０２）で計測される炉体（Ｐ０４）に流入するガス流量を、所定の値にするようにガスバルブ（Ｐ０２）の開閉量を計算し、ガスバルブ（Ｐ０２）に開閉度調整の指示を出す。

炉体（Ｐ０４）：高圧ガス供給部（Ｐ０１）、ガスバルブ（Ｐ０２）、及びバルブコントーラ（Ｐ０３）によって、所定のガス流量が送り込まれ、炉体（Ｐ０４）内の真空度が一定となるようにポンプコントローラ（Ｐ０５）及び真空ポンプ（Ｐ０６）によって排気される。炉体（Ｐ０４）には、圧力センサ（Ｓ０３）が備え付けられており、炉体（Ｐ０４）内の圧力を計測している。

ポンプコントローラ（Ｐ０５）：圧力センサ（Ｓ０３）で計測される炉体（Ｐ０４）の圧力が所定の圧力となるようなポンプ回転数を計算し、真空ポンプ（Ｐ０６）に指示を出す。

真空ポンプ（Ｐ０６）：炉体（Ｐ０４）内の気体をポンプコントローラ（Ｐ０５）から指示される出力によって排気する。真空ポンプ（Ｐ０６）には、ポンプ回転数センサ（Ｓ０４）が備え付けられており、真空ポンプ（Ｐ０６）の回転数を計測している。

＜異常事例＞
図１０は、図９の真空装置２００における異常事例を示す。各異常事例（Ｎｏの行）において、異常モード（ａ）、現象（ｂ）、異常原因（ｃ）、異常診断モデル（ｄ）を示している。本例では、ガス流量異常の事例（異常モード（ａ）：「ガス流量異常」）が３件（Ｎｏ１〜Ｎｏ３）、炉体の圧力制御異常の事例（異常モード（ａ）：「炉体圧力制御異常」）が４件（Ｎｏ４〜Ｎｏ７）の計７件の異常事例について説明する。尚ここで示す異常事例が、真空装置に起こり得る全ての故障モード（異常モード）を網羅している訳ではない。

ガス流量異常に関し、事例１（Ｎｏ１）では、現象（ｂ）として、バルブ開閉度（Ｓ０１の値）が最大値を超えた後、ガス流量（Ｓ０２の値）が所定値に満たないというアラームが発生した。調査及び対策の結果、異常原因（ｃ）として、高圧ガス供給部（Ｐ０１）の供給圧力不足が原因であることが判明した。事例１の異常診断モデル（ｄ）は、「Ｓ０１→Ｓ０２→Ｐ０１」で表される。尚、この異常診断モデル（ｄ）において、矢印（→）の向きは処理の流れ（現象から原因を推定して対策を出力すること）に対応している。矢印の元の現象（Ｓ０１→Ｓ０２）をもとに、矢印の先の異常原因（Ｐ０１）に対応した対策が示される。

同様に、事例２（Ｎｏ２）では、バルブ開閉度（Ｓ０１の値）が０、即ち閉じているにも関わらず、ガス流量（Ｓ０２の値）が所定値を超えるというアラームが発生した。原因はガスバルブ（Ｐ０２）のリークであった。異常診断モデルは、「Ｓ０１→Ｓ０２→Ｐ０２」となる。事例３（Ｎｏ３）では、ガス流量（Ｓ０２の値）が所定値に満たないというアラームが発生し、原因はバルブコントーラ（Ｐ０３）の異常であった。異常診断モデルは、「Ｓ０２→Ｐ０３」となる。

また、炉体圧力制御異常に関し、事例４（Ｎｏ４）では、炉体の圧力（Ｓ０３の値）が上限値を超えたというアラームが発生した。原因は、バルブコントーラ（Ｐ０３）の異常であった。異常診断モデルは、「Ｓ０３→Ｐ０３」となる。

同様に、事例５（Ｎｏ５）では、ポンプ回転数（Ｓ０４の値）が最大値（上限値）を超えた後、炉体圧力（Ｓ０３の値）の不足というアラームが発生した。原因は、炉体（Ｐ０４）の真空リークであった。異常診断モデルは、「Ｓ０４→Ｓ０３→Ｐ０３」となる。事例６では、炉体圧力（Ｓ０３の値）の不足というアラームが発生した。原因は、ポンプコントローラ（Ｐ０５）の異常であった。異常診断モデルは、「Ｓ０３→Ｐ０５」となる。事例７では、ポンプ回転数（Ｓ０４の値）が最大値（上限値）を超えた後、炉体圧力（Ｓ０３の値）の不足というアラームが発生した。原因は、真空ポンプ（Ｐ０６）の劣化に伴う排気不足であった。異常診断モデルは、「Ｓ０４→Ｓ０３→Ｐ０５」となる。

＜異常診断モデル例＞
図１１では、図１０の真空装置２００の異常事例から作成した異常診断モデルの作成結果を示す。図１０で説明した７種類の異常事例毎に、各センサ（Ｓ０１〜Ｓ０４）のアラームと対象部品（Ｐ０１〜Ｐ０６）との間の因果関係モデルが作成され、それら７つの因果関係モデルの合成処理により、真空装置２００全体の異常診断モデルを作成することができる。

本例の異常診断モデル１２００では、アラーム発生パターン（アラーム構造データ）の組み合わせにより、ガス流量センサ（Ｓ０２）及び炉体圧力センサ（Ｓ０３）のノードに、入出力関係に応じた発生確率データの表（１２０１，１２０２）が備え付けられている。ガス流量センサ（Ｓ０２）の場合、バルブ開閉度（Ｓ０１の値）に続いてガス流量センサ（Ｓ０２）のアラームが発生した場合、高圧ガス供給部（Ｐ０１）が異常となる確率が“０．５”、ガスバルブ（Ｐ０２）が異常となる確率が“０．５”と出力される。またガス流量センサ（Ｓ０２）のアラームのみが発生した場合、バルブコントローラ（Ｐ０３）が異常となる確率が“１”と出力される。

また、炉体（Ｐ０４）の圧力センサ（Ｓ０３）においては、ポンプ回転センサ（Ｓ０４）に続いて圧力センサ（Ｓ０３）のアラームが発生した場合、炉体（Ｐ０４）が異常となる確率が“０．５”、真空ポンプ（Ｐ０６）が異常となる確率が“０．５”と出力される。また圧力センサ（Ｓ０３）のアラームのみが発生した場合、バルブコントーラ（Ｐ０３）が異常となる確率が“０．５”、ポンプコントローラ（Ｐ０５）が異常となる確率が“０．５”と出力される。

＜異常診断モデル例＞
図１２は、図５の異常診断モデル作成方法の処理ステップＳ１０４における、保守作業、アラーム、及び稼動イベント種類の間の因果関係モデルを作成する処理の詳細フローを示す。

まず、Ｓ３０１において、異常診断モデル作成処理部７は、該当装置１における過去の保守作業データの履歴（Ｄ４）を取得する。次に、Ｓ３０２では、Ｓ３０１で取得した保守作業データの履歴（Ｄ４）の中から、非定常的に行われるトラブル対策の保守作業データを抽出する。このトラブル対策（異常対策）の保守作業は、定期的（例えば、日次もしくは週次など）で定型の保守作業もしくは確認作業ではなく、装置１に故障や不具合が発生した際に非定常的に行われるものである。そして、異常診断モデル作成処理部７は、抽出した保守作業データにおける保守作業種類及びその発生日時データを取得（抽出）する。ここで、保守作業種類（分類）は、前述したように、保守作業データＤ４の作業種別（ｄ）データもしくは作業コード番号（ｅ）の先頭記号から判別することができる（トラブル対策の保守作業を示す“Ｔ”）。

Ｓ３０３では、異常診断モデル作成処理部７は、Ｓ３０２で抽出したトラブル対策が行われたことを示す保守作業データを用いて、所定の時間間隔における保守作業種類別の発生回数の推移データを作成する。例えば、発生回数を集計する時間間隔を１日とする。

次に、Ｓ３０４において、異常診断モデル作成処理部７は、該当装置１における過去のアラームデータおよび稼動イベントデータの履歴（装置データ（履歴）Ｄ７）を取得する。

Ｓ３０５では、Ｓ３０４で取得したデータ（Ｄ７）を用いた、所定時間間隔におけるアラーム及び稼動イベント種類別の発生回数の推移データを作成する。発生回数を集計する時間間隔は、Ｓ３０３における保守作業種類別の発生回数の推移データで使用した時間間隔と同じである必要がある。

Ｓ３０６において、異常診断モデル作成処理部７は、Ｓ３０３で作成した保守作業種類別の発生回数推移データ、及び、Ｓ３０５で作成したアラーム及び稼動イベント種類別の発生回数推移データを用いて、保守作業種類とアラーム及び稼動イベント種類との間の発生回数推移データの相関係数（相関）を計算する。

Ｓ３０７では、異常診断モデル作成処理部７は、Ｓ３０６で計算した相関係数から、所定のしきい値を満足する相関関係を抽出し、保守作業種類、アラーム及び稼動イベント種類の間のグラフネットワーク（グラフネットワークモデル）を作成する。ここで、上記しきい値を用いた判定基準としては、［２つのデータ種類間の相関係数の絶対値］＞［しきい値］、の条件を満たす相関関係を抽出する。

Ｓ３０８では、異常診断モデル作成処理部７は、Ｓ３０７で作成した保守作業種類、アラーム及び稼動イベント種類の間のグラフネットワークの構造化計算を行い、閉回路関係となるノードのグループを抽出する（後述）。

Ｓ３０９では、異常診断モデル作成処理部７は、Ｓ３０８のグラフネットワークの構造化計算により抽出された閉回路関係となるノード（保守作業種類、アラーム及び稼動イベント種類）のグループに関して、各データの発生日時を用いて、時間経過順にグループ内のノードの指向性を設定し、保守作業種類、アラーム及び稼動イベント種類の間の因果関係モデルを作成する。

＜発生回数推移データ＞
図１３は、保守作業種類別の発生回数の推移データの一例である。ここでは、一日当たりの発生回数を集計している。ここでは、「Ｔ００１」から「Ｔ００９」まで、９種類の保守作業種類の発生回数の推移を示している。

図１４は、アラーム種類別の発生回数の推移データの一例である。ここでは、一日当たりの発生回数を集計している。ここでは、「Ａ００１」から「Ａ０１２」まで、１２種類の保守作業種類の発生回数の推移を示している。

図１５は、図１３の保守作業種類「Ｔ００９」の発生回数推移データと、図１４のアラーム種類「Ａ００６」の発生回数推移データとの相関図である。「Ｔ００９」と「Ａ００６」の間の相関係数は“１．０”と高く、「Ｔ００９」と「Ａ００６」が同じ集計単位となる時間間隔において同時に発生していることがわかる。

図１６は、図１３の保守作業種類「Ｔ００９」の発生推移データと、図１４のアラーム種類「Ａ０１２」の発生推移データとの相関図である。「Ｔ００９」と「Ａ０１２」の間の相関係数は“０．０１”と低く、「Ｔ００９」と「Ａ０１２」が同じ集計単位となる時間間隔において同時に発生していないことがわかる。

＜グラフネットワーク＞
図１７は、図１３の保守作業種類別の発生回数推移データと、図１４のアラーム種類別の発生回数推移データとから作成した、保守作業種類とアラーム種類の間のグラフネットワーク（表）である。前記図１２のＳ３０７で本図１７のグラフネットワーク（表）のデータが作成される。

縦軸および横軸の記号は、保守作業種類「Ｔ００１」から「Ｔ００９」、およびアラーム種類「Ａ００１」から「Ａ０１２」を示している。本例では、保守作業とアラーム種類の間の相関係数の絶対値が“０．４”以上となる関係のみを出力（表示）している。行列内の数字は、縦軸の項目と横軸の項目との間の相関係数の絶対値を示している。例えば、保守作業種類「Ｔ００９」とアラーム種類「Ａ００６」とが交わる行列要素の数字は“１．０”となっている（図１５）。また、本行列は対角行列に対して対称構造となっている。

図１８は、図１７の保守作業種類とアラーム種類の間のグラフネットワークに対して構造化計算（なお本構造化計算は、本特徴の１つの必要要素となる計算処理である）を行った後のグラフネットワークである。前記図１２のＳ３０８で本図１８のデータが作成される。本例の構造化計算では、図１７の行列の配列を並び替えることにより、３つの独立の保守作業種類およびアラーム種類のグループ（Ｇ１，Ｇ２，Ｇ３）が作成される。グループＧ１は、「Ｔ００１」、「Ｔ００２」、「Ｔ００３」から構成されており、互いに強い相関関係がある。グループＧ２は、「Ｔ００９」と、「Ａ００６」、「Ａ００８」、「Ａ００９」、「Ａ０１０」、「Ａ０１１」から構成されている。Ｇ２では、全てのデータ項目間に相関が見られる訳でないが、多くの項目間に相関が見られる。グループＧ３は、残りの保守作業種類およびアラーム種類（「Ｔ００４」、「Ｔ００７」、「Ｔ００８」、「Ａ００５」、「Ｔ００６」、「Ａ００１」、「Ａ００２」、「Ａ００７」、「Ａ０１２」、「Ｔ００５」、「Ａ００４」）から構成されている。

図１９は、図１８の構造化計算後のグラフネットワークのグループＧ２に属する保守作業種類およびアラーム種類の発生日時に関するデータを示す。発生日時の順に、エラーコード（アラーム種類）と対応付けて示している。本例では、Ｇ２に属する保守作業種類「Ｔ００９」およびアラーム種類「Ａ００６」、「Ａ００８」〜「Ａ０１１」は、Ａ００８→Ａ００９→Ａ０１１→Ｔ００９→Ａ００６→Ａ０１０の順に発生している。

図２０は、図１８の構造化計算後のグラフネットワークのグループＧ２に属する保守作業種類およびアラーム種類のデータに関する、指向性の設定の前と後の因果関係モデルを示す。（ａ）は、指向性設定前の保守作業種類「Ｔ００９」およびアラーム種類「Ａ００６」、「Ａ００８」〜「Ａ０１１」の因果関係を示す。この（ａ）の表現は、図１８のＧ２の行列表現と等価である。なお、実線の矢印（向きは両方向）は相関係数が“１．０”、破線の矢印（向きは両方向）は相関係数が“０．６”に対応する。

また、（ｂ）は、指向性設定後の因果関係を示し、（ａ）の各ノード間の指向性を図１９の発生日時の順に設定した結果である。（ｂ）では、指向性設定前に見られた閉回路関係が解消され、アラーム種類と保守作業種類を表す因果関係モデルとなっている。指向性の設定により、矢印の向きが片方向になっている。本例では、「Ａ００８」から「Ａ００９」または「Ａ０１１」が発生し、それらから「Ｔ００９」が発生し、「Ｔ００９」から「Ａ００６」が発生し、「Ａ００６」から「Ａ０１０」が発生している。

＜構造化計算＞
図２１は、前記図１２の因果関係モデル作成処理のＳ３０８のグラフネットワーク構造化計算処理の詳細フローを示す。まず、Ｓ４０１において、異常診断モデル作成処理部７は、指向性を持つグラフネットワークにおいて、他のグラフノードとの閉回路関係が無いグラフノードを抽出する。ここで、閉回路関係とは、グラフネットワークにおいて、基点とするノードから出発して基点となるノードに戻ってくる経路があることである。出発してから複数のノードを経由しても構わない。

Ｓ４０２では、異常診断モデル作成処理部７は、Ｓ４０１で抽出したグラフノードの中から、入力データを持たないグラフノードを、対象のグラフノード内で最初の順序にする。

Ｓ４０３では、異常診断モデル作成処理部７は、Ｓ４０１で抽出したグラフノードの中から、出力を持たないグラフノードを、対象のグラフノード内で最後の順序にする。

Ｓ４０４では、異常診断モデル作成処理部７は、Ｓ４０２およびＳ４０３で順序付けを行ったグラフノードを、処理対象から除外し、当該除外した状態のグラフネットワークに更新する。

Ｓ４０５において、異常診断モデル作成処理部７は、処理対象となるグラフノードにおいて、閉回路関係が無い、かつ、入力、出力データが無いグラフノードが存在するかをチェックする。この判定基準を満たすグラフノードが存在しない場合（Ｎ）、処理を終了する。一方、存在する場合（Ｙ）、Ｓ４０６を実行する。

Ｓ４０６では、異常診断モデル作成処理部７は、Ｓ４０４で更新されたグラフネットワークにおいて、閉回路関係となるグラフノード群を抽出し、これらのグラフノード群を１つのグラフノードに置き換える。そして、Ｓ４０１に戻り、処理を実行する。

また、本システムでは、前記図７（図１１）、図１７（図１８）、図２０等のような異常診断モデル（因果関係モデル）及びグラフネットワーク等の情報を、必要に応じて画面に表示する機能を備える。例えば、異常診断システム１００の管理者は、当該情報を画面に表示することで確認することができ、作業員への対策・保守の指示等に利用することができる。

以上説明したように、本実施の形態によれば、所定時間単位で、装置１等からの出力情報（センサデータＤ１、稼働イベントデータＤ２、アラームデータＤ３等）と保守作業データＤ４とを収集または取得し、それらのデータ間の因果関係をグラフネットワークモデルによって因果関係モデルとして表現し、因果関係モデルの合成による全体の異常診断モデルを逐次更新する機能を備えている。そのため、保守作業に伴い新規に発生する異常対策結果等を容易に異常診断モデルに反映させることができる。従って、故障事例に対して容易に異常診断モデルを作成及び更新することができ、それを用いることで装置１の異常の診断やトラブル対策・保守指示（部品候補など）を、的確に、効率的に実現できる。また、取り扱う装置１の台数が多い場合においても効率的に異常診断が可能である。また、統計的な処理を行うことより、今まで気づかなかった故障メカニズムの解明に寄与することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、各種装置の異常の診断、検知及び保守等を行うシステムに利用可能である。

本発明の実施の形態における情報処理システム（異常診断システムを含む）のブロック構成を示す図である。 本異常診断システムにおける対象の装置から出力されるセンサデータの出力結果の一例を示す図である。 本異常診断システムにおける対象の装置からのアラームデータおよび稼動イベントデータを含む装置データ（履歴）の出力結果の一例を示す図である。 本異常診断システムにおける対象の装置の保守作業データ（履歴）の出力結果の一例を示す図である。 本異常診断システムにおける異常診断モデル作成方法及び処理を示すフロー図である。 本異常診断システムにおける異常診断モデルを用いた装置異常診断方法及び処理を示すフロー図である。 本異常診断システムにおける、保守作業種類と稼動イベント及びアラーム種類（Ａ０２ノードの場合）との因果関係を表す異常診断モデルの一例を示す図である。 本異常診断システムにおける異常診断処理結果の一例を示す図である。 本異常診断システムにおける、事例として用いる装置（真空装置）の概略構成を示す図である。 図９の真空装置における異常事例を示す図である。 図１０の異常事例から作成された異常診断モデルを示す図である。 本異常診断システムにおける異常診断モデル作成処理における保守作業とアラーム及び稼動イベント種類の間の因果関係モデルの作成方法及び処理の詳細を示すフロー図である。 本異常診断システムにおける、保守作業種類別の発生回数の推移データの一例を示す図である。 本異常診断システムにおける、アラーム種類別の発生回数の推移データの一例を示す図である。 図１３の保守作業種類「Ｔ００９」の発生回数推移データと、図１４のアラーム種類「Ａ００６」の発生回数推移データとの相関図である。 図１３の保守業種類「Ｔ００９」の発生回数推移データと、図１４のアラーム種類「Ａ０１２」の発生回数推移データとの相関図である。 図１３の保守作業種類別の発生回数推移データと図１４のアラーム種類別の発生回数推移データとから作成した、保守作業種類とアラーム種類の間のグラフネットワークを示す図である。 図１７のグラフネットワークに対して構造化計算を行った後のグラフネットワークを示す図である。 図１８のグラフネットワークのグループＧ２に属する保守作業種類およびアラーム種類の発生日時の情報を示す図である。 図１８のグラフネットワークのグループＧ２に属する保守作業種類およびアラーム種類に対する指向性の設定の前後の因果関係モデルを示す図であり、（ａ）は設定前、（ｂ）は設定後を示す。 図１２の因果関係モデル作成処理におけるグラフネットワークの構造化計算の詳細を示すフロー図である。

符号の説明

１…装置（設備）、２…外部の異常検知システム（センサデータ異常検知システム）、４…データ収集部、５…装置データ履歴格納部、６…保守作業データ履歴格納部、７…異常診断モデル作成処理部、８…異常診断モデル格納部、１０…異常診断処理部、９０…保守端末、１００…異常診断システム、２００…真空装置、８００，１２００…異常診断モデル、８０１，１２０１，１２０２…発生確率、９００…診断結果情報、Ｄ１…センサデータ、Ｄ２…稼働イベントデータ、Ｄ３，Ｄ３’…アラームデータ、Ｄ４…保守作業データ（履歴）、Ｄ５…異常診断モデルデータ、Ｄ６…異常対策候補情報、Ｄ７…装置データ（履歴）。

Claims (10)

1. コンピュータによる情報処理により、対象とする装置の異常予兆の検知時または異常の発生時に、当該異常予兆もしくは異常の原因を推定し、当該原因に対する対策または保守の作業内容を指示するための装置異常診断処理を行う装置異常診断方法であって、
   前記装置異常診断処理に用いる前記装置の異常診断モデルを作成または更新する処理において、
   前記装置または外部の異常検知システムの少なくとも一方から出力される、稼働イベントデータまたはアラームデータの少なくとも一方を用い、
   所定の時間単位において、前記装置に関する保守作業データと、前記アラームデータまたは前記稼動イベントデータの少なくとも一方とを取得する第１の処理ステップと、
   前記第１の処理ステップで取得したデータを用いて、当該保守作業とそれに関連する稼動イベントまたはアラームの少なくとも一方との間の因果関係をグラフネットワーク構造によって表現される因果関係モデルとして作成する第２の処理ステップと、
   前記第２の処理ステップで作成した新規の因果関係モデルを今までに作成された因果関係モデルに対して合成し、当該グラフネットワーク構造における更新されたノード間の発生確率を再計算することで、当該因果関係モデルを含んで成る前記異常診断モデルを更新する第３の処理ステップと、を有すること、を特徴とする装置異常診断方法。
2. 請求項１記載の装置異常診断方法において、
   前記装置の異常診断モデルを作成または更新する処理において、
   前記装置から出力される、センサデータ、前記稼働イベントデータ及び前記アラームデータの３つと、前記装置からのデータをもとに異常予兆または異常を検知する外部の検知システムから出力されるアラームデータとを用い、
   前記第１の処理ステップでは、前記保守作業データは、保守作業の日時、種類、及び部品の情報を含み、前記稼働イベントデータは、前記装置の動作状態の種類、及び発生日時の情報を含み、前記アラームデータは、アラームの種類、及び発生日時の情報を含み、前記保守作業の日時をもとに所定時間内に発生した前記稼動イベント及び前記アラームのデータを取得し、
   前記第２の処理ステップでは、当該保守作業の種類とそれに関連する稼動イベントの種類及びアラームの種類との間の因果関係を、前記グラフネットワーク構造によって表現される因果関係モデルとして作成すること、を特徴とする装置異常診断方法。
3. 請求項１記載の装置異常診断方法において、
   前記因果関係モデルは、当該グラフネットワークのノード毎に、該当ノードへの入力関係となる１つ以上のノードとの間の発生パターンと、該当ノードからの出力関係となる１つ以上のノードとの間の発生パターンとにおける、すべての組み合わせに応じた、前記発生確率のデータを備えること、を特徴とする装置異常診断方法。
4. 請求項１記載の装置異常診断方法において、
   前記装置の異常診断モデルを作成または更新する処理において、
   前記第１の処理ステップでは、
   （Ａ）該当装置に関する過去の保守作業データの履歴を取得する処理ステップと、
   （Ｂ）該当装置に関する過去のアラームデータ及び稼動イベントデータの履歴を取得する処理ステップと、を有し、
   前記第２及び第３の処理ステップでは、
   （Ｃ）前記（Ａ）の処理ステップで取得した履歴を用いて、保守作業の種類毎に、所定の時間単位における発生回数の推移データを計算する処理ステップと、
   （Ｄ）前記（Ｂ）の処理ステップで取得した履歴を用いて、アラームの種類及び稼動イベントの種類毎に、所定の時間単位における発生回数の推移データを計算する処理ステップと、
   （Ｅ）前記保守作業の種類毎の発生回数の推移データと前記稼動イベントの種類及びアラームの種類毎の発生回数の推移データとの間の相関係数を計算する処理ステップと、
   （Ｆ）前記（Ｅ）の処理ステップで計算した相関係数のうち、しきい値を満足する相関係数を持つ、保守作業の種類と稼動イベントの種類及びアラームの種類を抽出し、当該抽出したデータの間のグラフネットワークを作成する処理ステップと、
   （Ｇ）前記（Ｆ）の処理ステップで作成したグラフネットワークに対する構造化計算により、閉回路関係となる保守作業の種類と稼動イベントの種類及びアラームの種類の１つ以上のグループを作成する処理ステップと、
   （Ｈ）前記（Ｇ）の処理ステップで作成したグループにおいて各データの発生日時順に基づき当該グラフネットワークの指向性を設定する処理ステップと、を有すること、を特徴とする装置異常診断方法。
5. 請求項１記載の装置異常診断方法において、
   新規の前記稼働イベントデータまたはアラームデータの少なくとも一方と、前記第３の処理ステップで更新された異常診断モデルとを用いて、前記装置異常診断処理を行う第４の処理ステップを有すること、を特徴とする装置異常診断方法。
6. 請求項５記載の装置異常診断方法において、
   前記第４の処理ステップでは、新規の前記アラームデータを取得した際、過去の所定の時間単位における前記保守作業データと前記稼働イベントデータ及びアラームデータとを取得して当該アラームに関する発生パターンを表すアラーム構造データを作成し、前記第３の処理ステップで更新された異常診断モデル内から、今回のアラーム構造データに一致するグラフネットワーク部を抽出し、その結果をもとに、異常対策候補情報を出力すること、を特徴とする装置異常診断方法。
7. 請求項５記載の装置異常診断方法において、
   前記第４の処理ステップでは、前記原因に対する対策または保守の作業内容を指示する情報を、本システムの管理者または保守の作業者が用いる情報処理装置の画面へ表示する処理ステップを有すること、を特徴とする装置異常診断方法。
8. 請求項１記載の装置異常診断方法において、
   前記異常診断モデルまたはそのうちの因果関係モデルの情報を、本システムの管理者または保守の作業者が用いる情報処理装置の画面へ表示する処理ステップを有すること、を特徴とする装置異常診断方法。
9. コンピュータによる情報処理により、対象とする装置の異常予兆の検知時または異常の発生時に、当該異常予兆もしくは異常の原因を推定し、当該原因に対する対策または保守の作業内容を指示するための装置異常診断処理を行う装置異常診断システムであって、
   前記装置異常診断処理に用いる前記装置の異常診断モデルを作成または更新する処理を行う異常診断モデル作成処理部を有し、
   前記異常診断モデル作成処理部は、
   前記装置または外部の異常検知システムの少なくとも一方から出力される、稼働イベントデータまたはアラームデータの少なくとも一方を用い、
   所定の時間単位において、前記装置に関する保守作業データと、前記アラームデータまたは前記稼動イベントデータの少なくとも一方とを取得する第１の処理と、
   前記第１の処理で取得したデータを用いて、当該保守作業とそれに関連する稼動イベントまたはアラームの少なくとも一方との間の因果関係をグラフネットワーク構造によって表現される因果関係モデルとして作成する第２の処理と、
   前記第２の処理で作成した新規の因果関係モデルを今までに作成された因果関係モデルに対して合成し、当該グラフネットワーク構造における更新されたノード間の発生確率を再計算することで、当該因果関係モデルを含んで成る前記異常診断モデルを更新する第３の処理と、を行うこと、を特徴とする装置異常診断システム。
10. 請求項９記載の装置異常診断システムにおいて、
    新規の前記稼働イベントデータまたはアラームデータと、前記第３の処理で更新された異常診断モデルとを用いて、前記装置異常診断処理を行う異常診断処理部を有すること、を特徴とする装置異常診断システム。

Images