JP7038629B2 - 機器状態監視装置及びプログラム - Google Patents

Description

本発明は、機器状態監視装置及びプログラム、特に施設に設置された設備の監視に利用される機器における異常の有無の判定に関する。

ＢＡＳ（Ｂｕｉｌｄｉｎｇ Ａｕｔｏｍａｔｉｏｎ Ｓｙｓｔｅｍ）やＢＭＳ（Ｂｕｉｌｄｉｎｇ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）などのビルシステムの分野では、設備やセンサのデータを分析した結果に基づいて設備を最適に制御するサービス、例えば、デマンドレスポンスやＺＥＢ（Ｚｅｒｏ Ｅｎｅｒｇｙ Ｂｕｉｌｄｉｎｇ）などのサービスが提供されている。これらのサービスを提供する上で、ビルシステムを構成する機器の状態を監視する技術を確立することは重要なことである。

機器を監視する際、機器の状態を監視し、機器に異常が発生したかどうかを判定する技術が種々提案されている。

例えば、機器のリソース負荷（ＣＰＵ使用率、メモリ使用量、Ｉ／Ｏアクセス数など）で示される機器の状態を監視し、リソース負荷が示す値によって機器を異常と判定する。あるいは、機器に要求を送信してから応答を受信するまでの時間（応答時間）が閥値を超えた場合に機器を異常と判定する。あるいは、ＣＰＵのリソース負荷と要求数（入力パケット数）に相関関係があることに着目して相関関係を示す回帰直線を算出し、直近の負荷と入力パケット数の関係の回帰直線からのずれの程度によって機器の異常を判定する。

更に、リソース負荷により異常と判定した後にハードウェアの状態を参照して判定の妥当性を検証する。あるいは、スケジュールに従って機器の動作を制御する場合には、そのスケジュールに従って動作するときのリソース負荷モデルを予め用意し、その負荷モデルとの乖離の程度によって機器の異常を判定する。

以上のように、従来から種々の指標を参照する種々の異常判定の技術が提案されている。

特開平０６－２０１４１５号公報 特開２０００－０５６８２３号公報 特開２０１７－１８７８２０号公報 特開２０１１－０７０６３５号公報

以上記載した異常判定手法はそれぞれ、誤判定する可能性を有している。例えば、応答時間のみを監視する方法では、機器への要求が集中した場合などに発生する応答時間の変動により誤って異常と判定してしまう可能性が生じてくる。これを解消するために、ＣＰＵＰの負荷と入力パケット数との相関関係を合わせて判定の指標とすることが提案されているが、負荷とパケット数に相関関係が存在する期間と存在しない期間（例えば、外部からの要求と関係のない監視処理やデータ圧縮処理等の実行期間）が混在するような状況下では、やはり誤判定が発生する可能性が生じてくる。

このように、従来から提案されている異常判定手法はそれぞれ、所定の条件の下では異常判定を正しく行うことは可能であっても、ビルシステムの環境や機器の状態が変化する状況下で異常判定を常時高精度で行うことは困難であった。

本発明は、機器の状態に合わせて適切な異常判定手法を選択可能とすることを目的とする。

本発明に係る機器状態監視装置は、それぞれ異なる判定指標を用いる判定手法により、施設に設置された設備の監視に利用される機器における異常の有無を判定する複数の異常判定手段と、前記機器において実行される処理の種類に対応させて、前記機器の当該処理の実行時における異常の有無の判定に用いる前記異常判定手段が設定されている選択ルール情報を記憶する選択ルール情報記憶手段と、前記選択ルール情報を参照して前記複数の異常判定手段の中から前記機器の処理の実行時における異常の有無の判定に用いる前記異常判定手段を選択する選択手段と、を有するものである。

また、前記機器における処理の実行に伴い生成されるログ情報を取得する手段を有し、前記選択手段は、前記ログ情報で特定される処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択するものである。

また、前記機器において処理が実行されたときの負荷に関する負荷情報を取得する手段と、前記負荷情報に基づき前記機器で実行される処理を予測する処理予測手段と、を有し、前記選択手段は、前記処理予測手段が予測した処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択するものである。

また、前記機器における処理の実行に伴い生成されるログ情報を取得する手段と、前記機器において処理が実行されたときの負荷に関する負荷情報を取得する手段と、前記負荷情報及び前記ログ情報を解析することによって前記選択ルール情報を設定するルール設定手段と、を有するものである。

また、前記選択手段は、前記機器が複数存在する場合、異常の有無の判定対象とする機器に対して前記異常判定手段を選択する際に他の機器に関連する情報を合わせて参照するものである。

また、仮想システム上で仮想機器に処理を実行させることで得られた負荷情報及びログ情報を解析することによって前記選択ルール情報を設定するルール設定手段を有するものである。

また、前記機器における処理の実行スケジュールを含むスケジュール情報を取得する手段を有し、前記選択手段は、前記スケジュール情報にスケジュールされた処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択するものである。

本発明に係るプログラムは、それぞれ異なる判定指標を用いる判定手法により、施設に設置された設備の監視に利用される機器における異常の有無を判定する複数の異常判定手段が実行可能であり、前記機器において実行される処理の種類に対応させて、前記機器の当該処理の実行時における異常の有無の判定に用いる前記異常判定手段が設定されている選択ルール情報を記憶する選択ルール情報記憶手段にアクセス可能なコンピュータを、前記選択ルール情報を参照して前記複数の異常判定手段の中から前記機器の処理の実行時における異常の有無の判定に用いる前記異常判定手段を選択する選択手段として機能させるためのものである。

本発明によれば、機器の状態に合わせて適切な異常判定手法を選択することができる。

本発明に係る機器状態監視装置の一実施の形態を含むビルシステムの全体構成図である。 実施の形態１における機器状態監視装置のブロック構成図である。 実施の形態１におけるログ情報蓄積部に記録されるログ情報のデータ構成の一例を示す図である。 実施の形態１における選択ルール情報記憶部に設定される選択ルール情報のデータ構成例を示す図である。 実施の形態１における異常判定処理を示すフローチャートである。 実施の形態１において判定手法選択部が実施する選択処理を示すフローチャートである。 実施の形態１において異常判定部が実行する異常判定処理を示すフローチャートである。 実施の形態１において他の異常判定部が実行する異常判定処理を示すフローチャートである。 実施の形態１において他の異常判定部が実行する異常判定処理を示すフローチャートである。 実施の形態２における機器状態監視装置のブロック構成図である。 実施の形態３における機器状態監視装置のブロック構成図である。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

実施の形態１．
図１は、本発明に係る機器状態監視装置の一実施の形態を含むビルシステムの全体構成図である。図１には、ビル１に設置されたシステムと監視センタ２とがネットワーク３を介して接続されたビルシステムの構成が示されている。監視センタ２は、ビル１に設置の設備４を遠隔監視するセンタである。ビル１側のシステムは、ビルサーバ５、コントローラ６、監視端末７及び機器状態監視装置１０をネットワーク８に接続して構成される。ビルサーバ５は、設備４の状態を表すデータ、設備４への設定値等設備４に関する情報を、コントローラ６を介して収集する。設備４に関する情報は、設備４に限らず設備４周辺に設置の各種センサ（図示せず）から収集してもよい。コントローラ６は、設備４の動作の制御を行い、また、設備４に関連する各種情報を収集してビルサーバ５へ送る。なお、図１に示すコントローラ６及び設備４の台数は一例であってこれに限るものでない。監視端末７は、ビル管理者等により使用される情報処理装置であり、例えばパーソナルコンピュータ（ＰＣ）で実現される。

機器状態監視装置１０は、ビル１側のシステムに含まれる機器の状態を監視するために用いられる装置である。機器状態監視装置１０が監視対象とする機器は、設備４の監視に利用される機器であり、本実施の形態の場合、ビルサーバ５及びコントローラ６が該当する。機器状態監視装置１０は、ＰＣ等従前からあるコンピュータで実現可能である。すなわち、機器状態監視装置１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスクドライブ（ＨＤＤ）等の記憶手段、マウスやキーボードなどの入力手段及びディスプレイなどの表示手段を含むユーザインタフェース、ネットワークインタフェース等の通信手段を有する。

図２は、本実施の形態における機器状態監視装置１０のブロック構成図である。本実施の形態における機器状態監視装置１０は、異常判定部１１、判定手法選択部１２、実行制御部１３、表示制御部１４、ログ情報蓄積部１５及び選択ルール情報記憶部１６を有している。なお、本実施の形態の説明に用いない構成要素については図から省略している。

本実施の形態では、複数の異常判定部１１を用意している。各異常判定部１１は、それぞれ異なる判定指標を用いて機器における異常の有無を判定する。すなわち、それぞれ異なる判定手法により機器における異常の有無を判定する。判定手法自体は従前から存在する判定手法を利用してよい。本実施の形態でいう「異なる判定指標」というのは、完全同一の指標を用いないことを意味しており、一部に同じ指標を用いる場合や用いる指標が包含関係にある場合もこれに該当する。具体的には、判定手法１が指標Ａ，Ｂ，Ｃを用い、判定手法２が指標Ａ，Ｂ，Ｄを用いる場合、判定手法１と判定手法２は、共通の指標Ａ，Ｂを用いるものの完全同一ではないので、異なる判定指標を用いることになる。また、判定手法１は指標Ａ，Ｂ，Ｃを用い、判定手法２は指標Ａ，Ｂ，Ｃ，Ｄを用いる場合、判定手法２は判定手法１が用いない指標Ｄを用いているため完全同一ではない。従って、判定手法１と判定手法２は、異なる判定指標を用いることになる。また、本実施の形態における「異常」には、機器が停止する障害に限らず、機器が停止しない異常や顕在化されていない警告レベルの異常が含まれる。前述したように異常判定の対象となる機器は、ビルサーバ５及びコントローラ６であるが、以降の説明では、特に断らない限りビルサーバ５を機器と想定して説明する。本実施の形態においては、従前からある判定手法を有効利用するものであり、いずれかの判定手法を選択的に有効利用することを特徴としている。

判定手法選択部１２は、選択ルール情報記憶部１６に設定されている選択ルール情報を参照して複数用意されている異常判定部１１の中からビルサーバ５の処理の実行時における異常の有無の判定に用いる異常判定部１１を選択する。実行制御部１３は、判定手法選択部１２が選択した異常判定部１１の実行制御を行う。表示制御部１４は、異常判定部１１の実行結果の表示を制御する。ログ情報蓄積部１５には、ビルシステムに含まれる機器（ビルサーバ５及びコントローラ６）における処理の実行に伴い生成されるログ情報が蓄積される。例えば、ビルサーバ５に対応するログ情報には、監視センタ２からの要求に応じてデータを送信する処理のログ情報、ビルサーバ５が保持している設備データの集計処理、ビルサーバ５がコントローラ６からデータを収集する処理のログ情報等が含まれる。

図３は、本実施の形態におけるログ情報蓄積部１５に記録されるログ情報の一例を示す図である。ログ情報は、機器において処理が実行されることに伴い生成され、ログ情報蓄積部１５に登録される。ログ情報には、ログ情報の生成日時、実行された処理の種類を特定する情報（以下、「種類識別情報」ともいう）等が記録される。図４に示すログ情報の記述例では、“Ｌｏｇ：”に続く文字列が種類識別情報に相当する。

図４は、本実施の形態における選択ルール情報記憶部１６に設定される選択ルール情報のデータ構成例を示す図である。選択ルール情報には、ビルサーバ５において実行される処理の種類に対応させて、ビルサーバ５の当該処理の実行時における異常の有無の判定に用いる異常判定部１１が設定される。具体的には、各選択ルールを識別するルールＩＤに対応させて、異常判定部１１を特定するための条件（判定手法設定ルール）及び当該異常判定部１１の識別情報（判定手法ＩＤ）が対応付けして設定される。選択ルール情報に設定する条件には、ログ情報に設定される種類識別情報が設定される。図４における“ｒｅｓｐｏｎｄ＿ｔｏ＿ｃｌｏｕｄ”や“ａｇｇｒｅｇａｔｅ＿ｄａｉｌｙ”等が種類識別情報に相当する。なお、図４では、５種類の処理に対応する選択ルールを例示しているが、処理の種類や数はこれに限定されるものではない。

前述したように、各異常判定部１１は、それぞれ異なる判定指標を用いてビルサーバ５において処理が実行されたときの異常の有無を判定する。図２には、ビルサーバ５のハードウェア状態、ＣＰＵの応答時間、負荷モデル、相関関係情報及び負荷情報を判定指標１７の例として示している。このうち、ハードウェア状態は、ＣＰＵの周波数等ハードウェアの状態を示す情報である。応答時間は、機器に要求を送信してから応答を受信するまでの時間である。負荷モデルは、機器が制御スケジュールに従って動作するときのリソース負荷モデルである。相関関係情報は、ＣＰＵのリソース負荷と要求数（入力パケット数）との相関関係を示す情報である。負荷情報は、機器に係る負荷に関する情報である。本実施の形態では、ＣＰＵ使用率、メモリ使用量、Ｉ／Ｏアクセス数等ハードウェアリソースに係る負荷と、時間当たりのバイト送受信数やパケット転送数等のネットワーク負荷とを含む。機器状態監視装置１０は、過去における各時点における上記情報及び現時点における上記情報を判定指標１７として当該情報を管理している機器から取得可能であり、また必要により内部に保持してもよい。これらの判定手法（異常判定部１１）及び判定指標は一例であって、これに限定する必要はない。

なお、図２では、判定指標１７と異常判定部１１との対応関係を矢印にて示しているが、図２においては、各異常判定部１１がそれぞれ異なる判定指標を用いることを模式的に示しているに過ぎない。すなわち、ＩＤ＝００１の異常判定部１１はハードウェア状態という指標のみを用い、ＩＤ＝００２の異常判定部１１は応答時間という指標のみを用いる、ということを表しているわけではなく、ＩＤ＝００４の異常判定部１１に例示したように
判定指標１７の中から複数の判定指標を参照する場合もある。また、ある判定指標１７は、他の判定指標１７を参照して得られる場合がある。例えば、負荷モデルは、負荷情報に基づき得られる判定指標である。

機器状態監視装置１０各構成要素１１～１４は、機器状態監視装置１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、各記憶手段１５，１６は、機器状態監視装置１０に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ－ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。

ビルサーバ５は、設備４の監視を行う際、設備監視に関連する種々の処理を実行する。実行する処理には、ＣＰＵを相対的に多く使用する集計処理や、ＣＰＵを相対的に多く使用しない監視センタ２やコントローラ６との間の通信処理が含まれる。このように、実行する処理には、ＣＰＵを相対的に多く使う処理、あるいはＲＡＭを相対的に多く使う処理やネットワーク通信を主に行う処理等様々な種類がある。ビルサーバ５がＣＰＵを多く使う処理を実行している場合、そのときのビルサーバ５の異常判定にはリソース負荷やＣＰＵの応答時間を判定指標１７として用いる異常判定部１１を利用するのが好適である。また、ビルサーバ５がデータ通信を主とする処理を実行している場合、そのときのビルサーバ５の異常判定には通信負荷を判定指標１７として用いる異常判定部１１を利用するのが好適である。データ通信を主とする処理を実行しているときはＣＰＵを相対的に多く使用していない場合が少なくないので、ＣＰＵの応答時間というデータ通信に関する判定指標１７を参照せずに異常判定しても精度の良い異常判定ができるとは限らない。全ての状況に対応可能な異常判定手法があれば問題ないが、多種多様な機能が提供され続ける現在では、全ての状況に適合した異常判定手法が作成可能とは言い難い。その一方、前述したように、ある特定の状況下においては異常を精度良く判定できる異常判定手法はある。

本実施の形態において特徴的なことは、ビルサーバ５において実行される処理の種類に応じてビルサーバ５における異常の有無の判定に用いる異常判定部１１を選択できるようにしたことである。これにより、処理の種類に適合した判定指標１７を参照する異常判定部１１を実行させて異常判定を行うことができるので、機器の異常判定を精度良く行うことが可能となる。

以下、本実施の形態における異常判定処理について図５に示すフローチャートを用いて説明する。

異常判定を実行する管理者は、ログ情報蓄積部１５に蓄積されているログ情報の中から判定対象としたい処理に対応するログ情報を指定する。これに応じて、判定手法選択部１２は、指定されたログ情報に記録されている処理の種類を抽出する（ステップ１０２）。続いて、判定手法選択部１２は、選択ルール情報を参照して、抽出した処理の種類に対応する判定手法ＩＤに基づき異常判定に用いる判定手法、すなわち異常判定部１１を特定する（ステップ１０３）。

図６は、図４に例示した選択ルール情報に基づく判定手法選択部１２における判定手法特定処理（ステップ１０３）を示すフローチャートである。図６に示すように、判定手法選択部１２は、ログ情報から抽出した処理の種類と、選択ルール情報に設定されている各種類識別情報とを比較する（ステップ１０３１）。そして、ログ情報から抽出した処理の種類が“ｒｅｓｐｏｎｓｅ＿ｔｏ＿ｃｌｏｕｄ”と一致すれば（ステップ１０３２でＹ）、判定手法選択部１２は、ＩＤ＝００５の異常判定部１１が提供する判定手法に特定する（ステップ１０３３）。あるいは、処理の種類が“ｃｏｌｌｅｃｔ＿ｃｏｎｔｒｏｌｌｅｒ＿ｄａｔａ” と一致すれば（ステップ１０３４でＹ）、判定手法選択部１２は、ＩＤ＝００１の異常判定部１１が提供する判定手法に特定する（ステップ１０３３）。そして、処理の種類が上記以外の場合、具体的には、“ａｇｇｒｅｇａｔｅ＿ｄａｉｌｙ” 、“ａｇｇｒｅｇａｔｅ＿ｍｏｎｙｈｌｙ”又は“ａｇｇｒｅｇａｔｅ＿ｙｅａｒｌｙ”のいずれかと一致する場合（ステップ１０３４でＮ）、判定手法選択部１２は、ＩＤ＝００４の異常判定部１１が提供する判定手法に特定する（ステップ１０３６）。

このようにして、異常判定部１１が特定されると、実行制御部１３は、該当する異常判定部１１を起動して異常判定を実行させる（ステップ１０４）。起動された異常判定部１１は、ログ情報を参照することにより、必要な時点（期間）の判定指標１７を取得してビルサーバ５の処理実行時における異常判定を行う。本実施の形態において異常判定部１１が実行する正常／異常の判定処理は、既存の判定処理を有効利用するが、以下、代表的な判定処理について簡単に説明する。

図７は、本実施の形態における異常判定部１１が実行する正常／異常の判定処理の一例を示すフローチャートである。上記ステップ１０４における処理を具体的に示すフローチャートである。図７に示す異常判定処理を実行する異常判定部１１は、負荷情報を取得すると（ステップ４１１）、機器に要求を送信してから応答を受信するまでの応答時間を算出する（ステップ４１２）。応答時間が所定の閾値以下の場合（ステップ４１３でＹ）、迅速に応答可能であるとして正常と判定する（ステップ４１７）。応答時間が所定の閾値を超えている場合（ステップ４１３でＮ）、更にＣＰＵのリソース負荷と要求数（入力パケット数）との相関関係を算出する（ステップ４１４）。相関関係が所定の閾値に満たなければ（ステップ４１５でＮ）、最終的に機器の状態は正常と判定する（ステップ４１７）。一方、相関関係が所定の閾値以上の場合（ステップ４１５でＹ）、機器の状態は異常と判定する（ステップ４１６）。なお、上記各閾値には、実績情報から適切な値が設定される。

図８は、図７に示す異常判定処理を実行する異常判定部１１とは異なる異常判定部１１が実行する正常／異常の判定処理の一例を示すフローチャートである。図８に示す異常判定処理を実行する異常判定部１１は、負荷情報を取得すると（ステップ４２１）、負荷モデルと対比すべきリソース負荷を示すデータを算出する（ステップ４２２）。そして、負荷モデルを取得すると（ステップ４２２）。負荷情報から算出したリソース負荷を負荷モデルと対比することによって機器の状態を判定する。ここで、機器が正常と判定できる場合（ステップ４２４でＹ）、機器の状態は正常と判定する（ステップ４２９）。一方、機器は正常と判定できない場合（ステップ４２４でＮ）、異常判定部１１は、続いてハードウェア情報を取得する（ステップ４１５）。そして、取得した負荷情報を正規化等必要により補正した後（ステップ４２６）、ハードウェア情報と比較することによって機器の状態を判定する。ここで、機器が正常と判定できる場合（ステップ４２７でＹ）、本処理において機器の状態は最終的に正常と判定する（ステップ４２９）。一方、この判定処理でも機器は正常と判定できない場合（ステップ４２７でＮ）、本処理において機器の状態は最終的に異常と判定する（ステップ４２８）。

図９は、図７及び図８に示す異常判定処理を実行する異常判定部１１とは異なる異常判定部１１が実行する正常／異常の判定処理の一例を示すフローチャートである。図９に示す異常判定処理を実行する異常判定部１１は、負荷情報を取得してから機器の状態を判定するまでの処理（ステップ４３１～４３４）は、図８に示す判定処理（ステップ４２１～４２４）と同じでよいので説明を省略する。機器は正常と判定できない場合（ステップ４３４でＮ）、負荷情報に対して外乱を消去する補正をしてから（ステップ４３５）、再度機器の状態を判定する。ここで、機器が正常と判定できる場合（ステップ４３６でＹ）、本処理において機器の状態は最終的に正常と判定する（ステップ４４０）。一方、機器が正常と判定できない場合（ステップ４３６でＮ）、負荷情報に対して時間をシフトしてから（ステップ４３７）、再度機器の状態を判定する。ここで、機器が正常と判定できる場合（ステップ４３８でＹ）、本処理において機器の状態は最終的に正常と判定する（ステップ４４０）。一方、の判定処理でも機器は正常と判定できない場合（ステップ４３８でＮ）、本処理において機器の状態は最終的に異常と判定する（ステップ４２８）。

以上例示した各異常判定部１１が実行する判定処理のように、各異常判定部１１は、複数の判定指標を組み合わせたり、負荷情報を必要により補正したりして機器の状態を判定する。

異常判定部１１が異常判定を行うと、表示制御部１４は、処理結果（異常判定結果）をディスプレイ等に表示するなどして管理者に通知する（ステップ１０５）。あるいは、異常判定結果を監視端末７に送信して表示させるようにしてもよい。なお、処理結果は、後で参照できるように所定の記憶手段に蓄積するようにしてもよい。

本実施の形態によれば、ログ情報に含まれる処理の種類によって機器の異常判定に用いる判定手法（異常判定部１１）を選択することができる。これにより、異常判定の精度をより向上させることが可能となる。

なお、本実施の形態では、異常判定に必要な構成要素を機器状態監視装置１０に集約したが、機器状態監視装置１０が持つ構成要素（処理機能）をビルサーバ５、監視端末７、あるいは監視センタ２に持たせてもよい。あるいは複数箇所に処理機能を分散させ、各装置を連携動作させて前述した異常判定処理を実行できるように構成してもよい。

実施の形態２．
上記実施の形態１では、ログ情報を参照することによりビルサーバ５において過去に実行された処理の実行時における異常判定を行うようにした。本実施の形態では、ログ情報蓄積部１５にログ情報が記録される前の処理、すなわち現時点において実行中若しくは将来において実行される処理を予測して、その処理の実行時における異常判定ができるようにしたことを特徴とする。

図１０は、本実施の形態における機器状態監視装置１０のブロック構成図である。本実施の形態におけるビルシステムの全体構成及び機器状態監視装置１０のハードウェア構成報は、実施の形態１と同じでよい、本実施の形態における機器状態監視装置１０は、実施の形態１における構成に、処理予測部１８を追加した構成を有している。なお、実施の形態１と同じ構成要素には同じ符号を付け、説明を省略する。処理予測部１８は、負荷情報に基づき機器で実行される処理を予測する。処理予測部１８は、機器状態監視装置１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。

次に、本実施の形態における異常判定処理について説明する。本実施の形態の基本的な処理の流れは実施の形態１と同じでよい、実施の形態１では、ステップ１０１においてログ情報を参照して異常判定の対象とする処理を特定していたが、本実施の形態は、この異常判定の対象とする処理を特定する方法が実施の形態１と異なる。

すなわち、処理予測部１８は、負荷情報を参照することによりログ情報を参照せずにビルサーバ５において実行中の処理やこれから実行される処理を予測する。例えば、負荷情報を解析すると、現在は通信負荷が高いため判定手法ＩＤが００５の異常判定部１１を用いて異常判定を行うのが適切であるかもしれないが、負荷情報の遷移からＣＰＵの使用率が増加し、これからも増加する傾向にあることが予測される場合、処理予測部１８は、通信負荷の高い処理に加えてＣＰＵをより多く利用する処理、例えば集計処理の実行が開始されたことを予測する。このように、処理は同時並行して実行される場合がある。なお、実行中若しくはこれから実行される処理に関するログ情報は、生成されない。

このように、処理予測部１８による負荷情報の解析により実行中若しくはこれから実行される処理が予測されると、判定手法選択部１２は、選択ルール情報を参照して、予測された処理の種類（例えば、“ａｇｇｒｅｇａｔｅ＿ｄａｉｌｙ”）に対応する判定手法、すなわち判定手法ＩＤが００３の異常判定部１１を特定する。この後の実行制御部１３、異常判定部１１及び表示制御部１４において実施される処理は実施の形態１と同じでよいので説明を省略する。

なお、ここでは、判定手法選択部１２が処理予測部１８による処理負荷の解析結果を参照して、判定手法を特定するように説明したが、処理予測部１８による処理負荷の解析結果を画面に表示して、管理者に処理の種類を選択させるようにしてもよい。

また、本実施の形態では、現時点で通信処理が実行されていても追って実行が開始された集計処理の異常判定の精度向上を優先させて判定手法を切り替えるようにしたが、通信処理の終了を待って判定手法を切り替えるようにしてもよい。

実施の形態１では、過去のログ情報を参照して過去に実行された処理の異常判定を行っていたが、本実施の形態によれば、現在若しくはこれから実施される処理の異常判定に用いる判定手法（異常判定部１１）を選択することができる。

実施の形態３．
実施の形態１では、管理者等により予め生成された選択ルール情報を参照して判定手法を特定していたが、本実施の形態は、選択ルールを学習することで生成する機能を有していることを特徴としている。

図１１は、本実施の形態における機器状態監視装置１０のブロック構成図である。本実施の形態におけるビルシステムの全体構成及び機器状態監視装置１０のハードウェア構成報は、実施の形態１と同じでよい、本実施の形態における機器状態監視装置１０は、実施の形態１における構成に、ルール学習部１９を追加した構成を有している。なお、実施の形態１と同じ構成要素には同じ符号を付け、説明を省略する。ルール学習部１９は、ルール設定手段として設けられ、負荷情報及びログ情報を解析することによって選択ルール情報を設定する。ルール学習部１９は、機器状態監視装置１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。

次に、本実施の形態における異常判定処理について説明する。本実施の形態の基本的な処理の流れは実施の形態１と同じでよい、実施の形態１では、ステップ１０３において判定手法の特定に用いる選択ルール情報を次のようにして生成する。

すなわち、ルール学習部１９は、負荷情報を一定期間に分割する。そして、分割期間毎に、当該分割期間に対応するログ情報を解析することで当該分割期間において実行されていた処理を抽出する。例えば、負荷情報を１時間毎に分割する。そして、当該１時間内において実行された処理を抽出する。処理は同時並行して実行される場合があるが、ここでは同時並行して実行される処理を含めて抽出する。ここで、１又は２，３種類程度の処理が抽出されたとすると、ルール学習部１９は、選択ルール情報における条件に、抽出された処理の種類に対応する処理識別情報を設定する。図４では、各選択ルール情報に対してただ１つの処理識別情報を設定する例を示したが、本実施の形態では、１つの選択ルールに対して複数の処理の種類を対応付けしてよい。上記説明では、負荷情報を一定期間に分割する時間長として１時間としたが、実際には、１又は２，３種類程度の処理が抽出されうる時間長に負荷情報を分割するのが好適である。

以上のようにして選択ルールに設定する条件（１又は２，３種類程度の処理の種類）が決まると、ルール学習部１９は、この条件に判定手法を対応付ける。これは、例えば、ただ１つの処理の処理識別情報が条件に設定されている選択ルール情報を参照し、条件に設定された処理の種類のうち当該分割期間において実行数が最大の処理の異常判定に対応付けられている判定手法を対応付けるようにしてもよい。あるいは、条件に設定された処理の種類を画面に表示し、管理者に判定手法を指定させるようにしてもよい。

なお、本実施の形態における選択ルールの生成方法では、条件に設定される処理の組合せが同一であり、かつ異なる判定手法が対応付けられた選択ルールが生成される可能性が生じるが、この場合は、管理者等にいずれか１つ選択させるようにしてもよい。

実施の形態４．
上記実施の形態１，３では、ビルサーバ５を機器の一例とし、ビルサーバ５に対するログ情報を参照することを想定して説明した。ただ、ビルシステムは、階層型・自律分散型を特徴としているため、特定の機器の状態（ログ情報）を参照しただけでは特定の機器の状態を認識しきれない可能性がある。例えば、特定の機器（ビルサーバ５）に障害が発生してログ情報が生成されない場合もありうる。

そこで、本実施の形態においては、複数の機器の負荷情報とログ情報からピルシステム全体の状態を監視するようにした。具体的には、ビルサーバ５において処理が実行されたときの異常の有無の判定を行う場合、コントローラ６及び監視センタ２は、ビルサーバ５との通信を行い、また連携して処理を実行する場合が想定できるので、判定手法選択部１２は、ビルサーバ５のみならず他の機器、例えばコントローラ６及び監視センタ２でのログ情報を合わせて参照する。このようにして、ビルサーバ５において処理が実行されたときの異常判定に用いる判定手法の選択の精度を向上させる。

実施の形態５．
本実施の形態では、仮想ビルシステムを利用して選択ルール情報を生成することを特徴とする。

仮想ビルシステムは、実ビルシステムの各機器を仮想マシンやコンテナなどにより仮想化してコンピュータ上で実現したシステムである。仮想ビルシステムは、負荷情報及びログ情報を解析することによって選択ルール情報を設定するルール設定手段を有している。ルール設定手段は、仮想ビルシステムの各コンポーホント（中央監視機能、コントローラ機能）の状態を監視することによって生成された負荷情報及びログ情報を解析し、各判定手法の結果（異常の有無の判定結果の妥当性）から、当該処理の種類に適合した判定手法を得る。そして、判定手法の選択ルールを生成する。

このようにして生成した選択ルール情報を実ビルシステムの機器状態監視装置１０に適用する。これにより、実機での運用を開始する前に高精度な選択ルールを生成することが可能となる。

実施の形態６．
上記実施の形態１においては、ログ情報を参照して、ビルサーバ５において実行された処理を特定していた。ビルサーバ５が予め設定された制御スケジュールに従って処理を実行する場合、制御スケジュールを参照することでビルサーバ５において実行される処理を特定することが可能である。すなわち、本実施の形態における機器状態監視装置１０は、制御スケジュールを管理するビルサーバ５若しくは監視センタ２から制御スケジュールを取得する。そして、判定手法選択部１２は、選択ルール情報を参照し、制御スケジュールにスケジュールされた処理の実行時におけるビルサーバ５の異常の有無の判定に用いる判定手法（異常判定部１１）を選択する。

本実施の形態によれば、ログ情報に代えて制御スケジュールを参照することで処理を特定し、その処理の実行時における異常判定に用いる判定手法（異常判定部１１）を選択することができる。

上記各実施の形態において説明した判定手法の選択方法及び選択ルールの生成については、適宜組み合わせて実行してもよい。

実施の形態７．
上記各実施の形態においては、選択ルールに従って精度の高い判定結果を得られると推測されるいずれか１つの判定手法（異常判定部１１）を選択し、その異常判定部１１における判定結果を提示するようにした。

本実施の形態においては、異常の有無の判定に用いる判定手法を１つに絞り込むことなく全ての判定手法を使用して判定結果を得て、その判定結果に基づいて異常判定を行えるようにしたことを特徴としている。

すなわち、単純には、正常と判定した判定手法の数と異常と判定した判定手法の数の多い方を異常判定の正解とする。いわゆる多数決にて異常判定を行う。この場合、選択ルールは不要となる。なお、多数決の場合は１つの判定手法を１として加算することに相当するが、選択ルールを参照して判定手法に重み付けをしてもよい。

１ ビル、２ 監視センタ、３，８ ネットワーク、４ 設備、５ ビルサーバ、６ コントローラ、７ 監視端末、１０ 機器状態監視装置、１１ 異常判定部、１２ 判定手法選択部、１３ 実行制御部、１４ 表示制御部、１５ ログ情報蓄積部、１６ 選択ルール情報記憶部、１７ 判定指標、１８ 処理予測部、１９ ルール学習部。

Claims (8)

1. それぞれ異なる判定指標を用いる判定手法により、施設に設置された設備の監視に利用される機器における異常の有無を判定する複数の異常判定手段と、
   前記機器において実行される処理の種類に対応させて、前記機器の当該処理の実行時における異常の有無の判定に用いる前記異常判定手段が設定されている選択ルール情報を記憶する選択ルール情報記憶手段と、
   前記選択ルール情報を参照して前記複数の異常判定手段の中から前記機器の処理の実行時における異常の有無の判定に用いる前記異常判定手段を選択する選択手段と、
   を有することを特徴とする機器状態監視装置。
2. 前記機器における処理の実行に伴い生成されるログ情報を取得する手段を有し、
   前記選択手段は、前記ログ情報で特定される処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択することを特徴とする請求項１に記載の機器状態監視装置。
3. 前記機器において処理が実行されたときの負荷に関する負荷情報を取得する手段と、
   前記負荷情報に基づき前記機器で実行される処理を予測する処理予測手段と、
   を有し、
   前記選択手段は、前記処理予測手段が予測した処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択することを特徴とする請求項１に記載の機器状態監視装置。
4. 前記機器における処理の実行に伴い生成されるログ情報を取得する手段と、
   前記機器において処理が実行されたときの負荷に関する負荷情報を取得する手段と、
   前記負荷情報及び前記ログ情報を解析することによって前記選択ルール情報を設定するルール設定手段と、
   を有することを特徴とする請求項１に記載の機器状態監視装置。
5. 前記選択手段は、前記機器が複数存在する場合、異常の有無の判定対象とする機器に対して前記異常判定手段を選択する際に他の機器に関連する情報を合わせて参照することを特徴とする請求項１乃至４のいずれか1項に記載の機器状態監視装置。
6. 仮想システム上で仮想機器に処理を実行させることで得られた負荷情報及びログ情報を解析することによって前記選択ルール情報を設定するルール設定手段を有することを特徴とする請求項１に記載の機器状態監視装置。
7. 前記機器における処理の実行スケジュールを含むスケジュール情報を取得する手段を有し、
   前記選択手段は、前記スケジュール情報にスケジュールされた処理の実行時における前記機器の異常の有無の判定に用いる前記異常判定手段を選択することを特徴とする請求項１に記載の機器状態監視装置。
8. それぞれ異なる判定指標を用いる判定手法により、施設に設置された設備の監視に利用される機器における異常の有無を判定する複数の異常判定手段が実行可能であり、前記機器において実行される処理の種類に対応させて、前記機器の当該処理の実行時における異常の有無の判定に用いる前記異常判定手段が設定されている選択ルール情報を記憶する選択ルール情報記憶手段にアクセス可能なコンピュータを、
   前記選択ルール情報を参照して前記複数の異常判定手段の中から前記機器の処理の実行時における異常の有無の判定に用いる前記異常判定手段を選択する選択手段として機能させるためのプログラム。

Images