JP7062505B2 - 設備管理支援システム - Google Patents

Description

本発明は、設備管理支援システムに関する。

近年、水道設備、電力設備、産業プラントなどの各種設備の管理を行う上で、管理ノウハウの継承ができないために、適切な管理ができない状況が発生している。
例えば、上下水道の水道設備については、従来は自治体が直接運営していたのに対して、近年の法改正により、コンセッション（公共施設等運営権）方式で民間の運営業者を選定することが可能になっている。日本の水道事業においては、人口減少に伴った水道料金収入の減少や節水の進展などから、厳しい財政状況になりつつあり、民間事業者の活用の流れは、今後益々拡大していくものと予想される。

コンセッション方式で運営業者を選定した場合、必ずしも該当する設備の運営に熟練した業者が運営とは限らないという問題がある。すなわち、従来は、熟練職員が持つノウハウや技術を、新しい職員に継承して行くことが行われていたが、今後の設備運営では、そのようなノウハウや技術の継承を期待できない可能性がある。
このような課題は、水道事業に限らず、電力施設や産業プラントについても同様である。

以上の課題を解決する方策の一つとして、設備管理支援システムがある。設備管理支援システムは、設備管理台帳を電子化・データベース化して管理を支援するものである。データベース化することで、膨大な情報を迅速かつ的確に検索可能で、情報共有が可能である。したがって、このような設備管理支援システムを構築することで、インターネットに接続されていれば、遠隔地へデータを転送可能で、診断ロジックによりプラント内の設備や機器などの保全状況を診断でき、設備の適切な運営を支援できるようになる。

このような設備管理支援システムの一例として、例えば特許文献１に記載されたものがある。特許文献１には、異なる物理モデル、知識モデルおよび統計モデルに基づく診断ロジックを所有する監視装置を連携させ、いずれかの診断ロジックを追加、編集または削除したとき、別の監視装置に記録されている診断ロジックを修正する技術が記載されている。

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

特許文献１に記載された技術によると、センサからの運転データや運転員の経験を活用して診断ロジックを更新することで、診断ロジックの信頼性が向上し、対象設備の監視制御の質を高めることが可能となる。しかしながら、制御対象となる設備が異なる別の設備になると、機器などの構成が異なるため、診断ロジックをそのまま適用することができないという問題がある。

本発明の目的は、既に管理を行っている設備での診断処理内容を、別の設備の管理に展開して、適切な管理ができる設備管理支援システムを提供することにある。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は、上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、第１の設備から取得した複数項目の運転情報及び操作履歴から、第１の設備の故障を含む非定常のイベントの発生事象と、その発生事象の原因の因果関係となる項目のパターンを特定するイベント発生パターン抽出部と、イベント発生パターン抽出部が特定した因果関係で示される項目の運転情報及び操作履歴から、故障を予知するための警報を出力するために必要な入力項目を定義した診断ロジックを生成する診断ロジック生成部と、診断ロジック生成部が生成した第１の設備の診断ロジックを取得し、取得した診断ロジックで示される入力項目が、第２の設備で取得される項目に含まれるかを判断するマッチング部と、マッチング部での判断結果で、第２の設備から取得される複数項目に、診断ロジックで示される項目が含まれる場合に、診断ロジックを記憶する診断ロジックデータベースと、診断ロジックデータベースが記憶した診断ロジックを、第２の設備に対して実行する診断ロジック実行部と、を備える。

本発明によれば、特定の設備を管理するための診断ロジックを、別の設備の運転管理に適用することが可能になり、多数の設備の運転管理を支援できるようになる。
上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明の第１の実施の形態例による設備管理支援システムの例を示す構成図である。 本発明の第１の実施の形態例による設備管理支援システムのハードウェア構成の例を示すブロック図である。 ＡＲＴ（Adaptive Resonance Theory：適応共鳴理論）の概要を示す特性図である。 本発明の第１の実施の形態例による水道施設のポンプ故障のＡＲＴ解析の結果の一例を示す説明図である。 本発明の第１の実施の形態例による適合度の判断指標の例を示す説明図である。 本発明の第１の実施の形態例による診断ロジックマッチング処理の流れを示すフローチャートである。 本発明の第２の実施の形態例による設備管理支援システムの例を示す構成図である。

＜１．第１の実施の形態例＞
以下、本発明の第１の実施の形態例について、図１～図６を参照して詳細に説明する。なお、以下の説明や各図において、同一要素または同一機能を有する要素には同一符号を用い、重複する説明は省略する。また、同一要素または同一機能を有する要素が複数存在する場合には、数字の符号の末尾に、ａ，ｂ，ｃなどの符号を付与して区別して示す。

［１－１．設備管理支援システムの構成］
図１は、本実施の形態例における設備管理支援システムの構成例である。
図１の例では、３箇所の対象プラント１００ａ、１００ｂ、および１００ｃに、それぞれネットワーク２００ａ、２００ｂ、および２００ｃを介して、設備管理支援装置３００ａ、３００ｂ、および３００ｃが接続される。それぞれの設備管理支援装置３００ａ、３００ｂ、および３００ｃは、ネットワーク４００を介して接続され、相互に通信が可能である。ネットワーク４００は、例えばインターネットやＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などである。
なお、ネットワーク４００は、常時接続されている必要はなく、後述する診断ロジックなどを伝送するときだけ、接続してもよい。

各設備管理支援装置３００ａ、３００ｂ、および３００ｃは、パーソナルコンピュータやタブレット端末で構成され、設備管理支援を実行するプログラムを実行することで、以下に説明する機能部やデータベースが構成される。
ここでは設備管理支援装置３００ａの構成について説明するが、設備管理支援装置３００ｂ、３００ｃについても、設備管理支援装置３００ａと同一の構成である。
設備管理支援装置３００ａは、点検情報入力部３１０ａ、イベント発生パターン抽出部３２０ａ、診断ロジック生成部３３０ａ、診断ロジック発信部３４０ａ、診断ロジック受信部３５０ａ、および診断ロジックマッチング部３６０ａを備える。また、設備管理支援装置３００ａは、運転情報データベース３７１ａ、操作履歴データベース３７２ａ、設備データベース３７３ａ、診断ロジックデータベース３７４a、および診断ロジック実行部３８０ａを備える。なお、以下の説明では、データベースをＤＢと称する。

点検情報入力部３１０ａは、対象プラント１００ａの運転情報や操作履歴を、運転情報ＤＢ３７１ａおよび操作履歴ＤＢ３７２ａへ入力する処理を行う。
ここで、運転情報は、対象プラント１００ａに設置されたセンサから収集された温度、流量、圧力などのデータや、ユーザが対象プラント１００ａを点検したときに記録したアナログ計器の読取値などである。センサから収集されたデータは、ネットワーク２００ａを介してリアルタイムに設備管理支援装置３００ａに入力する。あるいは、対象プラント１００ａの監視制御装置（不図示）で収集されたデータを、電子ファイルの形で設備管理支援装置３００ａに転送して入力する。また、手書きされた読取値などは、入力機器（キーボードやマウスなど）を用いてユーザが入力してもよい。

操作履歴は、対象プラント１００ａの監視制御装置で制御されている設備や機器、例えばポンプのオンオフやポンプの電流もしくは電圧値などのデータである。この操作履歴のデータについても、運転情報と同様にネットワーク２００ａを介してリアルタイムに設備管理支援装置３００ａへ入力する。あるいは、監視制御装置から電子ファイルの形で転送して設備管理支援装置３００ａに入力する。

設備管理支援装置３００aを使用するタイミングは、対象プラント１００ａで非定常のイベントが発生したとき、具体例を挙げるとポンプが故障したときなどである。イベントが発生したとき、予め運転情報および操作履歴を設備管理支援装置３００aへ入力した後、イベント発生パターン抽出部３２０ａを用いてイベントの発生パターンの抽出を実行する。ここで、イベントの発生パターンとは、例えば、ポンプの故障時には、流量が減少するといった発生事象と原因の因果関係のことである。

イベント発生パターン抽出部３２０ａは、発生事象と原因の因果関係を特定するもので、故障予知検知技術が適用される。故障予知検知技術の手法としては物理モデル、ＦＴＡ（Fault Tree Analysis）、統計モデルなどがある。統計モデルの具体例としては、逐次学習型のデータ分類技術であるＡＲＴ（Adaptive Resonance Theory：適応共鳴理論）がある。
本実施の形態例においては、ＡＲＴを使って故障予知検知を行う。ＡＲＴを使って故障予知検知を行う詳細については後述する。
なお、ＡＲＴを使って故障予知検知を行うのは一例であり、発生事象と原因の因果関係を特定できるものであれば、他の技術を使ってもよい。

診断ロジック生成部３３０ａは、抽出したイベント（本実施の形態例ではポンプ故障）の発生パターンを利用して対象プラントを診断できるように、警報レベルを算出するための入力項目を定義したプログラム（以下、「診断ロジック」と称する。）を生成する。このとき、例えば、予め合計警報レベルＳＡＬｖの閾値を設定しておき、発生パターンの合計警報レベルＳＡＬｖの値が、閾値より大きくなければ（つまり警報レベルＳＡＬｖ＞閾値でなければ）診断ロジックを生成しない。もしくは、合計警報レベルＳＡＬｖの大きい順に３つの診断ロジックを生成する。これらの仕組みを設けておくことで、診断ロジックの質を確保することが可能である。生成された診断ロジックは、診断ロジックＤＢ３７４ａに格納される。また、診断ロジックは設備ＤＢ３７３ａに格納された対象設備と関連付けられて記録される。なお、設備ＤＢ３７３ａは、対象プラント１００ａが備える設備についての情報を記憶する。

診断ロジック発信部３４０ａは、生成された診断ロジックを、ネットワーク４００を介して別の対象プラント１００ｂおよび１００ｃへ発信する。
別の対象プラント１００ｂおよび１００ｃは、それぞれの診断ロジック受信部３５０ｂ、３５０ｃにて、対象プラント１００ａから発信された診断ロジックを受信する。
さらに、それぞれの診断ロジック受信部３５０ｂ、３５０ｃの診断ロジックマッチング部３６０ｂ、３６０ｃは、受信した診断ロジックを、それぞれの対象プラント１００ｂ、１００ｃで使用可能かどうか判断する。

診断ロジック実行部３８０ａ、３８０ｂ、および３８０ｃは、診断ロジックＤＢ３７４ａ、３７４ｂ、および３７４ｃに記録された診断ロジックを実行し、対象プラント１００ａ、１００ｂ、および１００ｃの設備管理を支援する。この設備管理を支援する処理は、常に連続的に稼動してリアルタイム監視モードと、定期的に手動で設備状況を確認する手動モードがあり、設備の状況に応じて選択する。

［１－２．ハードウェア構成例］
図２は、設備管理支援装置３００ａ、３００ｂ、および３００ｃを構成するコンピュータのハードウェア構成の例を示す。
図２に示すコンピュータは、バス８にそれぞれ接続されたＣＰＵ（Control Processing Unit：中央処理装置）１、ＲＯＭ（Read Only Memory）２、およびＲＡＭ（Random Access Memory３）を備える。さらに、コンピュータは、記憶装置４、操作部５、表示部６、および通信インターフェース７を備える。

ＣＰＵ１は、本実施の形態例に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ２から読み出して実行する。
ＲＡＭ３には、演算処理の途中に発生した変数やパラメータ等が一時的に書き込まれる。本実施の形態例に係る各システムおよび装置における処理の実行は、主にＣＰＵ１がプログラムコードを実行することにより実現される。

表示部６は、例えば、液晶ディスプレイモニタであり、この表示部６によりコンピュータで実行される処理の結果が利用者に表示される。
操作部５には、例えば、キーボード、マウスなどが用いられ、利用者は操作部５を用いて所定の入力を行う。

記憶装置４には、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）などの大容量データ記憶媒体が用いられる。記憶装置４には、診断ロジックなどのプログラムや、各種ＢＤを構成するデータが記録される。
通信インターフェース７には、例えば、ＮＩＣ（Network Interface Card）などが用いられる。通信インターフェース７は、端子が接続されたＬＡＮ（Local Area Network）、専用線などを介して外部と各種データの送受信を行う。

［１－３．故障予知検知処理］
図３は、ＡＲＴを使って故障予知検知を行う処理の概要を示す。
ＡＲＴは、複数のデータをカテゴリに分類する学習型ニューラルネットワークで、異常データなしで異常を予知することが可能であり、汎用性が高いことが特徴である。
図３に示すグラフは、入力項目が、水温（横軸）とｐＨ（縦軸）の２つの場合で、ある期間のプラント状態を分析した例である。

イベント発生パターン抽出部３２０ａは、点検情報入力部３１０ａで入力した運転情報や操作履歴に基づいて、ＡＲＴによる解析を実行して、非定常のイベントが発生したときの発生パターンを抽出する。ここで、水温が高く、ｐＨが低い状態がカテゴリ１になり、水温が低く、ｐＨが低い状態がカテゴリ２になり、水温が高く、ｐＨが低い状態がカテゴリ３になる。
一方、ある期間内で、これらカテゴリ１、２、３から外れた値は異常として警報を出力するものとし、警報レベルで表現する。図３の例では、ｐＨと水温が両方高い場合、警報レベルとする。図３に示す例は、カテゴリから外れた値の検知数が２つであり、警報レベルを「２」とする。

図４は、水道施設のポンプ故障について、ＡＲＴ解析した結果の一例である。ここで、横軸は診断期間の日時を、縦軸は警報レベルを示す。警報レベルは、期間内にカテゴリから外れた値の検知数である。カテゴリから外れた値が多いほど警報レベルは上昇する。また、ポンプ故障時点は操作履歴より判断する。

図４の例では、ポンプの故障時点よりも早く警報レベルが上昇しており、警報レベルの上昇から故障が予知できた状態を示す。ポンプ故障のＡＲＴ解析における入力項目は、多すぎると解析に必要なデータ数が増えて、解析に時間を要することになるため、ポンプに関連した項目を予め設定しておくことが好ましい。例えば、ポンプに関連した入力項目としては、水温、水圧、ポンプ電圧、ポンプ電流、流量などがあり、解析のときは自動的に予め設定した項目のデータを運転情報ＤＢ３７１ａから抽出する。
ただし、一部の項目だけを使って解析するのは一例であり、対象プラント１００ａに設置しているセンサから取得された運転情報や、点検者が対象プラントを点検したときに記録した計器の読取値の項目を、全て使用してＡＲＴ解析してもよい。
なお、ＡＲＴ解析を行う場合には、入力項目のデータは正規化して使用する。あるいは、正規化することなく、入力項目のデータをそのまま使って、ＡＲＴ解析を行ってもよい。

イベントの発生パターンを抽出する際には、ＡＲＴ解析を複数の条件で実行し、複数の発生パターンを抽出する。例えば、上述した水温、水圧、ポンプ電圧、ポンプ電流、流量のうち、５項目全てを解析に用いたケース（第１条件）と、どれか１つの項目を除外して４項目に変更したケース（第２条件～第６条件の５つの条件）を実行する。このようにＡＲＴ解析した全条件（ここでは第１条件～第６条件の６つの条件）について、以下に示す妥当性評価を行い、抽出した発生パターンに優先順位を付ける。

図５は、発生したイベントに対する診断ロジックの妥当性評価結果の一例である。イベントの発生を予知する上で重要なことは、イベントの発生時点よりも前に警報が出力されることと、また、平常時と比較して明確に異常が検出されることである。そのため、本実施の形態例の場合、診断ロジックの妥当性は図５に示す合計警報レベルＳＡＬｖで表現し、合計警報レベルＳＡＬｖが大きいほど発生イベントの予知に有効であるとした。
合計警報レベルＳＡＬｖは、各期間の警報レベル（ＡＬｖｉ）と平常時の警報レベルの差分（ＮＬｖ）を合計したもので、以下の式（１）で算出される。

この図５に示す合計警報レベルＳＡＬｖの算出を、第１条件～第６条件の６つの条件全てで行い、最も大きな合計警報レベルＳＡＬｖが得られる条件から、優先順位を付与する。

［１－４．診断ロジックマッチング処理の流れ］
次に、図６のフローチャートを参照して、ＡＲＴ解析を行った結果に基づいて、診断ロジックマッチング処理を行う例について、図６を参照して説明する。
ここでは、次の表１に示すように、対象プラント１００ａの診断ロジック１、２、３、・・・の優先順位が付与され、さらに、対象プラント１００ｂ、１００ｃの運転情報の項目が設定されているとする。

すなわち、優先順位１位の診断ロジック１が、入力項目［水温、水圧、ポンプ電圧、ポンプ電流、流量］である。また、優先順位２位の診断ロジック２が、入力項目［水温、水圧、ポンプ電圧、流量］である。さらに、優先順位３位の診断ロジック３が、入力項目［水温、水圧、ポンプ電流、流量］である。
また、対象プラント１００ｂは、取得される項目が、［水温、水圧、ポンプ電圧、流量］であり、対象プラント１００ｃは、取得される項目が、［水温、水圧、流量］であるとする。これらの対象プラント１００ｂ、１００ｃの項目は、運転情報ＤＢ３７１ｂ、３７１ｃに記録されている。

このように項目が設定されているとき、対象プラント１００ｂ、１００ｃの設備管理支援装置３００ｂ、３００ｃでは、図６のフローチャートに示す診断ロジックマッチング処理が行われる。設備管理支援装置３００ｂ、３００ｃでは、設備管理支援装置３００ａから、各診断ロジックの情報を受信し、診断ロジックマッチング部３６０ｂ、３６０ｃが、診断ロジックマッチング処理を行う。

最初に、対象プラント１００ｂを管理する設備管理支援装置３００ｂが行う場合を例にして説明する。
まず、診断ロジックマッチング部３６０ｂは、対象プラント１００ａの最も優先順位が高い診断ロジック１の入力項目と、対象プラント１００ｂから取得される項目（対象プラント１００ｂの運転情報ＤＢ３７１ｂに記録されている項目）とを比較する（ステップＳ１）。そして、診断ロジックマッチング部３６０ｂは、比較した両項目が一致しているか否かを判断する（ステップＳ２）。

ここで、両項目が一致している場合（ステップＳ２のＹｅｓ）、受信した診断ロジック（ここでは診断ロジック１）を診断ロジックＤＢ３７４ｂに記録する（ステップＳ３）。
また、ステップＳ２の判断で、両項目が一致していない場合（ステップＳ２のＮｏ）、ステップＳ１で比較した診断ロジック１より優先順位が低い診断ロジック（診断ロジック２，３）と、運転情報ＤＢ３７１ｂに記録されている項目とを比較する（ステップＳ４）。そして、診断ロジックマッチング部３６０ｂは、比較で項目が一致しているか否かを判断する（ステップＳ５）。ここで、比較で項目が一致している場合（ステップＳ５のＹｅｓ）、一致した診断ロジックを診断ロジックＤＢ３７４ｂに記録する（ステップＳ６）。

例えば、表１の例では、対象プラント１００ａの診断ロジック２と、対象プラント１００ｂの入力項目とが一致していることが、ステップＳ５で判断され、診断ロジック２が診断ロジックＤＢ３７４ｂに記録される（ステップＳ６）。対象プラント１００ｂの設備管理支援装置３００ｂの場合には、このステップＳ６での記録処理が行われ、診断ロジック２が、診断ロジック実行部３８０ｂは、記録された診断ロジック２を、対象プラント１００ｂの診断に使用する。

一方、対象プラント１００ｃの設備管理支援装置３００ｃの場合には、対象プラント１００ｃから取得される項目と、診断ロジック１～３のいずれも一致せず（ステップＳ５のＮｏ）、ステップＳ７の処理に移る。

すなわち、診断ロジック１～３で得られる項目の内で、対象プラント１００ｃから取得される項目では不足する項目の情報（ここではポンプ電圧、ポンプ電流）を、設備管理支援装置３００ｃから設備管理支援装置３００ａに送信する（ステップＳ７）。設備管理支援装置３００ａでは、診断ロジック生成部３３０ａが、不足する情報を除外して、ＡＲＴ適用を行う。

そして、不足する項目を除外したＡＲＴ適用で、診断ロジック生成部３３０ａが、新たな診断ロジックを再生成し（ステップＳ８）、生成した診断ロジックが妥当か否か、例えば既に説明した合計警報レベルＳＡＬｖと閾値との比較で評価する（ステップＳ９）。つまり、新たに特定した因果関係から、対象プラント１００ｃを診断できるように警報を出力するための入力項目を定義した診断ロジックの生成が行われたか否かを判断する。

ここで、評価の結果、診断可能であると判断したとき（ステップＳ９のＹｅｓ）、診断ロジック生成部３３０ａが再生成した診断ロジックを設備管理支援装置３００ｃが受信し、受信した診断ロジックを診断ロジックＤＢ３７４ｃに記録する（ステップＳ１０）。このように診断ロジックが診断ロジックＤＢ３７４ｃに記録されたとき、診断ロジック実行部３８０ｃは、記録された診断ロジックを、対象プラント１００ｃの診断に使用する。

さらに、ステップＳ９での評価で、診断可能でないと判断したとき（ステップＳ９のＮｏ）、例えば合計警報レベルＳＡＬｖが以下の場合、設備管理支援装置３００ｃは、新たな診断ロジックの登録なしとして、診断ロジックマッチング処理を終了する（ステップＳ１１）。

以上説明した本実施の形態例による設備管理支援システムとすることで、生成した診断ロジックを別のプラントで使用でき、対象設備の安定した運転管理と更新が可能となる。また、システムにより設備管理を支援することで、人材不足と技術継承の課題を解決することが可能となる。

また、診断ロジックのマッチング機能により、別のプラントとの入力項目の違い、つまり、センサの設置状況の違いなどを確認できる。これを利用すれば対象プラントで有効な診断ロジックを使用するためのセンサの設置位置などを決定することが可能となる。

＜２．第２の実施の形態例＞
次に、本発明の第２の実施の形態例について、図７を参照して詳細に説明する。この図７において、既に第１の実施の形態例で説明した各図と同一要素または同一機能を有する要素には同一符号を用い、重複する説明は省略する。また、図７においても、同一要素または同一機能を有する要素が複数存在する場合には、数字の符号の末尾に、ａ，ｂ，ｃなどの符号を付与して区別して示す。

［２－１．設備管理支援システムの構成および支援動作］
図７は、本実施の形態例における設備管理支援システムの構成例である。
本実施の形態例の場合には、イベントの発生パターンの抽出、診断ロジックの生成・発信、および診断ロジックを評価する機能を備えた中央設備管理支援装置５００を設けたものである。この中央設備管理支援装置５００は、ネットワーク４００を介して設備管理支援装置３００ａ，３００ｂ，３００ｃに接続されており、運転情報や操作履歴を収集し、診断ロジックを生成する処理を行う。中央設備管理支援装置５００は、例えばコンピュータで構成される。

中央設備管理支援装置５００は、イベント発生パターン抽出部３２０、診断ロジック生成部３３０、診断ロジック発信部３４０、診断ロジックマッチング部３６０、診断ロジックＤＢ３７４、および点検情報受信部３９０から構成される。
これらの処理部の機能は、第１の実施の形態例で説明した設備管理支援装置３００ａ，３００ｂ，３００ｃが備える処理部の機能と基本的に同様である。
すなわち、診断ロジックマッチング部３６０が、図６のフローチャートに示す処理で診断ロジックのマッチング処理を行い、いずれかの設備管理支援装置３００ａ、３００ｂ、３００ｃに適用可能な診断ロジックを得る。また、新たな診断ロジックの生成が必要な場合、診断ロジック生成部３３０が生成する。中央設備管理支援装置５００で得られた（生成された）診断ロジックは、診断ロジック発信部３４０が対応した設備管理支援装置３００ａ、３００ｂ、３００ｃに発信されると共に、診断ロジックＤＢ３７４に記録される。各設備管理支援装置３００ａ、３００ｂ、３００ｃでは受信した診断ロジックを、対応した対象プラント１００ａ、１００ｂ、１００ｃの診断用に実行する。

ここで、イベント発生パターン抽出部３２０および診断ロジックマッチング部３６０での処理に必要な運転情報や操作履歴は、点検情報受信部３９０を用いて、各設備管理支援装置３００ａ、３００ｂ、３００ｃから受信する。

設備管理支援装置３００ａ、３００ｂ、３００ｃは、それぞれ点検情報入力部３１０ａ、３１０ｂ、３１０ｃ、診断ロジック受信部３５０ａ、３５０ｂ、３５０ｃ、および診断ロジック実行部３８０ａ、３８０ｂ、３８０ｃを備える。また、設備管理支援装置３００ａ、３００ｂ、３００ｃは、データベースとして、運転情報ＤＢ３７１ａ、３７１ｂ、３７１ｃ、操作履歴ＤＢ３７２ａ、３７２ｂ、３７２ｃ、設備ＤＢ３７３ａ、３７３ｂ、３７３ｃ、および診断ロジックＤＢ３７４a、３７４ｂ、３７４ｃを備える。各データベースの機能についても、第１の実施の形態例で説明した設備管理支援装置３００ａ，３００ｂ，３００ｃが備えるデータベースと同様である。

本実施の形態例のように、中央設備管理支援装置５００を設けて、中央設備管理支援装置５００が診断ロジックのマッチング処理や生成処理を行うようにしたことでも、第１の実施の形態例と同様の効果が得られる。また、本実施の形態例のように中央設備管理支援装置５００が診断ロジックのマッチング処理を行うことで、設備管理支援装置３００ａ、３００ｂ、３００ｃ側については、診断ロジックの生成などの機能が不要になり、既に設置されたシステムへの適用が容易になる。

＜３．変形例＞
本発明は、上述した各実施の形態例に限定されるものではなく、様々な変形例が含まれる。
例えば、図６に示す診断ロジックのマッチング処理は一例であり、プラント同士の運転情報の違いを考慮して診断ロジックをマッチングできる手法ならば、特にマッチング処理を行う手順は、他の手順であってもよい。

また、診断ロジックの入力項目と診断ロジックを受信した別の対象プラント１００ｂもしくは１００ｃの運転情報の項目との比較で一致している際、予め別の対象プラント１００ｂもしくは１００ｃの運転情報と操作履歴を用いて、診断ロジックを実行してもよい。そして、その診断ロジックを実行結果で、妥当性を評価する処理を加えるようにしてもよい。このような妥当性評価処理を加えることで、別の対象プラント１００ｂと１００ｃへの診断ロジック適用の信頼性をより高めることが可能となる。

また、図６のフローチャートに示すマッチング処理では、別の対象プラント１００ｂもしくは１００ｃに記録する診断ロジックは１つとした。これに対して、記録する診断ロジックは１つと限定せず、適用可能と判断された診断ロジックは全て診断ロジックＤＢ３７４ｂ、３７４ｃに記録されるようにしてもよい。

また、上述した各実施の形態例では、水道設備に適用した場合を例にしたが、電力設備や産業プラントなどの様々な設備管理の支援に本発明を適用することができる。また、故障予知検知としてＡＲＴを適用したのも一例であり、発生事象と原因の因果関係を特定できるその他の手法を適用してもよい。

また、上述した実施の形態例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、図１、図２、および図７の構成図や機能ブロック図では、制御線や情報線は説明上必要と考えられるものだけを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。また、図２や図７に示す各機能部については、ソフトウェアで実現する場合の他、それらの一部または全部を、例えば集積回路で設計するなどによってハードウェアで実現してもよい。
さらに、図６のフローチャートにおいて、実施の形態例の処理結果に影響がない範囲で、一部の処理ステップの実行順序を入れ替えたり、一部の処理ステップを同時に実行するようにしてもよい。

１…中央制御ユニット（ＣＰＵ）、２…ＲＯＭ、３…ＲＡＭ、４…記憶装置、５…操作部、６…表示部、７…通信インターフェース、８…バスライン、１００ａ，１００ｂ，１００ｃ…対象プラント、２００ａ，２００ｂ，２００ｃ…ネットワーク、３００ａ，３００ｂ，３００ｃ…設備管理支援装置、３１０ａ，３１０ｂ，３１０ｃ…点検情報入力部、３２０ａ，３２０ｂ，３２０ｃ，３２０ｄ…イベント発生パターン抽出部、３３０ａ，３３０ｂ，３３０ｃ，３３０ｄ…診断ロジック生成部、３４０ａ，３４０ｂ，３４０ｃ，３４０ｄ…診断ロジック発信部、３５０ａ，３５０ｂ，３５０ｃ…診断ロジック受信部、３６０ａ，３６０ｂ，３６０ｃ，３６０ｄ…診断ロジックマッチング部、３７１ａ，３７１ｂ，３７１ｃ…運転情報データベース、３７２ａ，３７２ｂ，３７２ｃ…操作履歴データベース、３７３ａ，３７３ｂ，３７３ｃ…設備データベース、３７４ａ，３７４ｂ，３７４ｃ，３７４ｄ…診断ロジックデータベース、３８０ａ，３８０ｂ，３８０ｃ…診断ロジック実行部、３９０…点検情報受信部、４００…ネットワーク、５００…中央設備管理支援装置

Claims (6)

1. 第１の設備から取得した複数項目の運転情報及び操作履歴から、前記第１の設備の故障を含む非定常のイベントの発生事象と、その発生事象の原因の因果関係となる項目のパターンを特定するイベント発生パターン抽出部と、
   前記イベント発生パターン抽出部が特定した因果関係で示される項目の運転情報及び操作履歴から、故障を予知するための警報を出力するために必要な入力項目を定義した診断ロジックを生成する診断ロジック生成部と、
   前記診断ロジック生成部が生成した前記第１の設備の診断ロジックを取得し、取得した診断ロジックで示される入力項目が、第２の設備で取得される項目に含まれるかを判断するマッチング部と、
   前記マッチング部での判断結果で、前記第２の設備から取得される複数項目に、前記診断ロジックで示される入力項目が含まれる場合に、前記診断ロジックを記憶する診断ロジックデータベースと、
   前記診断ロジックデータベースが記憶した診断ロジックを、前記第２の設備に対して実行する診断ロジック実行部と、を備える
   設備管理支援システム。
2. 前記イベント発生パターン抽出部および前記診断ロジック生成部は、それぞれの設備の管理支援装置とネットワークを介して通信が可能な中央設備管理支援装置が備え、
   前記診断ロジックデータベースおよび前記診断ロジック実行部は、それぞれの設備の管理支援装置が備える
   請求項１に記載の設備管理支援システム。
3. 運転情報のデータベース、操作履歴のデータベース、設備のデータベース、および警報を出力するための入力項目を定義したプログラムのデータベースを備え、
   前記イベント発生パターン抽出部は、各データベースが記憶した情報に基づいて、非定常のイベントの発生事象と原因の因果関係となる項目のパターンを特定する
   請求項１に記載の設備管理支援システム。
4. 前記イベント発生パターン抽出部は、適応共鳴理論を適用して発生した非定常のイベントの因果関係となる項目のパターンを特定する
   請求項１に記載の設備管理支援システム。
5. 前記診断ロジック生成部は、非定常のイベントの発生事象と原因の因果関係となる項目のパターンを複数条件求めて、合計の警報レベルを算出して優先順位を決定する
   請求項１に記載の設備管理支援システム。
6. 前記マッチング部が、前記第１の設備の診断ロジックの入力項目と、前記第２の設備で得られる項目を比較して一致しない場合、新たに特定した因果関係から前記第２の設備を診断できるように警報を出力するための入力項目を定義した診断ロジックを生成する
   請求項１に記載の設備管理支援システム。

Images