(57)【特許請求の範囲】
【請求項１】
リクエストレートに基づいてＩＰコントローラへリクエストを送信し、前記ＩＰコントローラから前記リクエストに対応したプロセスデータを受信する収集部と、
前記収集部による前記プロセスデータの受信毎に、前記リクエストの送信から前記プロセスデータの受信までに要した応答時間を記憶する記憶部と、
前記ＩＰコントローラから出力される警報情報を取得する取得部と、
前記取得部による前記警報情報の取得頻度が所定値を超えるか否か判定する判定部と、
前記取得頻度が前記所定値以下の場合に、前記記憶部から第１母集団となる複数の応答時間を取り出して統計値を計算し、前記取得頻度が前記所定値を超える場合に、前記記憶部から前記第１母集団より小さい第２母集団となる応答時間を取り出して統計値を計算する計算部と、
前記統計値が所定の閾値より大きい場合に、前記リクエストレートを小さくするように制御する制御部と、
を備える情報収集装置。
【請求項２】
前記ＩＰコントローラから前記プロセスデータを取得する監視端末の新規参入と、前記監視端末による参入処理の完了とを検知する検知部をさらに備え、
前記計算部は、
前記検知部が前記監視端末の新規参入を検知する前は、前記記憶部から前記第１母集団となる複数の応答時間を取り出して統計値を計算し、
前記検知部が前記監視端末の新規参入を検知した後、前記参入処理の完了を検知するまでの間は、前記記憶部から前記第１母集団より小さい第３母集団となる応答時間を取り出して統計値を計算し、
前記検知部が前記参入処理の完了を検知した後は、前記記憶部から前記第１母集団となる複数の応答時間を取り出して統計値を計算することを特徴とする請求項１に記載の情報収集装置。
【請求項３】
前記計算部は、前記検知部が前記監視端末の新規参入を検知した後、前記参入処理の完了を検知するまでの間に、前記取得頻度が前記所定値を超えた場合は、前記記憶部から前記第２母集団及び前記第３母集団より小さい第４母集団となる応答時間を取り出して統計値を計算することを特徴とする請求項２に記載の情報収集装置。
【請求項４】
前記収集部は、複数のＩＰコントローラへリクエストを送信してプロセスデータを受信し、
前記計算部はＩＰコントローラ毎に前記統計値を計算し、
前記制御部は、前記統計値が、対応するＩＰコントローラに設定された閾値より大きい場合に、当該ＩＰコントローラに対するリクエストレートを小さくするように制御することを特徴とする請求項１乃至３のいずれかに記載の情報収集装置。
【請求項５】
前記計算部は、前記第１母集団としてＵ１個（Ｕ１は２以上の整数）の応答時間を取り出し、前記第２母集団としてＵ２個（Ｕ２は１≦Ｕ２＜Ｕ１を満たす整数）の応答時間を取り出すことを特徴とする請求項１乃至４のいずれかに記載の情報収集装置。
【請求項６】
前記計算部は、前記第１母集団として第１所定時間内に前記記憶部に追加された応答時間を取り出し、前記第２母集団として前記第１所定時間より短い第２所定時間内に前記記憶部に追加された応答時間を取り出すことを特徴とする請求項１乃至４のいずれかに記載の情報収集装置。
【請求項７】
前記収集部が受信したプロセスデータを記憶する第２記憶部と、
外部システムからリクエストを受信する受信部と、
前記受信部が受信したリクエストに基づいて前記第２記憶部からプロセスデータを取り出すリクエスト処理部と、
前記リクエスト処理部が前記第２記憶部から取り出したプロセスデータを前記外部システムへ送信する送信部と、
をさらに備えることを特徴とする請求項１乃至６のいずれかに記載の情報収集装置。
【請求項８】
リクエストレートに基づいてＩＰコントローラへリクエストを送信するステップと、
前記ＩＰコントローラから前記リクエストに対応したプロセスデータを受信するステップと、
前記プロセスデータの受信毎に、前記リクエストの送信から前記プロセスデータの受信までに要した応答時間を記憶部に追加するステップと、
前記ＩＰコントローラから出力される警報情報を取得するステップと、
前記警報情報の取得頻度が所定値を超えるか否か判定するステップと、
前記取得頻度が前記所定値以下の場合に、前記記憶部から第１母集団となる複数の応答時間を取り出して統計値を計算し、前記取得頻度が前記所定値を超える場合に、前記記憶部から前記第１母集団より小さい第２母集団となる応答時間を取り出して統計値を計算するステップと、
前記統計値が所定の閾値より大きい場合に、前記リクエストレートを小さくするように制御するステップと、
をコンピュータに実行させる情報収集プログラム。
【請求項９】
請求項１乃至７のいずれかに記載の情報収集装置と、
複数の設備機器と、
前記複数の設備機器からプロセスデータを取得し、前記情報収集装置から受け付けたリクエストに基づいて、前記情報収集装置へプロセスデータを送信するＩＰコントローラと、
を備えるビル管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、情報収集装置、情報収集プログラム、及びビル管理システムに関する。
【背景技術】
【０００２】
ビルや工場などの大型の建物には、建物内の空調や照明などの設備機器の状態を監視制御するため、ビル管理システムが導入されている。従来のビル管理システムは、設備機器の監視制御を目的とする、監視端末と設備機器によって構成される閉鎖的なシステムであった。近年では、ビルの省エネや価値向上を目的とし、ビル管理システムを、OAシステムや物理セキュリティシステム等の外部システムと連携する事例が増えている。これにより、例えば、設備機器の稼働状態をパソコンのモニタ上に表示することができる。また、入退室管理システムと連携することで、部屋の空調や照明の消し忘れを防止することができる。また、スケジュール管理システムと連携することで、会議室の空調を自動的に運転監視できる。
【０００３】
外部システムはビル管理システムに対してリクエストを送信し、設備機器の状態情報（プロセスデータ）を取得する。例えば、空調のプロセスデータには、電源のＯＮ／ＯＦＦ値や、設定温度値などがある。このような、外部システムによって発生する処理は、従来のビル管理システムには無かった処理であり、ＢＥＭＳの負荷を増やす可能性がある。従来のビル管理システムは、数人のビル管理者ユーザから利用されることを想定しているが、外部システムと連携する場合は、数百・数千人規模のビル居住者から利用される可能性がある。ビル居住者の利用方法を正確に想定することは困難である。また、ビル管理システムの設計時には想定していなかった外部システムと、後々、連携する場合もある。そのため、外部システムとの連携は、ビル管理システムに対する負荷見積もりを困難にする。
【０００４】
外部システムとの連携による想定外の負荷発生を避けるための方法として、プロセスデータのクローリングとキャッシングがある。クローリングとは、プロセスデータを一定周期で収集（クロール）することである。キャッシングとは、クローリングしたプロセスデータを一定期間、蓄積（キャッシュ）することである。このクローリングとキャッシングを行う装置は、ゲートウェイ（以下ＧＷと記載する）と呼ばれる。
【０００５】
ＧＷを利用することで、ビル管理システムの負荷を見積もることが可能となる。すなわち、ＧＷがクローリングを行うことによって発生する負荷が、ビル管理システムに新たに発生する負荷となる。ＧＷはプロセスデータをキャッシュしているため、外部システムからのリクエストは、ＧＷのみで処理できる。外部システムが多くのリクエストを送信したとしても、ビル管理システムに発生する負荷は、ＧＷのクローリングによる負荷のみである。
【０００６】
クローリングを行うにあたり、クローリングの際のリクエストの送信頻度（リクエストレート）が高すぎると、ビル管理システムの負荷が高くなるため、負荷を許容範囲内に抑えつつ、できるだけ高いリクエストレートを達成することが課題となる。クローリングのリクエストを処理するのは、ビル管理システムにおけるＩＰコントローラであるため、クローリングによる負荷は、ＩＰコントローラに生じる。従って、ＩＰコントローラの負荷を把握し、出来るだけ高いリクエストレートを達成することが求められる。
【０００７】
機器の負荷状態を推定して、リクエストレートを調節する手法として、複数のウェブサーバの負荷状態を通信性能から推定する技術が知られている。具体的には、監視装置が、負荷推定用リクエストを各ウェブサーバへ送り、それに対するレスポンスが返ってくるまでの応答時間（Round Trip Time、以下ＲＴＴ）を計測する。そして、ＲＴＴの統計値が閾値を超えた場合に、そのウェブサーバが高負荷な状態であると判断し、そのウェブサーバへのリクエストレートを下げる。以下、ＲＴＴの計測、及びＲＴＴの統計値と閾値との比較を、負荷推定処理と呼ぶ。
【０００８】
このような負荷推定処理を、そのまま設備ネットワークに適用することは難しい。これは、常に、一定期間内に得られたＲＴＴから統計値を計算すること、すなわち統計値を計算する際の母集団が一定数であることに起因する。以下、詳細を説明する。
【０００９】
例えば、従来の手法では、ＲＴＴの統計値として、常に過去５回の負荷推定処理で計測されたＲＴＴの平均値を計算する。ウェブサーバが高負荷な状態（高負荷状態）になると、ＲＴＴが増加する。以下、高負荷状態において計測したＲＴＴのことを異常ＲＴＴと呼ぶ。ウェブサーバが高負荷状態になった後、負荷推定処理を１回実施した場合、過去５回中、１回のＲＴＴが異常ＲＴＴとなる。しかし、過去５回中、４回のＲＴＴは正常時の応答時間であるため、この時点では統計値（平均値）が閾値を超えない可能性がある。
【００１０】
さらに負荷推定処理を１回実施した場合、過去５回中、２回のＲＴＴが異常ＲＴＴとなるが、３回のＲＴＴは正常時の応答時間であるため、この時点でも統計値（平均値）が閾値を超えない可能性が高い。さらに負荷推定処理を１回実施し、過去５回中、３回のＲＴＴが異常ＲＴＴとなると、統計値（平均値）が閾値を超え、ウェブサーバが高負荷であると監視装置により判断されると考えられる。
【００１１】
このように、従来の負荷推定処理では、統計値計算の母集団が一定であるため、ウェブサーバが高負荷状態になった後、負荷推定処理を数回実施しないと、高負荷であることが判断されない。
【００１２】
しかし、設備ネットワークのＩＰコントローラは、ウェブサーバ向けのハードウェアに比べて低スペックである。また、ウェブサーバと異なり、冗長化構成を取っていない場合もある。従って、高負荷状態をできるだけ早く検出する必要がある。
【００１３】
従来の負荷推定処理を、そのまま設備ネットワークに適用すると、ＩＰコントローラが高負荷状態になった後に、負荷推定処理を数回実施しないとＩＰコントローラが高負荷状態であることが判断されないため、リクエストレートの低下が遅れ、ＩＰコントローラの高負荷状態が長引くという問題があった。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００６−１７８６９８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明は、設備ネットワークにおけるＩＰコントローラの高負荷状態を速やかに検出し、過度な負荷がかかることを防止できる情報収集装置、情報収集プログラム、及びビル管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本実施形態によれば、情報収集装置は、リクエストレートに基づいてＩＰコントローラへリクエストを送信し、前記ＩＰコントローラから前記リクエストに対応したプロセスデータを受信する収集部と、前記収集部による前記プロセスデータの受信毎に、前記リクエストの送信から前記プロセスデータの受信までに要した応答時間を記憶する記憶部と、前記ＩＰコントローラから出力される警報情報を取得する取得部と、を備える。情報収集装置は、さらに、前記取得部による前記警報情報の取得頻度が所定値を超えるか否か判定する判定部と、前記取得頻度が前記所定値以下の場合に、前記記憶部から第１母集団となる複数の応答時間を取り出して統計値を計算し、前記取得頻度が前記所定値を超える場合に、前記記憶部から前記第１母集団より小さい第２母集団となる応答時間を取り出して統計値を計算する計算部と、前記統計値が所定の閾値より大きい場合に、前記リクエストレートを小さくするように制御する制御部と、を備える。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１の実施形態に係るビル管理システムの概略構成図である。
【図２】同第１の実施形態に係る情報収集装置の概略構成図である。
【図３】ＲＴＴ記憶部のデータフォーマットの一例を示す図である。
【図４】同第１の実施形態に係る母集団の変更の一例を示す図である。
【図５】比較例による母集団を示す図である。
【図６】同第１の実施形態に係るプロセスデータ収集処理を説明するフローチャートである。
【図７】同第１の実施形態に係るＲＴＴ統計値計算処理を説明するフローチャートである。
【図８】同第１の実施形態に係る警報情報取得処理を説明するフローチャートである。
【図９】本発明の第２の実施形態に係る情報収集装置の概略構成図である。
【図１０】同第２の実施形態に係るアライブチェック部の動作を説明するフローチャートである。
【図１１】変形例によるＲＴＴ統計値計算処理を説明するフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を図面に基づいて説明する。
【００１９】
（第１の実施形態）図１に本発明の第１の実施形態に係るビル管理システムの概略構成を示す。ビル管理システムは、複数の設備機器３００と、それぞれ複数の設備機器３００の状態情報（プロセスデータ）を取得する複数のＩＰコントローラ２００と、ＩＰコントローラ２００からプロセスデータを収集する情報収集装置１００と、ＩＰコントローラ２００からプロセスデータを受け取り設備機器３００の状態を監視制御する監視端末４００とを備える。
【００２０】
設備機器３００は、例えば空調や照明である。設備機器３００のプロセスデータは、例えば、空調の電源のオン／オフ値や、設定温度値、照明のオン／オフ値である。
【００２１】
ＩＰコントローラ２００は、情報収集装置１００からリクエストを受け付けると、リクエストに対応したプロセスデータを情報収集装置１００へ送信する。また、ＩＰコントローラ２００は、監視端末４００からのリクエストに応じて、監視端末４００へプロセスデータを送信する。また、ＩＰコントローラ２００は、高負荷状態のときに警報情報を出力する。警報情報は、例えば空調の温度設定時や、災害等の緊急時など、様々なタイミングで出力される。
【００２２】
情報収集装置１００は、プロセスデータを要求するリクエストを各ＩＰコントローラ２００へ送信し、各ＩＰコントローラ２００からプロセスデータを収集する。また、情報収集装置１００は、外部システム５００からリクエストを受け付けると、収集したプロセスデータを外部システム５００へ送信する。情報収集装置１００は、ゲートウェイとも呼ばれる。
【００２３】
図２に情報収集装置１００の概略構成を示す。情報収集装置１００は、ＩＰコントローラ２００へリクエストを送信し、ＩＰコントローラ２００からプロセスデータを収集するプロセスデータ収集部１１０と、収集されたプロセスデータを記憶するプロセスデータ記憶部１４０と、リクエストの送信からプロセスデータの受信までに要した応答時間（Round Trip Time、以下ＲＴＴ）を記憶するＲＴＴ記憶部１５０と、ＩＰコントローラ２００から出力された警報情報を取得する警報情報取得部１６０と、ＩＰコントローラ２００において警報が多発している状況か否かを判定する警報多発判定部１７０と、ＩＰコントローラ２００毎にＲＴＴの統計値を計算するＲＴＴ統計値計算部１３０と、プロセスデータ収集部１１０がＩＰコントローラ２００へリクエストを送信する間隔（リクエストレート）を制御するレート制御部１２０と、を備える。
【００２４】
また、情報収集装置１００は、外部システム５００（図１参照）からリクエストを受信する受信部１９１と、受信したリクエストを処理し、外部システム５００に要求されているプロセスデータをプロセスデータ記憶部１４０から取り出すリクエスト処理部１９３と、リクエスト処理部１９３がプロセスデータ記憶部１４０から取り出したプロセスデータを外部システム５００へ送信する送信部１９２とをさらに備える。
【００２５】
プロセスデータ収集部１１０は、設定されたリクエストレートに基づいて、各ＩＰコントローラ２００からプロセスデータをクロールし、収集したプロセスデータをプロセスデータ記憶部１４０に追加する。クロールとは、プロセスデータを一定周期で収集することである。以下、複数のＩＰコントローラ２００のうち、ｊ番目のＩＰコントローラ２００ｊに対するリクエストレートを、Ｒｊ（リクエスト／秒）と表記する。つまり、ＩＰコントローラ２００ｊに対するリクエストの送信間隔Ｉｊ（秒）は、１／Ｒｊとなる。なお、ｊは１以上かつＩＰコントローラ２００の個数以下の整数である。
【００２６】
また、プロセスデータ収集部１１０は、リクエストを送信してから、プロセスデータ（レスポンス）を受信するまでの時間（ＲＴＴ）を計算し、ＲＴＴ記憶部１５０に追加する。
【００２７】
プロセスデータ記憶部１４０は、プロセスデータ収集部１１０により追加されたプロセスデータを予め設定された一定時間だけ記憶する。
【００２８】
ＲＴＴ記憶部１５０は、ＩＰコントローラ２００毎に、ＲＴＴを一定時間Ｃ１（秒）記憶する。Ｃ１をＲＴＴ記憶期間と呼ぶ。ＲＴＴ記憶期間Ｃ１は、各ＩＰコントローラに共通の値である。ＲＴＴ記憶部１５０のデータフォーマットの一例を図３に示す。ＲＴＴ記憶期間Ｃ１は、あらかじめ設定された値であり、リクエスト送信間隔Ｉｊに比べて、十分大きな値とする。従って、ＲＴＴ記憶部１５０は、ＩＰコントローラ２００ｊに対するプロセスデータ収集時のＲＴＴを、Ｃ１／Ｉｊ（除算の剰余は切り捨て）個記憶する。
【００２９】
警報情報取得部１６０は、ＩＰコントローラ２００が発信する警報情報を受信し、警報多発判定部１７０に通知する。
【００３０】
警報多発判定部１７０は、警報情報取得部１６０からの通知を受け、警報情報取得部１６０による警報情報取得頻度が所定値を超えるか否かに基づいて、警報が多発している状況にあるか否かを判定する。警報多発判定部１７０は、例えば、所定時間内に所定数を超える警報が発信されている場合、警報が多発している状況にある（非定常状態である）と判定する。警報多発判定部１７０は、判定結果をＲＴＴ統計値計算部に１３０に通知する。判定を行うタイミングは、警報情報を受けたタイミングでもよいし、一定間隔ごとでもよい。
【００３１】
ＲＴＴ統計値計算部１３０は、ＲＴＴ記憶部１５０に記憶されている複数のＲＴＴを取り出し、ＩＰコントローラ２００毎に、ＲＴＴの統計値を計算する。ＲＴＴ統計値計算部１３０がＲＴＴ記憶部１５０から取り出す複数のＲＴＴが、統計値計算の母集団となる。ＲＴＴの統計値を計算する間隔（秒）は、ＩＰコントローラ２００毎に設定される。例えば、ＩＰコントローラ２００ｊに対する統計値計算間隔を、リクエスト送信間隔Ｉｊと等しくしてもよい。この場合、ＲＴＴ記憶部１５０にＲＴＴが追加される度に、ＩＰコントローラ２００ｊについて、ＲＴＴの統計値Ｓｊを計算することになる。
【００３２】
統計値Ｓｊを計算する際の、母集団Ｕ１の初期設定は、各ＩＰコントローラ２００に共通とする。母集団Ｕ１は、個数で設定してもよいし、期間で設定してもよい。個数で設定する場合は、例えば、過去５個のＲＴＴを母集団として、統計値Ｓｊを計算する。一方、期間で設定する場合は、例えば、過去1分間におけるＲＴＴを母集団として、統計値Ｓｊを計算する。統計値Ｓｊには、例えば平均値、標準偏差値、最大値、合計値などを用いることができる。
【００３３】
ＲＴＴ統計値計算部１３０は、警報多発判定部１７０からの通知に基づいて、統計値Ｓｊを計算する際の母集団を、初期設定の母集団Ｕ１より小さい母集団Ｕ２に変更する。母集団が個数で設定されている場合、母集団Ｕ２は、母集団Ｕ１より少ない個数のＲＴＴとなる。また、母集団が期間で設定されている場合、母集団Ｕ２は、母集団Ｕ１より短い期間におけるＲＴＴとなる。
【００３４】
母集団の変更例を図４に示す。図４に示す例では、母集団をＲＴＴの個数で設定し、母集団Ｕ１は過去５個のＲＴＴ、母集団Ｕ２は過去３個のＲＴＴとし、統計値Ｓｊは平均値とする。
【００３５】
ＩＰコントローラ２００ｊが定常状態の場合は、図４（ａ）に示すように、過去５個のＲＴＴを用いて統計値Ｓｊが計算される。一方、ＩＰコントローラ２００ｊが非定常状態（警報多発状況）の場合は、図４（ｂ）に示すように、過去３個のＲＴＴを用いて統計値Ｓｊが計算される。
【００３６】
このように、ＩＰコントローラ２００ｊが非定常状態（警報多発状況）の場合に、母集団を小さくすることで、大きくなったＲＴＴの影響を統計値Ｓｊに速やかに反映させることができる。
【００３７】
ＲＴＴ統計値計算部１３０は、算出した統計値Ｓｊをレート制御部１２０に通知する。
【００３８】
レート制御部１２０は、ＲＴＴ統計値計算部１３０から通知された統計値Ｓｊに基づいて、リクエストレートＲｊを制御する。例えば、レート制御部１２０は、統計値Ｓｊと閾値Ｂとを比較し、統計値Ｓｊの方が大きい場合は、ＩＰコントローラ２００ｊが高負荷状態にあると判断して、リクエストレートＲｊを小さくするようにプロセスデータ収集部１１０を制御する。
【００３９】
図５に、比較例によるＲＴＴの統計値計算方法を示す。この比較例では、母集団の変更は行わず、常に過去５回のＲＴＴを用いて統計値を計算するものとする。また、ここでは、４回目のＲＴＴ計測の後に、ＩＰコントローラが非定常状態に遷移した場合を想定している。
【００４０】
図５に示すように、５回目のＲＴＴは、１〜４回目のＲＴＴよりも大きな値となっている。これは、非定常状態に遷移し、ＩＰコントローラの負荷が高くなっているためだと推定される。しかし、５回目の計測後の時点でＲＴＴ統計値を計算しても、５個中４個のＲＴＴは定常状態のＲＴＴであるため、レート制御部１２０における閾値Ｂとの比較処理において、統計値が閾値Ｂを超える可能性は低い。６回目の計測後でも、５個中３個のＲＴＴは定常状態のＲＴＴであるため、レート制御部１２０における閾値Ｂとの比較処理において、統計値が閾値Ｂを超える可能性は依然として低い。そのため、レート制御部１２０がリクエストレートを下げるタイミングが遅くなる。
【００４１】
一方、本実施形態では、ＩＰコントローラの非定常状態において、母集団を小さくする。図４（ｂ）では、ＩＰコントローラの非定常状態において、ＲＴＴ統計値の母集団を過去３回のＲＴＴとしている。これにより、６回目の計測後には、３個中２個のＲＴＴが大きな値となり、レート制御部１２０における閾値Ｂとの比較処理において、統計値が閾値Ｂを超える可能性が高くなる。すなわち、６回目の計測後に、リクエストレートを下げることが可能となる。
【００４２】
このように、本実施形態では、ＩＰコントローラ２００ｊが非定常状態（警報多発状況）の場合に、統計値Ｓｊ計算時の母集団を小さくするため、統計値ＳｊにはＲＴＴの変化（増加）が速やかに反映される。そのため、レート制御部１２０は、ＩＰコントローラ２００ｊが高負荷状態であることを速やかに検出し、リクエストレートＲｊを下げて、ＩＰコントローラ２００ｊの高負荷状態が長引くことを防止できる。
【００４３】
上述のように、情報収集装置１００の主な処理は、プロセスデータ収集処理と、ＲＴＴ統計値計算処理と、警報情報取得処理の３つである。以下、それぞれの処理についてフローチャートと共に説明する。
【００４４】
図６を用いて、プロセスデータ収集部１１０により実行されるプロセスデータ収集処理を説明する。
【００４５】
（ステップＳ１０１）ＩＰコントローラ２００ｊに設定されているリクエストレートＲｊの初期値に基づいて、プロセスデータのクローリングを開始する。１回のクロール（ＩＰコントローラ２００ｊが管理する設備機器３００のプロセスデータを一通り取得する処理）において、どの設備機器３００のプロセスデータから取得するかの順番は、例えば設備ＩＤから決めてもよいし、設備種別ごとにグループ化してから決めてもよい。ただし、一度決めた順番は変更しない。それにより、同一設備のプロセスデータを、一定間隔で収集できる。
【００４６】
（ステップＳ１０２）リクエストによって得られたプロセスデータを、プロセスデータ記憶部１４０に追加する。
【００４７】
（ステップＳ１０３）リクエストごとに計算したＲＴＴを、ＲＴＴ記憶部１５０に追加する。ここで、リクエストを送信してから、プロセスデータ（レスポンス）を受信するまでの時間を、そのままＲＴＴとしてもよいが、何らかの演算を施した値をＲＴＴとしてもよい。例えば、各リクエストで収集するプロセスデータの数が異なる場合、レスポンス受信時刻とリクエスト送信時刻の差を、今回のリクエストで取得したプロセスデータ数で割った値をＲＴＴとしてもよい。
【００４８】
（ステップＳ１０４）レート制御部１２０からリクエストレートＲｊを下げられた場合は、ステップＳ１０５へ進み、下げられていない場合はステップＳ１０６へ進む。
【００４９】
（ステップＳ１０５）リクエストレートＲｊが変更される。なお、リクエストレートＲｊの下げ幅は、予め設定されていてもよいし、レート制御部１２０がその都度決定してもよい。
【００５０】
（ステップＳ１０６）処理を継続する場合はステップＳ１０２に戻り、クローリングを実施する。
【００５１】
次に、図７を用いて、ＲＴＴ統計値計算処理を説明する。
【００５２】
（ステップＳ２０１）ＲＴＴ統計値計算部１３０が、統計値を計算するための計算スレッドを生成する。ＩＰコントローラ２００と同数のスレッドが生成される。
【００５３】
（ステップＳ２０２）各計算スレッドに、各ＩＰコントローラ２００が割り当てられる。
【００５４】
（ステップＳ２０３）各計算スレッドに、ＲＴＴ統計値計算の母集団Ｕ１が設定される。ここでは、母集団の設定方法として「個数による設定」が選択される。もちろん、別の設定方法を選択してもよい。 
（ステップＳ２０４）各計算スレッドに、ＲＴＴ統計値の計算間隔が割り当てられる。ここでは、計算間隔として、ＩＰコントローラ２００ｊの担当スレッドに対して、リクエスト送信間隔Ｉｊを割り当てる。もちろん、別の間隔を割り当ててもよい。
【００５５】
（ステップＳ２０５）各計算スレッドが、時間Ｉｊが経過するたびに、ＲＴＴ記憶部１５０から、対応するＩＰコントローラ２００のＲＴＴを取得する。ここでは、過去Ｕ１個のＲＴＴ（ＲＴＴ群）が取得される。
【００５６】
（ステップＳ２０６）各計算スレッドが、取得したＲＴＴ群を用いて、統計値Ｓｊを計算する。ここでは、統計値として標準偏差値が求められるものとする。
【００５７】
（ステップＳ２０７）各計算スレッドが、計算した統計値Ｓｊを、レート制御部１２０に通知する。
【００５８】
（ステップＳ２０８）レート制御部１２０が、ＲＴＴ統計値計算部１３０の計算スレッドから通知された統計値Ｓｊと、あらかじめ設定されている閾値Ｂとを比較する。統計値Ｓｊが閾値Ｂを超える場合はステップＳ２０９へ進み、超えない場合はステップＳ２１１へ進む。
【００５９】
（ステップＳ２０９）レート制御部１２０が、プロセスデータ収集部１１０にリクエストレートＲｊを下げるよう通知する。
【００６０】
（ステップＳ２１０）プロセスデータ収集部１１０は、レート制御部１２０から通知を受けると、ＩＰコントローラ２００ｊに対するリクエストレートＲｊの値を下げる。リクエストレートＲｊの下げ幅は、固定値でもよいし、統計値Ｓｊと閾値Ｂの差から動的に決定してもよい。
【００６１】
（ステップＳ２１１）処理を継続する場合はステップＳ２０５に戻る。
【００６２】
なお、ＲＴＴ統計値計算部１３０は、警報多発判定部１７０から、警報多発の通知を受けた場合、各スレッドに、ＲＴＴ統計値の母集団Ｕ２を設定する。ここで設定する母集団Ｕ２は、初期状態にて設定した母集団Ｕ１よりも小さい値である。母集団Ｕ２は、あらかじめ設定されている固定値でもよいし、警報の発生頻度から動的に計算してもよい。母集団をＵ１からＵ２に変更するスレッドは、警報情報を高頻度に出力しているＩＰコントローラ２００に対応するものだけでもよいし、すべてのスレッドとしてもよい。
【００６３】
母集団を小さくすることで、大きくなったＲＴＴの影響を速やかに統計値に反映させることができる。すなわち、ＩＰコントローラの負荷が高くなり、ＲＴＴ値が大きくなった場合に、統計値が大きく変化し、閾値Ｂを超える可能性が高くなる。
【００６４】
ＲＴＴ統計値計算部１３０は、警報多発の通知を受けてから一定時間が経過した場合に、各スレッドのＲＴＴ統計値の母集団Ｕ２を元の母集団Ｕ１に戻す。この一定時間は、あらかじめ設定されている固定値でもよいし、警報の発生頻度などから動的に計算してもよい。
【００６５】
続いて、図８を用いて、警報情報取得処理を説明する。
【００６６】
（ステップＳ３０１）警報情報取得部１６０が、ＩＰコントローラ２００の発信する警報情報を待ち受ける。例えば監視端末４００とＩＰコントローラ２００が、ＢＡＣｎｅｔ／ＩＰによる通信を行っている場合、警報情報は、ＩＰコントローラ２００からブロードキャスト送信される。警報情報取得部１６０は、定期的にＩＰコントローラ２００に、警報発生の有無を問い合わせてもよい。
【００６７】
（ステップＳ３０２）警報情報取得部１６０が、警報情報を取得し、警報多発判定部１７０に通知する。
【００６８】
（ステップＳ３０３）警報多発判定部１７０が、受け取った警報情報を、現在時刻と関連付けて記憶する。
【００６９】
（ステップＳ３０４）警報多発判定部１７０が、所定時間Ｔ１の間に受け取った警報情報の数と、閾値Ｎとを比較する。ここで所定時間Ｔ１及び閾値Ｎは、あらかじめ設定されている固定値でもよいし、過去の警報発生傾向などから動的に計算してもよい。所定時間Ｔ１の間に受け取った警報情報の数が閾値Ｎを超えている場合はステップＳ３０５へ進み、超えていない場合はステップＳ３０６へ進む。
【００７０】
（ステップＳ３０５）警報多発判定部１７０が、ＲＴＴ統計値計算部１３０に対して、警報多発状態になったことを通知する。
【００７１】
（ステップＳ３０６）警報多発判定部１７０が、所定時間Ｔ２よりも過去に受け取った警報情報を破棄する。所定時間Ｔ２は、あらかじめ設定されている固定値でもよいし、過去の警報発生傾向などから動的に計算してもよい。
【００７２】
（ステップＳ３０７）処理を継続する場合はステップＳ３０１に戻る。
【００７３】
このように、本実施形態によれば、警報が多発して、ＩＰコントローラ２００の負荷が通常時よりも高くなっている状態において、ＲＴＴ統計値の算出に用いられるＲＴＴの母集団を小さくすることで、ＲＴＴ値の増加を統計値に速やかに反映させる。そのため、速やかにリクエストレートを下げることができ、ＩＰコントローラ２００に過度の負荷がかかることを防止できる。
【００７４】
（第２の実施形態）図９に本発明の第２の実施形態に係る情報収集装置１００の概略構成を示す。本実施形態は、図１に示す第１の実施形態と比較して、監視端末の新規参入を検知するアライブチェック部１８０を備える点が異なる。図９において、図２に示す第１の実施形態と同一部分には同一符号を付して説明を省略する
ＩＰコントローラ２００の負荷を高める要因として、警報多発以外に、監視端末４００の新規参入がある。監視端末４００の新規参入には、実際に新たな監視端末４００が接続される場合の他に、監視端末４００の電源がオフからオンに切り替わる場合も含まれる。
【００７５】
監視端末４００は、参入処理の一部として、現状把握のために、多くのリクエストをＩＰコントローラ２００に送り、プロセスデータを取得する。そのため、監視端末４００の新規参入に伴い、ＩＰコントローラ２００の負荷が高まる。
【００７６】
本実施形態では、アライブチェック部１８０が、監視端末４００の新規参入を検知した場合に、統計値算出のための母集団を変更し、母集団を一時的に小さくすることで、速やかにリクエストレートを下げる。
【００７７】
アライブチェック部１８０は、監視端末４００の新規参入を検出すると、ＲＴＴ統計値計算部１３０に通知する。監視端末４００の新規参入は、定期的にアライブチェックのパケットを送信するなどして確認することができる。例えば、ＢＡＣｎｅｔ／ＩＰが利用されている場合、定期的にＷｈｏ−Ｉｓメッセージをブロードキャストする方法がある。Ｉ−Ａｍメッセージが返ってきた場合に、監視端末４００がビル管理システムに参入したと判断できる。また、定期的に監視端末４００のＩＰアドレスに対して、ｐｉｎｇを送信する方法もある。
【００７８】
また、以下のようにして、監視端末４００の参入処理が完了したことを検知することができる。例えば、ＢＡＣｎｅｔ／ＩＰが利用されている場合は、参入処理を行っている監視端末４００が、ＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎメッセージによって参入処理のフェーズを通知するため、アライブチェック部１８０は、そのメッセージを受信することで、参入処理の完了を検知できる。また、監視端末４００の参入を検知してから、あらかじめ設定された一定時間が経過した場合に、参入処理が完了したと判断してもよい。
【００７９】
図１０を用いてアライブチェック部１８０の動作についてさらに説明する。
【００８０】
（ステップＳ４０１）アライブチェック部１８０が、監視端末４００の新規参入を検知した場合はステップＳ４０２に進む。
【００８１】
（ステップＳ４０２）アライブチェック部１８０が、監視端末４００の新規参入を、ＲＴＴ統計値計算部１３０に通知する。
【００８２】
（ステップＳ４０３）アライブチェック部１８０が、監視端末４００の参入処理の完了を待つ。監視端末４００の参入処理が完了したことを確認するとステップＳ４０４へ進む。
【００８３】
（ステップＳ４０４）アライブチェック部１８０が、監視端末の参入処理が完了したことを、ＲＴＴ統計値計算部１３０に通知する。
【００８４】
（ステップＳ４０５）処理を継続する場合はステップＳ４０１に戻る。
【００８５】
ＲＴＴ統計値計算部１３０は、警報多発判定部１７０から警報多発の通知を受けた場合、各スレッドのＲＴＴ統計値の母集団の値を小さくする。ここで、小さくする値をＭ１とする。Ｍ１は、あらかじめ設定されている固定値でもよいし、警報の発生頻度から動的に計算してもよい。
【００８６】
ＲＴＴ統計値計算部１３０は、警報多発の通知を受けてから一定時間Ｔ３が経過した場合、ＲＴＴ統計値計算部１３０は、各スレッドのＲＴＴ統計値の母集団の値を、Ｍ１だけ大きくし、母集団を元に戻す。一定時間Ｔ３は、あらかじめ設定されている固定値でもよいし、警報の発生頻度などから動的に計算してもよい。
【００８７】
ＲＴＴ統計値計算部１３０は、アライブチェック部１８０から監視端末４００の新規参入の通知を受けた場合、各スレッドのＲＴＴ統計値の母集団の値を小さくする。ここで、小さくする値をＭ２とする。Ｍ２の決定方法は、あらかじめ設定されている固定値でもよいし、監視点数などから動的に計算してもよい。Ｍ２とＭ１は同じ値でもよいし、異なる値でもよい。
【００８８】
ＲＴＴ統計値計算部１３０は、アライブチェック部１８０から監視端末４００の参入処理の完了通知を受けた場合、各スレッドのＲＴＴ統計値の母集団の値を、Ｍ２だけ大きくし、元に戻す。
【００８９】
このように、本実施形態では、警報が多発した場合と、監視端末４００が参入した場合に、ＩＰコントローラ２００の負荷が定常時よりも高くなっている状態において、統計値母集団を小さくすることで、ＲＴＴ値の増加の影響を統計値に速やかに反映させて、リクエストレートを下げることができる。これにより、ＩＰコントローラ２００に、過度な負荷がかかることを防止できる。
【００９０】
ＲＴＴ統計値計算部１３０は、警報多発と監視端末参入が同時に発生した場合に、母集団を（Ｍ１＋Ｍ２）だけ小さくしてもよい。つまり、警報多発のみが発生している場合や、監視端末参入のみが発生している場合よりも、母集団を小さくする。これにより、ＲＴＴの値の増加の影響をさらに速やかに統計値に反映させて、リクエストレートを下げることができる。
【００９１】
上記第１、第２の実施形態において、複数のＩＰコントローラ２００の性能差を考慮して、レート制御部１２０において統計値と比較される閾値をＩＰコントローラ２００毎に用意してもよい。
【００９２】
ビル管理システムを構成する複数のＩＰコントローラ２００は、全て同一の性能を発揮するとは限らず、またハードウェアが異なる場合もある。この場合、ＩＰコントローラ２００の負荷は等しくても、ＩＰコントローラ２００によって、ＲＴＴの絶対値に差が生じたり、ＲＴＴのばらつきに差が生じたりする。すなわち、ＩＰコントローラ２００の性能が異なると、ＲＴＴの統計値に差が生じる。このとき、リクエストレートを下げるか否か決定するために統計値と比較される閾値が１つしかないとすると、負荷が等しいにもかかわらず、あるＩＰコントローラのＲＴＴ統計値は閾値を超えるが、あるＩＰコントローラのＲＴＴ統計値は閾値を超えないということになる。このような問題は、ＩＰコントローラ２００ｊごとに閾値Ｂｊを用意することで解決できる。
【００９３】
複数の閾値を用意した場合のＲＴＴ統計値計算処理を図１１に示す。図１１におけるステップＳ５０１〜Ｓ５０７、Ｓ５０９〜Ｓ５１１は、図７におけるＳ２０１〜Ｓ２０７、Ｓ２０９〜Ｓ２１１と同様であるため、説明を省略する。
【００９４】
（ステップＳ５０８）レート制御部１２０が、ＲＴＴ統計値計算部１３０のスレッドから通知された統計値Ｓｊと、あらかじめ設定されている閾値Ｂｊとを比較する。統計値Ｓｊが閾値Ｂｊを超える場合はステップＳ５０９へ進み、超えない場合はステップＳ５１１へ進む。
【００９５】
なお、ステップＳ５１０において、リクエストレートＲｊの下げ幅は、ＩＰコントローラ２００ｊの性能を考慮して算出するようにしてもよい。
【００９６】
このように、ＩＰコントローラの性能を考慮し、ＩＰコントローラ毎にリクエストレート制御のための閾値Ｂｊを設定することで、性能に応じたリクエストレート制御を実現できる。
【００９７】
上述した実施形態で説明した情報収集装置１００の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報収集装置１００の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
【００９８】
また、情報収集装置１００の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
【００９９】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１００】
１００  情報収集装置（ＧＷ：ゲートウェイ）
１１０  プロセスデータ収集部
１２０  レート制御部
１３０  ＲＴＴ統計値計算部
１４０  ＲＴＴ記憶部
１５０  プロセスデータ記憶部
１６０  警報情報取得部
１７０  警報多発判定部
１８０  アライブチェック部
１９１  受信部
１９２  送信部
１９３  リクエスト処理部
２００  ＩＰコントローラ
３００  設備機器
４００  監視端末
５００  外部システム
【図１】
0005214685.tif 000002
【図２】
0005214685.tif 000003
【図３】
0005214685.tif 000004
【図４】
0005214685.tif 000005
【図５】
0005214685.tif 000006
【図６】
0005214685.tif 000007
【図７】
0005214685.tif 000008
【図８】
0005214685.tif 000009
【図９】
0005214685.tif 000010
【図１０】
0005214685.tif 000011
【図１１】
0005214685.tif 000012