JP2010021904A - 設備機器管理システム及び設備機器管理方法 - Google Patents

Abstract

【課題】設備機器の構成のバリエーションによる発報データの処理負荷のばらつきを考慮した負荷の均一化が行える設備機器管理システム及び設備機器管理方法を提供する。
【解決手段】発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄにおける発報データの処理が規定時間を超えるか否か判断する（ステップＳ２）。規定時間を超えていれば、発報データに含まれるデータ量少なくなるように発報回数を増やすために、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが負荷分散装置８２を介して空調コントローラ６９ａ，６０ｃに次回の発報時刻を早めるよう指示を与える。
【選択図】図７

Description

本発明は、設備機器管理システム及び設備機器管理方法に関し、特に通信回線を介して複数の設備機器を遠隔から管理する設備機器管理装置及び設備機器管理方法に関する。

設備機器管理システムは、ビルなどの所定物件に配置された空調機などの設備機器を遠隔から管理するため、所定物件ごとに設けられた空調コントローラを備えている。また、これらを集中的に遠隔から管理するため、公衆通信回線を介して複数の空調コントローラに接続された中央管理装置を備えている（たとえば、特許文献１参照。）。この中央管理装置は、複数の空調コントローラから送られてくる非常に多くの発報データを複数の情報処理装置で処理している。複数の情報処理装置における非常に多くの発報データの処理負荷を分散するため、負荷分散装置が中央管理装置に備えられており、負荷分散装置が発報データを複数の情報処理装置に振り分けている。
特開２００４‐２３２９８０号公報

しかしながら、負荷分散装置を備えているにも拘らず、設備機器の構成のバリエーションから生じる発報データの処理負荷のばらつきなどが原因で、情報処理装置における発報データの処理の渋滞を十分に解消できない状況が発生することがある。図９は、日報発報の発報データと、それに基づき作成されるデータベースのテーブルとを示している。この場合、データベースのテーブルには、状態の値が時刻０１：００と時刻０２：００と時刻０３：００の３回にわたって追加される。

例えば、物件１：状態数の少ない機種（状態数２０）が２０台あり、物件２：状態数の多い機種（状態数２００）が２台あるという、２つの物件について考える。日報発報の発報データの状態の値の取得時間間隔が１時間の場合、物件１のコントローラと物件２のコントローラは、１時間あたりの状態数がともに合計４００で（機種構成のための管理情報が一部含まれるが）、両方のデータサイズは同じものとなる。この場合、受信したデータの読み込み時間及び処理負荷は両方とも大きく変わらない。しかし、日報発報に関するデータをデータベースサーバに登録する過程において、機種単位で登録するため、物件１では１日分の登録は２０（台）×２４時間＝４８０回、つまりデータベースサーバへの登録が４８０回発生するが、物件２では２×１４＝４８回となり、データベースサーバへのアクセスは物件の方が圧倒的に多くなる。このデータベースサーバへのアクセスがボトルネックとなるため、物件１において、より多くの処理負荷が発生する。

現在、コンビニエンスストア向けのもので状態数が２０程度と比較的少なく、データ取得の間隔は５分単位である。その一方で、複数台の室内機を1台の室外機で運転制御するマルチパッケージ型空調システムでは状態数が３００を超えるものもあり、状態数が増加する傾向にある。

本発明の課題は、設備機器の構成のバリエーションによる発報データの処理負荷のばらつきを考慮した負荷の均一化が行える設備機器管理システム及び設備機器管理方法を提供することにある。

第１発明に係る設備機器管理システムは、複数の設備機器を遠隔から管理する設備機器管理システムである。設備機器管理システムは、第１記憶装置を有する複数の監視装置と、負荷分散装置と、負荷分散装置に接続され第２記憶装置を有する複数の情報処理装置とを備えている。複数の監視装置の第１記憶装置には第１情報が記憶されている。複数の監視装置は、接続されている設備機器に関するデータを、第１情報に従って所定時間分まとめて発報データとして送信する。負荷分散装置は、通信回線を介して複数の監視装置の発報データを受信する。また、負荷分散装置は、通信回線を介して第１記憶装置の第１情報を書き換え可能に構成されている。複数の情報処理装置は、発報データを処理するために第２記憶装置に発報データを記憶する。また、第１情報を書き換えるために発報データの処理時間に関する第２情報を複数の情報処理装置は負荷分散装置に与える。

本発明によれば、負荷分散装置は、処理時間の掛かるいわゆる処理負荷の重い発報データを送ってきた監視装置に対して、第１情報を書き換えることにより、その監視装置が次に送信する発報データをまとめるための所定時間を短くすることができる。それにより、監視装置が発信する発報データのうち処理負荷の重い発報データのデータ量を少なくすることができる。

第２発明に係る設備機器管理システムは、第１発明の設備機器管理システムであって、複数の情報処理装置は、相互に第２記憶装置を読み取り可能に構成されている。複数の情報処理装置は、待ち行列に登録されたデータ数に応じて、自己の第２記憶装置に記憶されている発報データを他者の待ち行列に登録して処理する。

本発明によれば、第１情報の書き換えによって発報データの処理時間の均一化が図られていることから、待ち行列のデータ数が処理負荷と強い相関を持つものとなっている。そこで、自己の情報処理装置の待ち行列に多数の発報データが登録されている場合は、自己の情報処理装置に負荷が偏っていると判断できることから、自己の情報処理装置の第２記憶装置に記憶されている発報データを他者の待ち行列に登録して処理する。それにより、複数の情報処理装置の待ち行列に登録された発報データの数が均一化される。

第３発明に係る設備機器管理システムは、第１発明または第２発明の設備機器管理システムであって、第２記憶装置に記憶している発報データを、発報データの内容に応じて順番を入れ替えて待ち行列に登録する。

本発明によれば、発報データの内容に応じて、複数の情報処理装置が発報データを待ち行列に登録する順番の入れ替えを行うことができる。それにより、内容によって発報データの処理を急がないものは待ち行列に登録する順番を遅らせる一方、処理を急ぐ発報データから順に待ち行列に登録することができる。

第４発明に係る設備機器管理方法は、複数の設備機器を遠隔から管理する設備機器管理方法である。この設備機器管理方法の第１工程では、設備機器に関するデータを所定時間分まとめて発報データとして監視装置が発信する。第２工程では、発報データを受信して、複数の情報処理装置に振り分けていずれかの情報処理装置の待ち行列に登録する。第３工程では、発報データの情報処理装置での処理時間に応じて、次回送信すべき発報データについて、設備機器に関するデータをまとめる所定時間を監視装置に指示する。

本発明によれば、次回送信すべき発報データについて、設備機器に関するデータをまとめる所定時間が、情報処理装置での発報データの処理時間に応じているので、例えば発報データの処理時間が長くなったものの所定時間を短くすることができる。第３工程を繰り返すことにより、発報データを分割して送信回数をふやすこととなる。

第５発明に係る設備機器管理方法は、第４発明の設備機器管理方法であって、第２工程では、複数の情報処理装置に一旦振り分けられた発報データを、待ち行列のデータ数より少ない別の情報処理装置に再度振り分ける。

本発明によれば、第３工程を繰り返すことにより、第１情報の書き換えによって発報データの処理時間の均一化が図られていることから、待ち行列のデータ数が処理負荷と強い相関を持つものとなっている。そこで、他の情報処理の待ち行列に多数の発報データが入っている場合は、当該他の情報処理装置に負荷が偏っていると判断できることから、第２工程で、当該他の情報処理装置の第２記憶装置に記憶されている発報データを自己の待ち行列に登録して処理する。それにより、複数の情報処理装置の待ち行列に登録された発報データの数が均一化される。

第６発明に係る設備機器管理方法は、第４発明または第５発明の設備機器管理方法であって、第２工程において、情報処理装置に発報データを記憶する。また、第２工程において、記憶している発報データを、発報データの内容に応じて順番を入れ替えて待ち行列に登録する。

本発明によれば、内容によって発報データの処理を急がないものは待ち行列に登録する順番を遅らせる一方、処理を急ぐ発報データから順に待ち行列を登録する。それにより、処理を急がない発報データを情報処理装置の処理が集中しない時間帯に処理することができる。

第１発明に係る設備機器管理システムでは、監視装置が発信する発報データのうち処理負荷の重い発報データの１回当たりのデータ量を減らすことができる。それにより、情報処理装置でのデータ処理時間が均一化するようデータ量が減らされた発報データを負荷分散装置が振り分けることとなり、複数の情報処理装置における負荷の均一化を図ることができる。

第２発明の設備機器管理システムでは、情報処理装置の待ち行列に積まれる発報データ数の均一化により、複数の情報処理装置の負荷を均一化することができる。

第３発明の設備機器管理システムでは、処理を急がない発報データを情報処理装置の処理が集中しない時間帯に処理することができるようになり、発報データの処理の時間的な分散を図り、複数の情報処理装置の処理負荷を均一化することができる。

第４発明の設備機器管理方法では、第３工程が繰り返されることで、情報処理装置での処理時間が均一化されるよう一回あたりの発報データのデータ量が減らされるため、複数の情報処理装置の負担を均一化することができる。

第５の発明の設備機器管理方法では、第２工程により情報処理装置の待ち行列に積まれる発報データ数の均一化することで、複数の情報処理装置の負荷を均一化することができる。

第６発明の設備機器管理方法では、第２工程において処理を急がない発報データを情報処理装置の処理が集中しない時間帯に処理することができるようになり、発報データの処理の時間的な分散を図り、複数の情報処理装置の処理負荷を均一化することができる。

以下、本発明の一実施形態に係る設備管理システムである空調機器管理システムを図について説明する。

＜空調機器管理システムの管理対象＞
図１に示すマルチ式空調機器５０ａ，５０ｂ，５０ｃが空調機器管理システムの管理対象である。マルチ式空調機器５０ａ，５０ｂは第１ビル１０１に配置され、マルチ式空調機器５０ｃは第２ビル１０２に配置される。このマルチ式空調機器５０ａ，５０ｂ，５０ｃは、ビル１０１，１０２内の冷暖房や調湿などの空気調和機能を有する。マルチ式空調機器５０ａ，５０ｂ，５０ｃでは、図１に示されるように、１台または複数台の室外機２０ａ，２０ｂ，２０ｃに対してそれぞれ複数の室内機１０ａ，１０ｂ，１０ｃが冷媒配管（図示せず）および通信回線５５ａ，５５ｂ，５５ｃにより接続される。

＜空調機器管理システムの構成要素＞
図１に示されるように、空調機器管理システム１５０は、マルチ式空調機器５０ａ，５０ｂ，５０ｃに通信回線５４ａ，５４ｃによって接続された空調コントローラ６０ａ，６０ｃと、公衆通信回線１２０を介して空調コントローラ６０ａ，６０ｃに接続している中央管理装置８０を備える。

（１）空調コントローラ
空調コントローラ６０ａ，６０ｃは、図２に示されるように、マルチ式空調機５０ａ，５０ｂ，５０ｃの監視装置であって、主にＣＰＵ（Central Processing Unit）６１、ＲＡＭ（Random Access Memory）６４，ＲＯＭ（Read Only Memory）６５、ＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）６６、Ｉ／Ｏ（Input／output）制御部６７、モデム用インターフェース６９、空調機器用インターフェース７０、モデム７１、及び空調機器用コネクタ７２から構成されている。ここで、ＣＰＵ６１、ＲＡＭ６４、ＲＯＭ６５、ＥＥＰＲＯＭ６６、及びＩ／Ｏ制御部６７は、例えば、マイクロコンピュータであって、相互に第１バス線６８によって接続されており、１つの集積回路を構成している。また、モデム用インターフェース６９及び空調機器用インターフェース７０は、第２バス線７３ａ，７３ｂを介してＩ／Ｏ制御部６７に接続されている。モデム７１は、第１通信線７４を介してモデム用インターフェース６９に接続されている。空調機器用コネクタ７２は、第２通信線７５を介して空調機器用インターフェース７０に接続されている。

ＣＰＵ６１は、ＲＯＭ６５に記憶されている監視制御プログラムを読み込むとともにＥＥＰＲＯＭ６６に記述されている監視制御に関するデータを読み込み、読み込んだ監視制御プログラムに従って動作し、また、ＲＡＭ６４，ＲＯＭ６５、ＥＥＰＲＯＭ６６及びＩ／Ｏ制御部６７に指令を出す。ＣＰＵ６１は、自己が保持しているデータ以外に、ＲＡＭ６４、ＲＯＭ６５およびＥＥＰＲＯＭ６６から必要なデータを取得して演算処理を行う。また、このＣＰＵ６１は、演算処理の処理結果データを、ＲＡＭ６４やＥＥＰＲＯＭ６６に書き込むことができる。

ＲＡＭ６４は、ＣＰＵ６１の指示に従って各種データをＣＰＵ６１に供給し、ＣＰＵ６１から送信されるデータを一時的に記憶する。また、ＲＡＭ６４は、Ｉ／Ｏ制御部６７からデータを取得して一時的に記憶し、ＣＰＵ６１からの命令に応じて一時的に記憶しているデータをＩ／Ｏ制御部６７に送信する。

ＲＯＭ６５およびＥＥＰＲＯＭ６６は、監視プログラムや各種データを格納している。このＲＯＭ６５およびＥＥＰＲＯＭ６６は、ＣＰＵ６１の指示に従って監視プログラムや各種データをＣＰＵ６１に供給する。ＥＥＰＲＯＭ６６は、電気的に書換え可能であり、マルチ式空調機器５０ａ，５０ｂ，５０ｃの監視データなどを書換可能に記憶する。

Ｉ／Ｏ制御部６７は、モデム用インターフェース６９に着信するデータや、空調機器用インターフェース７０に送信されてくるデータ等をＣＰＵ６１やＲＡＭ６４等に対して出力する。また、Ｉ／Ｏ制御部６７は、ＥＥＰＲＯＭ６６やＲＡＭ６４に記憶されている各種データやＣＰＵ６１の制御信号などを中央管理装置８０やマルチ式空調機器５０ａ，５０ｂ，５０ｃに送信するためにモデム用インターフェース６９及び空調機器用インターフェース７０に出力する。

モデム用インターフェース６９及び空調機器用インターフェース７０は通信線７４，７５を介してモデム７１及び空調機器用コネクタ７２に接続されている。モデム用インターフェース６９は、モデム７１に着信するデータを受信し、受信したデータをＣＰＵ６１が処理可能な形式に変換する一方、Ｉ／Ｏ制御部６７からモデム７１に出力されるデータや制御信号などをモデム７１が処理可能な形式に変換する。空調機器用インターフェース７０は、マルチ式空調機器５０ａ，５０ｂ，５０ｃから送信されてくるデータ等を受信し、受信したデータ等をＣＰＵ６１が処理可能な形式に変換する一方、マルチ式空調機器５０ａ，５０ｂ，５０ｃに出力されるデータ等をマルチ式空調機器５０ａ，５０ｂ，５０ｃが処理可能な形式に変換する。

モデム７１は、ＥＥＰＲＯＭ６６に記憶されている発報データの送受信に関する情報に基づくＣＰＵ６１からの指令に基づいて、ＥＥＰＲＯＭ６６に格納されるマルチ式空調機器５０ａ，５０ｂ，５０ｃに関する各種データのうちの日報発報の発報データを、所定時間毎に公衆通信回線１２０を介して、中央管理装置８０に送信する。通常、空調コントローラ６０ａ、６０ｃ…は１日１回程度の頻度で日報発報のデータを送信するが、空調機器の種類や構成によって頻度やデータの内容や容量が異なる。また、日報発報のデータを送信する回数については、日報発報のデータの負荷の割合に応じて発報する回数を変えことがあるが、発報する回数の変え方については後述する。中央管理装置８０が管理する空調コントローラ６０ａ，６０ｃ…の数は数千に及ぶため、一日に受信する日報発報のデータの回数も膨大なものとなる。また、ＣＰＵ６１においてマルチ式空調機器５０ａ，５０ｂ，５０ｃに異常が発生したと判定された場合、ＣＰＵ６１の指示に従って異常識別コード、マルチ式空調機器５０ａ，５０ｂ，５０ｃの機種番号や機種名などのデータ、及びビル１０１，１０２を特定するための顧客識別データなどを即座に公衆通信回線１２０を介して中央管理装置８０にモデム７１が送信する。その外、試運転時に、空調コントローラ６０ａ，６０ｃ…から試運転に関するデータがモデム７１から送信される。空調機器用コネクタ７２には、マルチ式空調機器５０ａ，５０ｂ，５０ｃの室外機２０ａ，２０ｂ，２０ｃが接続される。

（２）中央管理装置
図３は、空調機器コントローラ６０ａ，６０ｃ…に公衆通信回線１２０を介して接続されている中央管理装置８０の構成を説明するためのブロック図である。

図３に示す中央管理装置８０は、ＤＮＳ（Domain Name Service）サーバ８１と、負荷分散装置８２と、４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄ、ウェブサーバ８４と、バッチ処理用サーバ８５と、データベースサーバ８６と、バックアップ用データベースサーバ８７と、ファクシミリサーバ８８と、メールサーバ８９を備える。ＤＮＳサーバ８１と、負荷分散装置８２と、４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄ、ウェブサーバ８４と、バッチ処理用サーバ８５と、データベースサーバ８６と、バックアップ用データベースサーバ８７と、ファクシミリサーバ８８と、メールサーバ８９は、ハブなどを用いて構築されるネットワークを介して相互に接続され、相互にデータや制御信号を伝送することができる。

ＤＮＳサーバ８１は、公衆通信回線１２０を介して送受信するデータのＩＰアドレスをホスト（ドメイン）名に、ホスト名をＩＰアドレスに変換する。それにより、中央管理装置８０は、多数の空調コントローラ６０ａ，６０ｃ…などを特定して、特定した空調コントローラ６０ａ，６０ｃ…などとの間でデータや制御信号の送受信を行う。負荷分散装置８２は、ＤＮＳサーバ８１で特定された空調コントローラ６０ａ，６０ｃ…等から送信されてくるデータを４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのいずれかに分配する。例えば、ＩＰアドレスの値やハッシュ値などを用いて、４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄにランダムに振り分ける。

４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、負荷分散装置８２から割り振られた発報データを記憶する。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、日報発報と異常発報の発報データの処理をマルチスレッドすなわち並列で進める。発報データの処理を進めるために、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、受信した発報データの処理をキューに登録する。そして、キューに登録された順序に従って、スレッドを実行する。ただし、負荷分散装置８２から日報発報の発報データを割り振られた発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが発報データの処理をするとは限らない。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのうち自己のキューに登録されている処理数が所定の数量を超える場合には、他の発報データ処理サーバのスレッドにて処理を実行する。このような処理先の変更については後程詳細に説明する。

４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで処理された発報データはデータベースサーバ８６に記憶される。また、ウェブサーバ８４は、発報データの解析結果などを表示するために用いられる。ただし、ウェブサーバ８４の構成は発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄと同じであるが、これらサーバの構成については後述する。

バッチ処理用サーバ８５は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの機能を全て含んでおり、１台の発報データ処理サーバとしても機能する。バッチ処理用サーバ８５は、通常は、データベースサーバ８６に記憶されている処理後の発報データを用いて、一日に一回、一時間単位のデータを一日単位のデータに変換して報告書用のデータを作成する。また、数ヶ月に１度や１年に１度の割合で発報データの処理を行う報告書作成のためのデータ処理を行う。報告書を作成する場合、バッチ処理用サーバ８５は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄと同じ機能を使って、発報データ処理サーバが行う日報発報の発報データの処理を行うこともある。

データベースサーバ８６は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが処理した発報データを記憶する。また、データベースサーバ８６は、記憶しているデータを、画面表示やバッチ処理のためにウェブサーバ８４やバッチ処理用サーバ８５に対して出力する。

バックアップ用データベースサーバ８７は、データのバックアップを行う。そして、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄでデータの消去を行うと、消去作業自体が負荷になるため、バックアップが必要でなくなったデータを、深夜に消去する作業もバックアップ用データベースサーバ８７が行っている。このバックアップ用データベースサーバ８７は、単にデータの保存等を行うものであり、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのようなデータ処理機能を有しない。

ファクシミリサーバ８８やメールサーバ８９は、異常発報のデータ処理において、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで行われた異常発報のデータ処理結果を受けて、ファクシミリの送信やメールの送信を行う。

（３）発報データ処理サーバ
図４は発報データ処理サーバ８３ａの構成の概要を示すブロック図である。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの構成は同じであることから、代表して発報データ処理サーバ８３ａの構成を説明する。

発報データ処理サーバ８３ａは、ＣＰＵ９１と、メインメモリ９２と、ハードディスク９３と、時計９５と、バス９５と、ポート９６とを備える。ＣＰＵ９１、メインメモリ９２、ハードディスク９３、時計９５及びポート９６は、バス９５により接続されており、データや制御信号がバス９５を通じて相互に伝送される。ハードディスク９３には、発報データを処理するためのプログラムが記憶されており、ＣＰＵ９１は、ハードディスク９３のプログラムに従ってメインメモリ９２にデータの書き込みや読み出しを行いながら処理を進める。また、ハードディスク９３には、データ処理の対象となる発報データが保存されており、ＣＰＵ９１は、データ処理のために、ディスク９３に保存されている発報データファイル９３ｄ（図５参照）を参照する。アプリケーションプログラムや発報データや発報データの処理結果のハードディスク９３への書き込みや読み出しは、ＣＰＵ９１の指令に従って行われる。発報データ処理サーバ８３ａの外部との間でデータやプログラムなどを入出力する場合には、ＣＰＵ９１の指令に従ってポート９６を通じて行われる。このポート９６は、例えばハブなどで構築されたネットワークによって、発報データ処理サーバ８３ｂ，８３ｃ，８３ｄや負荷分散装置８２やデータベースサーバ８６などに接続されている。

（４）ハードディスク
図５は、ハードディスク９３に記憶されているデータやプログラムなどの概念を示す図である。ハードディスク９３には、オペレーティングシステム９３ａと、デバイスドライバ９３ｂと、空調監視アプリケーション９３ｃと、発報データファイル９３ｄなどが記憶されている。

オペレーティングシステム９３ａやデバイスドライバ９３ｂにより、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄを動かすことができる。空調監視アプリケーション９３ｃは、空調コントローラ６０ａ，６０ｃなどから負荷分散装置８２を介して発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄに送信されてくるマルチ式空調機器５０ａ，５０ｂ，５０ｃの発報データを記憶したり処理したりするための方法が記述されているプログラムである。空調監視アプリケーション９３ｃには、処理時間判定アプリケーション９３ｅ、サーバ処理移動アプリケーション９３ｆおよび日報処理のキューイングリスト９３ｇが含まれている。処理時間判定アプリケーション９３ｅ、サーバ処理移動アプリケーション９３ｆおよび日報処理のキューイングリスト９３ｇについては後ほど説明する。

（５）負荷分散装置
図６は、負荷分散装置の構成の概念を示すブロック図である。負荷分散装置８２は、ネットワーク側送受信部８２ａと、処理部８２ｂと、サーバ側送受信部８２ｃと、記憶部８２ｄとを備えている。ネットワーク側送受信部８２ａは、空調コントローラ６０ａ，６０ｃなどから送信された発報データを受信するとともに、必要な応答を返信する。処理部８２ｂでは、送信されてきた発報データのＩＰアドレスを取得する。また、処理部８２ｂは、記憶部８２ｄに格納されているプログラムに従って、ＩＰアドレスの変換などを行い、発報データをサーバ側送受信部８２ｃに出力する。サーバ側送受信部８２ｃは、変換されたＩＰアドレスに従って、４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのいずれかを選択して、発報データを送信する。

処理部８２ｂは、ネットワーク側送受信部８２ａで受信した発報データのＩＰアドレスのハッシュ値を計算し、そのハッシュ値を使ってランダムに発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄに振り分けることにより負荷の分散を図っている。発報データが、図１に示すように公衆通信回線１２０を通して中央管理装置８０に与えられるため、発報データのＩＰアドレスはランダムに割り振られるからである。したがって、空調コントローラ６０ａ，６０ｃの発報データが発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの中の同じものにいつも送信されるとは限らない。

負荷分散装置８２は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄから空調コントローラ６０ａ，６０ｃのＥＥＰＲＯＭ６６に格納されている発報データの送受信に関する情報を書き換えるため、発報データの処理時間に関する情報をサーバ側送受信部８２ｃで受信して記憶部８２ｄに記憶する。そして、ネットワーク側送受信部８２ａから空調コントローラ６０ａ，６０ｃに返信する際に発報データの処理時間に関する情報を送信し、ＥＥＰＲＯＭ６６に記憶されているこの処理時間に関する情報を書き換える。発報データの処理時間に関する情報には、次回の発報時間に関する情報が含まれる。

＜空調機器管理システムの動作＞
（１）基本動作
まず、空調管理システム１５０の空調コントローラ６０ａ，６０ｃ…から発報データが送信される。発報データは、主に、日報発報、異常発報、及び試運転の発報データに分類される。この中で、負荷分散が必要になるのは主に日報発報の発報データであることから、日報発報に重点をおいて説明する。

例えば、空調コントローラ６０ａは、図１に示すマルチ式空調機器５０ａ，５０ｂから通信回線５５ａ，５５ｂを介して送られてくるデータを、図２の空調機器用コネクタ７２と空調機器用インターフェース７０を介して受信する。図２のＣＰＵ６１はＲＯＭ６５のプログラムに従って、受信したデータを１時間毎のデータに変換してＥＥＰＲＯＭ６６に格納する。

空調コントローラ６０ａは、ＲＯＭ６５やＥＥＰＲＯＭ６６に格納されているプログラムとデータに従って、１日に所定回数だけ所定時間に、ＥＥＰＲＯＭ６６に格納されている１時間毎のデータを日報発報の発報データに含めて、公衆通信回線１２０を介して中央管理装置８０に送信する。日報発報の発報データの量が少なければ、通常は一日に１回発報データを送れば充分であるが、データ処理に時間が掛かる大きな負荷の発報データの場合には、データ量を均一化するために分割する。そのために空調コントローラ６０ａが１日に送信する日報発報の発報データの送信回数の変更方法については後述する。なお、日報発報の発報データには、上述の１時間毎のデータに加え、送信先やその他のデータが含まれる。

一方、異常発報の場合、空調コントローラ６０ａは、ＥＥＰＲＯＭ６６に記憶されている異常発生前３０分間にわたる１分毎のデータを異常発報の発報データに含めて送信する。このとき、空調コントローラ６０ａは、ＲＯＭ６５やＥＥＰＲＯＭ６６に格納されているプログラムやデータに従って、公衆通信回線１２０を介して中央管理装置８０に送信する。

中央管理装置８０で受信した発報データは、日報発報も異常発報も同じように、ＤＮＳサーバ８１でＩＰアドレスが決められ、負荷分散装置８２の処理部８２ｂにおいて、４台の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのうちのいずれかに振り分けられる。一方、空調コントローラ６０ａへは、発報データの処理が終わらなくても、発報データの受信が終われば負荷分散装置８２から応答する。

発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで受信した発報データは、ポート９６やバス９５を介してハードディスク９３に記憶される。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄでは、ＣＰＵ９１の指令に従い、ハードディスク９３に格納されている空調監視アプリケーション９３ｃを用いて、日報発報の発報データと異常発報の発報データがマルチスレッドで並行して処理される。このとき、日報発報の発報データは、通常、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのうち受信されたもののスレッドで処理される。そのために、通常は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが受信した順に自己のキューに登録して、順次処理を行う。そして、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで処理されたデータは、データベースサーバ８６に格納される。

しかし、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのいずれかのキューに偏って多くの発報データが登録されている場合、受信した発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄではないものが処理を行う。また、処理の優先度が低い発報データ、つまり急いで処理をする必要のない発報データについては、処理の順序を遅らせ、あるいはバッチ処理用サーバ８５で処理を行う。これらの点に関しては後ほど説明する。

発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで処理されてデータベースサーバ８６に格納されているデータを用いて、異常処理の際に、ウェブサーバ８４が画面表示を行う。また、異常処理の際に、ファクシミリサーバ８８やメールサーバ８９からファクシミリや電子メールの送信が行われる。これらの処理も日報発報や異常発報とは異なるスレッドで並行して処理される。

発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄに記憶されている発報データは、一日に一回バックアップ用データベースサーバ８７を用いて例えば深夜に消去する。そのために、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは発報データのファイルをバックアップ用データベースサーバ８７に転送する。

（２）発報データの処理時間の均一化
日報発報の発報データは、図９を用いて説明したように、空調コントローラ６０ａ，６０ｃが管理するマルチ式空調機器５０ａ，５０ｂ，５０ｃの構成や種類によって、データの処理に必要な時間が異なる。そこで、処理時間の掛かる発報データを送ってくる空調コントローラ６０ａ，６０ｃに対しては、当該物件について発報回数を１増やし、発報時刻の再割り当てを実施する。

発報回数を増やす処理の流れを、図７のフローチャートにより説明する。発報回数を増やす処理の手順については、ハードディスク９３の処理時間判定アプリケーション９３ｅに記述されている。

発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄでは、日報発報の発報データについて、各発報データの処理に要した時間を、時計９４により測定している。ステップＳ１では、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのＣＰＵ９１が発報データの処理時間を入手する。そして、ＣＰＵ９１が発報データの処理時間が規定時間内か否かを判定する（ステップＳ２）。処理時間判定アプリケーション９３ｅに記述されている規定時間に基づいて判定し、規定時間内であれば発報回数を増やす処理をすることなく終了する。

ステップＳ２で、規定時間を超えていると判定された場合、ステップＳ３に進み、ＣＰＵ９１は、ハードディスク９３に格納されている発報データファイル９３ｄから、規定時間を超えていると判定された当該日報発報の発報時刻を入手する。次に、ＣＰＵ９１は、当該日報発報の発報回数を１増やし、ハードディスク９３の空調監視アプリケーション９３ｃに記述されている当該日報発報の発報回数に関するデータを書き換える（ステップＳ４）。

ＣＰＵ９１は、処理時間判定アプリケーション９３ｅにより、次回の発報時刻を基点として、増加させた発報回数から仮の発報時刻を求める（ステップＳ５）。次に、ステップＳ５で求めた仮の発報時刻から、ＣＰＵ９１は、１時間分の各分に対する登録されている発報回数を求め、１時間の平均回数を求める（ステップＳ６）。なお、割り当て時刻の最小単位は１分とする。

次に、ステップＳ７に進み、ＣＰＵ９１は、仮の発報時刻の登録されている発報回数がステップＳ６で求めた平均回数を上回っているか否かを判断する。平均回数を上回っている場合にはステップＳ８に移行して、ＣＰＵ９１が仮の発報時刻を１分早め、改めて計算し直すためにステップＳ５に進む。

ステップＳ７で平均回数を上回っていないと判断された場合は、ステップＳ９に進み、次の日報発報の際、割り当てた発報時刻を発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄから負荷分散装置８２を介して空調コントローラ６０ａに送る（ステップＳ９）。空調コントローラ６０ａでは、ＣＰＵ６１が、送られてきた発報時刻になるようＥＥＰＲＯＭ６６に記憶されている発報データの送受信に関する情報を書き換える。それにより、空調コントローラ６０ａは、次回の日報発報を新たな発報時刻に行うことができる。

（３）サーバ間でのデータ処理の移動
図８を用いて、発報データ処理サーバ８３ｂと発報データ処理サーバ８３ｄとの間でのデータ処理の移動について説明する。わかり易くするために、図８には、負荷分散装置８２と、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄと、データベースサーバ８６とを抜粋し、日報発報と異常発報の処理についての概念を示している。

図８において、発報データ処理サーバ８３ｂ，８３ｄには、日報発報の発報データファイル８３ｂ１，８３ｄ１と、日報発報処理用のキュー８３ｂ２，８３ｄ２と、日報発報処理用のスレッド８３ｂ３，８３ｄ３がある。また、発報データ処理サーバ８３ｂ，８３ｄには、異常発報の発報データファイル８３ｂ４，８３ｄ４と、異常発報処理用のキュー８３ｂ５，８３ｄ５と、異常発報処理用のスレッド８３ｂ６，８３ｄ６がある。図８では、発報データ処理サーバ８３ａ，８３ｃの発報データファイルとキューとスレッドの記載は省略している。

発報データファイル８３ｂ１，８３ｄ１，８３ｂ４，８３ｄ４は、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのハードディスク９３の発報データファイル９３ｄ（図５参照）に格納されている。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのハードディスク９３は、相互に共有化されており、例えば、発報データ処理サーバ８３ａのＣＰＵ９１が、発報データ処理サーバ８３ｂのハードディスク９３のデータを処理することができるようになっている。キュー８３ｂ２，８３ｄ２，８３ｂ５，８３ｄ５及びスレッド８３ｂ３，８３ｄ３，８３ｂ６，８３ｄ６は、発報データ処理サーバ８３ｂ，８３ｄのＣＰＵ９１が処理を実行するためのプロセスの概念である。キュー８３ｂ２，８３ｄ２，８３ｂ５，８３ｄ５に登録された発報データが、キューへの登録順に順次スレッド８３ｂ３，８３ｄ３，８３ｂ６，８３ｄ６で処理される。スレッド８３ｂ３，８３ｄ３，８３ｂ６，８３ｄ６で処理されたデータは、データベースサーバ８６に格納される。

図８は、発報データ処理サーバ８３ｂが混雑していて、発報データ処理サーバ８３ｄに余裕がある場合を示している。この状態で、新たに発報データ処理サーバ８３ｂに日報発報と異常発報の発報データが送られてきたものとする。発報データ処理サーバ８３ｂのＣＰＵ９１は、キュー８３ｂ２，８３ｂ５に登録されている発報データの数を取得する。そして、キュー８３ｂ２，８３ｂ５に登録されている発報データの数が規定値を超えていないかを判定する。この場合は、上述のように、発報回数をコントロールすることで、空調コントローラ６０ａ，６０ｃが１回に送信する発報データの処理負荷を均一化しているので、発報データの数が多ければ、処理負荷が大きくなっていると判定できる。

ここでは、発報データ処理サーバ８３ｂの日報発報処理用のキュー８３ｂ２の発報データの登録数が規定値を超えているので、発報データ処理サーバ８３ｂのＣＰＵ９１は、新しく受信した日報発報の発報データと異常発報の発報データを処理する他の発報データ処理サーバを探す。このとき、発報データ処理サーバ８３ａ，８３ｃ，８３ｄの中で、発報データ処理サーバ８３ｄのキュー８３ｄ２に登録されている発報データの数が最も少ないことを探知する。次に、発報データ処理サーバ８３ｂのＣＰＵ９１は、新たに受信した日報発報と異常発報の発報データを、発報データ処理サーバ８３ｄのキュー８３ｄ２，８３ｄ５に登録する。ところで、発報データ処理サーバ８３ｂにおいて、異常発報処理用のキュー８３ｂ５の発報データの登録数は規定値を超えていないが、一緒に発報データ処理サーバ８３ｄにデータ処理を移動している。これは、発報データ処理サーバ８３ｂで何らかの不具合が発生している可能性が高いため、処理を優先する異常発報を確実に処理するためである。

発報データ処理サーバ８３ｄは、キュー８３ｄ２，８３ｄ５に登録された順に、スレッド８３ｄ３，８３ｄ６で処理する。その際、発報データ処理サーバ８３ｂがキュー８３ｄ２，８３ｄ５に登録した発報データを処理するときは、発報データ処理サーバ８３ｂのハードディスク９３にアクセスして発報データファイル８３ｂ１，８３ｂ４の処理を行う。一方、発報データ処理サーバ８３ｂは、発報データ処理サーバ８３ｄのキュー８３ｄ２，８３ｄ５に登録したことを記録しているので、自己のハードディスク９１（発報データファイル８３ｂ１）に記憶していてもキュー８３ｄ２，８３ｄ５に登録した発報データの処理は行わない。

（４）発報データ処理サーバ以外での処理
ここまでは、日報発報のデータが負荷分散装置８２から各発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄに送信されてきた順に、キュー８３ｂ２，８３ｄ２，８３ｂ５，８３ｄ５に登録して、スレッド８３ｂ３，８３ｂ６，８３ｄ３，８３ｄ６においてキューの登録順に処理することについて説明した。しかし、日報発報の発報データは、顧客より要求されるサービスの内容によっては常時使用しない場合がある。

例えば、店舗の冷蔵庫内の温度を常時監視する場合や、需要家が時々刻々使用する電力量を監視して、デマンドが契約電力値を超えないように負荷設備を制御する場合などでは、発報データを逐次処理する必要がある。一方、単に空調の状況を監視するだけであって報告書を月単位で提出するような場合には、受信後直ぐに日報発報の発報データの処理を行う必要はない。

そのため、受信後直ぐに日報発報の発報データの処理を行う必要のないものは、直ぐにキュー８３ｂ２，８３ｂ５，８３ｄ２，８３ｄ５に登録しないようにする。そこで、日報発報のうち直ぐに処理しないもののリストテーブルをハードディスク９１に日報処理のキューイングリスト９３ｇとして記憶している。発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのＣＰＵ９１は、受信した日報発報の発報データを参照して、ハードディスク９３のキューイングリスト９３ｇの中に、直ぐに処理しないものとしてリストされているかどうかを判定する。

もし、直ぐに処理しないものに該当しなければ、キュー８３ｂ２，８３ｄ２に登録して処理を行う。一方、直ぐに処理しないものに該当する場合には、キュー８３ｂ２，８３ｄ２に登録しない。

直ぐに登録しない日報発報の発報データは、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのキュー８３ｂ２，８３ｄ２が所定数以下になったときに処理する。例えば、キュー８３ｂ２，８３ｄ２の登録数が２以下になった場合など、予め条件を設定しておく。それにより、直ぐに８３ｂ２，８３ｄ２に登録する必要のない発報データの順番を遅らせるように登録順序を入れ替えたのと同じこととなる。

もし、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの混雑が続いており、一定の期間内にキュー８３ｂ２，８３ｄ２に登録していないものの処理ができないときは、図３に示すバッチ処理用サーバ８５で処理する。そのために、定期的に発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの発報データファイル９３ｄをサーベイする。バッチ処理用サーバ８５は、報告書の作成などのバッチ処理用であるため、日報発報の発報データを処理することは可能である。しかし、キュー８３ｂ２，８３ｄ２に登録していないもの全てをバッチ処理用サーバ８５で処理すると、その処理能力を超えてしまうため却ってサーバの増設が必要になる。サーバの増設を避けるため、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄで処理できないときに限ってバッチ処理用サーバ８５で処理を行うよう構成している。

ところが、マルチ式空調機器５０ａ，５０ｂ，５０ｃの場合、異常があったときには、日報発報の発報データを必要とするイレギュラーな場合が発生する場合がある。その様な場合には、通常であれば発報データの処理を急ぐ必要のないものも直ちに処理しなくてはならなくなる。そのため、データベースサーバ８６に、直ちに処理する必要のない日報発報の発報データがあることを記憶させておく。また、画面表示のために、ウェブサーバ８４が発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのハードディスク９１にアクセスする必要があるため、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのハードディスク９１を、ウェブサーバ８４やバッチ処理用サーバ８５と共有できるように構成する。

＜特徴＞
（１）
処理時間の掛かるいわゆる処理負荷の重い発報データが送られてくると、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、ハードディスク９３の処理時間均一化アプリケーション９３ｅに基づいてＥＥＰＲＯＭ６６の発報データの送受信に関する情報を書き換えるため、次回の日報発報の発報データの発報時間を算出する。そして、次回の日報発報の発報データの発報時間を、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、負荷分散装置８２に対して出力する。負荷分散装置８２は、次回の日報発報の発報データの発報時間を、記憶部８２ｄに記憶する。負荷分散装置８２は、次にまた処理時間の掛かるいわゆる処理負荷の重い発報データを送ってきた空調コントローラ６０ａ，６０ｃに対して、発報データの送受信に関する情報を書き換えることにより、その空調コントローラ６０ａ，６０ｃが次に送信する発報データをまとめる所定時間を短くする。

空調コントローラ６０ａ，６０ｃが発信する発報データのうち処理負荷の重い発報データのデータ量を少なくすることができる。空調コントローラ６０ａ，６０ｃが発信する発報データのうち処理負荷の重い発報データの１回当たりのデータ量を減らすことができ、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが一回に処理する発報データの一つ当たりのデータ処理時間が短くなる。このような処理を繰り返すことで、処理負荷の思い発報データは徐々に少なくなり、負荷分散装置８２が振り分ける発報データの処理負荷が均一化されることから、それを割り振られた発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄにおける負荷の均一化が図られることとなる。

（２）
発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄは、相互にハードディスク９３を読み取り可能に構成されている。発報データの送受信に関する情報の書き換えによって発報データの処理時間の均一化が図られていることから、キュー８３ｂ２，８３ｂ５，８３ｄ２，８３ｄ５のデータ数が処理負荷と強い相関を持つものとなっている。例えば、発報データ処理サーバ８３ｂのキュー８３ｂ２に多数の発報データが入っている場合は、自己つまり発報データ処理サーバ８３ｂに負荷が偏っていると判断できる。このことから、発報データ処理サーバ８３ｂのハードディスク９３に記憶されている発報データを他の発報データ処理サーバ８３ｄのキュー８３ｄ２に登録して処理する。それにより、発報データ処理サーバ８３ｂ，８３ｄのキュー８３ｂ２，８３ｄ２に登録された発報データの数が均一化される。このように、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのキュー８３ｂ２，８３ｂ５，８３ｄ２，８３ｄ５に登録される発報データ数の均一化により、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの負荷を均一化することができる。

（３）
発報データの内容に応じて、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが発報データを待ち行列に入れる順番の入れ替えを行うことができる。それにより、内容によって発報データの処理を急がないものは待ち行列に入れる順番を遅らせる一方、処理を急ぐ発報データから順に待ち行列に入れることができる。処理を急がない発報データを発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの処理が集中しない時間帯に処理することができるようになり、発報データの処理の時間的な分散を図り、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの処理負荷を均一化することができる。

（４）
マルチ式空調機器５０ａ，５０ｂ，５０ｃに関するデータを所定時間分まとめて発報データとして空調コントローラ６０ａ，６０ｃが発信する。そこで、図７のステップＳ１およびＳ２に示すように、発報データの処理に時間の掛かるものを検出する。マルチ式空調機器５０ａ，５０ｂ，５０ｃに関するデータをまとめる所定時間が短くなるよう、ステップＳ３〜ステップ８を経て、次回発報する発報時刻を計算する。そして、次回は早く発報するように次回の発報時刻を空調コントローラ６０ａ，６０ｃに送信する。それにより、発報データの処理時間が長くなったものの所定時間を短くすることができる。つまり、図７に示すステップＳ１〜Ｓ９を繰り返すことにより、発報データを分割して送信回数をふやすこととなる。その結果、処理時間の掛かる重い発報データの一回あたりのデータ量を減らすことができるため、発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの負担を均一化することができる。

＜変形例＞
（Ａ）
先の実施形態に係る空調機器管理システム１５０では、マルチ式空調機器５０ａ，５０ｂ，５０ｃを管理対象としたが、本発明の管理対象は、マルチ式空調機器５０ａ，５９ｂ，５０ｃに限られない。監視対象は、例えば、セントラル式空調機器などの他形式の空調機器であってもよいし、照明機器、給湯機などの設備機器であっても良い。

（Ｂ）
先の実施形態に係る空調機器管理システム１５０は、ＤＮＳサーバ８１を１台用いた例を示したが、ＤＮＳサーバ８１は故障やセキュリティー対策のため複数台用いてもよい。

（Ｃ）
先の実施形態に係る空調機器管理システム１５０は、負荷分散装置８２が１台の場合について説明したが、負荷分散装置８２を複数台備えてもよい。

（Ｄ）
先の実施形態に係る空調機器管理システム１５０は、図８を用いて説明した日報発報処理用のキュー８３ｂ２に多数の発報データが登録されている場合、発報データ処理サーバ８３ｂが自己のキュー８３ｂ２の登録数を判断して、他の発報データ処理サーバ８３ｄのキューに登録する例を示したが、次のようにしてもよい。発報データ処理サーバ８３ａのキューの監視を発報データ処理サーバ８３ｂが行い、発報データ処理サーバ８３ｂのキューの監視を発報データ処理サーバ８３ｃが行い、発報データ処理サーバ８３ｃのキューの監視を発報データ処理サーバ８３ｄが行い、発報データ処理サーバ８３ｃのキューの監視を発報データ処理サーバ８３ｄが行う。そして、監視対象の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄのキューに規定を超える登録がある場合には、キューに登録の少ない発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄに指示して、キューの登録が少ない発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが自己のキューに監視対象の発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄの発報データを登録するようにしてもよい。つまり、いずれかの発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが監視して、キューの登録が多い場合には監視しているものがキューに登録しないサーバとキューに登録するサーバに指示を出せばよい。

（Ｅ）
先の実施形態に係る空調機器管理システム１５０は、図８を用いて説明した日報発報処理用のキュー８３ｂ２の監視は発報データ処理サーバ８３ａ，８３ｂ，８３ｃ，８３ｄが行う場合について説明したが、監視は負荷分散装置８２が行ってもよい。監視結果に基づいて、負荷分散装置８２がキューに登録しないサーバとキューに登録するサーバに指示を出せばよい。

本発明の一実施形態に係る空調機器管理システムの構成を示す図。 図１の空調機器管理システムの空調コントローラの構成を示すブロック図。 図１の空調機器管理システムの中央管理装置の構成を示すブロック図。 図３の中央管理装置の発報データ処理サーバの構成を示すブロック図。 図４の発報データ処理サーバのハードディスクの記憶内容を説明するための図。 図３の中央管理装置の負荷分散装置の構成を示すブロック図。 図３の中央管理装置の動作を示すフローチャート。 図３の中央管理装置の動作を説明するための図。 設備機器に特有の問題点を説明するための図。

符号の説明

５０ａ，５０ｂ，５０ｃ マルチ式空調機器（設備機器）
６０ａ，６０ｃ 空調コントローラ（監視装置）
６６ ＥＥＰＲＯＭ（第１記憶装置）
８２ 負荷分散装置
８３ａ，８３ｂ，８３ｃ，８３ｄ 発報データ処理サーバ（情報処理装置）
８３ａ，８３ｂ，８３ｃ，８３ｄ キュー（待ち行列）
９３ ハードディスク（第２記憶装置）
１２０ 公衆通信回線（通信回線）

Claims (6)

1. 複数の設備機器（５０ａ，５０ｂ，５０ｃ）を遠隔から管理する設備機器管理システム（１５０）であって、
   第１記憶装置（６６）を有し、接続されている前記設備機器に関するデータを、前記第１記憶装置に記憶されている第１情報に従って所定時間分まとめて発報データとして送信する複数の監視装置（６０ａ，６０ｃ）と、
   通信回線（１２０）を介して前記複数の監視装置の前記発報データを受信するとともに、前記通信回線を介して前記第１記憶装置の前記第１情報を書換可能に構成されている負荷分散装置（８２）と、
   前記負荷分散装置に接続され、第２記憶装置（９３）を有し、前記発報データを処理するために前記第２記憶装置に前記発報データを記憶するとともに、前記第１情報の書換えのために前記発報データの処理時間に関する第２情報を前記負荷分散装置に与える複数の情報処理装置（８３ａ，８３ｂ，８３ｃ，８３ｄ）と、
   を備える設備機器管理システム。
2. 前記複数の情報処理装置は、相互に前記第２記憶装置を読み取り可能に構成され、前記待ち行列（８３ｂ２，８３ｂ５，８３ｄ２，８３ｄ５）に登録されたデータ数に応じて、自己の前記第２記憶装置に記憶されている前記発報データを他者の前記待ち行列に登録して処理する、請求項１に記載の設備機器管理システム。
3. 前記複数の情報処理装置は、前記第２記憶装置に記憶している発報データを、前記発報データの内容に応じて順番を入れ替えて待ち行列に登録するよう構成されている、請求項１または請求項２に記載の設備機器管理システム。
4. 複数の設備機器（５０ａ，５０ｂ，５０ｃ）を遠隔から管理する設備機器管理方法であって、
   前記設備機器に関するデータを所定時間分まとめて発報データとして監視装置（６０ａ，６０ｃ）が発信する第１工程と、
   前記発報データを受信して、複数の情報処理装置（８３ａ，８３ｂ，８３ｃ，８３ｄ）に振り分けていずれかの前記情報処理装置の待ち行列に登録する第２工程と、
   前記発報データの前記情報処理装置での処理時間に応じて、次回送信すべき前記発報データについて、前記設備機器に関するデータをまとめる前記所定時間を前記監視装置に指示する第３工程と、
   を備える設備機器管理方法。
5. 前記第２工程は、複数の情報処理装置に一旦振り分けられた前記発報データを、前記待ち行列のデータ数のより少ない別の前記情報処理装置に再度振り分ける工程を含む、請求項４に記載の設備機器管理方法。
6. 前記第２工程は、
   前記情報処理装置に前記発報データを記憶する工程と、
   記憶している前記発報データを、前記発報データの内容に応じて順番を入れ替えて待ち行列に登録する工程と、
   を含む請求項４または請求項５に記載の設備機器管理方法。

Images