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